WhiteTreePaladin

Probably not a bad idea - at least some precision should be set. Trees are an issue. Will probably take quite a bit of effort to fix that. (The pathfinder is being worked on.) The only "solution" for now is to chose maps that either don't have as many trees, or have trees in dense clumps so that the pathfinder doesn't get confused. (Should greatly help with performance too.) The door is fine, but the door opening has slanted walls, so it looks like it is a result of texture stretching. I'm not sure if this is intentional or not because the base of the tower also has slanted walls, but it does look a bit odd.

You obviously did some research on this, and it is possible that the section in question could be the result of two merged accounts. However, I don't feel the particular points you listed provide compelling support for that. We often follow a summary account with a more detailed account, so I think that's not necessarily that odd in itself. I'm especially not surprised that some in Medieval times had unusual alternate explanations for things. (Actually, that's still common today.) Because the emphasis is on "clean" animals which is such a big topic in other passages, this most certainly meant both, not one or the other. If these were the result of two merged accounts, then one account would not preserve most animals (unclean) from the flooding. Also, it later states (Gen 8:20) that there were animal sacrifices made right after the flood, so there had to be some additional (clean) animals available for that purpose (or they would be killing off the last two of a particular animal). It mentions forty days of active flooding (ark was lifted up) and 150 days of water retention. I guess the 150 days is supposed to include the flooding and receding. The idea seems consistent enough with one account. It's implied that the raven never returned, so instead a dove was sent weekly until the dove returned with a branch indicating land was found. The last time the dove was sent it didn't return either. The three times is probably supposed to be symbolic. The raven vs. dove was probably included to provide a comparison (like goat vs. sheep, etc.) [Edit] fixed grammar

1. You only get loot when an enemy unit / structure is destroyed. 2. When a structure has been weakened to a certain threshold, all units inside will automatically be ungarrisoned. More units inside of a building make it more difficult to capture, so if you want to capture a strong building (like a fortress), it is best to weaken the structure to force the automatic ungarrisoning. You can then attempt to capture it. Holding the CTRL key down while right clicking to attack will change the cursor to the attack cursor and let you choose to attack and weaken it first. 3. I believe the bonus (3x, etc.) only applies to attack. 4. There may be basic units that appear to be shared, but each civilisation's citizen soldiers can differ in more then just name and appearance. Not sure about the 1v1. 5. The Espionage tech is somewhat unintuitive the first time you use it. It is based on enemy traders. If the enemy has no traders, then the technology cannot be used. You pay an amount and get the vision range of a random enemy trader for a limited time. 6. I think formations are position based only at the current time. I don't think they provide any additional bonus. 7. The rate in the actual template files are what the game uses. I'm not sure if those values in the history section are reading those values directly or if they were copied manually and haven't been updated. The Gauls do have a unique structure that increases farm gather rate. 8. That info is probably read directly from the unit's template file. Each rank has a different template. The modifiers from technologies are not reflected in the unit's base stats. Perhaps that should be updated to reflect that though. 9. Yes. Select a market and in the center panel where the icon portrait is you will see several small buttons at the bottom. Click the rightmost one which has an icon with three ancient coins. You will see a dialog where you can set the current rates for each resource. 10. It might be, I'm not sure. There are some variants of structures for scenario design purposes. 11. I'm guessing your territory only, but would need to verify. Like the blacksmith upgrades, I'm guessing that all stat modifiers won't be shown because those values are read directly from the units base stats. [Edit] Looks like you got some answers already [Edit 2] 12. - 14. I'm not familiar with the lobby. 15. Which units are allowed to garrison varies per building. For example, the Fortress allows Support, Infantry, Cavalry, Siege, while the Civil Center only allows Support, Infantry, Cavalry. I'm not sure which classes are used to generate arrow fire or exactly how the rates are affected. @stanislas69 do you know about the lobby questions or garrison fire rates?

It's a bit wasteful though. I think what we have is better because I prefer the larger viewing area, but we do lose out on the corners. That could probably be fixed in C++, but I don't know how hard that would be.

@stanislas69 The potential issue I see with starting a mod through an ingame option option, is that if someone is playing without internet access, then that feature wouldn't work if it couldn't be downloaded. We could include the mod in the main download, but at that point it kind of seems like it should just be built in directly.

Most of the talk about an "extra realistic" mode has involved treating it as an addon feature. It would require a separate download, so it shouldn't be an issue. As has been mentioned, the blood toggle has been requested before. (It's something I would like myself.) I think the consensus was that was a worthwhile feature, but we just needed someone to implement it. It's a bit tricky because it will involve changing how some of the art files work. Corrals are in the game, but they currently only provide a way to create animals. We do want to allow bonuses from leaving live animals garrisoned there (perhaps a food resource trickle), but it just hasn't been implemented.

A form of that is wanted for the Iberians (ability to hide in woods), but I don't believe there is any code support so far.

With transparent corners, you do lose the four buttons around the minimap (idle villagers, etc.)

We actually did try placing the minimap at the top right (and other places). It looked alright and didn't really get in the way of the selection rectangle (at least for right-handed users, it might be an issue for left-handed users though). However, it did obstruct the view. The bottom center panel we have now somewhat resembles an airplane cockpit with gauges which allows for a more open field of view. Not saying it's the best option, but it's surprisingly hard to get a consensus on a GUI layout. I wasn't thrilled with the bottom center panel at the time (preferred it on the left), but I've gotten used to it.

