Bug Thread

TC01 · May 26, 2010

This thread is for people to post bugs or strange occurances they think might be a bug. And not just for Final Frontier Plus- feel free to post Final Frontier bugs that need to be fixed here. Also, feel free to post ideas on how bugs can be fixed.

Reported Bugs:

Fixed:

-Final Frontier Plus tab on BUG option screen still doesn't work (missing Python file)
-Capital ship, carrier ship, and missile construction feats display incorrect text
-SpiralGalaxy mapscript creates a lot of (invisible) floodplains
-Python exception when running onCityRazed (iBuilding instead of iBuildingLoop variable used)
-A few icons missing from various places
-Game attempts to load the old, pre-FFPBUG CvGameUtils.py and CvFinalFrontierEvents.py files in addition to the FFPBUG versions
-Python exception on leaderhead screen due to Multiple Favorite Civics

Not Fixed:

-Playing a game, then exiting to main menu, then playing another game can lead either to:
--Python/C++ exceptions and lots of weird errors
--Solar systems being created too close to each other

Before Reporting a Bug:

1. Make sure Beyond the Sword is patched to 3.19. This mod will not run without 3.19 installed. Also make sure you download it from here and not by using the in-game updater.

2. Make sure you have patched Final Frontier Plus to the latest version. The bug you've ran into may be fixed in a future version or patch.

