Leaderboard

While discussing a quirk of the common AI API on IRC Stan suggested to take a code coverage measurement on the existent simulation components, since I had the toolchain already set up for AI development. I took the challenge and now present first results. However, I decided to not attach this to the already running jasmine-thread since I consider it an independent topic. To reproduce the measurements: Attached to this posting is a zip archive. Unzip it to binaries/data/mods/public/simulation. A new directory CoverageMeasurement will show up. Inside that directory, the subdirectory instrumented already contains the results of an instrumented run. Load the jscoverage.html file into a fully-scripting-enabled browser to see the results. They will look somewhat like this: To rerun the analysis, launch the runcomponenttests.sh shell script from the CoverageMeasurement directory. That script requires that the zip archive has been unpacked at the particular destination and 0AD fully compiled (SpiderMonkey shell is compiled via the update-workspaces.sh script). Observations during analysis: The test scripts are normally run from the pyrogenesis test script file test_scripts.h via the cxxtest subsystem. This means the scripts can enjoy the full Pyrogenesis environment, which is not available when runcomponenttests.sh runs the test scripts via SpiderMonkeyShell. For example, I had to manually define all interface identifiers IID_XXX in the jscover-driver.js file which contains the actual 0AD-specific analysis logic. Since I just faked the missing Engine functions, the logic of some test cases might not work, giving improper coverage results. Still, I found some component methods which seem to be not tested. My homebrew driver script runs all test scripts in the same JS environment without resetting the global scope. This caused SpiderMonkey errors when const values were redefined. To overcome this, the shell script wraps the content of each test script into a "(function () { test script })()"; encapsulation using an sed script. Some test scripts still caused errors and I resorted to skipping them for the first draft. Error analysis seemed too cumbersome when it is unclear whether this approach is feasible at all. The skipped test cases are marked in the CoverageMeasurement/jscover-driver.js file. Code coverage measurements are taken via the JSCover tool (not the most recent version). This tool is originally intended for web development and so relies on running a JSCover server in the background, while browsing the reports. I hacked the JSCover main script to allow browsing the results without the server running, as this was needed to integrate the JSCover results into a JSDoc documentation site. The hacked jscoverage.js script is found in the CoverageMeasurement/JSCover directory. Any comments or questions welcome. CoverageMeasurement.zip

https://code.wildfiregames.com/D3018 While I can propose patches, make suggestions, and raise concerns (anyone could), I don't decide what makes it in and what not. https://code.wildfiregames.com/D2815 would give all civs rams (kush would reuse the pers (i.e. Assyrian) ram actor), and multiple people are in favour; however, others have pointed out it would make civs more similar to each other, so I don't know what'll happen eventually. Actually something has to exist before it can be enabled, i.e. art has to be created first, unused assets are fine; a gameplay patch can follow later.

V 0.92 of Aye Pirates has a large changelog and some known bugs but I am mostly happy with it. capture the relic for 10 minutes on the large map is fun i think.

I'd prefer to have low number of knifes for all civs The problem is that you can't notice the difference by eye on modern hardware like 1050/1660+, but we have a lot of meshes each of them increases number of GL state changes which decreases performance (so in total they affect performance significantly). Also more different meshes makes instancing less applicable.

And now is merged and will be included in 3.5.0.

Sorry, my inbox was/is a mess I just read the last mail. I really hope the man is ok... What about @LordGood? Any spare time/interest in this? No problem man... I've seen it associated with Piye before myself, so it's an innocent mistake... Yeah, it might be. I think it's ok for a reference. A bit unique, which is good. For now only limited to Amanirenas. We'd need another "less-royal" chariot texture for a general chariot unit. But it would require consensus in the balance department to actually get in-game, which isn't straightforward. We still have some time to discuss it further before Alpha 24 drops, so we'll see if there is any appetite for a Kushite chariot unit.

I'm not really sure that would help... The goal of social media is to keep people interested. If we start claiming that, I think it will do the opposite ?

@user1 My Username: DerekO Offender: LeBlanc He left right before I destroyed his CC and killed his troops. I'm pretty annoyed that people do this kind of stuff commands.txt metadata.json