Leaderboard

Not sure whether this was ever shared with the team before, but we had a fairly robust documentation platform in place for this project. http://wiki.sciondevelopment.com/ The domain expires in February, but if you think you guys can get some usage out of this, I can afford to renew the name and continue maintaining the site. If you're interested, feel free to adapt the content to your current needs; it sounds like the project has come a long way.

Hey scythe !! Hope you still follow this topic; as I asked you in irc days ago, what about continuing sbb? After about 30 "real" matches in a17 there are a few points to mention/discuss: - champions. need. more. health. - buildings need more pierce armor. Its ridiculous, how 8 archers can tear down a building thats in progress or a few more archers can destroy eg a tower. (which damage do archers to a stone tower in reality? Imho: nearly none.) - rams are op now compared to catas. Need less pierce armor too, or champs more health, as said above. Or units generally dealing more hack, dunno. - That skirmcav auto-micro needs discussion too. All ranged units should get this feature, or, what I personally would prefer: no auto-micro at all. - Ptolemies are clearly op in earlygame. Its nearly impossible to defend their raids in first gameplay minutes without own eco going downhill. Also in lategame, that hero that increases pikemen health 40% during his lifetime is ridiculous. Give him an aura, or nerf the percentage. No balancing, but generally: 2v2 multiplayer are nearly impossible due to huge lag, compared to a16/15/early sbb. Afair leper told me that the lag might be related to the new FOW/mirages. If so, it might be worth to undo the new FOW, imho. I would prefer smooth gameplay to laaaaag and scouting.

I'm watching as do the buildings look like Mesoamerican buildings, you see what I failed yet(My English is very bad) And I made a building that has nothing to do with mod

Recently I put some effort into researching the creation of more realistic looking mountain and today I would like to publish my first results: As you can see, I focused on the middle and didn't bother too much about the sides. What do you think of this? Where and how could it be improved?

Hello, My name is Veronica and I am preparing my master thesis on localization of open-source video games. I am interested in the l10n process of 0 A.D. and I need the help of any developer of the game to complete a short survey for my study. The survey is mainly about the l10n process, programming languages and translators recruitment. Please, help me! Best, Veronica S.

The northernmost border of the Seleucid Empire, separating it from the steppe tribes and as far north as Alexander's army ever reached. It's my first 0 A.D. map, nothing very fancy as of visuals, as that's not my forte and the steppe biome doesn't help much, but I believe it plays pretty well. The AI seems to like it as well, it was tougher to beat compared to other maps I've played on SP. I also noticed an AI glitch while testing it. On one of the matches the AI built many defense towers across the northern edge of the map, while obviously none could invade it from that side. The forum won't let me upload one of the two map files, so I guess there should be some other way sharing it. Thanks to niektb for explaining how to place skirmish entities. Edit: Thanks again, map added. Jaxartes River (2).zip