3. Make sure Python exceptions are enabled. To enable them, go into your .ini file (_Civ4Config, it's called, in your Beyond the Sword directory), and search for:

Code:

; Set to 1 for no python exception popups.
HidePythonExceptions = 0

It should be set to 0.

If you get any python exceptions, please post them. This is made easier by enabling logging (see 2).

4. Turn logging on by looking for [DEBUG] in that same file and turn everything related to logging on (by changing the number from a 0 to a 1). Specifically:

Code:

; Enable the logging system
LoggingEnabled = 1

; Enable synchronization logging
SynchLog = 1

; Overwrite old network and message logs
OverwriteLogs = 1

; Enable rand event logging
RandLog = 1

; Enable message logging
MessageLog = 1

These logs will be generated in Beyond the Sword\_Logs (a shortcut link to a folder elsewhere), and be text files ending with ".log". As mentioned, the logs will include a PythonErr.log file which will record all Python exceptions, so instead of trying to copy down any exceptions you get, simply post the contents of that file.

5. If you get a repeatable crash, please post a save game.

dawe1313 · Jun 2, 2010

congrats on the the improvements to one of the best mods for BTS.

i recently got back in to Civ4, and was quite pleased to find this mod. i loved the original FF, and your additions make it even more fun, especially the decreased wait time in between turns. a noticeably major improvement on the standard FF. but i have run across some minor bugs and one major game-breaker.

i have:

Win7 Home 64-bit, core i7-920, 6GB RAM
BTS, manually patched to 3.19
FF+ 1.5 (the smaller file, since i already had FF)
FF+ 1.51 patch

installation went smoothly, with zero problems. starting the mod from a desktop shortcut working just fine, mostly...

Minor Bugs:

'pedia:
- text for omega battle cruiser says"TXT_KEY_CBATTLERUISER...", a simple typo which, when corrected, shows the proper text in the pedia
WorldBuilder:
- buildings added to a system, spawn on every planet, not just the currently selected build planet
- resources added to a system do not show on any planet. so you cannot build the appropriate improvement. this feature works fine for planets generated during the initial map creation, its just not working in the WB.

Maybe Bugs (not sure if it is intentional):

Capitol Buildings:
- not removed from individual planet building list if built somewhere else
Pirates:
- not spawning anything heavier than a destroyer. no stealth, cruisers or battleships

i like playing with raging barbarians, it certainly does make the early game lively

(and of course i did remove the caps for getting XP from barbs...)

now, for the game-breaker:

Map - FF, Huge, VD systems, VD resources, Random Hazards, Conquest victory.

personally, i'm an over-builder. i like to build every building on every planet. having several totally built-up 6-7 planets systems producing wealth lets me gold-rush new system's buildings (Democracy, Planned Economy), support a fairly large fleet, and still make credits faster that i can spend them.

played to the far future era, only one opponent left. he has more systems, i have more production capacity. i was gearing up to star the final war, so i was not pleased when all of the sudden i could not build any more buildings. planets with queues suddenly saying "can no longer build X building". all building buttons on all planets grayed out. units and wealth/culture/science are all that's available.

after spending several hours reading through various FF-based threads and not finding any fix, i decided to report it here. i did find several mentions of suddenly not being able to build more buildings, but no-one ever posted a fix, that i could find.

is there a cap on the number of buildings that can be built hidden somewhere? can it be changed? does it scale with the map size? or is it a fixed number? if i play on smaller/less populated maps, will this not happen?

i attached an autosave from 2-3 turns before this kicked in. i hope you can find the answers to these questions.

God-Emperor · Jun 3, 2010

Thanks for the bug report.

Wow. Over 1000 turns in. That's what you get for disabling every victory except conquest. I don't think I've had one last over 500 in any version of FF (including the original, my "Finaler Frontier" version, or Final Frontier Plus), but I've never disabled any VC. I've also never tried unrestricted leaders. Ordinarily you probably wouldn't be able to get the mix of values you did (getting both Wealth and Survival is highly unlikely) - I expect this is because you are playing on Warlord difficulty.

I ran your save for a few turns (6, I think) and never hit the "can't build buildings anymore" problem.

It is probably due to the extraneous Capitol building you have in one system (Phyrus, I think it was) - it is showing up on the list to the left (which comes from the DLL's info) but not on any planet's list to the right (which come from the Python info). This mismatch of what the Python thinks is in the system and what the DLL thinks is in the system is the usual reason for this problem.

Running your save is the only time I've seen something: the AI actually used doomsday missiles against a star system. On the third (I think) turn of its war it actually dropped 3 of them into a star system, converting 3 out of it's 5 planets into useless glowing cinders (supposedly - I don't think that that this actually removes all the buildings from the affected planet, which it should, and I'm sure it wouldn't remove a resource if there was one). The effects of this needs work.

Minor Bugs:
'pedia:
text for omega battle cruiser says"TXT_KEY_CBATTLERUISER...", a simple typo which, when corrected, shows the proper text in the pedia

I thought I had looks at all of the ship entries to make sure they were all showing up, but I evidently missed this one.

WorldBuilder:
buildings added to a system, spawn on every planet, not just the currently selected build planet
resources added to a system do not show on any planet. so you cannot build the appropriate improvement. this feature works fine for planets generated during the initial map creation, its just not working in the WB.

TC01 would know for sure, but I think the first one of these is how it is currently designed. The second one doesn't surprise me, but should probably be fixed.

Maybe Bugs (not sure if it is intentional):
Capitol Buildings:
not removed from individual planet building list if built somewhere else

This would be a real bug. Moving your capital needs to be checked into.

Pirates:
not spawning anything heavier than a destroyer. no stealth, cruisers or battleships

I have noticed this too. In the unit XML (CIV4UnitInfos.xml) battleships are set to spawn sometimes, but they don't. This is presumably because battleships are disallowed for the Barbarian leader in CIV4CivilizationInfos.xml.

TC01 · Jun 3, 2010

God-Emperor said:
Running your save is the only time I've seen something: the AI actually used doomsday missiles against a star system. On the third (I think) turn of its war it actually dropped 3 of them into a star system, converting 3 out of it's 5 planets into useless glowing cinders (supposedly - I don't think that that this actually removes all the buildings from the affected planet, which it should, and I'm sure it wouldn't remove a resource if there was one). The effects of this needs work.

Indeed- I'll go over the nuke code for the next patch.

TC01 would know for sure, but I think the first one of these is how it is currently designed. The second one doesn't surprise me, but should probably be fixed.

There are two ways to add buildings in Worldbuilder to a city. One method adds them to every planet in the system, one adds them only to the building planet. So yes, it was done by design.

And yes, resources aren't set up properly. That will hopefully be fixed for the next version.

This would be a real bug. Moving your capital needs to be checked into.

Yes- I can see why moving your capitol would cause a problem. This will be changed for the next version.

I have noticed this too. In the unit XML (CIV4UnitInfos.xml) battleships are set to spawn sometimes, but they don't. This is presumably because battleships are disallowed for the Barbarian leader in CIV4CivilizationInfos.xml.

That would be a simple explanation.

However, I thought I removed all checks for spawning barbarian units save the game era, to mimic the Python forced barbarian spawning.

Or maybe something else is wrong. I'll investigate.

dawe1313 · Jun 4, 2010

something else i remembered. there is something wrong with the choose a value system.

when i got Survivalism, i chose the Power value. i could build the School of Zealots, immediately, but not the advocate or shrine. instead i had grayed out Survival Advocate and shrine.

i was unable to build the Power Advocate & shrine until i had the tech that originally gave the Power value. also, i couldn't build the Survival advocate & shrine until i chose Survival value later on.

basically the advocates & shrines are still tied to the original tech, regardless of which value you choose.

God-Emperor said:
I ran your save for a few turns (6, I think) and never hit the "can't build buildings anymore" problem.

It is probably due to the extraneous Capitol building you have in one system (Phyrus, I think it was) - it is showing up on the list to the left (which comes from the DLL's info) but not on any planet's list to the right (which come from the Python info). This mismatch of what the Python thinks is in the system and what the DLL thinks is in the system is the usual reason for this problem.

i was gold rushing every building every turn, unless you were doing that also it probably will take longer for the issue to show up.

the extra capitol on Phyrus come from losing that system to early pirate wave attacks. the capitol automatically jumped to the other system. when i finally got back Phyrus, on the former capitol planet it still showed

Wpulsar · Jun 7, 2010

There seems to be a few bugs and play issues
1) Red syndicate's rapid construction worker is not able to build a sensory array while the other construction workers can, and by the way, the sensory station seems way too big, though that's a personal preference
2)Sensory array also seems to produce missiles once every few turns, is that supposed to happen?
3)The cruiser does not seem to count towards the anger loss experienced when you garrison at least one unit, though again, is that supposed to happen?

TC01 · Jun 7, 2010

Wpulsar said:
3)The cruiser does not seem to count towards the anger loss experienced when you garrison at least one unit, though again, is that supposed to happen?

Interesting. It seems it's been that way since the original version of Final Frontier.

I'm not sure as to why, though. Maybe Jon Shafer intended it to be that way, maybe not. I've "fixed" this for the next version, I suppose it's possible there's a good reason why the Cruiser doesn't provide military happiness... though I doubt it.

The other two bugs you reported are bugs and will be fixed.

Wpulsar · Jun 9, 2010

Thanks thanks. Also for New Earth civilisation, all their solar systems seem to start with 3 populations instead of 2 population as it was in the old Final Frontier and in-game description. I'll keep on posting whatever I find.

TC01 · Jun 9, 2010

Wpulsar said:
Thanks thanks. Also for New Earth civilisation, all their solar systems seem to start with 3 populations instead of 2 population as it was in the old Final Frontier and in-game description. I'll keep on posting whatever I find.

Yes, I noticed (and fixed) this when I was going through everything that was still hardcoded in Python.

It should be that all cities except their capital start with 3 population, I believe.

God-Emperor · Jun 9, 2010

Actually, it should be that all of their cities (including their capital) start with 2 population when they colonize them (it has never had an effect on captured cities). Since you added the bonus population effect to the DLL, it should be entirely removed from the Python. The onGameStart code to add a second population point to their home system was removed, but the code in onCityBuilt is still there.

I was wondering if anybody else had noticed this - it is fixed in the update I expect to post very soon. The update also includes wiping out everything on a planet destroyed by a doomsday missile (buildings and resource if any) - but I have not checked to see what happens if you nuke a capital and wipe out the capitol building. Also AI tweaks including adjusting the "city founding value" to include some value for resources and adding the new resource related buildings and "level 2" population and production buildings (habitation system and nanoextraction upgrade) as things it can select in doCityAIProduction, much like the commercial satellites can be.

TC01 · Jun 9, 2010

God-Emperor said:
Actually, it should be that all of their cities (including their capital) start with 2 population when they colonize them (it has never had an effect on captured cities). Since you added the bonus population effect to the DLL, it should be entirely removed from the Python. The onGameStart code to add a second population point to their home system was removed, but the code in onCityBuilt is still there.

I know- I meant, what's currently happening with the erroneous code is that all cities except the capital get 3 instead of 2 population.

I was wondering if anybody else had noticed this - it is fixed in the update I expect to post very soon. The update also includes wiping out everything on a planet destroyed by a doomsday missile (buildings and resource if any) - but I have not checked to see what happens if you nuke a capital and wipe out the capitol building. Also AI tweaks including adjusting the "city founding value" to include some value for resources and adding the new resource related buildings and "level 2" population and production buildings (habitation system and nanoextraction upgrade) as things it can select in doCityAIProduction, much like the commercial satellites can be.

I suspect that nuking a capital will cause some problems. Calling CyPlayer.findNewCapitol() before destroying the capital would hopefully fix it- this is what the DLL uses when a capitol is destroyed.

God-Emperor · Jun 11, 2010

I have found some bugs in v1.6

1) All ship and squadron upgrades are free.

