hyiltiz

The Texture Quality has been low throughout my testing; I turned it to High only once. It didn't seem to change the behavior noticably; it may have decreased time-to-issue-from-game-start, but I haven't been monitoring time too closely. I am booming almost the same way, and always attacking as I get close to 180 pop, so that is also about the time the issue appears, so Texture Quality didn't seem to have any noticable effect.

Yes; Texture Quality is set to low.

As reported from `lsmod` (attached above in Spoiler), I am using radeon. I tried amdgpu as well before, which can drive this GPU tho not quite sure which one would have better support for this. I know amdgpu has better and recent dev work. But either way, I can check temp via sysfs, for sure. In fact, I didn't even need to; earlier I could cook an egg on the surface, now it is only warm to the touch and doesn't even feel hot. I should probably clean the heat sink and the fans, and glue new coolant; I have done that before, and if needed, I can do that again. Thanks for the suggestion!

Running the following two lines before running 0ad helped: echo battery > /sys/class/drm/card0/device/power_dpm_state powertop --auto-tune It led to less heat-up, and GPU rendering worked throughout the game. I can now probably set it up so it persists over reboots.

I used OpenGL ARB, set both of the adaptive fps settings to 60, enabled VSYNC, disabled Shadows, set Number of Shaders to 0, but still got the same issue towards the mid-end of the game. It certainly seems like a performance issue: it tends to always coincide as my pop reaches beyond 100.

This is a laptop. I can confirm that it heats up a lot when that issue happens, and I am using the manufacturer's power supply adapter/chords etc. The monitor is laptop's internal monitor, no external display/monitors connected. I can try OpenGL ARB. Neofetch says: AMD ATI Radeon R9 M280X lspci says: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XT [Radeon R9 M280X] (prog-if 00 [VGA controller]) lsmod says:

Just encountered a few different variants of this issue; the bad rendering now even flickers, or becomes purple/pink etc. I was also able to re-produce when the structures disappear. All captured in videos here: https://drive.google.com/drive/folders/13z3abqfR2-rc7dOMQPF-3kuWG3-xyzjG?usp=share_link

Your hunch about graphics card memory is probably right; now I recall that after that rendering issues goes on for a while: the game sometimes hangs and I have to hot-reboot the OS (by holding the power button, yikes...) if I do not wait until the game hangs or I got lucky that it doesn't, when I close the game, I find out that my Firefox rendering all gets messed up (the tab bar becomes a flat rectangle, and no icons show up in tab bar nor text etc.) I can play Xonotic or an array of other games just fine. Is it possible that something with my config+hardware is leading to memory leaks? Updated my user.cfg as suggested, reproduced the bug and uploaded two videos in the same drive link. Also including a .tar.xz file including all my config and logs right after this reproduced gameplay. I added two new videos: first video shows when the rendering issue just showed up, and you can see enabling Shadows somehow "works around" the rendering issue (no more negative/cyan colored buildings -- these buildings could even disappear later on) second video shows that after playing for a few minutes with "Shadows" on, now even "Shadows on" setting has a different rendering glitch; the terrains now has an ugly-looking grid-like pattern. Toggling "Shadows" only allows selecting one of the two rendering issues, but both issue persists. @Stan` @vladislavbelov I am in #0ad and #0ad-dev, if that is more convenient.

Description: During a game play, entities such as trees, units and buildings seem to be colored/shaded with "anticolor" (kinda like negative film look). What I tried to fix it: This happens in both singleplayer against Petra bot and multiplayer In multiplayer, while it is happening in my Debian, it doesn't happen to the other player connected through local network via macOS it almost never happens in the first 15min of the game, but once it happens, it never goes away, even after saving the game, restarting 0ad then loading that save Some maps seem to lead to the issue more earlier it seems only changing "Shadow" settings would have an impact on it, and no other setting has any noticable effect: Turning off "Shadow" sometimes fixes it; but keeping Shadow off can still trigger it in the same game later or in the next game In "Shadow" submenu, sliding the "Cutoff distance" sometimes has an affect Here are videos of the effect I am talking about: https://drive.google.com/drive/folders/13z3abqfR2-rc7dOMQPF-3kuWG3-xyzjG?usp=share_link Various logs from 0ad: https://paste.tomsmeding.com/fxSf5Vb3 This *never* happened in A25 in the same computer and system... @Stan` @vladislavbelov

Fixed the last table so Gaia no longer shows up as stealing Athen's units (due to previously ignored mixin unit categories). This is more of a temporary fix; if a "prototype" unit, like jav cav, shows up in the future as a single unit that belongs to multiple Civs through mixin types each of which define their own skin etc., then this will not hold anymore. But until then... I need help in figuring out which units show up even though un-trainable; does anyone know if the unit trainability is included inside the unit .xml files?

