sanderd17

Only the Romans speak Latin now. The rest all speak Greek (due to lack of people who are able to make voice recordings). Some of the civs also have very few references on how their language was spoken.

It looks like you have some mixed installation. One file mentions 0.0.19 as engine version (which is alpha 19), while another file mentions you use arena 20 as lobby. So you should try to find that old version, and remove it (and perhaps also reinstall the new version). Didn't you get some warnings when installing? Edit: oh no, most likely the old number just means it's an old log, and the game crashes before being able to write the log. But for certainty, can you tell us what date the files were last touched?

Better ask someone like leper or perhaps Philip first. They should have a better idea of what the xmb file are, and if those file can work without xml.

Sorry, don't know the details of XMB either. Up until this thread, I didn't even realise we cached the XML files for the release (I knew about the meshes and the textures, but not about the xml files).

Reducing the number of templates won't be the case I guess. How can you build {civ}_house.xml when there's no such file? It could reduce the content of the templates though, but for that, the actor files need to be structured better (get rid of the hellenes and the celts, rename the full names to the short versions, ...)

They're not always rectangular. Their actual definition is a circle, but at some places in the code, it's approximated by an axis-aligned square to speed up computation.

There's no reason to append this request to a post from 2013, so I split this off to its own topic.

@fabio, the amount of natural resources also changes with the natural resources you need, and how you can extract them. Like Norway currently has a lot of natural resource: a lot of oil and gas in their seas. But given that oil and gas weren't important then. And there was no way to build an oil-drilling platform in the middle of a sea, they didn't have a lot of resources back then. The converse is probably true for Italy, where there were a lot of small, superficial mining places. Very easy to do surface mining and extract the metals and stones from it, but by now already depleted or too small to be commercially interesting. Belgium is a bit in an intermediate situation, there are no mines that are very easy to access, but we had some coal mines that weren't too deep, so it gave Belgium a good start during the industrial revolution. But most of the mines are depleted by now, and the places that still have coal are too small to be actually viable.

The size of siege engines is determined by their clearance in the pathfinder.xml. Sieges fall under the "large" category. So if you want, you can experiment a bit with the value and propose a better value. You can also open the "obstruction overlay" in the dev console to get a visual clue of how big the obstruction is.

@LordGood, the horses were also smaller back then (some were around big pony height ... maybe we should just use your ponies after all ). But then again,men were also smaller ...

There are some nice ideas here, but also some that need improvement. At a start of a campaign, an emperor should get some time to arrange his army, before the attacks can start. When an attacker picks a target, the attacker and defender at that target should be fixed until the game is played. You can't require people to be online always. So there should be some rule that both players at least have to be f.e. 1 hour online per 2 days. And that a game can only be refused a few times. If one of the players doesn't come online, or refuses too much, the game should be against an AI. It would need some server to keep track of all this. So it's not that easy to implement. Maybe it's easier to start with a singleplayer campaign, and then extend the maps to multiplayer.

Our game is very moddable, and if you are able to make the correct artwork, it's quite easy to add a civilisation in a mod, and even play against default civs. Examples of such mods are: Rise of the east (adds the Chinese faction for now) Millennium AD (adds medieval civs, like Germanics and Vikings) Ponies Ascendant (adds ponies) Aristeia (adds bronze-age civs) ... Note that not all these mods may work on the latest version of the game. As the base game changes, mods need to be updated to stay compatible with the base game. And neither the official team, nor the modders have enough people to keep up with all the requests. That said, the official game will probably stick to these 12 civs for our first part (a part 2 is planned for the main civs between 1 A.D. and 500 A.D.).

You can define as many rectangular obstructions as you want. It doesn't have to be named left, right or center, that's only a requirement for gates (where the center one is enabled and disabled to open and close the gate). So in theory, you can make quite complex obstructions (f.e. on a market, give every stall its own obstruction, and let units walk through it). But in practice, this may be a lot of work. Note that a more complex obstruction will also give a bit more work to the pathfinder. But if these are only used on buildings that don't appear so often (and not f.e. on trees), this shouldn't make a big difference. A few days ago, I also wanted to make circular obstructions possible (f.e. usable on the Briton CC or for Stonehenge). It worked great for building placement, and for the long range pathfinder, but the short range pathfinder doesn't seem to like that yet.