2) Star Citadels, and probably Star Fortresses, are not centered on the star anymore, their center is in an orbital ring.

3) The new onNukeExplosion does not work - it is using an undefined variable.

I would guess that problem 1 is related to the new upgrade tags.

Problem 2 arises because the special case code to make them centered on the sun instead of a planetary orbit has been removed from both onBuildingBuilt in CvDFinalFrontier.py and updateDisplay in CvSolarSystem.py. This had forced these to not be added to the normal on-screen building list and to use an szBuildingString of "FEATURE_DUMMY_TAG_BUILDING_0", which is not in the array of possible values used for the other buildings that appear on the map (they start at *_1). Currently when it is built it is using setSingleBuildingRingLocation to select a random orbital ring to occupy just like the other buildings.

I am posting some experimental code over in the Development thread to solve #3. I think it is fairly thorough in covering the potential pitfalls and worked OK in my still somewhat limited testing.

There is one more thing that is not exactly a bug, but has serious balance problems:
The priates have Delta Battleships (well, so far I have seen only 1, but where there is 1 I expect there is, or will be, more) showing up in the Expansion era. This is a full era before any non-pirate player can build them.

TC01 · Jun 11, 2010

God-Emperor said:
I have found some bugs in v1.6

1) All ship and squadron upgrades are free.

