Leaderboard

I made some measurements concerning the topic we discussed today. We really need a better solution for applying entities delta. This was a 2vs2 AI game that ran for about 15000 turns.

I've decided to get back to Spidermonkey issues. I uncommented the iteration order workaround and measured performance again. The simulation state in the end isn't exactly the same because the workaround is disabled, but it shouldn't differ too much. In the end we have 3120 entities with 1.8.5 and 3133 entities with the new version. The results I got were bad unfortunately. Before my simulation state fixes, we had a performance improvement compared to 1.8.5 in the end of the game in many functions (see previous measurements). This Improvement is gone now and I assume it was only due to bugs that caused the AI to develop worse. Now most functions have more or less the same performance graphs with 1.8.5 and the new version (v26 at the moment). There are some tiny differences where sometimes one version is better and sometimes the other. There are a few peaks where v26 performs much worse and these are the ones I intend to fix. I officially stopped expecting a better performance from v26 now. The tracelogging graphs have shown that there aren't many places left where JIT compiling is broken for some reason and the profiling has shown that there's currently only one place where we really get a significant improvement. We have seen that Ion Monkey performs very well for the random map script where it now takes about 1/3 of the time to generate the map. Unfortunately after seeing so much other code that doesn't get improved, my only conclusion can be that this only applies to some very rare cases that are probably common for benchmarks but not for real world applications. The random map script is more like a usual benchmark that does the same thing many many times in a loop. The improvements that work in these cases apparently don't apply to more common real world scenarios. All I try to achieve now is getting the same performance as 1.8.5 again. If there are any hints that there could still be a general problem somewhere in our code, I will investigate that of course. I will also help as good as I can if the Mozilla people have questions or want to do more analysis with our code (will also post the updated patch soon). The Spidermonkey upgrade is still required, even if it's only to be updated again and to avoid being stuck with an old unsupported version. To get back to 1.8.5 performance it looks like only a few spots need to be fixed, mainly these: ExecuteItems (already analyzed a bit and reported in bug 897926) BuildNewDropsites (EDIT: this also calls map-module.js:39, so it's probably also bug 897926)

I would have a question about the code. My co-researchers and I are working on a monitor to detect bugs at runtime in a video games. We've already been successful with other games, but we want to try it on a bigger one like 0 A.D. The first step is to examine the code to see where we can get the information we want, but this step seems to be harder than we thought in 0 A.D. To be precise, none of us are really at ease with scripting and it has been quite difficult to get what we want. Since our deadline is near, we decided to ask for help on the forum. The information we want is about the units and structures in the game. We rapidly found that these informations are mostly done in the Javascript as it's the only place we found information about health, armor, attack, etc. Alas, we still haven't found how to access it in the C++ code, something we would really like. We also found that this information is stocked in XML or JSON (we already use XML for our monitor, so it was a really nice discovery). He are some questions we still have : 1. Is there a way to access information like a unit's health in the C++? We're pretty sure it should be possible, but this still eludes us. 2. If it is possible, can we get the XML structure with it? It's not as important because we could still make our own XML and put the information we want, bu since we saw there is a really neat one already done, it would be nice to get it. 3. Is there some way to get access to all units/structures a player controls like in a array or something else? In Player.cpp or Player.h (if I remember correctly), we couldn't find anything like it. Thanks in advance for any information. When we start working in the game, we're gonna create our own fork so that it doesn't change anything in the source code.

the code is almost finished, but as it won't be in A14, I postponed development a bit. there is still alot of work to be done for imagining new auras, and balancing them .

Keep in mind that in multiplayer games, the simulation state on every client has to be identical (for out of sync testing, we simply hash the binary state and compare them). But AIs don't only react to the current simulation state, they also store data from previous turns. This means if you don't serialize the AI state properly (I would say fully) then deserialize it, like if someone rejoins in multiplayer or you load a saved game in single player, the AI will have different internal state, which very likely means it will send different commands. That will cause the simulation state to differ and an OOS error in multiplayer. In single player games, the problem is more subtle, the AI will simply behave differently after loading a saved game. Or you may get errors when certain code paths are hit requiring data that wasn't de/serialized. I actually don't see it as that difficult of a problem. It would require substantial modification of the AIs and their API to fix correctly (Aegis, like qBot and JuBot before, is based on Testbot, which was only a prototype AI that didn't correctly implement serialization and had flaws in the design that make it more difficult now). But those modifications are fairly straightforward for someone familiar with the AI.

For both things, take a look at the Promotion component. That replaces a unit with an upgraded unit, and copies many things (like ownership, position, current and planned tasks ...) to the new one. For buildings, you could use the same I think (copying the production queue etc). And you can use some of that code to let it spawn arbitrary units. In the Garrison component, you can also see how to easy pick a good spawn position. And I believe the Init function is only called when the building is complete. Like the BuildingAI starts firing at enemies directly after the Init function. while in game it only happens when the building is complete. If you ever need to do something on the foundation, you should make that part of the template copyable to the foundation, but I'll have to research on how to do this myself. But if you're going to implement this all, I'd prefer if you split it in single functionality patches. Some of those patches could make it directly to the main game (if the code quality is good enough). But one big blob of code, with a zillion functionalities added will be too hard to review and never make it to the main game. If you keep all those patches in separate component files, I think this won't be too hard to split up.

What do you mean with "Shouldn't stack"? I understand that, if there are 2 females around one citizensoldier, that soldier would only get the bonus once, but OTOH, what if there is a female around, and a hero with a different but similar aura? Do you want to remove the "Auras" component and extend the technology component to make range and formation based techs possible?