God-Emperor
Deity
Well, I don't KNOW that there is one, but it seems to me that there ought to be one.
Bug Thread
- Thread starter TC01
- Start date
Well, I don't KNOW that there is one, but it seems to me that there ought to be one.
The attached savegame shows 2 exceptions.
It's from a freshly installed 1.7 Full + 1.71 patch.
BUG Options exception
... you should see it when loading the save.
City Razing results in exception
Just end the turn, and see presumably the pirates raze some unknown city.
It's from a freshly installed 1.7 Full + 1.71 patch.
BUG Options exception
... you should see it when loading the save.
City Razing results in exception
Just end the turn, and see presumably the pirates raze some unknown city.
God-Emperor
Deity
Interestingly, I don't see either problem. My version of FFP has only one slight difference from the released version.
The issue may be two extraneous files in Assets/Python that I have deleted from my installation of FFP (as per the first part of post 168 in this thread). BUG seems to still load these two files which seems to result in bad versions of some event handlers and such being loaded in addition to the correct versions.
So try removing these two files from the mod's "Final Frontier Plus\Assets\Python" folder:
CvFinalFrontierEvents.py
and
CvGameUtils.py
The first one has been replaced by the FinalFrontierEvents.py file, and the second by FinalFrontierGameUtils.py. The originals from Final Frontier exist because the installer starts by copying the FF mod and then overwrites it (well, it does that if you use the smaller "requires FF to still exist on your computer" version - I don't know if the other one has these two files).
Then see if the exceptions still happen. With a little luck, this simple removal of extraneous files will fix it.
I'm beginning to think that perhaps I should not have used the new file names when I merged BUG in - it would have avoided this "extraneous files" problem if I had stuck with the original names. (At the time, I was thinking that I should have also changed the CvSolarSystem.py file to a different name. The renaming was done because of some significant differences in how things work from regular FF and previous versions of FFP.)
The issue may be two extraneous files in Assets/Python that I have deleted from my installation of FFP (as per the first part of post 168 in this thread). BUG seems to still load these two files which seems to result in bad versions of some event handlers and such being loaded in addition to the correct versions.
So try removing these two files from the mod's "Final Frontier Plus\Assets\Python" folder:
CvFinalFrontierEvents.py
and
CvGameUtils.py
The first one has been replaced by the FinalFrontierEvents.py file, and the second by FinalFrontierGameUtils.py. The originals from Final Frontier exist because the installer starts by copying the FF mod and then overwrites it (well, it does that if you use the smaller "requires FF to still exist on your computer" version - I don't know if the other one has these two files).
Then see if the exceptions still happen. With a little luck, this simple removal of extraneous files will fix it.
I'm beginning to think that perhaps I should not have used the new file names when I merged BUG in - it would have avoided this "extraneous files" problem if I had stuck with the original names. (At the time, I was thinking that I should have also changed the CvSolarSystem.py file to a different name. The renaming was done because of some significant differences in how things work from regular FF and previous versions of FFP.)
TC01
Deity
Well, there are these two bugs, which I fixed for the unreleased 1.72:
I also made a batch script and got it integrated with the (again, unreleased) 1.72 installer that will delete those two Python files.
The only reason I haven't released 1.72 yet is the extra solar systems mapscript bug. I don't suppose anyone's figured out what's wrong? Because if I can't fix it soon I'll just releas 1.72 as is.
I also made a batch script and got it integrated with the (again, unreleased) 1.72 installer that will delete those two Python files.
The only reason I haven't released 1.72 yet is the extra solar systems mapscript bug. I don't suppose anyone's figured out what's wrong? Because if I can't fix it soon I'll just releas 1.72 as is.
God-Emperor
Deity
Oh, right. I forgot about both of those (even though I reported them). I have both of them fixed in my copy too, so that would explain why I didn't see that.
It's good that you figured out how to script that. The other option would have been to go back to the old names for them and change the BUG configuration files to use those. But being able to script stuff could come in handy in the future, should any other such issues arise.
I guess I have more changes in my copy than I had thought.
So, to quote Professor Farnsworth, "Good news everyone!" With most of the bug fixes that have been found for issues in 1.71 in place, the save loads and runs fine. For me, anyway. (I have not fixed the incorrect messages for half of the "first unit of type X built messages - other than that, I think I have fixes in place for all of the reported in-game issues.)
As for the map regeneration issue, it is probably a mix of both retained mapscript data and retained solar system data (since the arrays and counters related to that are not cleared when starting a game except when loading a save). I have not really tried tracking it all down yet.
It's good that you figured out how to script that. The other option would have been to go back to the old names for them and change the BUG configuration files to use those. But being able to script stuff could come in handy in the future, should any other such issues arise.
I guess I have more changes in my copy than I had thought.
So, to quote Professor Farnsworth, "Good news everyone!" With most of the bug fixes that have been found for issues in 1.71 in place, the save loads and runs fine. For me, anyway. (I have not fixed the incorrect messages for half of the "first unit of type X built messages - other than that, I think I have fixes in place for all of the reported in-game issues.)
As for the map regeneration issue, it is probably a mix of both retained mapscript data and retained solar system data (since the arrays and counters related to that are not cleared when starting a game except when loading a save). I have not really tried tracking it all down yet.
God-Emperor
Deity
The issue in post #152, which predates 1.7, is still present.
To recap the issue: If the pirates capture and hold a star system long enough they might build a squadron factory there (and if they capture more than one they may be forced to do so via the build override python) and after that they may try to (or be forced to) build squadrons - except that they can't build squadrons since their civilization has the unit types set to "none" for those unit classes. This causes the current code to make calls that use invalid unit type numbers (-1) in the canTrain function call which causes a Python exception (of the unknown C++ error type) in two places.
The fix in post #152 avoids this problem, not only for the pirates but for any civ that might be added to the mod (or in any mod-mod) that can't build squadrons of one or both types.
The new line numbers for the lines to change in CvAI.py are now 933 and 980 (instead of 925 and 972).
To recap the issue: If the pirates capture and hold a star system long enough they might build a squadron factory there (and if they capture more than one they may be forced to do so via the build override python) and after that they may try to (or be forced to) build squadrons - except that they can't build squadrons since their civilization has the unit types set to "none" for those unit classes. This causes the current code to make calls that use invalid unit type numbers (-1) in the canTrain function call which causes a Python exception (of the unknown C++ error type) in two places.
The fix in post #152 avoids this problem, not only for the pirates but for any civ that might be added to the mod (or in any mod-mod) that can't build squadrons of one or both types.
The new line numbers for the lines to change in CvAI.py are now 933 and 980 (instead of 925 and 972).
Got a double leaderhead python error when called by Pritchard/Paradise later in the same 1.71 game:
Savegame attached, just load & end turn
Code:
Traceback (most recent call last):
File "BugUtil", line 695, in <lambda>
File "DiplomacyUtil", line 223, in handleAIComment
File "DiplomacyUtil", line 238, in dispatchEvent
File "DiplomacyUtil", line 185, in dispatch
File "DiplomacyUtil", line 132, in <lambda>
File "PlayerUtil", line 307, in getFavoriteCivic
AttributeError: 'CvLeaderHeadInfo' object has no attribute 'getFavoriteCivic'
ERR: Python function beginDiplomacy failed, module CvDiplomacyInterface
Code:
Traceback (most recent call last):
File "BugUtil", line 695, in <lambda>
File "DiplomacyUtil", line 233, in handleUserResponse
File "DiplomacyUtil", line 238, in dispatchEvent
File "DiplomacyUtil", line 185, in dispatch
File "DiplomacyUtil", line 136, in <lambda>
File "PlayerUtil", line 307, in getFavoriteCivic
AttributeError: 'CvLeaderHeadInfo' object has no attribute 'getFavoriteCivic'
ERR: Python function handleUserResponse failed, module CvDiplomacyInterfaceSavegame attached, just load & end turn
God-Emperor
Deity
OK, with the new version 1.72 I have seen these same sorts of civic related errors, although they are complaining about "getFavoriteCivics", the plural version, now (on line 323 of BUG's PlayerUtil.py).
I did a quick check on the source code in Final Frontier Plus\CvGameCoreDLL and nowhere in there is there a "getFavoriteCivics". The definition for "getFavoriteCivic" has been commented out in CvInfos.h but there is no plural version added in there. So that is not how it works now. Therefore, the issue is that PlayerUtil.getFavoriteCivic() is calling leader.getFavoriteCivics(leader) (looking for a function call in the DLL that doesn't exist) when it should be calling the new PlayerUtil function getFavoriteCivics(leader).
So, the current code for line 323 in PlayerUtil.py is
and the fixed version should be
(Just removing the no longer needed "leader." prefix.)
I did a quick check on the source code in Final Frontier Plus\CvGameCoreDLL and nowhere in there is there a "getFavoriteCivics". The definition for "getFavoriteCivic" has been commented out in CvInfos.h but there is no plural version added in there. So that is not how it works now. Therefore, the issue is that PlayerUtil.getFavoriteCivic() is calling leader.getFavoriteCivics(leader) (looking for a function call in the DLL that doesn't exist) when it should be calling the new PlayerUtil function getFavoriteCivics(leader).
So, the current code for line 323 in PlayerUtil.py is
Code:
favorites = leader.getFavoriteCivics(leader)
Code:
favorites = getFavoriteCivics(leader)(Just removing the no longer needed "leader." prefix.)
Sadly, 1.72 gives me an exception upon building a starbase.
Savegame is attached.
Savegame is attached.
Code:
Traceback (most recent call last):
File "CvScreensInterface", line 961, in forceScreenRedraw
File "CvMainInterface", line 1309, in redraw
File "CvMainInterface", line 1765, in updatePlotListButtons
File "PLE", line 321, in updatePlotListButtons_PLE
File "PLE", line 1401, in displayUnitPlotListObjects
RuntimeError: unidentifiable C++ exception
ERR: Python function forceScreenRedraw failed, module CvScreensInterface
Traceback (most recent call last):
File "CvScreensInterface", line 961, in forceScreenRedraw
File "CvMainInterface", line 1309, in redraw
File "CvMainInterface", line 1765, in updatePlotListButtons
File "PLE", line 321, in updatePlotListButtons_PLE
File "PLE", line 1390, in displayUnitPlotListObjects
AttributeError: 'NoneType' object has no attribute 'getButton'This isn't really a bug more a question of I've done something in XML that is affecting Pythons ability to function.
In CvAI.py there is a line of code as follows -
This is basically a check to get the AI to build a carrier. The problem is that in the B5 mod I have restricted a lot of ships so that they cannot be built until such time as they have access to a resource. So, even though the Civ has the tech required to build the carrier, it can't as it has no access to that resource yet.
The question then is this causing the problem? Attached is the screen shot from when I experienced the error message.
In CvAI.py there is a line of code as follows -
Code:
if ( pPlayer.canTrain( iCarrierIUnit, true, false) ) :
# It is important to note that we can only get here if the city already has
# a Capital Shipyard (otherwise we'd have to check for one)This is basically a check to get the AI to build a carrier. The problem is that in the B5 mod I have restricted a lot of ships so that they cannot be built until such time as they have access to a resource. So, even though the Civ has the tech required to build the carrier, it can't as it has no access to that resource yet.
The question then is this causing the problem? Attached is the screen shot from when I experienced the error message.
God-Emperor
Deity
The most likely situation is that some civ simply can't construct a unit of that type at all so its "iCarrierIUnit" value is actually -1. This happens for any civ that has the unit type for the unit class set to NONE in the Units section of CIV4CivilizationInfos.xml. This situation was an oversight on my part when I converted it to allow for unique units.
This is actually the same type of bug as mentioned in post 187 and 152. There is an easy fix for this specific type of bug.
That code on that line should actually be this:
Pretty much anywhere that is is using the unit type returned by function to retrieve a civilization's unique unit (via pCivilization.getCivilizationUnits) and then feeds the result into the pPlayer.canTrain function this check for a -1 value needs to be done first since canTrain does not deal with a -1 value as well as one might hope.
In regular FFP this only happens for the pirates when they have captured a star system or two and are building stuff the normal way since in FFP only the pirates are (currently) prevented from building units via the UU = NONE method.
It is possible for a similar issue to arise for buildings if a civ is prevented from producing building types with the same type of method.
This is actually the same type of bug as mentioned in post 187 and 152. There is an easy fix for this specific type of bug.
That code on that line should actually be this:
Code:
if ((iCarrierIUnit != -1) and pPlayer.canTrain( iCarrierIUnit, true, false) ) :In regular FFP this only happens for the pirates when they have captured a star system or two and are building stuff the normal way since in FFP only the pirates are (currently) prevented from building units via the UU = NONE method.
It is possible for a similar issue to arise for buildings if a civ is prevented from producing building types with the same type of method.
God-Emperor
Deity
I have been attempting to solve this particular problem, apparently without much success. It happens when there is another unit at the same location when a starbase is completed and that unit is currently selected when the starbase is built. Why creating the list of buttons for the units on the plot it somehow has a unit that passes checks I have added to make sure it is a valid unit but then fails as above with the claim that it is not a valid unit anymore. I have not yet found a way to definitely identify these "undead" units prior to the function call.
****
Uh-Oh. I just checked what checks were being done and the version of the Python\Screens\PLE.py file in version 1.72 does not have my additional checks. These additional checks may not completely fix the problem, but they do at least seem to make it less likely to happen (it may have happened to me once since adding them).
(There are two posts in the FFPBUG beta thread about this issue.)
So something for v1.73: it needs the version of PLE.py from the FFPBUG beta that has 2 extra checks on line 290.
God-Emperor
Deity
2 more multiple favorite civics bugs, with fix:
1) After doing my last fix in post 189 I must not have hit the conditions again since there is still a bug in PlayerUtils.py:
On line 304, in getFavoriteCivics, the "gc.getNumCivics()" should be "gc.getNumCivicInfos()".
2) The Info tab on the Foreign Advisor screen fails because it is trying to display the favorite civic icons for each leader using the old method.
The simple 3 step fix:
add a line up in the imports list to "import PlayerUtil"
fix line 487 (new line number after adding import line), the code should now be:
fix line 686 to also read:
The more complicated, but better, fix for this would be to show all of the favorite civics. There is room for more than one on the screen, although I'm not sure how many it could show since there is a modifier that is shown if you are using their favorite civic (I'm assuming the diplo modifier is applied for each of them, so it needs to have enough space to show it for each). I'm guessing it has room for at least 3 and maybe as many as 5 (which is more than FFP needs since it only has 4 categories) without changing any screen width, column spacing, icon size, or font settings.
1) After doing my last fix in post 189 I must not have hit the conditions again since there is still a bug in PlayerUtils.py:
On line 304, in getFavoriteCivics, the "gc.getNumCivics()" should be "gc.getNumCivicInfos()".
2) The Info tab on the Foreign Advisor screen fails because it is trying to display the favorite civic icons for each leader using the old method.
The simple 3 step fix:
add a line up in the imports list to "import PlayerUtil"
fix line 487 (new line number after adding import line), the code should now be:
Code:
nFavoriteCivic = PlayerUtil.getFavoriteCivic(iLoopPlayer)
Code:
nFavoriteCivic = PlayerUtil.getFavoriteCivic(iLoopPlayer)The more complicated, but better, fix for this would be to show all of the favorite civics. There is room for more than one on the screen, although I'm not sure how many it could show since there is a modifier that is shown if you are using their favorite civic (I'm assuming the diplo modifier is applied for each of them, so it needs to have enough space to show it for each). I'm guessing it has room for at least 3 and maybe as many as 5 (which is more than FFP needs since it only has 4 categories) without changing any screen width, column spacing, icon size, or font settings.
I've changed the code on the line as you have instructed but am still getting exactly the same error message. There are no specific requirements to build a Capital Shipyard, the Bomber Squadrons section has been commented out and the Carriers and Fighters lines changed as instructed. Besides the CivAI.py are there any other .py files that these lines appear in?
God-Emperor
Deity
Wen it throws a Python exception the problem pretty much has to be on the line that the Python exception says it is on, although it could ultimately come from a line that is executed before that which is improperly setting up (or changing) some variable that it is trying to use.
Are you sure that that is the line 868 the error is indicating?
By the way, you could probably remove all the code relating to carriers too since the AI never actually puts a squadron on a carrier. Because of that it is not really a good plan to actually force it to build one. At the time I put it in, I was hoping there would be an easy fix for this problem, but nobody has found one yet (easy or otherwise).
God-Emperor
Deity
The bug in the onCityRazed callback is not actually fixed.
Line 1235 of FinalFrontierEvents.py should be using iBuildingLoop instead of just iBuilding.
Line 1235 of FinalFrontierEvents.py should be using iBuildingLoop instead of just iBuilding.
TC01
Deity
Ugh. I really need a version control system...
...speaking of which, do you (or anyone else, I guess, who might at some point need to use) have any preferences as to what service we should use? I was thinking Sourceforge with subversion, but that's just because I know svn.
God-Emperor
Deity
Multiple production does not appear to work.
I never get more than one thing and the city screen's production hover shows the overflow from the previous turn being larger than the cost to make the next item (when attempting to build multiple missiles, which are cheap).
I never get more than one thing and the city screen's production hover shows the overflow from the previous turn being larger than the cost to make the next item (when attempting to build multiple missiles, which are cheap).
God-Emperor
Deity
I think the multiple production issue is caused by some missing code in CvCity::doProduction.
It looks like there ought to be a section inside the "if (isProduction())" code to check the game option and do what it is currently doing if the option is not active, and do something "multiple production related" if it is active (involving a loop that runs as long as there is still enough production to finish the next item, unless it hits something in the queue that is not allowed to use multiple production).
It looks like there ought to be a section inside the "if (isProduction())" code to check the game option and do what it is currently doing if the option is not active, and do something "multiple production related" if it is active (involving a loop that runs as long as there is still enough production to finish the next item, unless it hits something in the queue that is not allowed to use multiple production).