Translator names are automatically extracted from the transifex interface and are included in the in-game credits.

It depends a lot on the system you're on. On my system (with quite slow intel graphics), 3D rendering causes the main slowdown in the start of the game. In the later game, there are more units around, so the simulation part (pathfinding, attack-damage calculations, target selection, ...) causes more slowdown, while the graphics stays pretty much constant (depends on the number of tris in your view, but not a lot more). You can easily see the impact of different components when you enable the profiler (F11). Another advantage of splitting off the rendering would be that we could have more fancy graphics, without causing extra lag as it can be calculated together with the simulation.

Horses were domesticated for riding and driving at least around 3500 BC. So it would seem strange to me that in all those years between the domestication of the horse and our timeframe, nobody had discovered the benefits of a trot. https://en.wikipedia.org/wiki/Domestication_of_the_horse Btw, the article also has some nice info on the size of the horses used in warfare too, they were a bit smaller than the current horses, but then again, men were smaller too. So I guess it evens out.

@cRaZy-biScuiT, the theads are indeed only used to have some non-blocking IO AFAIK. Not to speed up the calculations. The biggest problem we have with multi-threading is that the simulation must be deterministic. All players on a networked game must have the same state after the same commands. So these heavy calculations like the pathfinder will be pretty hard to parallelize, as paths can depend on each other. What would be possible is to split off other parts. Like the 3D renderer and the GUI renderer are mostly independent from the simulation. And the AIs could also be calculated in a simultaneous thread, as long as they're synced again each turn.

mod.json should be a file, not a directory. Take a look to an existing mod to see how the structure looks inside a mod: https://github.com/0ADMods/millenniumad Apart from that, the contents seems ok.

If you want to get involved in some development, this isn't very hard to fix. Just take a look at the global functions of the gui, and see what options are offered by the toLocaleTimeString method. The more annoying part is making it configurable (I don't like 12-hour clocks, and many with me). So it should be configurable in some way (perhaps you can toggle between "12", "24" and "off" instead of just "true" and "false").

Can you post some more info? Like the path of your mod.json, the contents of it, the path to some of your modded files, ...

We had a balancing team, but it was unbalanced. A balancing leader works better than a team for this.

The code is still fully compatible with the old actor format (which is handy, as now I can update one batch at a time). And since actors had no inheritance whatsoever, it means they all operate on their own, so aren't affected by the changes I'm doing. So if you don't want to change anything, it's not needed to change. But if you change it too (perhaps wait a bit until the dust has settled in SVN), the files will be a lot smaller and easier to create/maintain.

The problem with friendly fire is that our UnitAI code isn't clever enough. If the unitAI needs to check for every possible target if there are allied units nearby (like a soldier in real-life would do), it would cause a lot more calculations, and cause more lag. Because we don't want the micro-tasking of assigning a new target for every individual unit, it was decided that archers can just fire and never hit friendly units. Limiting ammunition would cause the same annoying micro-tasking, and a lot more shuttling over and back. Note that a secondary attack is planned for some units, but it's also hard to figure out when to switch between primary and secondary attack. It's easy enough to enable friendly fire though: just check the ballista template, the ballista does give (or at least gave in the past) friendly fire since it's more realistic indeed, and doesn't cause that much micro management (there are less ballistas, and the targets are normally big buildings).

Small note from the technical side: updating actors with new animation-prop combos should become easier. See the Athenian infantry files that have their civilian tasks split off already: http://trac.wildfiregames.com/changeset/18057

It can't be done in a mod, as it needs engine modifications. But that doesn't really influence the complexity of the problem. There's an advantage that with the current game, it already keeps the network lag caused by players. So now the host should just calculate some good default from that every x turns (f.e. make sure 90% of the turns fit in the given turn time). Other games probably do this differently. They could already start the animation before the command is and to the host. So just to provide some user feedback. This would probably give better results visually, but making a distinction between real and virtual commands well be hard. I do understand the mouse issue now. So I guess it's mainly because your mouse is to precise, and it starts drawing a rectangle to early. I don't have a gaming mouse, and I'm not that fast to move, so I never really make an accidental bounding box.