feneur

Have you tried changing the file-type to be .dae (just "rename" it to be exactly the same but with lowercase .dae instead of uppercase .DAE). I have a feeling I've heard that causing issues before, so it's definitely worth trying.

Sounds good to me Simple while still reasonably accurate.

Why? The second release will contain all the things from the first (only better ), so there should really not be any point in playing the first release once the second is out (There's of course always the risk that you will not like some of the changes in the second release, in which case you might want to keep playing the first. We'll probably make it possible to turn at least some of the features though, so generally there shouldn't be any reason at all to use the old release once the next is out ).

Seasons and units on walls have been cut from the first release of 0 A.D. They are complicated to implement, and at least seasons aren't adding as much to the gameplay as they cost in development time. Units on walls would take a lot of work to get good, so while it might be possible to implement a lesser version we'd rather wait and implement something that works great.

Ok, so let's break that down in smaller pieces I can understand (Food + Wood + 2*(Metal + Stone))/12 Ok, the first part (food, wood, metal, stone) I get and can see the value of, stone and metal are generally more rare (though since you can get any of the resources via trade the differences diminish). What I don't see is why it's divided by 12? I guess that depends on what the answer is to my next question though: "number of units" + 2 * "number of buildings" + "number of units killed" + 2 * "number of buildings destroyed" What do you mean by "number of ..."? Do you mean the actual "number of..." as in player x has Y number of units? I guess that's easier than to calculate a cost for each unit/building, but it does not really tell very much about the actual strength of a player as in this calculation 100 female citizens would be "worth" as much as 100 elephants, though the latter not only cost the player more but would also be more useful in a fight. 20 * "number of techs researched" Again, what's the significance of the number 20? And also, it might be useful in some ways to treat all the techs the same, but different techs are more or less worth compared to each other. On the other hand that might even out over the course of the game as early techs which might be cheap can be worth a lot in the long run etc, so I guess it's less of an issue for techs. Either way is fine with me, though having subtractive elements does keep the scores down =) Yep, most definitely I guess that was implied, but thanks for making it clear so there's no confusion about it

In AoK I think (though I could definitely be wrong) that the sounds were tied to the buildings. Iirc e.g. the sea sounds were played over the docks. Either way, would it be much harder to do sounds which can only be attached to either terrain or objects or which can be attached to both? If it's not much more difficult I'd say go for make it possible to attach ambient sounds to just about anything and we have the options to do whichever works best in the different cases Speaking about ambient sounds from a more general/sound engine point of view: it would probably be nice to have the engine automatically just play one (or at most at few) of the possible ambient sounds which can be played depending on the different emitters on screen. And at around maximum zoom just play a generic wind sound or something.

That sounds like it should be possible yeah The things which are important to remember imho when it comes to ambient sounds in whichever way they're implemented are 1) that their volume can be set independently of other sounds (and is relatively low in comparison to the other sounds by default) and 2) that they are implemented in such a way that they only play every now and then (possibly randomly, and perhaps in such a way that you can set an optional "silent time", or a "silent time range", i.e. that the sound isn't played for say 15-30 seconds or something).

I think our buildings generally look to random as it is. I.e. it is not always immediately clear from the silhouette/general layout that a building belongs to a specific category. As long as it's reasonably clear from e.g. props and how it looks compared to that civs other buildings I think it's fine though as it makes the civs different from each other (though at least some common elements between civs are of course making it easier for players to know which building is which and thus imho a good thing), but I really don't think having variations is a good thing. It depends on what you mean by variations though. It's one thing if you e.g. have different props (though of the same category) and perhaps say a chimney in one place in one and in another in another variation. It's a completely different thing if the entire layout of the building is different though for example.In either case, as long as we don't have one variation for each building for each civilization I don't think we should add more variations to one building (and again, props is one thing, and houses is also another thing since you don't need to interact with them very often + you have such a large number of them (+they're usually unique enough compared to other buildings that it's easy to tell them apart anyway)).

Is that with or without the new graphical effects enabled? Is it on all maps? Even with a small number of AIs? Even on a small map?

So, for starters, does anyone know exactly how the AoE series calculated its points? I think it was something like 1 point per 1 of each resource you had, and then the cost of a unit/building was removed from the total, but you got the double back when it was trained/built. Then when you killed/destroyed an enemy unit/building you got some percentage (50%?) of its cost as points(which was permanent unlike the points for resources/units/buildings). And I think you lost all the points a certain unit/building had contributed to when it was killed/destroyed. Do we want something like that or something different? Also, for in-game display, where do we want it? I would say the bottom right, top right could also be an alternative, but I think it's best to let the tech queue stay there

I can do it later since we might want to discuss how to calculate the points first. I'll move this topic to the technical discussions forum...

