sanderd17

Well, currently, the biome info isn't that important. It even never gets in the game (if you check the XMLs, you won't find any biome info). Only for soil textures, the biome is used as part of the name, just to make them easy to find (as there are so many different forest grounds). Maybe we should discuss adding that info at least to the XML, so when alternative query methods are added to Atlas, you can query for biome. Are you willing to add biome info to the XMLs? (it will be a lot of edit work). And then create a patch, so it can easily be applied. If you want to do that, I guess we'll first have to discuss what the best method will be, and then you can do it. Also, you could collect textures (as Micket said, photo's of the complete animal, from different angles, and preferably on a clean background). If you can collect those, I suggest you add them to the correct trac ticket. http://trac.wildfiregames.com/query?status=!closed&keywords=~Animal If they're on the trac ticket, they won't get lost in old forum posts. And remember, everything you contribute to the project should have an explicit free license.

Yeah, AI isn't really dynamical now. It's made for standard settings. So it starts by creating almost 100 femals. And if the population limit is 100, well then the AI has a problem Also, if the AI gets extra resources to start with, it won't upgrade to town or city phase a lot earlier than without those extra resources.

Now, if someone could implement triggers,

At alpha123, when you're doing competition, shouldn't you just take a map that has at least random as possible? Also no dangerous animals. If there is only a limited number of animals that can "attack" your food resources, you can surely find a map without bears. It could be fun for casual players I think.

This is a suggestion I hadn't heard before, and it looks interesting on first sight. Although, as there will be infinite farms, it will be a bit hard to make it realistic (you can't graze already collected food). So you would need to have animals stealing food. Like a bear hanging around your farmstead to take food. It would be nice for map designers anyway.

shift doesn't add to the group, but to the selection. If you select 5 swordsmen, and press shift+1, those 10 men in group 1 are added to that selection. But group 1 isn't changed. If you want to save that selection to group 1, you need to press ctrl+1 again. Maybe we should have ctrl+shift+# to add the selection to a group, I have no idea if this is implemented.

