TC01
Deity
Okay, I'll merge everything and update probably either tonight or some time tomorrow (depending on how much time I have).
Bug Thread
- Thread starter TC01
- Start date
God-Emperor
Deity
Uh-oh. The number of pirate ships is insane. Noble difficulty, standard size Final Frontier map, start of turn 36, and according to the Python console a getNumUnits() on the Pirate player shows that they have 428 units. Ouch.
So I think the barb fix is a tad off.
I see the problem: It no longer divides the number of unowned tiles by the the iDivisor value, which is the number of unowned tiles per barbarian (and cut in half, to double the result, if set to raging barbarians). Without this, the number of barbarians is many times what it should be - like about 120 times as many on Noble difficulty (which tells me that in that test game the total would have been 3 or 4 instead of 428 if the divisor was in use)...
So my "I think the comment's version is correct" comment was not quite right since the comment didn't include the divisor.
What is currently says (which includes the previous version:
What I think the equation should actually have been:
On the other hand, as long as its being fixed again...
I'm thinking that this might make too big of a jump in pirates from the first era to the second since ((int)GC.getGame).getCurrentEra() + 1)) jumps from 1 to 2 (since the era starts at 0 rather than 1). To reduce the relative size of the jump perhaps it should use +2 instead of +1. This would change the progression from 1, 2, 3, 4 for the 4 eras to 2, 3, 4, 5. To counteract this increase, the values for iUnownedTilesPerBarbarianUnit would be doubled for each handicap level (which doubles the value of iDivisor) so the result for the first era would be the same as it is now, and the second era would have a target that is (theoretically, not accounting for the shrinking number of unowned tiles) 50% more instead of double and then progressing up to a (theoretically, again) 2.5 times as many in the last era instead of 4 times as many (I expect this to usually end up only a little above the first era's count once the lower number of unowned tiles is taken into account).
So I think the barb fix is a tad off.
I see the problem: It no longer divides the number of unowned tiles by the the iDivisor value, which is the number of unowned tiles per barbarian (and cut in half, to double the result, if set to raging barbarians). Without this, the number of barbarians is many times what it should be - like about 120 times as many on Noble difficulty (which tells me that in that test game the total would have been 3 or 4 instead of 428 if the divisor was in use)...
So my "I think the comment's version is correct" comment was not quite right since the comment didn't include the divisor.
What is currently says (which includes the previous version:
Code:
// Change way max number of barbarian units is generated
// Target = (Number of Unowned Tiles * (Current Era + 1)) - Num Barbs
// To get actual value, subtract rand number less than half the Target
/* Old Code:
iNeededBarbs = ((pLoopArea->getNumUnownedTiles() / iDivisor) - pLoopArea->getUnitsPerPlayer(BARBARIAN_PLAYER)); XXX eventually need to measure how many barbs of eBarbUnitAI we have in this area...
New Code:*/
int iNumBarbs = pLoopArea->getUnitsPerPlayer(BARBARIAN_PLAYER);
int iTarget = (pLoopArea->getNumUnownedTiles() * ((int)GC.getGame().getCurrentEra() + 1)) - iNumBarbs;
// int iTarget = ((pLoopArea->getNumUnownedTiles() / iDivisor) - iNumBarbs ) * ((int)GC.getGame().getCurrentEra() + 1);
// Buggy version, kept for historical purposesWhat I think the equation should actually have been:
Code:
int iTarget = (pLoopArea->getNumUnownedTiles() / iDivisor * ((int)GC.getGame).getCurrentEra() + 1)) - iNumBarbs;On the other hand, as long as its being fixed again...
I'm thinking that this might make too big of a jump in pirates from the first era to the second since ((int)GC.getGame).getCurrentEra() + 1)) jumps from 1 to 2 (since the era starts at 0 rather than 1). To reduce the relative size of the jump perhaps it should use +2 instead of +1. This would change the progression from 1, 2, 3, 4 for the 4 eras to 2, 3, 4, 5. To counteract this increase, the values for iUnownedTilesPerBarbarianUnit would be doubled for each handicap level (which doubles the value of iDivisor) so the result for the first era would be the same as it is now, and the second era would have a target that is (theoretically, not accounting for the shrinking number of unowned tiles) 50% more instead of double and then progressing up to a (theoretically, again) 2.5 times as many in the last era instead of 4 times as many (I expect this to usually end up only a little above the first era's count once the lower number of unowned tiles is taken into account).
TC01
Deity
Okay, will do all that for a hotfix.
The pirate issue is still there. I'm playing a Monarch game, and the pirates have been relentless.
I can handle them, especially now that I have learned to use influence and squadrons as recon units to safely reduce the fog. However, the AI cannot handle them.. I'm up to turn 225 now, and the pirates are taking over star by star.
There have been just one war between the civs, which I won easily when the other poor guys second star was captured by pirates. Everyone is busy fighting the pirates, and the AI is losing.
It was fun, but it is a bit tedious to do all the squadron recon every turn. Would have been more fun if the AI was competent at fighting the pirates too.
I can handle them, especially now that I have learned to use influence and squadrons as recon units to safely reduce the fog. However, the AI cannot handle them.. I'm up to turn 225 now, and the pirates are taking over star by star.
There have been just one war between the civs, which I won easily when the other poor guys second star was captured by pirates. Everyone is busy fighting the pirates, and the AI is losing.
It was fun, but it is a bit tedious to do all the squadron recon every turn. Would have been more fun if the AI was competent at fighting the pirates too.
Agreed, the AI doesn't seem to like building planetary defense type units even when you weight them heavily. In the B5 mod they stick with the free orbital defense unit at game start until it's destroyed and only add to the defense with units that are mobile. E.G. Transports or Recon units both of which are poor in defence against the early pirate/alien units.
God-Emperor
Deity
New bug report:
The civic option to reduce the cost of units bases on their unit combat does not work - the costs stay the same.
Technically, it applies a 1% discount to all units for all civics that have this set to -1 (or in the hopefully impossible event that the array in the civic info is null, since it returns a -1 for that too). Since I don't think this is happeneing, I assume that the default is 0 rather than -1.
The problem would be on line 5845 of CvPlayer.cpp
This applies the discount only if it is == -1. This ought to apply the discount if it is != -1.
While I was looking at this, I noticed that it is needlessly looping over all the unitcombat values. Since it only does something for the unitcombat that is equal to the unit type in question's unit combat the loop is not needed, as long as you remember that some units have no unitcombat and those shouldn't be checked (this was the net effect of the loop, since units with no unitcombat wouldn't find a match in the loop).
Streamlined version:
(Untested, of course.)
The civic option to reduce the cost of units bases on their unit combat does not work - the costs stay the same.
Technically, it applies a 1% discount to all units for all civics that have this set to -1 (or in the hopefully impossible event that the array in the civic info is null, since it returns a -1 for that too). Since I don't think this is happeneing, I assume that the default is 0 rather than -1.
The problem would be on line 5845 of CvPlayer.cpp
Code:
if (GC.getCivicInfo(eCivic).getUnitCombatCostMods(iUnitCombat) == -1)While I was looking at this, I noticed that it is needlessly looping over all the unitcombat values. Since it only does something for the unitcombat that is equal to the unit type in question's unit combat the loop is not needed, as long as you remember that some units have no unitcombat and those shouldn't be checked (this was the net effect of the loop, since units with no unitcombat wouldn't find a match in the loop).
Streamlined version:
Code:
//Added in Final Frontier SDK: TC01
// Gets unit cost mods from civics used by the player
// This eliminates python getUnitCostMod callback in CvGameUtils
int iCivicOption, iUnitCombat, iCostMod;
CivicTypes eCivic;
for (iCivicOption = 0; iCivicOption < GC.getNumCivicOptionInfos(); ++iCivicOption)
{
eCivic = getCivics((CivicOptionTypes)(iCivicOption));
iUnitCombat = GC.getUnitInfo(eUnit).getUnitCombatType();
if (iUnitCombat != NO_UNITCOMBAT)
{
if (GC.getCivicInfo(eCivic).getUnitCombatCostMods(iUnitCombat) != -1)
{
iCostMod = 100 + GC.getCivicInfo(eCivic).getUnitCombatCostMods(iUnitCombat);
iProductionNeeded *= iCostMod;
iProductionNeeded /= 100;
}
}
}
//End of Final Frontier SDKdeanej
Deity
Found a bug in the No Aliens gameoption:
The plot function takes x,y coordinates of a plot... no idea what is being shoved into it here.
Code:
pAlien = CyMap().plot(i)God-Emperor
Deity
Never saw this since I have never used the No Aliens option...
That should be "CyMap().plotByIndex(i)".
That should be "CyMap().plotByIndex(i)".
TC01
Deity
See the post directly above yours.
plot(x, y) gives you plot (x, y), whereas plotByIndex(i), gives you plot number i. I haven't fixed this yet- deanej ran into it earlier though.
God-Emperor
Deity
As per the discovery over in the FFP-BUG merge thread, worldbuilder saves are having their mapscript name come through in lowercase which defeats the check to see if it is not a worldbuilder save. Therefore they are not loading right. Every time you load one, it thinks it is not a WB save and therefore generates a second random star system for each star system feature and appends it to the end of the list, and then it generates a new set of planetary resources and applies them causing mismatches between what tags are shown on the map and what is on the planets.
The fix posted there is what is needed here too.
The fix posted there is what is needed here too.
God-Emperor
Deity
TC01, do you have a Debug build of the current DLL handy?
In a test game I have stumbled across a crash to desktop type bug that I have not been able to identify. There is nothing in any log file that seems related - the PythonErr.log file is empty and the PythonDbg.log file ends with no hint. I suspect it is a DLL issue.
This is with FFPBUG, but it does not appear to be specific to the merge. You'll need the merge beta installed to run the savegame. (Actually, any FFPBUG save should probably work without the BUG stuff by just copying FFP into the expected mod folder called "Final Frontier Plus BUG", but I haven't actually tried it.)
I have looked around with WorldBuilder and done some fiddling, like deleting any ship that could go through a wormhole, but so far have not managed to stop it from crashing although I have not tried deleting entire civilizations or even "cities". (It was during the messing with this that I discovered the WB file loading issues I posted about earlier.)
Here is the saved game. Just hit the end turn button and it should crash like it does for me.
In a test game I have stumbled across a crash to desktop type bug that I have not been able to identify. There is nothing in any log file that seems related - the PythonErr.log file is empty and the PythonDbg.log file ends with no hint. I suspect it is a DLL issue.
This is with FFPBUG, but it does not appear to be specific to the merge. You'll need the merge beta installed to run the savegame. (Actually, any FFPBUG save should probably work without the BUG stuff by just copying FFP into the expected mod folder called "Final Frontier Plus BUG", but I haven't actually tried it.)
I have looked around with WorldBuilder and done some fiddling, like deleting any ship that could go through a wormhole, but so far have not managed to stop it from crashing although I have not tried deleting entire civilizations or even "cities". (It was during the messing with this that I discovered the WB file loading issues I posted about earlier.)
Here is the saved game. Just hit the end turn button and it should crash like it does for me.
TC01
Deity
I can make a debug DLL in a minute or so.
But- I've already done some changes to the stock 1.651 DLL, which could be a problem: I added the Pirate Hordes ("Bugged Barbarians") gameoption, I merged one of the modcomps, I began merging Sephi's speed modcomp...
I should be able to build a 1.651 debug DLL though if you want one.
But- I've already done some changes to the stock 1.651 DLL, which could be a problem: I added the Pirate Hordes ("Bugged Barbarians") gameoption, I merged one of the modcomps, I began merging Sephi's speed modcomp...
I should be able to build a 1.651 debug DLL though if you want one.
God-Emperor
Deity
I was hoping you already had one and could run the save to see where it dies, as I have no clue as to what the problem is.
The log files just end - there is no Python exception reported.
The most common cause of the sudden crash to desktop seems to be missing art, but CivCheck showed nothing unusual.
That leaves me thinking it is something in the DLL, but I don't know for sure.
The log files just end - there is no Python exception reported.
The most common cause of the sudden crash to desktop seems to be missing art, but CivCheck showed nothing unusual.
That leaves me thinking it is something in the DLL, but I don't know for sure.
God-Emperor
Deity
I just did an interesting test...
I renamed my Final Frontier Plus BUG folder. I then copied Final Frontier Plus and named the copy Final Frontier Plus Bug.
The savegame that I posted above loaded with two small Python exceptions that didn't cause it to die. The first was caused by the Tutorial data. In regular FFP the Tutorial data is picked and stored in the CyGame script data. In FFPBUG the BUG component has data in a dictionary that it pickles and stored in the CyGame script data and the Tutorial data is added to that dictionary. That means the data loading didn't get the Tutorial data (a Python exception happens when it trys to interpret the data incorrectly). The second was during the auto-save to the WorldBuilder file, WBQuickSave.CivBeyondSwordWBSave, that it always does when you start or load a savegame. When the non-BUG version tried this it reports that the latin-1 codec can't encode a character, which would be the delta character in a unit name (an issue that is fixed in the BUG version).
Other than that, it appears to have loaded correctly.
I click "end turn". Instant crash, just like in the FFPBUG case. I think this makes it somewhat unlikely to be BUG or merge related, and much more likely that it is some problem with the DLL (which is the same version in both cases).
I renamed my Final Frontier Plus BUG folder. I then copied Final Frontier Plus and named the copy Final Frontier Plus Bug.
The savegame that I posted above loaded with two small Python exceptions that didn't cause it to die. The first was caused by the Tutorial data. In regular FFP the Tutorial data is picked and stored in the CyGame script data. In FFPBUG the BUG component has data in a dictionary that it pickles and stored in the CyGame script data and the Tutorial data is added to that dictionary. That means the data loading didn't get the Tutorial data (a Python exception happens when it trys to interpret the data incorrectly). The second was during the auto-save to the WorldBuilder file, WBQuickSave.CivBeyondSwordWBSave, that it always does when you start or load a savegame. When the non-BUG version tried this it reports that the latin-1 codec can't encode a character, which would be the delta character in a unit name (an issue that is fixed in the BUG version).
Other than that, it appears to have loaded correctly.
I click "end turn". Instant crash, just like in the FFPBUG case. I think this makes it somewhat unlikely to be BUG or merge related, and much more likely that it is some problem with the DLL (which is the same version in both cases).
TC01
Deity
Well, I can install 1.651 and build a DLL out of the source code.
Not that convenient, but I will do it.
EDIT: Your save won't even load for me.
I get a Runtime Error when trying it... installed BUG 4.4, then stock FF+ 1.651, then FFPBUG.
I can build a DLL though.
EDIT 2: Odd, I redownloaded the save and it worked. Hmm. Weird.
Not that convenient, but I will do it.
EDIT: Your save won't even load for me.
I get a Runtime Error when trying it... installed BUG 4.4, then stock FF+ 1.651, then FFPBUG.
I can build a DLL though.
EDIT 2: Odd, I redownloaded the save and it worked. Hmm. Weird.
TC01
Deity
Built debug DLL, loaded save, found problem. 
It's an access violation exception in CvPlot::getFeatureType(). That means that the plot instance getFeatureType() is being called on doesn't exist.
The call is coming from DoGravityField- the code Kiwikaz added for feature effects. Specifically, it occurs when checking the plots around a gravity field for the presence of a black hole.
I've fixed it by adding some checks to make sure the plot is not null before trying to get the feature type.
My guess is that a black hole is close enough to the edge of a map that some of the plots the loop is running through are invalid.
Also, I got a load of assert failures which may be helpful to you in debugging FFPBUG:
It's an access violation exception in CvPlot::getFeatureType(). That means that the plot instance getFeatureType() is being called on doesn't exist.
The call is coming from DoGravityField- the code Kiwikaz added for feature effects. Specifically, it occurs when checking the plots around a gravity field for the presence of a black hole.
I've fixed it by adding some checks to make sure the plot is not null before trying to get the feature type.
My guess is that a black hole is close enough to the edge of a map that some of the plots the loop is running through are invalid.
Also, I got a load of assert failures which may be helpful to you in debugging FFPBUG:
Code:
ON LOAD:
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_AGGRESSIVE not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_CHARISMATIC not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_CREATIVE not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_FINANCIAL not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_IMPERIALIST not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_INDUSTRIOUS not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_ORGANIZED not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_PHILOSOPHICAL not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_PROTECTIVE not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvglobals.cpp
Line: 3493
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TRAIT_SPIRITUAL not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvplayer.cpp
Line: 11669
Expression: eIndex < GC.getNumCivicOptionInfos()
Message: eIndex is expected to be within maximum bounds (invalid Index)
----------------------------------------------------------
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvteam.cpp
Line: 3451
Expression: eIndex >= 0
Message: eIndex is expected to be non-negative (invalid Index)
----------------------------------------------------------
ON CLICKING NEXT TURN:
Assert Failed
File: f:\civilization 4 mods\sdk stuff\dll 1 bts\1.651 debug dll\cvgamecoredll\cvcity.cpp
Line: 1096
Expression: iCount == getBaseYieldRate((YieldTypes)iI)
Message:
----------------------------------------------------------God-Emperor
Deity
Interesting.
So it was a low probability thing - you have to use a mapscript without wrap and there has to be a black hole that is "too close" to the edge. No wonder my myriad of tests and games never had it happen before - I usually use the maps that wrap.
I was aware of the standard traits appearing in EspionageMissionInfo but have not looked at it yet. I'll have to look into the others too.
So it was a low probability thing - you have to use a mapscript without wrap and there has to be a black hole that is "too close" to the edge. No wonder my myriad of tests and games never had it happen before - I usually use the maps that wrap.
I was aware of the standard traits appearing in EspionageMissionInfo but have not looked at it yet. I'll have to look into the others too.
God-Emperor
Deity
I just checked the map to try and delete an offending black hole and at first look it seemed like there was no black hole close enough to the edge of the map to cause the problem. The closest is along the upper edge near the right, above the Paradise systems. That one is 3 plots from the edge, leaving 1 plot of normal space between the grav-field and the map edge.
That is when I remembered (hopefully correctly) that when there is a unit on it, the grav-field plot itself (or, I suppose, the unit on it) checks the plots within a range of 2 looking for the black hole that it is associated with the grav-field to determine what direction to push the ship, so it would be checking 1 row of plots off the top of the map. Sure enough, there is a Red Syndicate scout sitting in the grav field right there where looking 2 plots north for the black hole would be looking 1 past the edge of the map.
So that must be the one.
Edit: I deleted the black hole with WB and it now runs the turn just fine.
That is when I remembered (hopefully correctly) that when there is a unit on it, the grav-field plot itself (or, I suppose, the unit on it) checks the plots within a range of 2 looking for the black hole that it is associated with the grav-field to determine what direction to push the ship, so it would be checking 1 row of plots off the top of the map. Sure enough, there is a Red Syndicate scout sitting in the grav field right there where looking 2 plots north for the black hole would be looking 1 past the edge of the map.
So that must be the one.
Edit: I deleted the black hole with WB and it now runs the turn just fine.
Similar threads
- Sticky
- Sticky