It should definitely be possible to add the total points (though we need to define exactly how to calculate them), and to make it possible to view the current stats in-game as in the Age of Empires games etc. We should probably add a small crown or wreath or something next to the winning players to make them stand out, even if/when total points are added as in for example team games a player might have less points than most other players, but still be on the winning team.

Hmm, maybe we could have "a generic other player unit selection sound" and "a generic other player building selection sound"? Not a big deal either way, but it just seems a bit weird if it would be "clink" I guess my main point is that I would want the unit/building sound to be different from the UI sound I do agree that it's probably a good idea to have some audio confirmation that you've selected something, even if it is your enemy's, and I think it's best to reserve the building-specific sound to player-owned buildings. And I think your chart makes sense. For ambient: what about have the global as an "automatic" ambient sound and then make it possible for scenario designers/map makers to place ambient emitter object in Atlas/RMS scripts? (If it's not too much work it could of course be nice to have some more general desert/ocean/forest/corrals/etc ambient sounds, but I think the priority should be: global-->placeable-->"automatic" )

0 A.D. was first created when multi-core processors were not common, so it only uses one CPU, and unfortunately it's hard to change that at this time.

Ok, maybe not. I was looking at the heroes in the civ profile and didn't see it there Seems like it is described as a special technology. Sorry for my confusion (I'd still say there will be no "conversion" in 0 A.D. as this is a bit different, but yeah, apparently I spoke without knowing what I was talking about )

If so it should be very, very quiet, otherwise it will get annoying quickly. Like the gate sound is now

There will not be conversion in 0 A.D. Previously we had something similar (you would have to pay a small price to be able to "convert" a unit) for some of the Roman heroes, but that has been cut, so no conversion at all in 0 A.D.

If you use SVN (see http://trac.wildfire...rtoiseSVN_Guide ) you can get them as soon as they are added to the game (+Any other improvement that is done in-between releases. And of course + the risk for bugs and instability that comes with using software that's in development. It's generally not much worse than the alpha releases though )

That would be a good start And since those features aren't very likely to change over time it's probably a good thing to do them in a video/videos of their own and then do individual videos on other more complicated features.

It is being written though: http://trac.wildfiregames.com/wiki/0adManual And that particular thing is mentioned on the Hotkeys page There are definitely a lot of things which still needs to be added though, so anyone with some knowledge on the game is welcome to help out adding information

Sweet Could be one way to do it. Personally I would favor techs that increase the amount of resources gained as it's clearer what's going on then. And if the cost is high enough (and if the big improvement is only available in the City Phase, there could definitely be a tech in the Town Phase that has a smaller increase as well) it still has that time effect to it.

Just left-click-and-drag or press the [ and ] keys while placing the building to rotate it

While this is not really having anything to do with this topic I'll just briefly mention that I disagree. To me it's better to have the limit being "natural". I.e. they don't gather as much resources in the same amount of time as e.g. farming or fishing does (which they shouldn't as the other forms of resource gathering should be faster and trade only something for the later game), but on the other hand you can build a large number of them. That in turn is limited by how much population space you have available for them (as is of course the total number of gatherers in general, but on the other hand you have citizen soldiers who can both gather and fight, something the traders can't). Also, since the traders need to cover a significant distance to get a significant amount of resources there is also a greater risk involved. But at the same time, unlike the other ways of gathering resources, trade "doesn't run out", which in my opinion is an argument not to increase the resources they gather. The exact numbers can of course be tweaked, but I don't think they are very far off in more general terms. Especially since you do gain more if you trade with an ally + there needs to be room for benefits from trade techs, so to me the number seems fine.

Not sure what you mean here? You can already select random maps (see http://trac.wildfiregames.com/wiki/Manual_SettingUpAGame#a1.ChangeMatchType if you aren't aware of it already), so there's no reason to add that functionality. Are you suggesting you'd add a way to "select randomly from one of the available maps"? (I think Spahbod is already working on something like that, or at least have thought about it, so if that is the case please talk with him first so there is no duplicate effort. See http://www.wildfiregames.com/forum/index.php?showtopic=16242 ) It's probably wiser to implement something that actually "is connected to something", perhaps something like http://trac.wildfiregames.com/ticket/942 ? The issue with that particular one is that it requires you to work with wxWidgets, so unless you have previous knowledge of that it might not be the best thing to start with. I'll try to have the programmer's pitch in and we'll see if they have better ideas

Ah, now that you remind me of that case it does make sense indeed Still not sure it's generally useful, but on the other hand, I'm not sure the alt+double click is generally useful either, and I've found that to have it's specific uses So better to have functionality that you'll rarely use than not to have it at all (At least as long as it doesn't complicate implementation unnecessarily, but I doubt this will )