2) Star Citadels, and probably Star Fortresses, are not centered on the star anymore, their center is in an orbital ring.

3) The new onNukeExplosion does not work - it is using an undefined variable.

I would guess that problem 1 is related to the new upgrade tags.

Problem 2 arises because the special case code to make them centered on the sun instead of a planetary orbit has been removed from both onBuildingBuilt in CvDFinalFrontier.py and updateDisplay in CvSolarSystem.py. This had forced these to not be added to the normal on-screen building list and to use an szBuildingString of "FEATURE_DUMMY_TAG_BUILDING_0", which is not in the array of possible values used for the other buildings that appear on the map (they start at *_1). Currently when it is built it is using setSingleBuildingRingLocation to select a random orbital ring to occupy just like the other buildings.

I am posting some experimental code over in the Development thread to solve #3. I think it is fairly thorough in covering the potential pitfalls and worked OK in my still somewhat limited testing.

There is one more thing that is not exactly a bug, but has serious balance problems:
The priates have Delta Battleships (well, so far I have seen only 1, but where there is 1 I expect there is, or will be, more) showing up in the Expansion era. This is a full era before any non-pirate player can build them.

1. I'm not sure what's wrong with upgrades... unless, for some reason, the upgrade override in the XML is defaulting to 0 instead of -1. I'll look into it, though.

2. I see what's wrong with the Star Fortress.

I had added an XML override

Code:

		#XML override (used for buildings like Star Fortress that take a specific ring) -- TC01
		iXMLOverride = gc.getBuildingInfo(iBuildingType).getSingleRingBuildingLocation()
		if iXMLOverride != -1:
			iRing = iXMLOverride

