Leaderboard

Well, here is the rough code I have so far. It achieves what I wanted it to do - large armies can stick together fairly easily without formations as long as they are in an open area, and it does reduce short range pathfinder use in those situations. However, there is still a problem, which is that units can get stuck against static obstructions. I think that may have something to do with the short range pathfinder being too optimistic about being able to walk around static obstacles when the navcells block the way (and the units have been bumped off the long range path by sliding). I'll still be tweaking it to see if I can solve that problem. Meanwhile please give it a try! For the most part this is 2 changes. First, units slide against each other parallel to the path, as I mentioned above. Second, units move in an order determined by their long-range path length - units with shorter paths move first to make room for those behind them, who usually have longer paths. A note - one interesting thing Starcraft II pathfinding does, is allow moving units to push stationary allied units out of the way. It might give a nice aesthetic to try that as well. Another note - this patch is far from polished. "It compiles" is about what can be said for it! Please don't murder me over the coding style, which I'll clean up a bit before submitting on trac if I can fix the units-get-stuck problem. sliding.diff

Probably this strategy would be nerfed with the next alpha. If I recall correctly, the planning for the game was having 25% less work rate per level, so a Elite unit like the spartan commando will be -50% worst working, but was broken until now, that was fixed. So if you focus on building a economy based on commandos, you will be a step behind another player with the same level in the economical side. @elexis correct me about that. I think that this fix doesn't appear in the changelog. EDIT: Maybe Skiritai Commando (Ekdromos Skiritai) should be renamed to Skiritai runner (Hammipos Skiritis). very short to read Sources 1, 2. Maybe not. I found the explanation that Mythos have in mind here. But this is a little Off-topic. EDIT2: 18131 and 18165

Fixed it. Will commit it tonight

SerugiuHellDragoonHQ emailed back, he just said: " Regarding your private message you sent me via YouTube. I don't know why they sent you to me. I am playing 0 A.D. from time to time but I have no Official link with them. " I get the feeling that means "I'm not interested" considering I never asked for him to have any official link to you guys, but I'll try and clarify it with him anyway.

See http://trac.wildfiregames.com/wiki/Audio_Voice_List We currently have Greek and Latin, but both could be improved. Both in pronunciation and recording quality. For Persian, we have some sentences, but no records yet. And yes, you can certainly direct her to our forums (anywhere is good). Edit: there are also quite some other threads on the forums about voices.

The main limiting factor in bigger maps is the performance. Several algorithms we use loop in O(n²) or worse on the number of terrain tiles. So if the map becomes 4 times as big (which is just doubling the sides), calculation of that method takes 16 times as long (or worse). There are some demo maps that are really huge, but they're not decorated (there are no trees, no resources, no ...), and even then, they can be quite slow. Let alone what would happen if the map would be filled with trees, buildings and units. So with the same game mechanics, this doesn't seem possible to have a huge map that allows all online players to play together. If such a gametype is made, the game mechanics should be simplified a lot.

Yes, this bug has been reported before. If you first change another setting, it creates the user.cfg, and changing the language works. But changing the language as a first change doesn't work (at least on Windows, didn't know for Mac).

I have been experiencing that once, I think it's because it fails to create the local.cfg file in "appdata/roaming/0ad/config/"