Norse_Harold

Hey, that was quick. Thanks!

Okay, I think that I know what entities trigger the symptoms: the hostile animals (brown bears and wolfhounds) that are owned by AI-controlled players. I used a technique similar to the binary search algorithm, specifically the generalization to graphs, by making multiple edits of the map file in order to narrow down the possible entities causing the problem. Then I guessed that AI-controlled hostile animals could trigger the symptoms, so I edited the map to only change the hostile fauna to be owned by player 0 instead of players 2, 3, 4, or 5. It seems to be correct so far, but long-term testing with this fixed version would be wise. Winter Is Coming(5).zip In the future, when you place animals, especially hostile animals, ensure that Gaia is selected as the owning player at the bottom of the scenario editor window. Also, I consider it a bug in the game for these symptoms to occur when AI controls a hostile animal. Or, it's a bug in the game to allow the user to create a map that is able to trigger these symptoms. I have reported this on Trac with a minimal test case.

Don't edit the map yet. I have an idea for how to find out which entities are triggering the problem. I'll let you know what I find out soon, probably tomorrow.

It probably was made by ChatGPT. Also, kozarets modified the quoted text and added an advertisement and link to a third party commercial website. I've banned kozarets as a spammer.

Okay, thanks for the update. Is your computer a laptop or a desktop? If it's a laptop then what's the brand and model of laptop? Laptop manufacturers' websites usually have the specifications of the builtin graphics adapter given the brand and model of laptop. If you have a desktop with an add-on PCI-e graphics card then the information you have posted about the graphics card is not enough to determine whether it is factory overclocked. There are many variations of each GPU made by graphics card manufacturers. Each variation may have a different clock rate. The information about brand and model would be on the invoice when you first purchased your graphics card, or your prebuilt desktop with bundled graphics card. If your computer has a desktop or tower design then you can power off your computer, unplug it, open it, and look at the labels on the graphics card itself. If the brand and model is not obvious from the front of the graphics card then it is likely a reference or OEM card. In that case a photo of it may be enough to identify it. Removing the card will allow observation of small labels on the back of the card. Again, ensure the computer is off and unplugged before doing that sort of thing. If you think there's a risk of breaking the card or computer by removing the card then don't do it.

I am able to reproduce the problem, even on version alpha 26. Steps to reproduce. Extract the Winter Is Coming(5).zip file to the mods/user/maps/scenarios folder in your 0ad game data folder. Load the scenario Winter Is Coming(5). Slot yourself as player 1, and slot 4 AI in the remaining slots. In fact, you can't change any of the starting parameters. Civs are forced to random. Use the cheat "gift from the gods" (type it in chat) to get p3, a lot of resources, and fast building. Build a stable and produce 50 champ cavalry. Send the champ cavalry to attack another player, generally at the cardinal directions of the map. After fighting with an AI-controlled opponent for several seconds, the error should appear. Here is the repeating error message that I see when I test the map with 0ad version alpha 26. During the test, I was Britons and the player that I attacked was Hans. I made a modified version of the map, where I deleted all entities except one civic center and 4 women for each player. The warning and error messages then did not occur with that modified map. A hypothesis is that the symptoms are triggered by certain entities in the map.

Try adjusting the graphics settings. Maybe reduce the quality. Consider using OpenGL ARB instead of OpenGL for the Renderer Backend under Settings, Options, Graphics (advanced). Restart the game and try to load a match again. If the problem persists, please share mainlog.html and system_info.txt. Also try these troubleshooting tips about black screen symptoms.

The problem seems like one of these possibilities. Missed frames with G-SYNC or FreeSync causing a black screen Inadequate rating of monitor cable for the resolution and refresh rate expected Monitor not on the approved list for G-SYNC Factory overclock of the graphics adapter causing the GPU to malfunction and cease functioning until rebooted Note that the Magic-SysRq key has some settings in sysctl that enable or disable certain aspects of its functionality. Some Linux distros disable the ability to reboot with it. So, you should test that it actually works for rebooting while your computer is functioning properly. If it doesn't work for rebooting then add the following to /etc/sysctl.conf. Note that a line with kernel.sysrq might already exist in the file, so comment out other lines that try to assign it, or ensure that your line is last in the file. kernel.sysrq=1 Also consider the option of setting up the openssh server so that you can ssh into your computer for making observations when the black screen occurs. Consider restarting the graphics hardware by shutting down X, removing the kernel module for the video adapter and reinstalling the kernel module. (I'm not sure whether this actually restarts the graphics hardware.) Try the troubleshooting steps in this thread. A good starting point is to check whether the game is still rendered despite the screen being black. Check that by pressing F2 to take a screenshot while the text entry cursor is not in a text entry box. Then look at the screenshot, found in the game data directory. Another good test is to run other graphics intensive 3D games as long or longer than you run 0ad, and with various conditions such as low complexity with high FPS, and high complexity with low FPS. You can even try benchmarking software like 3Dmark, furmark, or Unigine Heaven, Valley, or Superposition for extended periods of time like 12+ hours. (The first two are Windows only. The next 2 support Windows, Mac, and Linux. Superposition supports Windows and Linux.) I have a theory that the problem happens with other 3D software if it's tested long enough. Considering that your computer is freezing, crashing, and the screen goes black, that resembles the GPU malfunctioning due to factory overclock. I advise using reference clock rates. What brand and model of graphics adapter do you have?