But pathfinder in Atlas should update the pathfinding based on the terrain. How can a map designer otherwise design cliffs and passable hills? Since it's the same code being used, that's rather difficult. Btw, I also think a 45° angle is a bit too steep to build on (see the screenshot, Enrique didn't believe it was buildable), maybe we could bring it to something lower? Bring the "building-land" class to a max slope of something like 0.5? For most maps, this won't change, but you won't be able anymore to build on the entrance way to an acropolis (which might even be a good thing, no player wants to build there, and if the AI builds there, it gets pathfinding problems). http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/data/pathfinder.xml

Great animals you make. You're getting yourself a fine animal database @Lion, the ox cart needs animation (and texturing). I believe Micket doesn't do those.

I think to couple unit preservation to the "morale" (which also needs to be implemented). When morale is low, the strength of your army will become low (easy to capture units, they fight less ...). The morale would be influenced by a lot of things (like the amount and the strength of surrounding units), but I would also like to get the dead/created ratio in the morale. Of course, balance is fragile.

Pheasants normally walk, but they fly when they flee for something (which makes them very easy to hunt on with a gun). It's hard to take a picture though, as they hide themselves very well before they flee. So you never have your camera ready. It would be nice if it would be a skittish animal, with a flying flee animation. But I think that'll be rather hard. So I have no problem with only walking pheasants.

a prop can be attached to the root (as most props currently in the data) or it can be attached to a 'bone' (as I've seen in the software). I don't know a lot about modelling, but I think that's a special point in the model. That could be used to let it float.

After a night of sleep, I decided I won't change the terrain elevation. That's just too dangerous for a newbie to the code base like me. The terrain has to be synced perfectly. And if I do it, I could cause additional OOS problems. I'll leave it for someone more qualified to do it. I'll instead look around for something else to do.

Depending on the desing yes, a piece or five. If the pieces are designed with care (with step-like features between them) I think it could work. Hiding the seam would indeed be the most difficult. It can be done with separate pieces of wood, or some buttresses. Gates would still be one piece I guess. That's a lot harder to change. But at least walls would follow terrain. Which is something Michael wanted (he mentioned that here somewhere). Well, but you can re-use props directly by just referencing to them. Use the same basket as a prop for a house, the mill, the civil center ... So a lot less duplicate meshes. I turned on the passability overlay, and the terrain I placed it on is still passable (and also constructable) but only barely. Sorry, that doesn't seem clear as the mill also marks those squares red. But they were originally green. Could cause some long iterations for big buildings though. But as you're art dept lead, I'll first check that.

@RedFox, I don't know if adjusting every group on the ground would be a good idea. It could give some strange results. @Enrique, Wow, I never discovered that about the elephant stables. Nicely done. But how would having multiple props with a single element be more difficult than a single prop with multiple elements? I also would like the decision to the artists if they want their prop to be floating, or if they want it to be fixed. So you wouldn't have to do that trick with the table (which is very well thought). Maybe it could be even extended to set floating in some range if you like. And how do you feel about the walls? Would it be a solution for those? Every wall would need some vertical thing (like the vertical woods in the celtic wall) to obscure the seam I guess. @zoot: stick out on one side, and be burried on the other side indeed. But I think flattening would be more dangerous to implement. If the terrain is almost impassable, and you flatten a part, an other part will become steeper and completely impassable. AI will have a nice time searching where to build the dropsite so the way to the dropsite doesn't become impassable. And some new players could be very surprised.

Currently, there are issues with buildings on non-flat terrain. One of the solutions would be to flatten it. But that won't be the nicest one. The main problem is, even if the model has deep foundations. There are still artefacts that shouldn't happen, such as floating props (see screenshots). So I would suggest to add a attribute to the "prop" element of an actor. I imagine something like floating="ground" or floating="water". in which case, the horizontal (X,Z) position would still be taken from the original model (just as the prop is currently bound to a point), but the vertical Y position would be the terrain height on that point. That way, you won't get those floating props (at least not if you have a separate prop for every object you add). But moreover, it could give an advantage to walls. If the wall pieces would just consist out of some small props (a few meters wide, or exactly one merlon wide), repeated with some variation. Then those wall props could float on the ground, and create a nice landscape following layout. It does seem possible (and quite simple) this far, but the render code is huge, so I haven't yet found where the prop placement happens. If someone could help me with that, it would be great. I also like to hear some input from designers. I even believe, once floating props are implemented, terrain flattening shouldn't even happen anymore. Everything could be fixed in the models.

It's a 7 year old suggestion. But still waiting for someone to implement it. http://trac.wildfiregames.com/ticket/35

you can kill your own sheep if you want. Gaia is more like "nobodies stuff".

Hmmm, we certainly won't bring graphics to the CPU. That would give you less than 1 frame per second. Some are even suggesting to bring the physics calculation to the GPU. But it's not so simple to do that. As not even all current GPUs have interfaces that can be used for common calculations. And excluding computers with GPUs that are still produced seems a bit too extreme for me.

Blackberry and Raspberry would be easy. You wouldn't even have to model (unless you want to). Changing the texture of the current berry model might be enough. Having food and wood on one thing isn't possible for now. It's not a problem with the engine, but in the GUI you can't choose which one you want. (And giving the player extra hotkeys to select between the sort of resource is no good I think. We're already short on available keys.) Bees nests would indeed be cool. And already possible. Also, don't forget flowers and weed. Just as eyecandy. And don't go too high poly. Certainly those small features (like those mushrooms) will need to be low poly.

2GHz processor is good enough. It only uses one core, so dual core doesn't change a thing (well, it uses 100%, so with dual core, the rest of the system still has the other core, which may relax it a bit). It's not GPU heavy (only the water rendering, but you can disable that in the settings). So it should work. 1GB of ram is quite low though. What does it mean? About 700MB left for 0AD? I don't know if that's enough. If you start swapping. You'll really get a lot of lag.

I would like to see some more trees (and other plants). Unit modelling is indeed harder, as you need to find good references. And I don't think the extra tiers are worth the extra modelling work. But that's my opinion. For each tree, you should have some variations (not every palm looks the same, if you add trees in Atlas, you'll see that they randomly vary). Some trees also have an autumn, winter or dead variation. Trees don't require that much modelling work though (the top consists out of a lot of cutting planes). But good textures really make the trees.

There's a suggestions for 0AD thread, which has a lot of these questions and answers. A lot of the same. And they're all noted ... somewhere. Some in the trac tickets, some in design documents. All public, but a bit hard to find for a newbie.

I'm out anyway, because my GPU isn't supported by OpenCL (and can't be supported).

If you are willing to make 2 extra models per unit. They should be distinct from the existing ones. Then I won't stop you.

Currently, the corral doesn't work as expected. It's meant so you can garrison domestic animals in it, which will generate food on a slow rate. But someone needs to implement that