Thank you all for all the feedback and criticism! Keep it coming! Yes, the final table is incorrect: Gaia and Athens is swap due to a slightly complicated code logic (mixins based on multiple inheritance), which is easy to fix for now (just swap them) but to be an actual future-proof fix, there needs to be some substantial rework on the parser. That might come later. @Yekaterina I used different shades of green to be color blind friendly; the previously used red/green/black coloring made it not obvious that they were all label availability of unit to different degree. I welcome any graphics design suggestions and CSS. BTW, loved your guide and love watching your replays. Really happy to see you commenting on my stuff I had no idea some units were not trainable; I can look into that and fix it for now. A real future proof solution is in the discussions in #ad-0dev as well (come hang out :D); namely, let the pyro do the parsing then export valid units and the traits. Right now, this analysis script is playing mouse and cat with the engine and easily turns into code rot. On a more detailed and future-proof design Currently, all the parsing is done based on file names and what the parent property claims in the XML files. However, apparently the real thing is much more complicated at several levels: - some units are not trainable - civs may stop being separate XML folders but just mixin categories interpreted via multiple inheritance - some unit types are misrepresented in file names (like Spartan Skiritai and some Merc units) As you can see from the git commits, there were some serious overhauls needed for this script to be maintainable, and some non-trivial parsing fixups for it to work. It doesn't even accurately represent how the units actually work in the game right now. - One way to fix that (I am just a noob; I didn't even know the game 2 months ago) is to ask the community (YOU) to tell me what's wrong so I can fix them; - A better future-proof way to fix them is to base the analysis on the results of the pyro engine parsing so I do not have to re-implement parsing the same way the game engine does. Even if I can do that now, that won't stay that way in the future as the engine evolves. To do so, I need to throw away all the parsing work I've done so far and replace it with the game engine parser library result, for which I see three possibilities: write a thin wrapper around the game engine parser library so it can do all the parsing just like it would do for the game, then export it for me to do the analysis, add a feature to the pyro engine executable so it can export the game unit stats (e.g. as a JSON) for me to do the analysis. This has an additional benefit of being able to be used by other tools as well since JSON is very accessible; also poses a challenge since pyro needs to be cross-platform compatible and someone who knows enough about C++ cross-platform syscalls and CLI arg parsing has to do the implementation; re-implement the unit analysis in JavaScript, so these analysis could be available in-game just like the Civ tree as part of the manual. I think: method 1 is relatively easy (only requires work on my part) method 2.3 must be most desirable because it will be available in-game, but requires substantial work to port the analysis into JavaScript and some more. method 2.1 is non-trivial and not worth the effort method 2.2 might be a good middle-ground for now, as well as being a good foundation for 2.3 in the future. Ideas? Comments? Volunteers?

There has been some discussion in #0ad-dev about migrating to git. In addition to the benefits mentioned earlier (maybe we need to pile them up in a single document to do a cons vs. pros comparison), it also helps bring new contributors by making it easier to submit a small patch via a web interface or a list of patches via a pull request, which is standard feature in Github and many other popular customer-facing platforms. I think a self-hosted Gitlab instance (like the ones hosted by KDE and GNOME) may be a great idea. We might even be able to ask for what they learned and what to look out for during migration so avoid some common mistakes that might be harder to fix in retrospect. To minimize code base so cloning (a typical step for a git or DVCS oriented work flow) is cheap, it is probably worthwhile to move all binary assets (real binary files, not the contents of ./binary/ folder in the .svn repo, such as artwork, images, as well as build artifacts like as .dll, .so, .dylib, .exe) out of the main repository. The git repo can contain the source code for the game engine plus the main game 0ad (aka the "public" mod), and various build scripts and automation scripts so the build artifacts can be built automatically by a) downloading automatically on a new developer/contributer/CI system necessary (like dev platform tools like Python, SpiderMonkey, Lua library etc.) build and dev tools; b) installing and configuring the dependencies automatically to build it in a given supported platform. The artwork can be a git submodule that will be mostly updated by artists, and that will be fetched only if the build process requires it. A majority of the development work and balancing actually does not require access to the artwork assets. Without artwork assets, it is quite possible that cloning the whole repo could be less than 50 MB (my guesstimate). Ideas? Volunteers? Donations?

Here it is: https://hyiltiz.github.io/0ad-unit-analysis/ It shows 3 tables: - a table for all template units that shows the specs of a generic unit, e.g. a Cav Archer; - a table for Civ specific changes from the generic template unit; - a table for unit availability for all generic template units for each of the Civs Let me know if you have any specific ideas for improvements, preferably at #0ad-dev but I might check back here too. PRs are very welcome too! Story I wanted to work on something like this, and @Stan pointed out to me in #0ad that there is already a script in the repo at ./source/tools/templatesanalyzer/unitTables.py. Unfortunately, the script hasn't been updated substantly since 2014 and the script simply threw an error when I tried to run on the latest version of the game (A26, more specifically, the trunk r26182). I forked the directory so I can keep my commits small and with a specific theme to facilitate merge and auditing, as well as to publish it in Github so anyone can view it online without having to deal with SVN, HTML, JS, Python etc. As such, note that the majority of the program logic, design and program is NOT my own; it is based on previous work of fatherbush, Itms, scythetwir, wraitii and others(?). I will be trying to getting this merged into 0ad main repo soon. The idea of Mixins (like unit tags, e.g. hoplites who can use Phalanx formation) were introduced since this script was originally written, and currently I have not found a good way to represent them as part of the table, except just listing these Mixin tags as a list in a separate column. But that would be barely useful, so Mixin types are omitted at the moment.