for the Star Fortress, and I set the <iSingleRingBuildingLocation> (or whatever) in the XML to 0 (because it's "FEATURE_DUMMY_TAG_BUILDING_0). But I forgot that the Python adds 1 to the ring index in updateDisplay.

All that should need to be done is to change the Python to: iRing = iXMLOverride - 1 (because the tag defaults to -1).

3. I'll try your Python code.

4. It's been this way since unmodded Final Frontier, unless I made a mistake with the XML tags. Should it only be the Galactic era?

Wait, so barbarian spawning is working properly now? Interesting.

TC01 · Jun 11, 2010

I see at least one problem with upgrades:

Code:

	int iUpgradeOverride = GC.getUnitInfo(getUnitType()).getUpgradePriceOverride();
	[COLOR="Red"]if (iUpgradeOverride >= -1)[/COLOR]
	{
		if (GC.getUnitInfo(eUnit).isOmega() && !(GC.getUnitInfo(getUnitType()).isDelta()))
		{
			iUpgradeOverride *= 2;
		}
		return iUpgradeOverride;
	}

it shouldn't be ">= -1", it should be "> -1". However, testing shows that units are getting a "0" iUpgradePriceOverride for some reason. So I'm going to change it to "> 0" (while I'm not sure what the bug is, that should at least fix it).

And for the Star Fortress... I realize that what I said still doesn't work (it then looks for location "0" in the array, not FEATURE_DUMMY_TAG_BUILDING_0). For the time being, I guess I'll restore the Python hardcoding for it from Final Frontier, if I can't think of a better idea.

God-Emperor · Jun 11, 2010

TC01 said:
2. I see what's wrong with the Star Fortress.

I had added an XML override

Code:

#XML override (used for buildings like Star Fortress that take a specific ring) -- TC01 iXMLOverride = gc.getBuildingInfo(iBuildingType).getSingleRingBuildingLocation() if iXMLOverride != -1: iRing = iXMLOverride

for the Star Fortress, and I set the <iSingleRingBuildingLocation> (or whatever) in the XML to 0 (because it's "FEATURE_DUMMY_TAG_BUILDING_0). But I forgot that the Python adds 1 to the ring index in updateDisplay.

All that should need to be done is to change the Python to: iRing = iXMLOverride - 1 (because the tag defaults to -1).

I don't think this will solve this specific problem. The FEATURE_DUMMY_TAG_BUILDING_x strings are not being constructed, they are stored in a list. The first thing in the list is FEATURE_DUMMY_TAG_BUILDING_1 at index 0, but to center it on the star it needs to be FEATURE_DUMMY_TAG_BUILDING_0 (which was only present in the special case code, not in the list everything else uses).

Either the list storing these values needs to be rearranged to include the _0 value, the string needs to be constructed instead of pulled from a list, or it still needs to be dealt with as a special case.

4. It's been this way since unmodded Final Frontier, unless I made a mistake with the XML tags. Should it only be the Galactic era?

Wait, so barbarian spawning is working properly now? Interesting.

It looks like it might bedoing so in 1.6, but "properly" is hard to judge. So far I have seen exactly one battleship per run of my test game and it was a delta type that I spotted on turn 136 the first time. I have run the saved game multiple times, the first time was under 1.51+local adjustments, the last couple under 1.6: by the way, 1.6 is save compatible with 1.51 since no new buildings/units/etc. were added. The next time I ran the same game I spotted it in a slightly different location, south of New Paris rather than NW of it, about 2 or 3 turns later (I survived it by attacking with a fighter and 2 bombers a few times). This is a screenshot of the first time I saw one, one turn before I declared war on, and nuked, Halis' capital (using world buildered ships and doomsday missiles, of course - you can see the omega battleship that is escorting the omega cruiser with 3 nukes, and such).

Spoiler :

I suggest having delta battleships in galactic and far future, with the omega version only in the far future (currently set to galactic and far future). Regular battleships are currently defined to be in the expansion era only, which is good.

TC01 · Jun 11, 2010

God-Emperor said:
I don't think this will solve this specific problem. The FEATURE_DUMMY_TAG_BUILDING_x strings are not being constructed, they are stored in a list. The first thing in the list is FEATURE_DUMMY_TAG_BUILDING_1 at index 0, but to center it on the star it needs to be FEATURE_DUMMY_TAG_BUILDING_0 (which was only present in the special case code, not in the list everything else uses).

Either the list storing these values needs to be rearranged to include the _0 value, the string needs to be constructed instead of pulled from a list, or it still needs to be dealt with as a special case.

Realized that... see my post in the Development thread. I set it up to construct the string for this specific case (although making it construct the string in general might be a good idea too).

It looks like it might bedoing so in 1.6, but "properly" is hard to judge. So far I have seen exactly one battleship per run of my test game and it was a delta type that I spotted on turn 136 the first time. I have run the saved game multiple times, the first time was under 1.51+local adjustments, the last couple under 1.6: by the way, 1.6 is save compatible with 1.51 since no new buildings/units/etc. were added. The next time I ran the same game I spotted it in a slightly different location, south of New Paris rather than NW of it, about 2 or 3 turns later (I survived it by attacking with a fighter and 2 bombers a few times). This is a screenshot of the first time I saw one, one turn before I declared war on, and nuked, Halis' capital (using world buildered ships and doomsday missiles, of course - you can see the omega battleship that is escorting the omega cruiser with 3 nukes, and such).

That's promising- since I can't think of any other way a Pirate Delta Battleship would have spawned.

I'm surprised it is save-game compatible. I thought adding XML tags that get written to and read from save games (like buildings and units, among other things) broke it, but evidently not.

I suggest having delta battleships in galactic and far future, with the omega version only in the far future (currently set to galactic and far future). Regular battleships are currently defined to be in the expansion era only, which is good.

I like that idea- will be changed for the next patch (which I'll probably release today, unless some other major bugs are reported soon).

Wpulsar · Jun 12, 2010

good work on the 1.61 patch, fixed quite a few errors. however though the star fortress bug fixed work, the star citadel seems to have disappeared all together despite still being a building. And the squadron defence network is now centred on the sun instead of orbiting it like before. Man, wish i knew some coding so i could help you all ><
*correction: this only occurs in some situations, some star fortress and citadels are still graphically functioning properly, still trying to find out what triggers*

God-Emperor · Jun 12, 2010

It looks to me like in v1.61 all of the on-screen buildings are now being placed on top of the star.

TC01, are you sure that iSingleRingBuildingLocation is being initialized to -1, not 0 (or set to -1 if the tag is not present, at least)? If they were all being set to 0 it would explain everything being put at the center of the system. It seems to me like GetChildXmlValByName itself applies a default value of 0, as seen in

Code:

DllExport bool GetChildXmlValByName(int* piVal, const TCHAR* szName, int iDefault = 0);

on line 93 of CvXMLLoadUtility.h, so the initialized value of -1 in the CvBuildingInfo constructor is probably overwritten by that when the XML is loaded; it looks like that call takes an optional 3rd argument that is the default value to use which should be set to -1 for this. (This could also explain the weirdness in the upgrade cost being 0 issue.)

TC01 · Jun 12, 2010

God-Emperor said:
It looks to me like in v1.61 all of the on-screen buildings are now being placed on top of the star.

TC01, are you sure that iSingleRingBuildingLocation is being initialized to -1, not 0 (or set to -1 if the tag is not present, at least)? If they were all being set to 0 it would explain everything being put at the center of the system. It seems to me like GetChildXmlValByName itself applies a default value of 0, as seen in

Code:

DllExport bool GetChildXmlValByName(int* piVal, const TCHAR* szName, int iDefault = 0);

on line 93 of CvXMLLoadUtility.h, so the initialized value of -1 in the CvBuildingInfo constructor is probably overwritten by that when the XML is loaded; it looks like that call takes an optional 3rd argument that is the default value to use which should be set to -1 for this. (This could also explain the weirdness in the upgrade cost being 0 issue.)

Of course...

Since 0 = false (when translating integers to booleans), it has to be that way. Because all booleans default to false (unless a default is inserted as the third argument). So all integers will default to zero.

That makes sense.

So you would have to change the GetChildXmlValByName call for iSingleRingBuildingLocation to have a third argument of -1 to fix this problem.

God-Emperor · Jun 12, 2010

It also appears to be impossible to actually build an extraction facility. The construction ship accepts the command and spends the time building it, but when it is done there is no extraction facility present. You can "build" them over and over and you never get anything out of it. And no extraction facility = no resource gained, so at the moment the only resources you can actually get are the ones from planets. So far, I know no specific piece of XMl or code to point to for why this is happening. The only difference in the XML for the construction ship is the sound entry, and the build info and improvement info files look identical to those in v1.51. I am guessing that this is a DLL problem, possibly involving the starbase improvement to unit conversion related stuff (something like the extraction facility has no UnitClassBuilt defined, so it is being converted to nothing instead of being kept).

By the way, there is a good workaround for the "stacks all buildings on top of the star" problem: set each of the 3 buildings that should appear on the map orbiting the star (capital shipyard, squadron factory, squadron defense network) to have "<iSingleRingBuildingLocation>-1</iSingleRingBuildingLocation>" at the end of their entries in CIV4BuildingInfos.xml. This solves the problem for new games (or saved games that havn't gotten to the point where any have been built yet). For saved games that have some built already this will cause newly built buildings of those types to be placed correctly except if it is randomly placed in the outermost orbit in which case it will be placed on top of any already built in the system. Existing buildings of those types will all be placed in the outermost orbit (all stacked on top of each other if you have more than one) since they already have a ring value of 0 stored and there is a -1 to that stored value (to convert from the normal "ring" values of 1 to 8 to the list index values of 0 to 7) when selecting the array entry that determines where they actually show up. That makes it use an index of -1 in the list of locations and in Python an index of -1 is the the last entry in a list (negative index values count from the end of the list back towards the beginning).

Bug Thread

Deity

Chieftain

Attachments

Deity

Deity

Chieftain

Chieftain

Deity

Chieftain

Deity

Deity

Deity

Deity

Deity

Deity

Deity

Attachments

Deity

Chieftain

Deity

Deity

Deity

Similar threads