sanderd17

This is an OS decision, we can't give packages for every distro. We do try to cooperate with distros, like 0 A.D. is on the latest version A14 in Debian testing (http://packages.debian.org/testing/games/). It's not in stable yet, but that's a rather logical choice of Debian, as 0 A.D. isn't stable. As you probably know, you can always try to install the debs from testing, or you can add the PPA for Ubuntu mentioned here: http://trac.wildfiregames.com/wiki/LatestReleaseLinux#Ubuntu

Some reconstructions of buildings (from the first settlements in the region to the Gallo-Roman period): http://www.archeosite.be/reconstitutions.php?lang=en I think the Gallic buildings in game are rather good.

Well, bridges would still be terrain-modifying. They'd just do it automatically instead of you having to manually adjust terrain. Walkable meshes are a lot more difficult, and require tight interaction with the pathfinder. And roads won't be postponed, but completely disabled. Jump Point Search, the pruning algorithm that is used in the new pathfinder (which is under construction) needs that travelling happens on a uniform grid (a grid where every movement is equally fast). We can have speed bonuses or puhishments for certain areas, but the pathfinder won't see those. So the pathfinder will never decide to follow a road, and doing it manually will just cause way too much micro. Things like "speed bonus on enemy terrain" can be made possible, as it doesn't matter if the pathfinder ignores those (normally you don't traverse a lot of terrains).

A coral shouldn't look too solid imo, so I prefer the first sketch.

OnUpdate is an engine function that's run every simulation turn (normally 4 times per second), it has nothing to do with updating the object.

Do you have your code somewhere (you can upload WIP patches to trac if you want)? It's probably something you're overlooking.

P2 starts when P1 is about finished. And P1 will only be finished when the performance problems are solved at first.

It's still rather up-to-date (those are big features, they aren't added that often). Some features are already partially implemented, but you'll notice when you click on the ticket numbers. It true it's not accurate though, as most of the work happens by volunteers, they choose what they want to do. That can be something on the list, or something else. And it's perfectly possible that the list won't be finished at the release of part 1, just because nobody wanted to do a certain task.

Forest regeneration isn't very easy to get right. You need to take different maps into account. Some forest maps have a lot of trees, and if you add forest regeneration there, it can block your paths (I don't think we want that). On the other hand, forest regeneration would probably be way too slow on desert maps to be noticeable. We can avoid the overlapping trees mentioned by LordGood, but the simulation engine doesn't really know about textures, and even if it did, it would be a lot of work to bind every texture to a class of trees it can grow, and also pass that info to f.e. the random map scripts.

The design document just includes what units, buildings and bonuses the civ has (based on historical information). There are examples of design documents on the wiki (http://trac.wildfiregames.com/wiki/Civ%3A_Ptolemies http://trac.wildfiregames.com/wiki/Civ%3A_Spartans ), but it's the content that matters, not the style.

I think "Achmenids", "Ptolemaics" "Mauryans" ... are good for small spaces, but when more space is available (like in the history section), I'd prefer "Ptolemaic Egyptians", "Mauryan Indians", "Achmenid Persians" ...

When you have resources, you also need a way to use it. What will cost x Wind f.e.? And they need to be separatable, like I guess "Water" is included in "Food". No need to have both when they'll always be used together. You know 0 A.D. is fully moddable, right? So every mod can add his own resources. But I don't think we need to overcomplicate the default game with more resources.

You can edit the hay prop, when you look at the actor definition, you see that the hay prop are the props/structures/iberians/farmstead_b_hay.xml and props/structures/iberians/farmstead_hay.xml actor files. You can either modify those hay meshes defined in those actor files directly (but that's not a good idea if they're used elsewhere), or you can copy and edit those hay meshes and actor files.

We had roads (at least the code was ready to have different move speeds for different terrain), but it causes too many problems with the pathfinder. When there are no roads, we can add jps pruning to the A* algorithm, and make the pathfinder a lot faster. As for bridges, when they are historical, I don't see a problem. I have some code ready for bridges, though it needs to be approved first.

I think a tiger can stand pretty well on his hind legs when fighting. So I think the entire fight, the tiger can be standing up. But I do wonder how you get it in that pose from idle.

From the main website: “0 A.D.” is a time period that never actually existed: In the usual calendar, one goes from 1 B.C. to 1 A.D. and skips zero. This reflects the historical fiction in the game: Who would have won if all the factions were pitted against each other when each of them was at its prime? http://play0ad.com/game-info/project-overview/ When it's used in in-game descriptions, it should be a reference to the game, not to a date.

I don't see a problem. Priests ask the gods to heal someone, and that person is healed.

A tile is 4x4 meters, so a 72m mountain on a 4km² surface is not very steep.

First of all, the contrast isn't completely up. The whitest part still in only about 90% white, the blackest part is only still about 10% white. Next to that, the resolution of the image is quite big. It only contains one mountain in the centre, so the map is stretched which makes the mountain less steep, but still as high. If you try reducing the resolution, it will generate a smaller map, but a steeper mountain. For such big maps, if you want them to be mountainous, you need to have multiple mountains.

The Ptolemaic door is rather small though I'm not sure about the door size. I'd need to see it in a different perspective, next to some other fortress probably.

I like the new one better, but aren't the doors a bit big? When compared to other fortresses, the cart doors are already big, and these seem to be bigger. And I agree with those banners on the roof. I think a weapon rack (available in the eyecandy models) could be used instead of one of the banners. Great work though.

Increasing the contrast will work. As black and white mean the top and bottom of your world (or the other way around). So if the contrast is maxed, the peaks will be very steep. If the picture is mostly grey, it will be rather flat. Some automatic texture importing could also be nice indeed. We could map every pixel of the image to a tile, and use the closest texture available in the special textures (that includes most basic colours). Later on, the map designer can replace those special textures with the grass or cliffs he wants. Painting cliffs would also be nice, but before you make a ticket, can you think about the best way to set it wrt UI? (note that some parts of this post are dreaming aloud, I don't have a lot of experience in the Atlas code, so I can't do most of it)

Itms, when such issues arise, don't hardcode the classes ("Female", "Unit" ...) but make them definable in the templates. Make general code where you can have an arbitrary number of alerts. with some global variable that defines the sounds and icons and stuff. The more you can generalise it, the better. So we can just test it, and it's easy to change when not approved. For now, I think I'd like 2 alerts, but that opinion could change. I'm curious how far you can generalise it

For gameplay changes, you should talk to the design team. Mainly Mythos_Ruler and alpha123 are currently active with balancing the stats etc. I suggest you contact those people on the #0ad-dev Quakenet IRC channel (IRC is easier to discuss than forums). As for PR, you should probably talk to Jeru. He isn't that active on IRC though. But once you have 5 posts here, you can PM him. Managing tournaments isn't really needed now, it's only good if their input can be used to make the game a bit better. The game isn't finished, so any player ranking or similar is rather arbitrary.

Please don't do that "50% f mais rápido" trick. They'll make it hard to track down the strings with issues. It's better to just leave them not translated. That way they're easier to find. And as leper said, you can download the po file, edit it offline, and upload it again. This avoids the % problem too, and you can give the correct translations.