feneur

Generally that should work as well, it just uses the OS method of doing it. On Windows at least it should take a screenshot and put it in the clipboard if you press "PrtScn" as it's known on my keyboard at least =) Then you'd of course have to paste it into e.g. Paint/Photoshop/Gimp/etc to actually use it, but it does grab a screenshot (I think there might be another shortcut to save screenshots to disk directly even just using the OS commands, but I haven't memorized it =) )

As Aviv hinted at, the main reason we don't publicize this more is because it's not as well defined as one could wish (especially with people leaving/joining =) ). I'd rather see it as this: Management: Me (Erik), Michael (aka Mythos_Ruler, for the artists), Aviv (aka Jeru, for PR in general), Kieran (aka k766, overseeing programming contributions, both in-team and from other contributors), Brian (aka bstempi, web dev lead) Art: Several official contributors and a few who contribute every now and then, but who don't want to join the team Programming: In theory Jan is dept head yeah, but due to having very little free time (and having moved to Singapore) he's more of an advisor at this point. Philip is definitely the lead programmer though. Apart from them there are a couple of official programmers and several who contribute in various ways as Aviv said. Music: See Aviv's post Web: Actually three Brian, Geek377, and gerbilOFdoom. Brian is the web dev lead, but Aviv oversees it as it's part of PR. PR: See Aviv's post (though he missed to mention that he's in charge, at least formally, with real life sometimes getting in the way it's not always feasible in practice + The History guys, though they're not as active anymore as they're not needed as much anymore. Another thing that makes it harder to keep a too strict hierarchy is that after a while the lines start to blur a bit Someone might have joined for one thing, but end up doing a bit of this and that in addition to the main task

Attack move is pretty likely to be implemented yeah.

I'm pretty sure he means ranged infantry units yeah Not sure how good Romans should be against ranged mounted units, the little history I know seems to indicate that's where they had there biggest weakness

Have been tired (remnants of a cold + lots of pollen in the air doesn't make things better =) ) and fairly busy the last couple of days, but now here's my reply True But it wouldn't be as versatile, it would just be a search and destroy thing =) But it's probably best to implement it as one in either case Hmm, this is probably the hardest part. We can't give the UnitAI too much power because that would lessen the role of the player (and it's probably hard to make sure it makes the correct choices in all cases), but on the other hand we should remove things which are just tedious micromanagement without any strategical value. It's hard to decide exactly where to draw the line imho. Yeah, attack-move interfering with stances (or stances interfering with it rather I guess =) ) doesn't sound too good

And also, the final implementation isn't decided until we've got something already in the game that we can test how it works in actual gameplay (Something that may sound great in theory might prove not to work at all in reality for example) So there's a limit to how much we can say when we can't be sure ourselves

Citizen Soldiers (representing the fact that some soldiers in the ancient times were both ordinary farmer/workers and soldiers) can already repair structures. Champion Units (representing professional soldiers who fought for a living and didn't work in any other way) on the other hand can't. While this might not be 100% historically correct, Roman soldiers were probably some of the best builders of ancient times, or at least some of the most efficient, it serves a gameplay purpose as it makes the different units have clearer roles. If all units can do everything there's no reason to choose the one over the other

Thanks, done

Should be fixed in revision 11698

http://www.wildfiregames.com/forum/index.php?showtopic=15797&view=findpost&p=236241 I'll add this to the Known issues topic even though it's not specifically an issue, enough people have suggested it to count as one anyway =)

Thanks for your concern. Formations do indeed require quite a lot of work before they're fully working. As it is a known issue I've added this to the "known issues" topic, and will close this as there are better places to discuss the actual implementation and we're already aware of the issue.

Take a look at your private messages here in the forums if you haven't already...

(Just realized I had missed "'t" in my reply above so it said "you can" rather than "you can't" which is what I meant It's fixed now though. =) )

1. To just make it attack I'd say look at the other towers, how they do it. To make it only attack when there are soldiers garrisoned you might have to do some programming though. 2. Palisades should/will be available in all phases by default. So no need to mod that.

Please be very sure there are no issues before including it. Unless it's extremely stable I would wait until after Alpha 10 is released, it is after all just over a week until the feature freeze, so while it sure would be nice to have sound on Mac as well I definitely don't think we should do anything that would lessen the experience on the other platforms. Even if everything works at least as well on Win/linux I'm still a bit wary about including something as significant this close to a release. Better to include it right after the release and make sure everything works well for Alpha 11 imho.

That seems like copyright infringement as far as I can tell (there's nothing on that page signifying that the uploader has acquired permission to post the document online), so it really shouldn't be linked to on these forums.

You currently can't, so that is why it's hard =) When running is implemented it will be done by right-double-clicking (as opposed to single right-clicking for walking), which should be easy enough

I'll leave it to the programmers to comment on the programming related stuff, but I'll say as a general comment that this sounds very promising Thanks for working on this!

Hmm, am getting tired again, so while I'm sure there are things I can comment on I'll leave that for tomorrow =) If I forget please add a reply so I don't miss this topic

the pop limit increase of a fortress - sure, could be added. I don't personally see much need for it as the change has already been done though + it's one of those things you quickly learn The amount of food a farm grants is shown (the right bar, hover over to see exact amount). Not sure what you mean by "attack bonus", it does say which units a unit is bonused against/which are bonused against it if you hover over the unit portrait with one selected (ok, it does say "counters/is countered by", but the meaning is the same). If that is what you mean

Something like that is planned indeed. One side to it is as an initial ceasefire period that can be set in the pre-game setup during which time no one can attack, or at least is punished for it, we'll have to see exactly how we implement it in the end. But most probably is either to make it impossible for units to enter enemy territory during this initial period, or have them lose health if they do, one of those two. Another is to include a ceasefire option among the diplomacy options, in other words, among the things you will be able to negotiate with your enemy about is to set a ceasefire period, during which you cannot attack each other. In this case it's probably more likely to incur some kind of punishment if broken though as it would be a nice feature to be able to set different kind of access permissions in diplomacy (i.e. so you could make an agreement with your enemy that your trade units can enter each others territories, etc).

New things should preferably add genuinely new things, this just seems to be a combined farm/palisade. Things which fills a combined purpose rarely is as good/useful as something that does something specific as it has to do both things, and preferably not too good as that would overpower them which would remove the reason for the features whose functionality they duplicate to exist. In other words: it sounds like something that "sounds cool, but actually doesn't add to the gameplay" imho

It would be possible, but then the GUI would be more crowded/or we'd have to remove other things. I'm sure there will be GUI mods though that might do something like this For the main version we're not very likely to change it though as unit stats aren't something you generally need to access quickly (apart from health/loyalty, but those you get easily displayed with the colored bars for a quick check and hover over for more detail).

Actually, personally I guess it's mostly the Stand ground stance I want to avoid having ranged units moving around too much/getting in harms way =) Michael probably has bigger expectations for them/greater motivation for them being there, so I'll let him comment on that. (I write a bit more later, but am too tired to combine the answer to this question with my point below Hope you still is able to read it all and see the arguments further down ) Hmm, we're talking about the same thing with different words It's the current behavior of the units moving together to shape a specific form that I meant with (as opposed to actually have some effect of them moving around next to each other apart from them looking nice and orderly) I guess I could have been clearer. In either case my point was exactly what you said above about the formations currently only being a visual thing Currently formations only "work" for movement (and the only way to move groups of units is to move them as a formation, which does make sense in many cases, but not when you want scattered units to get away from danger asap =) ). If we're able to implement formations in a useful way though the units will fight in/as a formation and not be scattered unless the formation breaks. We'll have to see exactly how formations end up being implemented, but one thing that has been suggested is for them to work like "if you put a group of units into formation they will essentially be as one big/wide unit, moving together, taking damage together, dealing damage together, and not break up unless either the user breaks up the formation or enough of them get killed that they're too few to be a formation so they get scattered as individual units".There is a "scatter" formation (might use another word, I'm too tired right now to check exactly what it is, might be loose ), which currently doesn't seem to do what you suggest (just move the units around a random distance apart from each other, but in all other regards work as an ordinary formation), but that could be changed to work like what you suggest, or something similar, where the units move together, but aren't set up in a predefined shape but rather just moving near each other to the same goal. Hmm, partly we're getting into a philosophical discussion here "What is a player order, and how do you define it in a way that includes all possible situations?" I do think there is a slight point to it though, so I'll continue. =) Well, at an abstract/higher level it was a player order to "search and destroy", but if you break it down into smaller move and attack orders the individual move/attack orders are automatic (you didn't order the unit to move from point A to point B, to point C, etc, you didn't order it to attack the enemy soldiers it encountered while it moved from point X to point Z, etc). If you just want the units to always move around and attack anything they come near (i.e. a search and destroy command), the definition really is pretty moot. However, if there isn't a pure search-and-destroy action, but rather a search and destroy effect from using an auto explore mode together with an aggressive stance there is some merit to make a distinction as it then is just that, automatic behavior defined by the stances you've set. (I'm not saying it's the best way to implement it, and you're probably right that at least from a user point of view it's easiest if there is a search and destroy command as you don't have to understand the different combinations but rather can just click a button and the units do the job for you. As it'd mostly be useful in late game for hunting down individual units it would be fine to implement it in this way, so my main point with the rest of this discussion is to discuss stances in general, not as part of a way to implement a search and destroy feature ) I guess you're right about not interacting with player given orders, not sure where I got move orders from I don't think it's possible to create a unit AI that can handle all situations good enough, mostly because it cannot know what your plans are. (And here comes some deeper/better arguments for stances as a whole than above ) You might be gathering up your troops for a big assault on your enemy, but a few scattered enemies come close. Now, what is the best way for your units to behave? If just judging from the perspective of these unit (which is all UnitAI is capable of, unless you hook up a proper AI to it, in which case you could just as well just watch two AIs fight ) it's probably best to all-out assault the enemies and destroy them completely, even if that means moving far away from the original point. In this case a defensive stance where they would attack the enemies if they get too close, but not move far away; a stand ground stance where only ranged units can attack unless the enemy walks right up to your units; or a passive stance where they don't do anything, probably would be best as they (depending on the exact stance) can defend themselves, but won't move away from the place you placed them. In another case you might be near your enemy, but don't want to provoke the enemy units to attack yet as you don't have enough units. The enemy units might be just out of sight of your units most of the time, but moving around gathering resources etc, and the enemy player hasn't paid any attention to your units yet (say you have units with greater LOS or he just hasn't looked at that part of the map for a while, either way once his units are attacked he will get a notification and will be aware your units are near). In this case it could be fatal to have your units attack the enemy units before you has had the chance to move more troops there to make a greater assault at a time, so you place your units in passive stance where they don't attack. A short while later your main force is near and you order the mass of ranged units to attack the unsuspecting enemy (a direct player order should of course override the passive stance and while the units attack you can change to e.g. aggressive, or defensive if you don't want your units to move too close to the towers the enemy has built closer towards the center of his camp, but not yet near his resource gatherers where you attack). Or you might be in the middle of a battle and want to have your ranged units keep attacking any enemy getting close enough too get within range, but not move closer (especially not past the protection of your melee units) and get killed by the enemy units, nor move further away and not be able to attack units that get closer, you put them in stand ground mode and they stay where you put them. Etc, etc. My point is that I seriously doubt that a completely automatic system would be able to handle all possible cases/human plans. Take for example the last situation, maybe it's possible to create a system that can take care of the ranged units well enough to do that, but you might want them to be more aggressive and attack the enemy at closer range even though it means an almost certain death of them. Perhaps because you want to fool the other player that you're a beginner or desperate, while in fact you're just making him focus his attention on this fight while you're moving in another, larger, force from another direction/in another place where he doesn't expect it. A stances system is a way to give the player more control over how his units behave rather than less (though it currently works in the opposite way as stances takes priority over player orders, something I don't think they should ), by making it possible for the player to tell how the units should behave when idle. Not sure exactly what you're asking for here Are you talking about what you mentioned in the first sentence here or something else? If so I don't think it should be a part of stances at all, but rather of a more basic priorities system, something like: "a direct player order takes highest priority, even if it would be more logical from other code to attack a nearby unit it would still attack another unit further away (it's a bit hard to decide what the units should do if you've given them a direct order to attack - or for non-siege later capture - a building, but units start to attack them, should they continue to focus on the building - direct player order - or respond to the enemies - direct threat?); next comes units attacking it; later nearby enemy units, later still enemy units further away but still within range/LOS. Apart from that there should be another priorities system so e.g. melee never attacks ranged units (unless by direct player order), cavalry prioritizes ranged infantry, ranged infantry prioritizes enemy melee infantry. And apart from that there should be the stances which should define e.g. whether the units follow enemy units far away or not, whether they stand still even while attacked etc. In other words, even if set to aggressive units should still attack an enemy unit they have a greater chance to defeat, the stances should just define e.g. how far they pursue them/whether they attack at all. (Phew, that was a lot of text, hope it all makes sense. I hope I haven't left any unfinished sentences/points somewhere, if so I blame them on being tired and ask that you'll require me to explain myself tomorrow )

I think auto explore/search and destroy should be continued after units auto attacked something due to an offensive stance. Yeah, but that's not a player order But rather an automatic order from the explore/search-and-destroy system My point was rather that player orders would not have to be taken into consideration for the auto explore/S&D system Something like this yeah =) But player influence is the issue here =) I do think it's nice to retain some of that though, but the final implementation of formations is likely to be a bit more like that. Right now formations is more like "these units move around kinda close to each other" and doesn't provide much benefit/effect of any sort. Either way I think at least part of the problem (apart from the absence of a priorities system - that would prioritize direct player orders over stance effects etc) is that melee infantry is too fast =) At least as far as I understand it, historically speaking melee infantry shouldn't really be able to even get close to moving ranged infantry (apart from the units which are both melee/ranged), but rather have enough armor to withstand quite a few ranged attacks, to hunt down ranged infantry cavalry should be used. I would say all player orders apart from move orders should completely ignore stances (even if they include moving to e.g. a building to garrison there). Maybe. Most of the time they should run to cover though, and melee units shouldn't be much use in fighting them in the first place. =) Perhaps a (minor/part of a) fix for the issues would be to make them less likely to turn to move again, i.e. run to max range, stay and attack until the enemy gets into min range, rinse and repeat It should not try to attack the archer So there we agree for sure That depends on how the groups/formations are implemented, currently they're explicitly tied to each other and a move order for a group of unit first means they have to form up into formation (and it would probably be a pain to have the formation system try to find out whether there are enemy units nearby and thus have the formation form up later). For most cases it should work fine though, so perhaps it would be wiser to add a "flee" command, where they would move directly to a safe spot? (Probably easiest to have the user set a spot rather than the game trying to find out where it's safe to go =) ) This should be fixed yeah It should be independent on unit behavior in terms of implementation, but either way, there's no reason it can't wait until unit behavior has been improved I'm trying to discuss the final behavior, not how things are now (And I'm probably confusing myself over all the replies so if something is unclear blame it on me and ask what I mean rather than assume I mean something weird )