Save files are very unlikely to work from one version to another. I think they're even stored in separate folders so that they aren't visible to a different version of the game. If you consider the save game very important then I advise installing Linux or running a Live Linux OS from the DVD or USB memory stick in order to load the save game. It will be a 64-bit process, and it will be able to allocate more than 4 GB of RAM. Assuming that reaching the 4 GB limit for memory allocation is the problem, yes, I advise that you not save when 0ad uses close to the 4GB limit on Windows. How "close" to the limit will need to be determined through trial and error. If you save every 10 minutes then you can restore the game with however far back in time still works. You can keepo a watch on memory usage before you save each time and eventually determine how much memory usage is still safe for saving. Not really. We have a good guess about what the cause of the problem is. And, it is apparently reproducible, so you can post a mainlog.html file if/when it happens again.

Based on system_info.txt, you're using Windows 10. Realize that the Windows version of 0ad can allocate a maximum of only 4 GB of RAM because it's a 32-bit process. The developers plan to improve that in the future by making a 64-bit build for Windows, probably for the alpha 27 release. But, for now, 0ad on Windows is limited to 4 GB. Additional observations that contribute to the hypothesis that 0ad ran out of memory: the game went on for a long time, the problem was triggered by saving the game, and the errno was 12 (Not enough memory). I find that after about 40 minutes the game uses close to 4 GB of RAM. When you save the game then it doesn't buy you time. It actually consumes the maximum amount of RAM significantly earlier than otherwise. You can test the hypothesis by using Task Manager to watch how much memory pyrogenesis has allocated at the point that it crashes. If it has close to 4 GB allocated just before it crashes then that confirms that it's crashing due to insufficient memory. If you avoid saving then you might have a bit more play time before it eventually crashes anyway. If you install Linux, or buy a Mac, or Hackintosh a Mac, then 0ad can allocate almost all of the RAM that your computer has free, because it's a 64-bit process on those operating systems. The game should then run almost forever, as it is unlikely to run out of memory. Note that mainlog.html appears to be a brief start and successful stop of the game. Realize that each time you start the game, mainlog.html is erased and started from scratch. It seems that you started the game after the crash but before retrieving mainlog.html.

Thanks for the update. That's a minimal description of steps to reproduce. It might be relevant what hardware you're using with Armbian. I suggest trying to disable the Chinese Language mod on the Armbian system (by editing user.cfg directly, as I explained in my earlier post in this thread) and seeing whether the game successfully starts. If it doesn't then maybe something else was changed along the way. In fact, starting and stopping the game may write a config file that causes the game to no longer start in case there's a bug with mobile device compatibility, such as window or screen size configuration, rendering settings, etc. Another step that may be necessary for disabling the Chinese language mod on the Armbian system is to change the language in user.cfg. Find the line "locale = zh_CN" and either remove that line or change it to the following. If that isn't enough help then please consider attaching logs in order to help with the troubleshooting process.

We need more information in order to help. Can you provide steps to reproduce the problem? Have you tested disabling the mod and seeing whether the game still starts in Armbian? You can disable the mod by editing config/user.cfg and changing the mod.enabledmods line to I think that it's unlikely that the Chinese language mod would cause this problem. How did you install the Chinese language mod on your Armbian system? Did you copy your 0ad user data folder (including user.cfg file) from your x86 Debian system to your Armbian system? If so, that could explain the problem, and I would expect that the problem would persist even after disabling the Chinese language mod. In that case, you should backup and remove user.cfg on the Armbian system so that it can be recreated from defaults. Otherwise, we need logs and steps to reproduce. Does the game work if you reinstall it and have a default configuration with no mods on Armbian?

@neodavid7 It looks like the hero "garrison+regicide" bug. Merely installing community-mod may or may not solve the problem. If it doesn't solve it then follow the steps listed here.

I deleted the other post in General Discussion that you made with the same content.

