feneur

It was added =) I think Ben did it last time. If you know the Unicode code for that specific letter the easiest way to make sure it's done is to create a ticket called something like "Add Unicode character ###" to Trac (This was the last time I believe: http://trac.wildfiregames.com/ticket/960 So it seems it was Philip who fixed it, but Ben who reported it.)

Yeah, and I remember when playing AoK that even if I had deforested the entire map etc, I rarely used even close to all those resources (as you may guess I enjoy playing defensively And basically wait until the AI was already defeated before attacking =) ). It might be fun for some people/in some cases if there is a gameplay mode with renewable resources, so I'm not against it completely, but I don't think it should be the default.

Just thought of another thing, it would be great if qbot would be able to barter, that way it could survive even if an enemy at that point is surrounding it and it has used used up all nearby wood, but there is plenty of stone and metal (and more long-term food, but if it hasn't resolved this particular issue by that time it probably has no chance). Not sure how much it would take to get it to do that though, and in general I'd say it's better to focus on expansion so it never finds itself in that situation. Just something to keep in mind. Once trade is in qbot should definitely use that though, I'd say that should be higher priority. Both because that actually produces resources (compared to barter which just converts them to get you out of a tricky situation etc) and because it would be great for interacting with other players in a non-combat way (and even if you're not allied with qbot trade routes would be either a nice target or at the very least they'd make the map more alive ).

Some of those should be fixed already, and we're hoping to have most fixed for Alpha 8 (a big reason why it might still be a while before it's out, we want to try our best to improve the performance, especially in cases like this).

Well, as you say our content is licensed under CC-BY-SA, so we can't, and won't restrict you from putting it up on your site. I'm having trouble seeing what we would gain from putting in any effort in getting the content onto the site ourselves though. Most of our content is created with the specific purpose of being in the game, and while other people could find some use/inspiration in our content I think it is to a lesser degree that we could benefit from other people's content. To some extent one of the reasons we're creating this game is for the sheer joy of creating, so using pre-existing models doesn't sound anywhere near as rewarding. Either way it is probably going to take some work to get the models to work properly for your site. We do not use the texture information in the Collada files themselves, but rather use XML files to tie models and textures together. Now, I'm not one of the artists, so I don't know all the aspects of what that means, but if nothing else the person uploading the files would have to make sure both the model and the texture is available in the same folder + update the path (and possibly other information) in the Collada file to link to the texture.

(But preferably with some more space between them =) Right now they squish together/overlap a bit too much But yeah, I think they should be completely outside any formations in that sense. Perhaps if you select them together they'd move along behind the formation, either spread out behind it or in a line behind it depending on what space there is.)

I'm also mostly a fan of the way AoE does things =) But with this I'm definitely starting to lean more towards doing things like this: units are created as individual units (and in terms of promotion etc always are), when doing economic tasks they stay as individual units, even if you've given them a group order (perhaps even give them some "spread out" unitAI to avoid all gathering from the same tree etc, and more importantly to avoid having to individually order them to gather from individual trees, to avoid issues with units gathering in places where you really don't want them they should probably just spread out within LOS of the spot you initially ordered them to gather from). When you want to move larger groups they get put into a column "formation", which is as thin as required depending on the obstacles and "snakes" around obstacles on the way. If they are attacked during the way they break out as individual units and respond (only if they are within LOS of the attack, if some units in the column aren't they just keep on walking, if they later come within LOS of the enemy - depending on stance and whether or not you're using attack move - they also respond to the attack). True formations should only be used on the battle field (i.e. big open spaces), and be a "battalion". Their movement would be restricted (slow, takes time to turn around), but they would be greatly bonused in other ways. I'm thinking they should still keep individual experience (they might have been part of another formation earlier etc), but should probably lose hitpoints evenly. Or perhaps the formation could be split in a couple of areas for damage purposes? That way the direction you attack the formation would matter, but it wouldn't matter exactly which unit was hit. In fact you'd only be able to attack the formation as a whole/per section rather than individually. If you want to get units back to economic purposes you'd turn off formations and perhaps also if you want to pursue fleeing enemy units (as most if not all formations should be slower than individual units moving around). It would be really nice if it is possible to have the units automatically go back and forth between "proper" formation and a column for movement. That way it would be more likely for players to actually use them, while allow the game to benefit from the good things of using a column for movement. Not sure whether that's reasonably easy to do though

Something like that is the plan yeah We don't necessarily make any difference between male and female animals, but the idea is that you will be able to corral domestic animals (chicken, goats, etc) and get a slow trickle of food. That would symbolize milk, but also eggs and killing off a few every year etc.

Ah, true. Was thinking about the Romans, but thought "Oh, but they have more or less two buildings already" =) But now that you said the above I'm reminded that (apart from generally most likely being used together) none are meant to be built "at home", so they'd not have something unique in their base. A Siege Workshop would be great

