I have a infernal save linked at the top of page 4 of this thread where infernal player can make a very easy city capture.
OOS Discussion, Tracking and Fixing
- Thread starter Tholal
- Start date
I have a infernal save linked at the top of page 4 of this thread where infernal player can make a very easy city capture.
Yes. Here is a new DLL that includes the OOS fix and a few other things as well.
Thanks a ton!!
Oh, sorry, I missed it. Thank you! It has been very helpful. I have used Fr8Train's savegame to obtain logs for the "OOS on infernal conquest" error, which are attached to this post. As Tholal suspected, the cause is indeed the free Infernal buildings gotten on conquest:
I can confirm that moving the code you mention in that post to the onCityAcquired method in CvEventManager prevents the OOS error when the Infernals conquer a city. I'm guessing that this code was in onCityAcquiredAndKept because of the religion changes. If the religion of the city was changed to Ashen Veil just before razing it, the Infernals would be forced to reduce the Armageddon Counter whenever they razed a city, and that would be very unfortunate. I suggest moving only the building changes and removing the religion changes. The onCityDoTurn method will take care of switching the religions in the next turn without doing weird things to the Armageddon Counter, anyways. I'm also attaching the modified CvEventManager file that fixes the OOS error.
I just checked this in Fr8Train's savegame. Trading a city to the Infernals causes no OOS errors. Razing a city as the Infernals causes no OOS error either.
I suspect that the real cause of onCityAcquiredAndKept causing an OOS error in the specific case of conquering a city is that the decision to keep it is made by a popup that is probably not multiplayer safe. That's why it is not causing OOS error when called from other places.
Modifying this method to use sendModNetMessage (like the the "Declare war on the barbarians" spell and other already fixed "OOS error because of popup" errors do) and doing all of the required stuff for onCityAcquiredAndKept in CvEventManager.onModNetMessage instead should also work.
I still prefer the first solution I suggested because IMO there is no real need to use onCityAcquiredAndKept for the Infernal conquer code. Adding the buildings before taking the decision will also have the nice side effect of making the scoreboard display the right points for the civilization when the dialog asking if you want to keep the city is shown, and also after conquering and after razing a city. Judging from the logs, it will also calculate the final total player assets of keeping the city properly (I don't know how the AI chooses to raze or keep cities, though).
Shortly after making this post I will add a link to it as a comment in the tracker issue.
EDIT: To my knowledge only the puppet states OOS error remains. Any savegames?
![[to_xp]Gekko](https://civfanatics-data.community.forum/avatars/m/74/74677.jpg?1475248346){kind=avatar}
[to_xp]Gekko
QCT junkie
what he said
I'm posting here a version of my Testing Guide tailored for More Naval AI. I wasn't sure about the bits about Assert errors (in ExtraModMod I have been released beta versions with asserts enabled) but I left them in for this first version. The log filenames it mentions are the ones from the improved logging patches I submitted so I think this guide should be meant for 2.53.
I added the guide as a concept page ingame in ExtraModMod. Once that the offline version reaches a definitive version it should be easy to code this for More Naval AI too if there is interest for it.
--------------
Testing Guide
This guide is meant for anyone who is interested on being able to provide more information along with bug reports, in order to help with improving More Naval AI.
Configuration
Civilization IV allows to enable the generation of different files that can be very helpful in order to check why a certain bug happened. To enable them, you need to modify your CivilizationIV.ini file (usually found in the "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword" folder). The following values should be set from 0 to 1:
GenerateCrashDumps: Generates a dmp file when the game crashes to desktop. These dumps are very useful for debugging crash to desktop (CtD) errors.
LoggingEnabled: Allows the game to create logs. This is essential for reporting all kind of bugs.
SynchLog: Enables synchronization logging. These logs are specially important for checking errors in multiplayer games.
OverwriteLogs: Logs are overwritten each time the game is restarted. This allows to discard old logs easily, but bear in mind that you should copy any logs related to an issue before you restart the game or they will be lost.
RandLog: Enables random event logging. These logs are specially important for checking errors in multiplayer games.
Additionally, the following values should be set from 1 to 0:
HidePythonExceptions: Disabling this will allow to show python errors ingame.
When playing with beta builds, it is strongly advised to set the following option to 0:
FullScreen: Controls if the game will be shown on fullscreen or not. When playing with a build that will display Asserts (like beta versions), it is better to put the game in a window as sometimes Assert windows will lock the game if it is in fullscren.
When a player enables logging and logs into a multiplayer game, other players will get a message saying "Player X has logging enabled. Verify that this is a trusted player". I don't know why the game throws this warning (logging seems harmless to me) but if you are playing with more people they should be aware of why this message is being shown. Bear in mind that in order to debug OOS issues properly all players should enable logging.
Logs appear in the "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword\Logs" folder.
Reporting bugs
Bugs can be reported in either the Bug Tracker by creating a new issue and uploading all pertinent information, or directly at More Naval AI's bug reports thread. OOS errors should be reported in the bug tracker or in the OOS discussion thread. In the following sections of this document you can find more information on how to report each kind of issue.
If you are unsure about which kind of issue you are experiencing (or it just does not fit into any of the types described below), just make a report including a description of the issue explaining what you think that went wrong along with any information you think that is relevant. Keep a backup of the "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword\Logs" folder just in case any of them is relevant of the issue (you will be asked for specific files in that case).
Assert errors
Asserts are warnings that may be the cause of bugs. They are only shown when playing with beta versions. Assert errors can appear either when the game is being initialized or during a game, and they appear on popup windows that look like this:
It is possible for MapScripts to cause assert errors. These errors will happen during map generation or, in the case of using MapScriptTools, while the game is being initialized. In these cases, you can safely ignore the assert. In all other cases, assert errors should always be reported. It is usually enough information to copy the text inside of the assert error window and paste it on the bug report. If the error happened right after something specific was done, it is also helpful to know about it.
Python errors
When HidePythonExceptions is disabled, python errors are shown ingame in a popup like the one shown below:
It is possible to get multiple popups on top of each other instead of a single one. In the case of a python error, it is better to provide the log files PythonDbg.log and specially PythonErr.log in the bug report than a screenshot of the error.
AI errors
You may notice the AI doing something weird or just wrong. In this case, the bug report should include a description of what you consider wrong, what you expected, a screenshot showing the problem (or even better, a savegame) and the "BBAILog - (PLAYERNAME).log" file.
Crash to Desktop
When the whole game crashes, every log (the entire contents of "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword\Logs") should be included in the bug report. If the game allows you to generate a crash dmp file, always select "generate a full dump" and attach it to the bug report too. dmp files appear after a CtD in the folder in which Civ4BeyondSword.exe is in. For complete editions of Civilization IV, this folder is: "C:\Program Files (x86)\2K Games\Firaxis Games\Sid Meier's Civilization 4 Complete\Beyond the Sword".
OOS errors
OOS errors happen only in multiplayer games. They are the hardest ones to reproduce and fix, and therefore any information about them is very welcome. OOS errors are very noticeable when they happen; all players will see a big notice announcing the OOS in red letters in the bottom part of their screen. To report an issue of this type, the SynchLog and the OOSLog of **EACH PLAYER** (called "SynchLog - (PLAYERNAME)" and "OOSLog - (PLAYERNAME) - Turn N.txt" respectively) are required. The "BBAILog - (PLAYERNAME).log" file should also be sent, if present, as OOS errors may sometimes be caused by errors in the logic of the AI code. An autosave from a few turns before is also very useful.
I added the guide as a concept page ingame in ExtraModMod. Once that the offline version reaches a definitive version it should be easy to code this for More Naval AI too if there is interest for it.
--------------
Testing Guide
This guide is meant for anyone who is interested on being able to provide more information along with bug reports, in order to help with improving More Naval AI.
Configuration
Civilization IV allows to enable the generation of different files that can be very helpful in order to check why a certain bug happened. To enable them, you need to modify your CivilizationIV.ini file (usually found in the "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword" folder). The following values should be set from 0 to 1:
GenerateCrashDumps: Generates a dmp file when the game crashes to desktop. These dumps are very useful for debugging crash to desktop (CtD) errors.
LoggingEnabled: Allows the game to create logs. This is essential for reporting all kind of bugs.
SynchLog: Enables synchronization logging. These logs are specially important for checking errors in multiplayer games.
OverwriteLogs: Logs are overwritten each time the game is restarted. This allows to discard old logs easily, but bear in mind that you should copy any logs related to an issue before you restart the game or they will be lost.
RandLog: Enables random event logging. These logs are specially important for checking errors in multiplayer games.
Additionally, the following values should be set from 1 to 0:
HidePythonExceptions: Disabling this will allow to show python errors ingame.
When playing with beta builds, it is strongly advised to set the following option to 0:
FullScreen: Controls if the game will be shown on fullscreen or not. When playing with a build that will display Asserts (like beta versions), it is better to put the game in a window as sometimes Assert windows will lock the game if it is in fullscren.
When a player enables logging and logs into a multiplayer game, other players will get a message saying "Player X has logging enabled. Verify that this is a trusted player". I don't know why the game throws this warning (logging seems harmless to me) but if you are playing with more people they should be aware of why this message is being shown. Bear in mind that in order to debug OOS issues properly all players should enable logging.
Logs appear in the "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword\Logs" folder.
Reporting bugs
Bugs can be reported in either the Bug Tracker by creating a new issue and uploading all pertinent information, or directly at More Naval AI's bug reports thread. OOS errors should be reported in the bug tracker or in the OOS discussion thread. In the following sections of this document you can find more information on how to report each kind of issue.
If you are unsure about which kind of issue you are experiencing (or it just does not fit into any of the types described below), just make a report including a description of the issue explaining what you think that went wrong along with any information you think that is relevant. Keep a backup of the "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword\Logs" folder just in case any of them is relevant of the issue (you will be asked for specific files in that case).
Assert errors
Asserts are warnings that may be the cause of bugs. They are only shown when playing with beta versions. Assert errors can appear either when the game is being initialized or during a game, and they appear on popup windows that look like this:
It is possible for MapScripts to cause assert errors. These errors will happen during map generation or, in the case of using MapScriptTools, while the game is being initialized. In these cases, you can safely ignore the assert. In all other cases, assert errors should always be reported. It is usually enough information to copy the text inside of the assert error window and paste it on the bug report. If the error happened right after something specific was done, it is also helpful to know about it.
Python errors
When HidePythonExceptions is disabled, python errors are shown ingame in a popup like the one shown below:
It is possible to get multiple popups on top of each other instead of a single one. In the case of a python error, it is better to provide the log files PythonDbg.log and specially PythonErr.log in the bug report than a screenshot of the error.
AI errors
You may notice the AI doing something weird or just wrong. In this case, the bug report should include a description of what you consider wrong, what you expected, a screenshot showing the problem (or even better, a savegame) and the "BBAILog - (PLAYERNAME).log" file.
Crash to Desktop
When the whole game crashes, every log (the entire contents of "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword\Logs") should be included in the bug report. If the game allows you to generate a crash dmp file, always select "generate a full dump" and attach it to the bug report too. dmp files appear after a CtD in the folder in which Civ4BeyondSword.exe is in. For complete editions of Civilization IV, this folder is: "C:\Program Files (x86)\2K Games\Firaxis Games\Sid Meier's Civilization 4 Complete\Beyond the Sword".
OOS errors
OOS errors happen only in multiplayer games. They are the hardest ones to reproduce and fix, and therefore any information about them is very welcome. OOS errors are very noticeable when they happen; all players will see a big notice announcing the OOS in red letters in the bottom part of their screen. To report an issue of this type, the SynchLog and the OOSLog of **EACH PLAYER** (called "SynchLog - (PLAYERNAME)" and "OOSLog - (PLAYERNAME) - Turn N.txt" respectively) are required. The "BBAILog - (PLAYERNAME).log" file should also be sent, if present, as OOS errors may sometimes be caused by errors in the logic of the AI code. An autosave from a few turns before is also very useful.
Attachments
CurseUppl
The bureaucracy expands.
ing lovely. Gonna give the game a swing with a friend.Kurios and puppet states still buggered?
Thanks for all the hard work, I really appreciate it. It's been a long time since I could enjoy some FFH multiplayer with infernals.
*edit* lol censorship
UPDATES
Fixes - OOS caused by the Kuriotates being played by a human player will be fixed in ver 2.53. This release will also fix the OOS caused when the Infernals capture a city.
New Issue - OOS when a player uses Hyborem's Whisper (human player only or does it also happen when the AI uses the spell?) - original report here
I believe that I found the cause of the Puppet States OOS error; as I suspected it is making game changes on a popup. On line 383 of CvDLLButtonPopup.cpp, you can see that it directly calls makePuppet instead of using CvMessageControl like the other buttons. Before playtesting if this is really the source of error and providing a fix, I wanted to know if you have plans to include Version 1.6 of Puppet States. This version moves the problematic code (but it does not fix the OOS) and I don't want to provide a fix if it is going to cause future code conflicts.
Nope.
To my knowledge, the last OOS that is still present in the game is produced when a puppet state is created. Last time I already found a probable cause of this OOS, but in order to fix it I need a multiplayer savegame in which it is possible to create a puppet state in that same turn. Does anybody have a savegame like this for the latest MNAI beta? If so, let me know and you will save me a lot of time!
To my knowledge, the last OOS that is still present in the game is produced when a puppet state is created. Last time I already found a probable cause of this OOS, but in order to fix it I need a multiplayer savegame in which it is possible to create a puppet state in that same turn. Does anybody have a savegame like this for the latest MNAI beta? If so, let me know and you will save me a lot of time!
I doubt that you'll find anybody with such save because people avoid having puppet states enabled in multiplayer precisely because it causes OOS.
Not everyone knows that. Also, maybe someone who knew would want to help in getting a savegame for testing. But I have thought of a quick and painless way to test this so now there is no need for a savegame anymore
Similar threads
- Sticky
