feneur

Order queues already exists, and have for quite a while now. There are issues with groups and order queues though, but for individual units it works fine. As for the pre-orders, not sure about how easy it would be to implement just that, but at least for single-player gameplay it should be possible to make you able to give orders while the game is paused, which is more or less the same, except you don't need to remember some keyboard combinations other than the "Pause" button =) That doesn't apply to multiplayer though, so there something like what you suggest can definitely be relevant

The Helepolis cannot be garrisoned in something else, but it can hold other units garrisoned within itself.

Another thing to remember is that we intend to implement a special running/charging feature, which definitely makes the distinction necessary. Read more about that here: http://www.wildfiregames.com/0ad/page.php?p=10066

Indeed, there are other problems. My intention was more to issue a small warning that island maps/more than one AI should probably be avoided for now (Island maps can work in multiplayer, if you order the ships one by one and is ok with things being a bit awkward, but for singleplayer they're definitely not recommended at the moment.)

Island maps should not be considered implemented at this point, not only doesn't the AI understand naval combat/the concept of islands yet, but we need yet to implement special pathfinding for ships. In other words: we're aware of the issues and intend to fix them Also, more than one AI is probably not recommended at this point I'm afraid. At least not on larger maps.

There should be no need to locate the files. Atlas should automatically save them in the correct directory for the game to load them. However, by default maps are given the "hidden" keyword, which means that you need to change the map filter to "Show all maps" for them to show up in the game setup screen.

We're continuously working on adding new animations. Alpha 9 will see a lot of new ones, both for animals and other things. However, animating is a lot harder than creating the models, so unfortunately it will probably be a while before everything that we would like to have animated is animated.

The formation system currently just is implemented for walking (and not fully there either), so we definitely will do some more work on it before the game is finished.

As far as I understand that it sounds like a really good solution to at least part of the problems, nice work so far Philip

The main thing is that things are being done, the exact way doesn't matter that much. Since we do use Trac in general it's probably best to use it in this case as well, to make it easier to keep track on what's being worked on and not, and as you say there are some pre-existing already etc, so it's probably the least confusing in any case

Individual pieces are flat yeah, but as a whole several terraces aren't =) But that's not too important I'd say, the important thing is how it works in-game. I guess it depends a bit on what kind of building it is as well. For something bigger like a civic center flattening definitely seems like a better option (possibly with fairly strict limits for how big the terrain height difference can be to avoid the "square pit" scenario), and for smaller things like towers extended foundations/the model going slightly into the ground sounds like a better option.

You're not going to build on the side of a hill =) (Or actually if you do you're probably going to use terraces rather than demolishing the entire hill just to fit in your building ) Seriously though, I think that we shouldn't do full flattening even in the cases where you should be able to build, but more than a little flattening is needed. Mostly because it would look strange with well defined "pits" for the buildings and then the slope continues as before around it. But also since most buildings at least to some extent represent a multitude of individual buildings. But overall I do definitely agree that "full flattening" would be best, I just think there are cases when that would look worse than the alternatives. Preferably most maps should contain enough flat buildable areas for the problem to be minor.

Does those tasks have "proper" Trac tasks?

Having both extended foundations and flattening sounds like the best option to me, that way neither has to be too extreme

Ok, it might not work anymore/not work with random maps/perhaps I just don't remember correctly

Iirc there's something on Windows that hinders hotloading the way it is implemented now, as far as I've been told it works on e.g. Linux though :-/

I would assume that's a seed of its own. Especially since '0' often seems to equal "one" in programming (Maybe that's more in lists and the like, but anyways =) ) But Ben would know for sure

Aha Good that you've updated the manual now

Weren't you the one working on this? from: http://trac.wildfiregames.com/wiki/Atlas_Manual_Map_Tab Or did someone provide me with incorrect information? =)

Philip is only being paid after the work is done. After one week of work has been completed (regardless of whether the five work days that make up said week are in an actual week or spread out over a longer amount of time) the payment for that week of work is paid out. It would of course in many ways be great if the work would be done one day after another, but reality isn't always what one hopes for (especially since we're not a corporation who can fire Philip or anything). Partly it's Philip prioritizing other things over game development, perhaps he doesn't need the money enough or what do I know. Perhaps we should try and be more strict about it, but on the other hand what would be the alternative? At least currently no one else with anywhere near the same knowledge of the code has got the time to work on the game full time (regardless of how you define that), so if we'd "forbid" Philip then no full time work would be done at all for who knows how long time. Partly however it's also Philip finding that the latest part of his paid work, pathfinding, is taking more time to research, and think about, and plan, than he anticipated and he doesn't want to be paid for working full time when it's that kind of work which is hard to put a number of hours to. It is good that you care though, and I hope seeing your comments will encourage Philip to prioritize working on the game. As I said though, Philip is only getting paid after work has been done, so it's not like he's gotten money for a full month already and just hasn't done all the work yet. If against all odds Philip will not be able to work all the days we have gotten donations for we will find someone else of the programmers who are able to do the same, so even though in the worst case it might take some time the money will go to developing the game and nothing else. With the caveat mentioned on the Pledgie page: However, we should definitely update the Pledgie page to highlight the fact that the month of full time work means 20 days of eight hours of work each, and not necessarily a calendar month. We had originally hoped, and I'm sure Philip had as well, that it would more or less completely correspond to a calendar month which meant we didn't think it was necessary to mention. As things are we should definitely be more clear about it.

Hello and welcome Bogdan! Seems like you at the very least have a very good start on the programming, especially since a lot of the gameplay programming is done with javascript

You'll have to wait for the programmers to give you any direct answers to your questions, but just as a general information here is the link to the related page in the Trac wiki in case you haven't seen it already: http://trac.wildfiregames.com/wiki/Random_Map_Generator

Thanks Michael for working on this guide, and thanks everyone who's working on the random map scripts, really nice to see how we might actually be able to get to the number of maps originally envisioned

Aha That shows how much I know about these things =) Ah well, I'm grateful I don't have to know it all but have a lot of other people on the team to know all the details

Hmm, looking at the background and the small piece of the minimap you can see that looks like you are playing on an islands map? The AI cannot currently use island maps. I'm not sure whether that is the problem in this case as I'm not the AI programmer, but thought I should mention it in any case so you (and anyone else reading this) is aware of it for the future if nothing else. Also, it is easier to see the errors if we get them in a text format rather than from an image like that. To easiest do that you can To expand on Ben's possibly cryptic answer: we use Collada (.dae) files to create the models and animations, but then the game engine automatically converts the Collada files to a custom format. For release versions this is done while the release is being packaged, but if you're using the SVN version it is being done on-the-fly while running the game. In both cases the files are then cached, so the process only needs to be run once per model. (And something similar is done for the texture files, many are created as PNG files, but converted to .dds files either when first encountered in a map/Atlas if you use the SVN version, or when packaging for the release versions.)