kiwitt
Road to War Modder
Just started playing 1.8 ... no bugs found, except the generic Civ IV bug, i.e. if you task switch back to windows the game crashes sometimes. I simply save my game now, before actually switching back to Windows.
Bug Thread
- Thread starter TC01
- Start date
Imperator Knoedel
Currently obsessed with The Owl House
I don´t know if this point has been mentioned already, but sometimes Starbase culture seems to vanish for one turn, as far as I could tell this seems to happen when I accept a vassal.
I uploaded three saves of a game where this happens, one in the turn of taken Hanji Takeno as vassal before doing so, one afterwards when the culture of my and his starbases vanished, and the third one in the turn afterwards with everything back to normal.
I uploaded three saves of a game where this happens, one in the turn of taken Hanji Takeno as vassal before doing so, one afterwards when the culture of my and his starbases vanished, and the third one in the turn afterwards with everything back to normal.
God-Emperor
Deity
The one turn vanishing culture is not, technically, a bug. It always happens when you accept a vassal, and has done so in every version of FFP and plain old ordinary FF too. It may not be entirely desirable, but it is not a bug.
The issue is that the ownership of the plots caused by a starbase is not done in the DLL, it is done in Python each turn. Normally, in the DLL's determination of plot ownership, only plots withing a city's cultural radius can be owned, but some Python code overrides this and manually (so to speak) forces the ownership of the plots near starbases to be set every turn. When you accept a vassal, the DLL recalculates plot ownership which wipes out the forced assignment that was done for the starbase controlled plots. The Python for the starbases is not run again until the next turn is processed, so the ownership of those plots disappears briefly.
There is one exception to the "ownership not assigned in the DLL" statement. In FFP (not in regular FF) on the turn a starbase or sensor station is built the code in the DLL that creates the unit instead of the improvement also immediately assigns the ownership of plots in the range indicated in the unit's iCultureRange setting, which is why building a sensor station temporarily causes ownership of the plot it is built on. On the other hand, the Python that sets the ownership every turn does not actually use this value and only runs the plot ownership code for starbases, not sensor stations. Not using this value from the XML could be considered a bug, or at least a "design issue". Making it use the value from the XML would allow different types to have different ownership ranges.
The issue is that the ownership of the plots caused by a starbase is not done in the DLL, it is done in Python each turn. Normally, in the DLL's determination of plot ownership, only plots withing a city's cultural radius can be owned, but some Python code overrides this and manually (so to speak) forces the ownership of the plots near starbases to be set every turn. When you accept a vassal, the DLL recalculates plot ownership which wipes out the forced assignment that was done for the starbase controlled plots. The Python for the starbases is not run again until the next turn is processed, so the ownership of those plots disappears briefly.
There is one exception to the "ownership not assigned in the DLL" statement. In FFP (not in regular FF) on the turn a starbase or sensor station is built the code in the DLL that creates the unit instead of the improvement also immediately assigns the ownership of plots in the range indicated in the unit's iCultureRange setting, which is why building a sensor station temporarily causes ownership of the plot it is built on. On the other hand, the Python that sets the ownership every turn does not actually use this value and only runs the plot ownership code for starbases, not sensor stations. Not using this value from the XML could be considered a bug, or at least a "design issue". Making it use the value from the XML would allow different types to have different ownership ranges.
God-Emperor
Deity
Yep, it's a bug. I forgot to add the delta version as a UU for the Red Syndicate, and also forgot to add the upgrade data to the Rapid Construction Ship.
My test game where I was the Red Syndicate evidently didn't quite get that far and I didn't notice the lack of upgrade in the 'pedia.
Attached is a zip file with copies of the two fixed files. You can use them to update the game - they need to replace the existing files of the same names, one in Assets\XML\Civilizations, the other in Assets\XML\Units. (The SVN has been updated.)
Edit: By the way, if you replace the files, savegames will continue to work. However, any existing rapid construction ships won't be able to be upgraded, a side effect of changing data in an on-going game, but any new builds will be the upgraded version.
Thanks for the quick response. 
Not sure if this is a bug or intended, but you can't upgrade starbases when there are missiles on them.
Also found a strange text bug: the unit name (not type) does not always upgrade from delta to omega thus resulting in something like this: delta destroyer 2 (omega destroyer)
it also happens on some planetary defence ships. (possible other ship types as well)
Propably intended, but perhaps unbalanced: inhabitans of planets only use one food
(2 in original Final Frontier), but with a nutrition facility every planet produces one food already. Resulting in an ever growing starsystem as long as you can keep up health till there's eventually a large amount of useless population in a very unhealthy system.
Perhaps more balanced would be 2 food per population, but giving recycling center +2 health... (best would be removing sickness from factory and manufacturing plant per planet, but this may be difficult to code)
Not sure if this is a bug or intended, but you can't upgrade starbases when there are missiles on them.
Also found a strange text bug: the unit name (not type) does not always upgrade from delta to omega thus resulting in something like this: delta destroyer 2 (omega destroyer)
it also happens on some planetary defence ships. (possible other ship types as well)
Propably intended, but perhaps unbalanced: inhabitans of planets only use one food
(2 in original Final Frontier), but with a nutrition facility every planet produces one food already. Resulting in an ever growing starsystem as long as you can keep up health till there's eventually a large amount of useless population in a very unhealthy system.
Perhaps more balanced would be 2 food per population, but giving recycling center +2 health... (best would be removing sickness from factory and manufacturing plant per planet, but this may be difficult to code)
correction on the previous post concerning the name bug:
some ships don't have the delta sign in front of their name, thus no problem there. Those that have the sign don't upgrade it from delta to omega.
No idea why some have a sign in front of their name and others don't...
The construction ship fix seems to work fine.
Robbedem
some ships don't have the delta sign in front of their name, thus no problem there. Those that have the sign don't upgrade it from delta to omega.
No idea why some have a sign in front of their name and others don't...
The construction ship fix seems to work fine.
Robbedem
God-Emperor
Deity
The name problems are an issue with the unit naming feature (regular or advanced) that was added as a part of BUG. Upgrading a ship does not change its assigned name. The BULL mod, which is additional DLL effects that extend the functionality of BUG, allows upgrading to change the name. BULL has not been added to FFP. If you do not use the naming feature, it isn't a problem since the name it shows is actually the unit's type text instead of the unit's name text - that is, the stuff that shows up in parenthesis after the ships name if you do use the naming feature (which might be on by default, I don't remember). The advanced naming also has this problem, but has the advantage that the assigned names are shorter.
Starbases have never been upgradable when they have missiles on them. I'm not exactly sure why (I haven't looked at the code in the DLL) but the issue is that Starbases are defined in the XML to carry squadrons, not missiles. The missiles are forced to be loaded onto them by the Python that creates them, regardless of what the XML says they are supposed to carry. For some unknown reason this prevents upgrading.
As for food, in regular FF each population point also only uses 1 food. As far as I know it has always been that way, but I suppose it could have been changed in a patch (I didn't get BtS until after at least one patch was out and I think it was shortly after 3.17 and probably didn't try FF until after patched to that level). Anyhow, I have occasionally considered bumping the food per population up to 2 and rebalancing food production (especially planet food yields) to suitable levels, but it has never seemed vital. Currently, it is rarely actually necessary to build a nutrition facility (since you start with one on the planet that is initially settled) except sometimes when capturing a star system and losing all of them that were there and in a few rare cases where there is lots of big 0 food planet population capacity, or a bit more often if you are the Forge, although building one on a size 2 or 3 planet can increase your population growth rate significantly.
Starbases have never been upgradable when they have missiles on them. I'm not exactly sure why (I haven't looked at the code in the DLL) but the issue is that Starbases are defined in the XML to carry squadrons, not missiles. The missiles are forced to be loaded onto them by the Python that creates them, regardless of what the XML says they are supposed to carry. For some unknown reason this prevents upgrading.
As for food, in regular FF each population point also only uses 1 food. As far as I know it has always been that way, but I suppose it could have been changed in a patch (I didn't get BtS until after at least one patch was out and I think it was shortly after 3.17 and probably didn't try FF until after patched to that level). Anyhow, I have occasionally considered bumping the food per population up to 2 and rebalancing food production (especially planet food yields) to suitable levels, but it has never seemed vital. Currently, it is rarely actually necessary to build a nutrition facility (since you start with one on the planet that is initially settled) except sometimes when capturing a star system and losing all of them that were there and in a few rare cases where there is lots of big 0 food planet population capacity, or a bit more often if you are the Forge, although building one on a size 2 or 3 planet can increase your population growth rate significantly.
Some more minor and one possible larger bug
- the civics screen says -1
for the 6 largest cities for Mechanized workforce, while in fact it does +1
- when loading a game it sometimes says the military academy increases military production, but can only be built by a great general (their are no great generals in FF)
- for some reason the AI seems to cannibalise their systems to 4, even 1 population, making them practically useless. Even when they have sufficiënt happiness and health to support a larger population.
- in the attached savegame the city Rightcheousness from the Brotherhood has -2 population assigned (it has 8 people on the planets, but only 6 population)
Robbedem
- the civics screen says -1
for the 6 largest cities for Mechanized workforce, while in fact it does +1- when loading a game it sometimes says the military academy increases military production, but can only be built by a great general (their are no great generals in FF)
- for some reason the AI seems to cannibalise their systems to 4, even 1 population, making them practically useless. Even when they have sufficiënt happiness and health to support a larger population.
- in the attached savegame the city Rightcheousness from the Brotherhood has -2 population assigned (it has 8 people on the planets, but only 6 population)
Robbedem
God-Emperor
Deity
Uh-Oh.
Here's a copy of something I just posted in another thread.
As I said, I think the might be the right DLL. But I'm not really sure. I don't remember where it came from. It is the same size as my latest. I'm not certain that missing the changes in that one file would change the size measurably, but I think it should. Using the version of this file from 1.73 would affect performance in a variety of ways including not getting the improved civic evaluation code, the improved ship evaluation for unit AI code, and some other stuff.
Edit: I now strongly suspect this was some local SVN/Tortoise issue with my local working copy that for some reason reverted that one file back to the version that was originally added to the thing
Edit 2: Then again, the copy that was shipped with the mod is the old version so it can't be a recent issue and must have affected TC01 as well...
Here's a copy of something I just posted in another thread.
I have committed the current version of this file to the SVN (trunk, of course).
As I said, I think the might be the right DLL. But I'm not really sure. I don't remember where it came from. It is the same size as my latest. I'm not certain that missing the changes in that one file would change the size measurably, but I think it should. Using the version of this file from 1.73 would affect performance in a variety of ways including not getting the improved civic evaluation code, the improved ship evaluation for unit AI code, and some other stuff.
Edit: I now strongly suspect this was some local SVN/Tortoise issue with my local working copy that for some reason reverted that one file back to the version that was originally added to the thing
Edit 2: Then again, the copy that was shipped with the mod is the old version so it can't be a recent issue and must have affected TC01 as well...
God-Emperor
Deity
Some more minor and one possible larger bug
- the civics screen says -1
I have noticed the before. Repeatedly. I have finally fixed it. There should be a patch released sometime relatively soon that will include this fix.
The Hints inherited a lot of BUG hints when that was merged, some of which are not correct. I do hope to get great generals back into the game at some point (probably renamed as Great Admirals), at which time that particular hint would become less wrong.
Edit: I checked and this is not a BUG hint. It has always been in Final Frontier. Don't know why.
I'm not sure whey this happens all of the times it does. Most, or possibly all, of it happens on the rare occasions when they adopt the Slave State civic (especially the Red Syndicate - it is Korovin's favorite) and proceed to whip and draft with great abandon. For some unknown reason it sometimes does not seem to reassign the remaining population to high food planets to get the population back up - they often stagnate at very low populations.
I can't load the save (protected assets blah blah blah - I have different assets since I have a couple of bugfixes), but have seen this before. It should fix itself when you proceed to the next turn. The population reassignment should happen before the yields are calculated so there should be no extra from the phantom population points. Note the "should" in various places there. It should. But it might not...
TC01
Deity
Aha. This is yet another full download issue- in the full download they can be packaged into the .fpk because there is no base Final Frontier art to overwrite, and I guess I forgot this when preparing the regular download this time around.
Is there any other art that overwrites besides than the contents of Art/Interface/Screens?
Oops. This is definitely something I should have done when implementing iCultureRange in the beginning. I'm going to fix this now and release it as part of 1.81 (which now looks to be either tomorrow or Monday).
Any idea what causes it? I've not heard of this one (at least, not that I can remember.. it's entirely possible I've seen it too back when I played the mod more often).
God-Emperor
Deity
I see it happen from time to time. Typically it is because someone (usually the pirates) has severed a trade route and one or more of my star systems looses access to happy providing resources and suddenly has a few angry population. So, as in the above example, a population 8 system that was at its happy cap is now 2 over the happy cap but still has 8 population assigned to the planets, causing it to show a -2 for the amount of population that can still be assigned to planets.
This really ought to clear itself up the next time you end your turn. I'm not sure if it happens anymore, but I think it may still sometimes linger. I don't know why for sure, but I suspect it is because in updateHumanCityTurn it only runs the update if the calculated number of population to assign is > 0 but the calculation in the above example is likely to come up with a value of -2. If this is correct, the condition could linger indefinitely (until the system changes owner or is nuked, or gets the happy back). I'm thinking that perhaps the end of the updateHumanCityTurn should look more like this:
Code:
if (iUnassigned > 0):
AI.doCityAIUpdate(pCity, iUnassigned)
[COLOR="DarkRed"]elif (iUnassigned < 0):
AI.doCityAIUpdate(pCity)[/COLOR]
God-Emperor
Deity
I'm tempted to say "it's a secret".
Here is one thing I will tell you about. Or, technically, a set of things. It is the main reason for putting it out now instead of probably another week or two. Did you notice the posts where I said there was an SVN glitch and a file was the wrong version for me? It turns out that this was not just something local to me. There was an actual SVN glitch somehow resulting in it showing a file with no modifications, the version originally added to it as far as I can tell, as the latest version. Well, it might not have been a SVN glitch as such - it is possible, I suppose, that I somehow managed to mess the thing up and commit the original version instead of the modified version since I did the last update to it (actually, I think I'm the only one who has touched that particular file since it was put in the SVN). Because of this the DLL for 1.8 was compiled using a file that was old. Therefore version 1.8 of FFP (and your mod too, as it uses it) does not, in fact, have every change that was listed for version 1.8...
The changes that are missing are nice. They can be helpful to the AI's decision making processes for evaluating some civics and sometimes what tech to research next (both due to adding some evaluation of some more of the data moved from Python into the XML, which allows the DLL to see it), give a slight increase in its desired minimum star system defenses, and a bit better determination of what to build for attacks on star systems. And probably some other stuff that isn't coming to me right now. A more complete list of what was supposed to be in, but was not actually in, 1.8 may be given when the patch comes out.
Imperator Knoedel
Currently obsessed with The Owl House
Huh, I do not suppose older saves will work with that new actual 1.8 version, do they?
TC01
Deity
Well, it looks like there was a reason that I left the culture range code in Python rather than doing it in the DLL, because when I move the code to the DLL it doesn't work. Or, rather, it works for the human player but not for the AI- in fact, this means that AI starbases probably don't have culture around them on the turn when they are first created, and if they do I'm not sure why.
I think the problem related to the fact that all we're doing is setting the "owner" of the plot but not setting the plot's culture. That's probably why plots show up with 0% culture but are nevertheless marked as being owned by a player.
I don't have any saves to test with- but since none of the DLL's header files were changed and no new XML stuff was added, it's entirely possible they will.
I think the problem related to the fact that all we're doing is setting the "owner" of the plot but not setting the plot's culture. That's probably why plots show up with 0% culture but are nevertheless marked as being owned by a player.
I don't have any saves to test with- but since none of the DLL's header files were changed and no new XML stuff was added, it's entirely possible they will.
God-Emperor
Deity
Unless TC01 adds something to the patch that I don't know about, it is savegame compatible.
I determined, with certainty instead of just guessing it might have been, that the 1.8 DLL was not built with the correct version of that one file by running the same save with the 1.8 DLL and one I built that I knew was built with the correct version of the file. Using the information available with the cheat code, I looked at the values the AIs were calculating for the Green Economy civic - they were different, and much lower, for the 1.8 DLL therefore it was built with the wrong file since the new file gives it some value for the increased population limit and the old versions didn't. None of the saved data was changed for (or by) the "missing stuff", only some of the logic and constants.
God-Emperor
Deity
Yeah, the Python code runs every turn and reassigns the ownership every time. This is why creating a vassal wipes out the borders from starbases until you progress to the next turn - taking a vassal immediately causes the ownership of plots to be reassessed but the Python for the starbases is not run at that time so the plots they get ownership of are not claimed until the turn is ended.
The DLL only gives plots ownership based on being inside the cultural area of a city. I expect it would take a fair amount of fiddling to get it to get it to do starbases properly.
The Python code for the starbase's plot ownership could used the range specified for that unit type in the XML instead of the current hardcoded +/- 2. That would be much easier than moving it to the DLL.