I've spent quite some time analyzing the effect of gcPreserveCode on memory usage and performance. In the previous measurements, we have seen a 13.5% performance improvement in the non-visual replay when gcPreserveCode is enabled. I've also checked memory usage there, but it was only the size of the JS heap reported by SpiderMonkey. If SpiderMonkey needs more memory with gcPreserveCode that is not part of the JS heap, we wouldn't have seen it there. So one of the first things to do is comparing total memory usage: Here you see a graph of the total memory usage during a non-visual replay of 15000 turns with preserving JIT code and without (both v31). The measurement in blue will be explained later. There's one sample all 5 seconds. As expected, the keepjit graph (green) is a bit shorter because it runs faster. In the end of the replay, keeping the JIT code needs 76 MB or 24-25% more memory. This is just the non-visual replay, so the percentage looks less scary with a real game where much more memory is needed for loading models, textures, sound etc. It's not only important what effect the gcPreserveCode setting has during a game, but also what effect it has when playing several games in a row. The JIT code is kept on the compartment level (might partially be zone level, but that's the same for this case in practice). We create a new compartment when we start a new game and destroy the compartment when we end it. This means we don't keep simulation JIT code for more than one game. The same is true for the NetServer in multiplayer games, for random maps and for GUI pages. Also we can run a shrinking GC at any time, which throws away all the JIT code and associated information. The third graph (in blue) shows an additional memory measurement when a shrinking GC is called all 500 turns and gcPreserveCode is enabled. It confirms that calling a shrinking GC really frees the additional memory used for JIT code and associated data. I would have expected it to have more or less the same negative effect on performance as the default settings, but actually it looks like the performance is as good as with keeping the JIT code for the whole game. It's a bit dangerous to conclude that from this single measurement though. I've not been especially careful about other programs runnings on the system and it's just one measurement. I've also worked on fixing some problems with the new tracelogger in v31. I've shown some tracelogging graphs in the past already. It not only gives information about how long JS functions run and how often they are called, but also engine internal information like in which optimization mode they run and how often they had to be recompiled. Among other information you can also see how long garbage collection and minor GCs took. The tracelogger wasn't really used for such large programs like 0 A.D. so far, so it had a few bugs in that regard (correct flushing of log files to disk for example). Some of them are fixed in even newer versions or scattered across different bugzilla bugs, waiting to be completed, reviewed and committed. Together with h4writer who helped us in the past already and who is the main developer of the tracelogger, I've managed to backport the most important fixes to v31. In addition, we discovered a limitation with large output files and he has made a new reduce script that can be used to reduce the size of the output files. Now that the new tracelogger is functional, it can be used to further analyze the effect of gcPreserveCode. The following diagrams are made from Tracelogger data. They show how long different code runs in the different levels of optimization. Code starts running in the interpreter, which is the slowest mode. After a function has run a few times in the interpreter, it starts to get compiled to baseline code (BaselineCompilation) and then runs in Baseline mode. The highest level of optimization is IonMonkey. TL stands for Tracelogger and can be ignored because it's only enabled when the Tracelogger is used. So basically the higher the IonMonkey part, the better. Interpreter should be close to 0%. I've added everything >=1% to the diagram and left the rest out. V31 (no gcPreserveCode, no shrinking GCs) V31 with gcPreserveCode v31 with gcPreserveCode and shrinking GCs all 500 turns The Tracelogger data matches the results from the performance measurement. Using gcPreserveCode without a shrinking GC obviously gives better results than with shrinking GC from the Tracelogger perspective. The difference is quite small though and probably doesn't justify the increased memory usage. Also the memory graphs indicate that there's probably not a big difference between these two modes (but this would need to be confirmed with additional performance measurements). The Tracelogger results from the default mode without gcPreserveCode are much worse (as expected). The code runs much less in IonMonkey, more in Baseline and even quite a bit in interpreter mode. The code gets garbage collected and throw away way too often and thus has to be recompiled more often, resulting in more compilation overhead and more time running in less optimized form. Conclusion My conclusion based on these results is that using gcPreserveCode together with a regular shrinking GC seems to be a good compromise between memory usage and performance. It might be worth to confirm that the shrinking GCs really don't have a significant (negative) effect on performance with additional measurements.

Cavalry now have reduced pierce armor, spearmen deal pierce damage, so they counter them.

For a long time 0ad was designed to play on most computers. I think doing that will go against this idea cause we have a lot of integrated graphics players who would'nt be able to run the game. If we do thatthings like suppor only opengl4.3 would appear making 0ad unplayable for most people for little to no benefit. A Three 1280x1024 screen user.

I also like to play zoomed out, and I agree that, in some maps, the level of distance fog is a bit annoying and I'd like to be able to reduce it.

Wonderful, I got it. I can now edit maps with SVN atlas and run them with Hannibal as mod in release. Thanks.

In svn, there were some changes in simulation/components/GuiInterface.js, so you should update the mod to make it work properly with svn (although it should seem ok as long as you only have AI players). Otherwise, I use it from time to time to test Petra, and it is quite useful, thanks.

Does it.. eat people off of ships? Please?!

I think we'll have some form of trigger editor, now that we have triggers, but did it actually work pre-Alpha? A lot of things were implemented pre-OS, then were removed when the simulation was reimplemented by Philip, etc. Did you try loading maps from anywhere in Atlas? That was broken for years until A16(?), because maps are loaded through the VFS, which is mapped to only a few real directories on your computer. The old file dialog was misleading that way, you couldn't really open or save anywhere. http://releases.wildfiregames.com/