Might the team making the builtin encyclopedia find it useful to have custom illustrations? @ShadowOfHassen@Vantha@Lion.Kanzen

I think that "inflammable" is not the word to use here. Inflammable means capable of being set on fire; combustible; flammable. Scroll down at this dictionary entry to see an explanation that people tend to think that "in-" means the negative, but it doesn't in this case. Instead, I suggest using "nonflammable" or "noncombustible".

Pluto, talk to me via IRC when I'm online, typically starting at about 18:00 UTC. I can walk you through the process of setting up an apt source for bullseye-backports or else building 0ad version 0.0.26 from source (including distro patches).

No, it's not. Defc0n decided to shut down GenieBot, and ModerationBot no longer responds to profanity because auto-unmuting isn't working. I think that a substantial portion of the moderation bots will need to be changed in order to fix it in a reliable manner. It's on the todo list, and that list is long. We can use more volunteers to help with development work. Today I talked to noogler on IRC, who knows Python, C++, JavaScript and Java. He's interested in contributing. Hooray! Good thing I'm in the habit of having notifications enabled on IRC and actually responding to people there. In the meantime, lobby helpers are watching chat history occasionally and muting people when infractions are excessive. Please ping us for a quicker response to infractions.

Happy New Year! If we are friendly and act like mentors to new volunteers then we can gradually grow the development team.

Can you please try using the official Fedora method for building the package from source. This should ensure that you have the necessary dependency packages installed and distro-provided patches applied to the source code. Specifically, dnf download --source 0ad cd 0ad rpmbuild -bb I haven't tested these commands because I don't have a Fedora system. The most likely point of failure would be the name of the directory to change to in the second command. If the official Fedora method of building the package from source doesn't work, then Fedora would surely like to know about it. It's likely a bug that they can fix, or else it's user error. Based on the build logs it should build successfully on Fedora 39. Edit: oops, the official Fedora method for building the package from source is only applicable to 0ad version alpha 26. However, it may at least help you ensure that you have the necessary build dependencies installed. We need more information, such as the versions of python, python3 and python3-six that you have installed, in order to help you with troubleshooting building alpha 27. How did you update to Fedora 39? Did you do a clean install, or did you upgrade from an existing installation of an older version of Fedora? You might still have a lot of python2 packages. The build of spidermonkey might be using python2 packages by default instead of the necessary python3 packages. I think that you should try to remove as many python2 packages as you can without breaking lots of other packages. Replace them with equivalent python3 packages. python2 packages are named "python-name". python3 packages are named "python3-name".

I would like to know which distributions specifically do that for their official binary package releases. I haven't found any so far. Debian doesn't do it. I assume that Ubuntu doesn't do it, since Ubuntu packages are based on Debian packages. I just checked, and Fedora 39 doesn't do it. One might think that their 0ad.spec file uses system-provided mozjs by default, but it's a counter-intuitive syntax. It actually disables the build condition of system_mozjs by default. Proof is in the build logs that it's building the bundled spidermonkey. Debian would like to use system-provided libraries in general because it makes it easier to maintain security of dependencies (ie. apply security updates promptly and in a centralized manner). But, from watching how they update the 0ad package, I see no evidence that the two maintainers are testing the game any more than verifying that it starts up after the package is installed. That's a conflict with the warning to developers and maintainers (yes vlad, I know that it is technically a compiler #error) that system-provided mozjs should be tested thoroughly. Debian maintainers are simply not doing that. They're doing the minimum to maintain the package. I assume that it's similar with maintainers of other distros. We need to know which distributions and users are doing this so we can get feedback about whether it works reliably, and so that we know about a likely explanation for OOS problems. They're trailblazers and guinea pigs, because, as I understand it, use of a system-provided mozjs with 0ad is just not being done by the majority of users currently.

In source/scriptinterface/ScriptTypes.h is a message that the only version of mozjs that works is the one that is bundled with 0ad. Either this message in the source code needs to be updated, or we need to double check the statement that use of a system mozjs is recommended for multiplayer. Also note the warning about the need for testing with any other version of mozjs, which distro maintainers aren't doing. They run the bundled FCollada tests, but they don't do testing of multiplayer or running replays and comparing the final hash. In order for use of differing versions of mozjs to work properly in multiplayer, it needs to not only have the same intended functionality, but it also needs to have bug-for-bug compatibility.

If SolarEagle wants to play 0ad multiplayer then he shouldn't be using anything other than the bundled mozjs, right? Otherwise, even a small difference in how the JavaScript engine functions, such as serialization and deserialization, could cause an out-of-sync condition during multiplayer gameplay.

@implodedok

Can confirm. The last notification email I received was on November 21, 2023 at 01:58 am UTC.