T-hawk
Transcend
I compiled the DLL with the fix. It seemed to work in a quick test. File is here:
http://forums.civfanatics.com/downloads.php?do=file&id=13779
http://forums.civfanatics.com/downloads.php?do=file&id=13779
Final Frontier: Problems & Issues (Post-3.13 Update Available)
- Thread starter Jon Shafer
- Start date
BuDDaH
Chieftain
T-hawk! Good job! I love you! The patch does work. I've played the whole game and enjoyed normal functionality. By the way, AIs, it seemed, developed much better and quicker than in previous games without this patch.
T-hawk, thanks a lot. I'll place a reference to your patch at Russian civfanatics.ru forums, if you don't mind of course.
TC01
Deity
I have discovered a Final Frontier bug that explains a few weird occurances when playing on flat maps:
The code in red is designed to make starbase culture be created on the other side of the map if a starbase is on the edge of the map, because the FinalFrontier mapscript, the only one that was intended to be used in FinalFrontier, was wrapped on both x and y. But if you have a flat mapscript (like FinalFrontierFlat), the culture will still be created on the opposite side of the map!
There needs to be a check there to only do this if the map is wrap x or wrap y. But then, because we might have plots that don't exist that culture is being spread to, the culture should only be spread to if the plot isn't none. I changed it to this:
Code:
def updateStarbaseCulture(self, iPlayer, iX, iY):
# Create culture around unit
for iXLoop in range(iX-2, iX+3):
for iYLoop in range(iY-2, iY+3):
iActiveX = iXLoop
iActiveY = iYLoop
[COLOR="Red"]if (iActiveX < 0):
iActiveX = CyMap().getGridWidth() + iActiveX
if (iActiveY < 0):
iActiveY = CyMap().getGridHeight() + iActiveY[/COLOR]
pLoopPlot = CyMap().plot(iActiveX, iActiveY)
# pPlotLoop = CyMap().plot(iXLoop, iYLoop)
# printd("Setting Player %d as the owner of %d, %d" %(iPlayer, iXLoop, iYLoop))
# Don't override culture that's already here
if (pLoopPlot.getOwner() == -1):
pLoopPlot.setOwnerNoUnitCheck(iPlayer)The code in red is designed to make starbase culture be created on the other side of the map if a starbase is on the edge of the map, because the FinalFrontier mapscript, the only one that was intended to be used in FinalFrontier, was wrapped on both x and y. But if you have a flat mapscript (like FinalFrontierFlat), the culture will still be created on the opposite side of the map!
There needs to be a check there to only do this if the map is wrap x or wrap y. But then, because we might have plots that don't exist that culture is being spread to, the culture should only be spread to if the plot isn't none. I changed it to this:
Code:
def updateStarbaseCulture(self, iPlayer, iX, iY):
# Create culture around unit
for iXLoop in range(iX-2, iX+3):
for iYLoop in range(iY-2, iY+3):
iActiveX = iXLoop
iActiveY = iYLoop
[COLOR="red"]if CyMap().isWrapX():[/COLOR]
if (iActiveX < 0):
iActiveX = CyMap().getGridWidth() + iActiveX
[COLOR="red"]if CyMap().isWrapY():[/COLOR]
if (iActiveY < 0):
iActiveY = CyMap().getGridHeight() + iActiveY
pLoopPlot = CyMap().plot(iActiveX, iActiveY)
# pPlotLoop = CyMap().plot(iXLoop, iYLoop)
# printd("Setting Player %d as the owner of %d, %d" %(iPlayer, iXLoop, iYLoop))
# Don't override culture that's already here
[COLOR="Red"]if not pLoopPlot.isNone():[/COLOR]
if (pLoopPlot.getOwner() == -1):
pLoopPlot.setOwnerNoUnitCheck(iPlayer)
Do i need to put the CPP file in anywhere or do i only need the DLL installed as instructed?
All other fixes have now been added to the B5 Mod. Thank you all for posting the fixes and to God-Emperor for calling my attention to them.
T-hawk
Transcend
You need just the DLL. I included the .cpp just for anyone that wants to see the source or incorporate it into another recompilation of the DLL.
BuDDaH, feel free to distribute on a Russian civ site or anywhere else.
BuDDaH, feel free to distribute on a Russian civ site or anywhere else.
Thanks too.
I was close before stop playing Final Frontier due to the waste of any production overflow from buildings.
However now with your CvGameCoreDLL.dll the fun is back.
Hmm... FF runs quite slower now.
As partially mentioned in this thread, the time between the turn seems to be a real problem for several people, in my case however strange is, the time between the rounds suddenly increased in extreme way (i haven't found anything about this).
Concretely between turn 136 and 137 it took about 10 seconds to wait. Now between turn 137 and 138 it's now over 1 minute !???
I have no clue why, i can't see any clear event to cause this. Well, could it be related on espionage anyhow? However at the moment i only have a few espionage points...
Maybe somebody could enlighten me what's going on/wrong here...
Beside of this, i'm wondering if still somebody feels responsible about improving this (generally great) mod?
Because i've found a bug/lack in the planet selection (when you found the 'city'). It can be improved by a slightly more sophisticated worth-assignment for each the planet.
Also there is something strange about the culture level requirements in the quick playing mode. You only play 2/3 of the normal amount of turns, but the culture you need to reach the next culture level is only 50% of the amount needed in normal mode!? Beside of this culture thresholds are quite low anyway, (much) too low i think - resp. there are too many/strong possiblities to produce culture, in particular if you achieve more than one religion/value.
As partially mentioned in this thread, the time between the turn seems to be a real problem for several people, in my case however strange is, the time between the rounds suddenly increased in extreme way (i haven't found anything about this).
Concretely between turn 136 and 137 it took about 10 seconds to wait. Now between turn 137 and 138 it's now over 1 minute !???
I have no clue why, i can't see any clear event to cause this. Well, could it be related on espionage anyhow? However at the moment i only have a few espionage points...
Maybe somebody could enlighten me what's going on/wrong here...
Beside of this, i'm wondering if still somebody feels responsible about improving this (generally great) mod?
Because i've found a bug/lack in the planet selection (when you found the 'city'). It can be improved by a slightly more sophisticated worth-assignment for each the planet.
Also there is something strange about the culture level requirements in the quick playing mode. You only play 2/3 of the normal amount of turns, but the culture you need to reach the next culture level is only 50% of the amount needed in normal mode!? Beside of this culture thresholds are quite low anyway, (much) too low i think - resp. there are too many/strong possiblities to produce culture, in particular if you achieve more than one religion/value.
God-Emperor
Deity
Does the time between turns stay large? I don't know why, but sometimes the time it takes jumps up by a very large amount for a few turns, and then drops back down to more normal times. It does tend to keep increasing as the game goes on, but it is usually a fairly steady increase.
TC01
Deity
In regards to speed: I moved a lot of the callbacks into the DLL, disabled them, and using my modified DLL, I found things were significantly faster. I played a Huge map game and found that while there is still noticeable lag, it's not nearly as bad as Final Frontier used to be on a huge map.
I know the lag is because of the python callbacks that are normally disabled in BTS, because the pickled arrays for solar systems keep getting larger, because there's a lot of AI in python called every turn for every AI city and many units, and because the onBeginGameTurn and onBeginPlayerTurn functions are heavily used. But I don't know why the lag would suddenly increase and then decrease.
I imagine that killing an AI player would decrease the lag. It would increase whenever a solar system was colonized, especially by the AI, because now the pickled array for solar systems is storing not just system data but also buildings, and there is now another city that needs updating every turn. The more buildings in a system, the slower things get too.
I know the lag is because of the python callbacks that are normally disabled in BTS, because the pickled arrays for solar systems keep getting larger, because there's a lot of AI in python called every turn for every AI city and many units, and because the onBeginGameTurn and onBeginPlayerTurn functions are heavily used. But I don't know why the lag would suddenly increase and then decrease.
I imagine that killing an AI player would decrease the lag. It would increase whenever a solar system was colonized, especially by the AI, because now the pickled array for solar systems is storing not just system data but also buildings, and there is now another city that needs updating every turn. The more buildings in a system, the slower things get too.
...so i just have proceeded my game, and amazingly after ~10 turns the old/shorter duration came back.
Hopefully it remains now short until the end...!
As tested the problem with this suddenly much longer turn/calculation duration also happens with the original DLL/*.py files.
By the way i think too with your DLL from above the duration between the turns is really some shorter
- besides of the 'production overflow fix' i really appreciate.I have checked the map with the world builder (before and after the problem appeared the first time) and there is no evident reason for this lag. It's a small map and the last free solar systems has been colonized several turns ago, also there aren't any newly established starbases. Only cultural borders slightly increased.
TC01
Deity
I think you misunderstood- I didn't make the modified DLL posted in this thread, T-hawk did.
I did, however, create another, unreleased DLL which has allowed me to disable nearly all of the python callbacks which are helping to slow the game down at present (and by disabling them, things speed up). That's what I meant.
I did, however, create another, unreleased DLL which has allowed me to disable nearly all of the python callbacks which are helping to slow the game down at present (and by disabling them, things speed up). That's what I meant.
Uh, sorry, my fault. I hope T-hawk will forgive me the confusion...!?
However it's good to see that several people (still) are engage in this great mod.
Meanwhile I have terminated my second game successfully - even without being nuked, despite of the unique religion/value and 3 wars.
And luckily the long lags between the turns didn't come back again.
T-hawk
Transcend
Heh, no problem. TC01, does your DLL include my overflow fix? If not, feel free to add it.
TC01
Deity
Yes, it does.
You can find my modmod here. It doesn't just include a new DLL- but a lot of bugfixes from this thread (including the AI stuff that was just discovered recently), and a lot of community Final Frontier content- like four new mapscripts.
And of course, things are a lot faster now too. I played a test game with it on a huge map. And while I don't have any statistics because I didn't actually time the lag between turns, the mod is definitely faster. And that's on a Huge map...
You can find my modmod here. It doesn't just include a new DLL- but a lot of bugfixes from this thread (including the AI stuff that was just discovered recently), and a lot of community Final Frontier content- like four new mapscripts.
And of course, things are a lot faster now too. I played a test game with it on a huge map. And while I don't have any statistics because I didn't actually time the lag between turns, the mod is definitely faster. And that's on a Huge map...
I didn't know there was such a mod project. However it looks very interesting.
Well i hope you don't mind it, but for another release maybe once, could you add possibly the planet name the GUI?
So when you hold the mouse above there would be planet name plus yield information.
This easily could be done CvGameUtils.py, which is already part of your modmod:
Of course, this is rather cosmetic but the planets usually have funny/spacy names. 
Another thing that is maybe more critical gameplay-wise: If there are a small earth and a medium earth in the inner orbit of a solar system, then it may happen that getBestPlanetInSystem(pSystem) gives you the smaller planet because this function doesn't respect planet size.
This is a bit annyoing, it's nice you get the mine and nutriation facility for free but it leaves the impression they would be would be better invested on the bigger earth.
So after some minutes playing with my pocket calculator, i have changed the old formula:
...into...:
In this context to mention perhaps, as i found out pPlanet.getPlanetSize() returns 0 for the smallest planet and 2 for the biggest size. And this approach really worked fine until THE FORGE appeared with their start handicap of -1 food. The Forge really has problems to expand if not on a earth-like 3/1/2 planet, also form them it's not so expensive to build a further mine (due to their start bonus).
This matter could be 'solved' with food * 150 and planetSize + 8, but i myself couldn't insert a TRAIT_THE_FORGE condition in this function.
Well, this is just a proposal and there are surely more sophisticated ways to solve this problem - unfortunately i just can't find my math book about economical operation research.
However basically i just think the planet size should be included too anyhow.
Well i hope you don't mind it, but for another release maybe once, could you add possibly the planet name the GUI?
So when you hold the mouse above there would be planet name plus yield information.
This easily could be done CvGameUtils.py, which is already part of your modmod:
Code:
szHelpText = localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP_0", (iFood, iProduction, iCommerce))
Code:
szHelpText = pPlanet.getName() + "\n" + localText.getText("TXT_KEY_FF_INTERFACE_PLANET_SELECTION_HELP_0", (iFood, iProduction, iCommerce))Another thing that is maybe more critical gameplay-wise: If there are a small earth and a medium earth in the inner orbit of a solar system, then it may happen that getBestPlanetInSystem(pSystem) gives you the smaller planet because this function doesn't respect planet size.
This is a bit annyoing, it's nice you get the mine and nutriation facility for free but it leaves the impression they would be would be better invested on the bigger earth.
So after some minutes playing with my pocket calculator, i have changed the old formula:
Code:
iValue = (pPlanet.getBaseYield(0) * 2) + pPlanet.getBaseYield(1)...into...:
Code:
iValue = ( (pPlanet.getBaseYield(0) * 75) + (pPlanet.getBaseYield(1) * 35) + (pPlanet.getBaseYield(2) * 10) )
iValue *= (pPlanet.getPlanetSize() + 4)
# VALUE/ORDER OF PLANETS:
# Planet 3,1,2,2 = 1400 (Earth Mid)
# Planet 2,2,1,3 = 1380 (Yellow Large)
# Planet 2,2,1,2 = 1150 (Yellow Mid)
# Planet 3,1,2,1 = 1120 (Earth Small)
# Planet 2,0,3,3 = 1080 (Sugar Large)
# Planet 1,2,3,3 = 1050 (Copper Large)
# Planet 1,1,6,3 = 1020 (Gold Large)
# Planet 2,0,3,2 = 900 (Sugar Mid)
# Planet 1,2,3,2 = 875 (Copper Mid)
# Planet 1,1,6,2 = 850 (Gold Mid)
# Planet 0,3,3,3 = 810 (Stone Large)
# Planet 0,2,5,3 = 720 (Blue Large)
# Planet 0,3,3,2 = 675 (Stone Mid)
# Planet 0,2,5,2 = 600 (Blue Mid)In this context to mention perhaps, as i found out pPlanet.getPlanetSize() returns 0 for the smallest planet and 2 for the biggest size. And this approach really worked fine until THE FORGE appeared with their start handicap of -1 food. The Forge really has problems to expand if not on a earth-like 3/1/2 planet, also form them it's not so expensive to build a further mine (due to their start bonus).
This matter could be 'solved' with food * 150 and planetSize + 8, but i myself couldn't insert a TRAIT_THE_FORGE condition in this function.
Code:
iValue = ( (pPlanet.getBaseYield(0) * 150) + (pPlanet.getBaseYield(1) * 35) + (pPlanet.getBaseYield(2) * 10) )
iValue *= (pPlanet.getPlanetSize() + 8)
# VALUE/ORDER OF PLANETS:
# Planet 3,1,2,2 = 4545 (Earth Mid)
# Planet 3,1,2,1 = 4040 (Earth Small)
# Planet 2,2,1,3 = 3800 (Yellow Large)
# Planet 2,2,1,2 = 3420 (Yellow Mid)
# Planet 2,0,3,3 = 3300 (Sugar Large)
# Planet 2,0,3,2 = 2970 (Sugar Mid)
# Planet 1,2,3,3 = 2500 (Copper Large)
# Planet 1,1,6,3 = 2450 (Gold Large)
# Planet 1,2,3,2 = 2250 (Copper Mid)
# Planet 1,1,6,2 = 2205 (Gold Mid)
# Planet 0,3,3,3 = 1350 (Stone Large)
# Planet 0,3,3,2 = 1215 (Stone Mid)
# Planet 0,2,5,3 = 1200 (Blue Large)
# Planet 0,2,5,2 = 1080 (Blue Mid)Well, this is just a proposal and there are surely more sophisticated ways to solve this problem - unfortunately i just can't find my math book about economical operation research.
However basically i just think the planet size should be included too anyhow.
TC01
Deity
There wasn't such a mod until I released it this morning. I've actually been working on it for a month or so, I was just fixing whatever bugs I had created. (That's discounting my time working on Wormholes and FF Worldbuilder).
I'd be happy to add both your changes. If you have any specific suggestions, you could post them in the main mood thread as well.
I've actually been working on it for a month or so, I was just fixing whatever bugs I had created. (That's discounting my time working on Wormholes and FF Worldbuilder).I'd be happy to add both your changes. If you have any specific suggestions, you could post them in the main mood thread as well.
God-Emperor
Deity
Here's another bug, minor but irritating. (Fixed for myself about over a month ago, but I forgot to mention it here.)
When you capture a star system it does not update the choice of planet where things are currently being built. If the previous owner has it set to a planet not in the innermost influence area it will remain set to that planet unless you change it yourself. This allows you to build things on a planet that is not currently within the system's influence related borders.
Fix: somewhere near the end of the onCityAcquired function in CvFinalFrontierEvents.py (I put it just before the line that says "AI.doCityAIUpdate(pCity)") add this:
When you capture a star system it does not update the choice of planet where things are currently being built. If the previous owner has it set to a planet not in the innermost influence area it will remain set to that planet unless you change it yourself. This allows you to build things on a planet that is not currently within the system's influence related borders.
Fix: somewhere near the end of the onCityAcquired function in CvFinalFrontierEvents.py (I put it just before the line that says "AI.doCityAIUpdate(pCity)") add this:
Code:
# Set the default selected & building planet to the best one
pBestPlanet = pSystem.getPlanetByIndex(getBestPlanetInSystem(pSystem))
pSystem.setSelectedPlanet(pBestPlanet.getOrbitRing())
pSystem.setBuildingPlanetRing(pBestPlanet.getOrbitRing())God-Emperor
Deity
This situation is addressed starting about one page back.
There is a bug which keeps overflow from working when producing buildings. A new DLL has been posted that corrects this problem.
