I've implemented the B fix (The reason for this is that every ship for every civ is in effect a unique unit. The only common units are the Colony, Construction, Planetary defence and Stealth ships.)but am now getting crashes at end of turn 47 start of turn 48. I've attached the PythonDBug Log, hope this helps. I've added another Debug log from a different playtest in th hopes that an additional log will enable greater fault analysis of the problem.
Final Frontier Plus BUG
- Thread starter God-Emperor
- Start date
I've implemented the B fix (The reason for this is that every ship for every civ is in effect a unique unit. The only common units are the Colony, Construction, Planetary defence and Stealth ships.)but am now getting crashes at end of turn 47 start of turn 48. I've attached the PythonDBug Log, hope this helps. I've added another Debug log from a different playtest in th hopes that an additional log will enable greater fault analysis of the problem.
God-Emperor
Deity
When you say it crashed, do you mean the application just fell over dead, or did it produce one or more Python exception messages?
If it produced Python exceptions, we need to see the PythonErr.log. That file is of interest any time it is not size 0 (it holds all the information showi in the Python exception pop-ups).
If there is no Python exception, then it is a lot harder to figure out what is going wrong. (If there is, what follows is probably not very useful. Even if there isn't it might not be.)
And now we get into the longish rambling part of the post involving the not-so-ancient art of diagnosing mysterious problems via messages on the internet.
In both PythonDbg.log files, the last thing is a message indicating the the windowActivation event happened, which is evidently indicative of the game window being selected or deselected (or probably also leaving or returning to the game if running in full screen mode) - that may not be incredibly helpful. Does the mod have anything in the onWindowActivation event handler? FFP doesn't use this, so it would have to be something added to it. This is probably a red-herring.
In both cases, the next to last thing reported is the "Population which should be assigned on cultural expansion: 0" message for a city. Based on the preceeding messages, it is running the updateHumanCityTurn which was called by the doBeginTurnAI function in FinalFrontierEvents.py. Since the value is 0, it indicates that the AI.doCityUpdate function was not run for that city. The next thing that would happen after that is one of only 3 things before the doBeginTurnAI function ends:
1) Loop to the player's next city. In this case, it would be getting the CyCity instance then printing a message. The message is not present. It is unlikely that getting the CyCity would fail.
2) Running the starbase AI code for each starbase (or other base type), if there are any. This is more likely to be having problems. It does nothing for human controlled starbases. For AI controlled starbases the first thing it does is print a message. No such message is in the file and it is unlikely that checking to see if the player is a human (the only thing in the function before the message) would fail.
3) If there are no starbases, the next (and last) thing in doBeginTurnAI is a check for a random chance of declaring war by calling doAIWarChance if the player is not the human player. There were a number of issues with this function that were revealed from running a debug DLL (it failed some asserts). As far as I know, all of them have been fixed.
None of these seem likely to fail without giving a Python error.
The typical next message in the logs is the BugEventManager report of the cityDoTurn event going off, or sometimes other cityX messages like cityGrowth or cityHurry, or other things like techAcquired. Basically, things done by the DLL over the course of processing the city and the rest of the player's turn. Whatever is going wrong is happening before that next Python event can happen after the beginTurnAI Python event, unless there is a Python exception.
As you can see, guessing what is going wrong is hard.
There is a fair chance that this is not actually related to the unit class default of NONE problem. Doing that last fix for that may have just let you get far enough to have some other problem show up.
At this point, I'm suspecting there is a moderate chance it is an art problem. Why? It's one thing that I know can crash the game suddenly, and it is fairly common.
If it does turn out to be related to the unit class default NONE problem...
You can see why, after all that, if turns out that this is still the problem I suggest you try the other solution - solution A in that last message of mine: removing the NONE as the default unit type. Your ship types are shown in the mod thread as a table with a column for each civ and a row for each ship type (last shown in post 1338 of that thread). Making each row a unit class and each entry in the columns a unit type of that class gets you the UU for each civ, but instead of using a default unit type of NONE you'd just pick one civ to use as the default (probably the Earth Alliance, as the show was mostly focused on the humans - they did build B5, which both the show and the mod are named after, so it's not too surprising the show is mostly about them) and enter its types into the class default field instead of NONE (and you can remove those ship specifications from the civilization info file since they don't need a UU to be specified since the default is their ship type). If there are any classes that the selected default civ doesn't have a ship for, then pick somebody else as the default for that. Any civ that doesnt' have a type for a class gets an entry of NONE in their civilization info's units.
Disadvantage: in the civilopedia there will be references to the chosen default from the others saying essentially "this is a UU version of that other unit" and the default unit will list the others as UUs for the other civs (not much of a disadvantage)
Advantage: it should work (always a good thing)
If it produced Python exceptions, we need to see the PythonErr.log. That file is of interest any time it is not size 0 (it holds all the information showi in the Python exception pop-ups).
If there is no Python exception, then it is a lot harder to figure out what is going wrong. (If there is, what follows is probably not very useful. Even if there isn't it might not be.)
And now we get into the longish rambling part of the post involving the not-so-ancient art of diagnosing mysterious problems via messages on the internet.
In both PythonDbg.log files, the last thing is a message indicating the the windowActivation event happened, which is evidently indicative of the game window being selected or deselected (or probably also leaving or returning to the game if running in full screen mode) - that may not be incredibly helpful. Does the mod have anything in the onWindowActivation event handler? FFP doesn't use this, so it would have to be something added to it. This is probably a red-herring.
In both cases, the next to last thing reported is the "Population which should be assigned on cultural expansion: 0" message for a city. Based on the preceeding messages, it is running the updateHumanCityTurn which was called by the doBeginTurnAI function in FinalFrontierEvents.py. Since the value is 0, it indicates that the AI.doCityUpdate function was not run for that city. The next thing that would happen after that is one of only 3 things before the doBeginTurnAI function ends:
1) Loop to the player's next city. In this case, it would be getting the CyCity instance then printing a message. The message is not present. It is unlikely that getting the CyCity would fail.
2) Running the starbase AI code for each starbase (or other base type), if there are any. This is more likely to be having problems. It does nothing for human controlled starbases. For AI controlled starbases the first thing it does is print a message. No such message is in the file and it is unlikely that checking to see if the player is a human (the only thing in the function before the message) would fail.
3) If there are no starbases, the next (and last) thing in doBeginTurnAI is a check for a random chance of declaring war by calling doAIWarChance if the player is not the human player. There were a number of issues with this function that were revealed from running a debug DLL (it failed some asserts). As far as I know, all of them have been fixed.
None of these seem likely to fail without giving a Python error.
The typical next message in the logs is the BugEventManager report of the cityDoTurn event going off, or sometimes other cityX messages like cityGrowth or cityHurry, or other things like techAcquired. Basically, things done by the DLL over the course of processing the city and the rest of the player's turn. Whatever is going wrong is happening before that next Python event can happen after the beginTurnAI Python event, unless there is a Python exception.
As you can see, guessing what is going wrong is hard.
There is a fair chance that this is not actually related to the unit class default of NONE problem. Doing that last fix for that may have just let you get far enough to have some other problem show up.
At this point, I'm suspecting there is a moderate chance it is an art problem. Why? It's one thing that I know can crash the game suddenly, and it is fairly common.
If it does turn out to be related to the unit class default NONE problem...
You can see why, after all that, if turns out that this is still the problem I suggest you try the other solution - solution A in that last message of mine: removing the NONE as the default unit type. Your ship types are shown in the mod thread as a table with a column for each civ and a row for each ship type (last shown in post 1338 of that thread). Making each row a unit class and each entry in the columns a unit type of that class gets you the UU for each civ, but instead of using a default unit type of NONE you'd just pick one civ to use as the default (probably the Earth Alliance, as the show was mostly focused on the humans - they did build B5, which both the show and the mod are named after, so it's not too surprising the show is mostly about them) and enter its types into the class default field instead of NONE (and you can remove those ship specifications from the civilization info file since they don't need a UU to be specified since the default is their ship type). If there are any classes that the selected default civ doesn't have a ship for, then pick somebody else as the default for that. Any civ that doesnt' have a type for a class gets an entry of NONE in their civilization info's units.
Disadvantage: in the civilopedia there will be references to the chosen default from the others saying essentially "this is a UU version of that other unit" and the default unit will list the others as UUs for the other civs (not much of a disadvantage)
Advantage: it should work (always a good thing)
There are no error messages the game effectively locks up. I have to use the windows key (between Ctrl & Alt keys on left hand side bottom row)to drop the game down whereupon I see the window giving me the option to do a Full Dump, Normal Dump or No Dump. Whichever I select closes the game down.
This has just reminded me of something I see in the main 'City' window. If a city has 3 planets in it's first ring able to support 2 population each (for example) If the city grows to size seven the city window doesn't show that there is an 'idle' or 'unassigned' population point it still shows the 6 population that is working. If the city radius expands the invisible 'unassigned' population point automatically appears on any available planet in the new city radius.
If this is the problem then going into the world builder and seeing what units other Civ's are due to complete on the turn the game crashes should give me an indication of which units artwork is at fault, yes?