I also think something like what we have now is good. We need to remember not to make the game too difficult to understand for new players. If you think about it there are quite some different buildings, all civs has at least one special building, and the only civ that just has one so far is the Celts, and for them you get two different fortresses depending on which sub-faction you choose (I know it's not a new building in terms of function, but at least it adds some variation). I don't think we should add any more buildings at the moment at least. If we find in Beta that new players easily grasps the current buildings and that new buildings would enhance the gameplay, that's another thing.

Finally got around to adding the useful of the ones you mention, I've left out the G key as that seems less than useful in most cases. I think it's generally best to keep this document as short and basic as possible, at least until we have a proper manual system with several pages, and perhaps search etc, for now too much information and people will be unable to find the important stuff in all the text. For more info there's always the Wiki manual.

Yeah, I was reminded yesterday about that =) It's up to them what they do with the engine, but they have to obey the rules

The technology system isn't yet implemented, so at the moment it's not possible. I'm afraid you'll have to wait a while yet.

No, there's no communication between us and them. And no, they don't contribute to the engine in any way.

Oh Amish posted about it a while ago I think.

It's actually an old feature =) It's been planned for as long as I know to have the cavalry able to capture female citizens. (Having them carrying them to the home base would take too much work to implement I would guess, so the plan is to have them convert enemy female citizens which are within an area around your cavalry units, and don't have any enemy non-female units nearby.)

Yes, we are aware of it.

I played a bit on Oasis V against Jubot today, and every say ten seconds or so there was a slow-down. It seemed like it was caused by the AI being confused by there being two CCs (or at least because it tried to put units from both places in formations or something, or perhaps just that the central, most direct route between the two initial player one CCs is fairly narrow, with a lot of trees). That's probably a bit hard to work around (alternatively depend on other non-AI improvements). Another thing I noticed should hopefully be easier to do something about: the AI tried to build CCs right on the edge of my territories, where it was easy for me to destroy them (at least once I noticed what it was doing =) ). Perhaps you could put in a limit for how close to the enemy CCs/fortresses the new CCs should be built. At least the first ones shouldn't generally be too close as they are too vulnerable.

Well, I both agree and disagree =) The web site sure could be better, we've been aiming for a new site for quite some time, but web designers seems to be busy people so we haven't gotten very far so far. That has kept us away from doing much about the FAQ etc as it has seemed a bit pointless to do a lot of work on the old site. On the other hand, we've wanted to keep the news in general from going into too much detail about the development so people who just want the big news has a chance to do that. If you want to follow the development closer you can do that by following the forums, IndieDB ModDB profile, Facebook page. That's not to say we couldn't do more, but just that we shouldn't do too much as some people don't want to know everything before they play the game (and don't want to play the game until it's finished) and at least don't want to know much more than the releases. The exact balance is of course hard to find, so thanks for your suggestions. We'll think about them and see if we can do some of it. In general though: if you want to follow the development more closely the other places are more useful than the news on the main site (and will continue to be).

It is indeed intentional. One small extra thing that can give you benefits if you tend to it (i.e. make sure they leave their first resource at a dropoff site before starting to gather the next), but which doesn't punish you terribly if you aren't careful.

Looking forward to hearing your new recordings And I'm sure almost any microphone is better than a webcam microphone, so hopefully it should be more than good enough

I think I meant possibly trade, and the bounding box patch wasn't in then I believe, and perhaps the rally point marker line patch was on my mind as well So something like that. Great to see that update Philip, and a great write-up of the issues involved in reviewing patches. Perhaps something like that would be good to have written on the committing patches page in Trac? (After the process related stuff of course so people can find the most urgent things without having to read through a lot of text, but it would be nice to have something like this available there so people committing patches get a greater understanding of what's going on with their patches. And why it might take a while.)

TLA has indeed been indefinitely postponed. The people involved in the project simply were to busy with real life to keep working on it.

It's actually a feature, not a bug Or rather, not the long time, but rather the fact that the game converts all textures to .dds. This allows for artists/modders to use PNG files for maximum ease of use, but at the same time the game can use DDS which is more efficient. For release versions all textures are preconverted, but for SVN versions all new textures will have to be converted. It only does this the first time each texture is used though, so as you say the next time it should be the same as using a release version of the same map.

During the last month we've had the joy of welcoming four new team members here at Wildfire Games. First we had the chance to reward three of our most diligent Open Source contributors: Jonathan, Jeroen, and Yves, who all have worked hard programming for 0 A.D. and we thought it was time to recognize that. Jeroen (vts on the forums) has worked on fixing things, perhaps most notably making selecting units a lot easier (a more technical explanation: he's worked on making the bounding boxes correspond better to the actual models). He's also worked on adding rally point marker lines. In other words: the rally point you place to tell newly created (and ungarrisoned) units to go to a certain spot on the map can be a bit hard to find at times, but with this feature you get a line on the ground showing you the way to it. And also roughly the way the units will walk to get to it. It's probably easier to see how useful it can be from a screenshot though, so below you have one: Rally point marker line, the line going from the building to the rally point. Yves (Yves on the forums) has mostly been working on upgrading to premake4 and other compile related fixes (a less technical explanation: he's made it easier for people to build the game - the process of turning the code into an actual game that can then be played). Jonathan (quantumstate on the forums) has been (and still is) the leading force behind qbot, one of the AIs for 0 A.D. A video showing a match against one of the latest versions of qbot. Second, we've gotten a new artist on board: Enrique (Enrique on the forums), who has already created some marvelous Roman buildings which will help enhance the game world. New Roman temple (to the right, to the left is the Hellenic temple for reference).