We tried demos of many options in the past when we were designing the current GUI. Honestly, bottom left for the minimap tends to work best. Our current layout isn't in the actual left corner, but it's close and works well.

The current GUI has empty space on the left and right (assuming a wider resolution than 1024x768), so it works left-handed or right-handed.

@Shiyn Very interesting design! Kind of looks like a boat. It leaves the lower right corner empty which makes it easier to make extra large selection rectangles (at least for right-handed users). There is a lot to like about that GUI. They only had one resource to display though. Also, battalions / squads weren't displayed (but there was room). Actually, I think it works better on the left for right-handed people. When making a large selection, a right-handed person will normally start at the top left and drag to lower right. If there is a large piece of the GUI there, then they would have to stop before they reached the GUI which makes for a smaller selection rectangle. You could allow dragging / release on top of the GUI, but that's not something most players would intuitively do. This only applies to large selections; smaller selections don't need the extra space.

There is a point where cards that don't support more recent standards won't have enough power to run the game well anyway. I don't know what that level is, but I somewhat doubt we need to support less than OpenGL 3. OpenGL 4 would be debatable, but 8 years is a still a long time.

That would be awesome!

Does it just need more work and will be included later?

Better Collada exporter stability between releases would be great. More exposure for 0 A.D. in the Blender community might someday result in a better Collada exporter.

Exactly. I was thinking of around 5-10 units like BFME, but they could be larger. That's true to a degree, although I found the "battalions" (5-10 units usually) to be very easy to manage in the BFME series.

I think the reason unit ranking works well with battalions is because the units in battalions regenerate (albeit slowly) which allows steady progress to be made when gradually levelling during battles. The current promotion system has individual units which die too easily. This makes it too difficult to retreat and salvage your veteran troops. You end up with a mix of low and high ranks that just tend to cycle rather than gradually increase in strength; the net effect of a few higher ranked units mixed in is negligible. "Champion" units are always preferred and resources are the only limiting factor. It is orders of magnitude more effective to work on resource management and train champion units, than it is to micromanage unit training to create an army of elite (veteran) troops. These "elite" troops also happen to be weaker than champion units which makes the situation worse. As you mentioned, in other games individual unit ranking is reserved for very strong, unique units like true elite warriors and heroes. I just feel that it isn't really working well currently which is sad because there is likely a lot of potential. It doesn't break anything and the game is still enjoyable, so it's mostly just been left alone.

That sounds more like AoK. Not that that's a bad thing. AoK has a lot of good things. Many seem against small battalions, so AoK continues to remain the most closely related game. I don't find unit promotion useful at all from a gameplay perspective the way it is currently implemented. I do hope it could be kept, but it will need some adjustments. As it is, promotion doesn't really hurt anything, but it's almost completely useless. Ranking up by a technology (like AoK) affects gameplay more directly by giving the player more control of when and what to upgrade, and is also easier to balance. (Viable promotion would be difficult to balance. It currently doesn't affect the balance, but that's because it doesn't really affect the gameplay either.) It would be possible to have class upgrades and use promotion for other effects rather than remove entirely. Promotion could also be a way to access classes early for a limited group of your units before you research a class upgrade tech. Once you researched it, all the other units you have at that rank would "catch up" to the new class/rank.

I guess I'm thinking more middle age feudal timeframes then. Hmm, then a lot of our champion units don't make sense for some civs. Perhaps we should remove most champions and make that an elective (manual) upgrade for an elite citizen soldier. Loosing champions in battle would be a much bigger deal as they couldn't quickly be replaced making a full champion army rather valuable. (You could speed up the process with barracks garrisoning training.) I think champion is a poor name for them currently. It's better than the old "super" units, but still not good. They are supposed to represent professionals - royals guards and seasoned warriors (but not mercenaries). I don't think the current way we obtain them makes sense, at least not for all of them. I miss the unit class upgrades in AoK (again medieval timeframe). I guess I find the promotion system incomplete. It's not a large enough boost to make ranks worthwhile (especially when champions exist). I wish unit ranking were more useful. Maybe it would be better to remove it entirely as I don't feel it really adds much currently. Perhaps there's a way to make it more relevant and central to gameplay? As you mentioned, the citizens would return for future battles. Surely those with experience would have a dramatic advantage. Perhaps there's some other way to handle it. Just thinking.

I think the original idea of citizen soldiers was to provide for defense only. If you got attacked, you could arm all of you citizen work force and try to survive. If a citizen proved an able fighter, you would conscript that person and they would take on the new employment. Generally, soldiers and laborers were separate historically. Soldiers could be put to work constructing things, but I cannot imagine a country that would send talented soldiers to farms between battles. Military training was important. In 0AD, citizen solders were meant to transition over to military duties if they proved exceptional. This is represented by the increase in power and corresponding decrease in gathering efficiency. I believe all of these have been suggested before, but here are some ideas: Garrisoning citizen soldiers in barracks could auto-level them after a certain time. They would gain rank, but you would not be able to use them to gather or build during that time. This represents military training. Low level citizen soldiers could be made much weaker. (This would lower their offense potential, but still allow them to be used for defense.) Veteran citizens would have much worse gathering rates than they do now. I would preserve veteran construction rates because that makes sense for military units.

Yeah, they weren't really meant to be a threat in AoK. We would get the added utility of hunting which was only available for villagers in AoK.

I do think scout cavalry (with a food only cost like AoK) would be a nice addition.

Either the Athenians or Macedonians would get it most likely.

Unless it is a very large amount, it's probably worth adding the extra polygons for the player color.