Final Frontier: Problems & Issues (Post-3.13 Update Available)

I was having a problem with not having any initial planets in my homeworld for Moo2civ, and the creator suggested something might be wrong with my FF mod. So I checked, and in both FF and Moo2civ I have the same problem. I suspect something in my FF installing is messed up, which raises another problem for me: I'm not in the mood to uninstall/reinstall and patch BTS (have neither the time nor patience).

Is there any other way/place to get the files for FF? I already checked out my BTS disk, and couldn't find a scenarios section, nor could I find a full installation of FF on google (Except for the BTS demo). Or barring that, anyone have an idea why I wouldn't get a homeworld when generating a new map?
 
Enjoju said:
I was having a problem with not having any initial planets in my homeworld for Moo2civ, and the creator suggested something might be wrong with my FF mod. So I checked, and in both FF and Moo2civ I have the same problem. I suspect something in my FF installing is messed up, which raises another problem for me: I'm not in the mood to uninstall/reinstall and patch BTS (have neither the time nor patience).

Is there any other way/place to get the files for FF? I already checked out my BTS disk, and couldn't find a scenarios section, nor could I find a full installation of FF on google (Except for the BTS demo). Or barring that, anyone have an idea why I wouldn't get a homeworld when generating a new map?
Click to expand...

So, your problem is that when you start a game, the solar system with your capital in it has no planets.

Do you have anything installed in your CustomAssets directory, like BUG, by any chance? If you do, you'll have to edit the Final Frontier.ini file so that:

Code: 
; Custom XML and Python from user folder are not loaded
NoCustomAssets = 0

is set to 1.
 
@ TC01

Hey thanks! That was exactly it; I had recently installed the new version of BUG into Custom Assets. Now it's working properly, saving me from tearing the rest of my hair out in frustration :crazyeye:
 
Alerted by fulano I found the following end game bug: there is no end game! If you elimiate the last civ, the game just keeps going. (I've checked: it also happens with FFPlus and Babylon 5 mod. Haven't had the opportunity to confirm this w/Star Trek mod though.)

TC01 said:
So, your problem is that when you start a game, the solar system with your capital in it has no planets.

Do you have anything installed in your CustomAssets directory, like BUG, by any chance? If you do, you'll have to edit the Final Frontier.ini file so that:

Code: 
; Custom XML and Python from user folder are not loaded
NoCustomAssets = 0
is set to 1.
Click to expand...

Thanks - Ill add that to the MOO2Civ Install problems thread. ;)
 
Alerted by fulano I found the following end game bug: there is no end game! If you elimiate the last civ, the game just keeps going. (I've checked: it also happens with FFPlus and Babylon 5 mod. Haven't had the opportunity to confirm this w/Star Trek mod though.)
Click to expand...
I know that with the B5 mod we have disabled the transcendancy victory and as i had never played a game through to total victory, was unaware that there was no endgame victory. I'll have to look into this when i get the time.
 
I found the problem. It's this function in CvGameUtils.py:

Code: 
	def isVictoryTest(self):
		if ( gc.getGame().getElapsedGameTurns() > 10 ):
			return True
		else:
			return False

What it appears to be doing is saying that if there haven't been 10 elapsed turns yet, don't check for victories. I don't know why this is. But what it boils down to is that if you win a victory in less than 10 turns, you don't actually win until the 11th turn. I just played ten turns on a Duel map, then on the eleventh worldbuildered a Battleship III next to my enemy and destroyed him. I won a Conquest victory as expected.

So, yes, it IS because you're all cheating to get the victory earlier.

If you have tests to do regarding victories in FF+, you can use AI Auto Play (which I merged into FF+ when I merged in CAR). Otherwise you can just play out eleven turns- or win and then wait eleven turns.

It's set up this way in regular civ too.
 
TC01 said:
What it appears to be doing is saying that if there haven't been 10 elapsed turns yet, don't check for victories. I don't know why this is.
Click to expand...

That safeguard is to allow time to move your starting settler if you so desire. Otherwise you would lose on turn 0 because you don't have a city. The safeguard is not necessary for Final Frontier because the map script actually does create a city for each player rather than a settler. So you're fine in taking it out for FF.
 
TC01 said:
I found the problem. It's this function in CvGameUtils.py:

Code: 
    def isVictoryTest(self):
        if ( gc.getGame().getElapsedGameTurns() > 10 ):
            return True
        else:
            return False
What it appears to be doing is saying that if there haven't been 10 elapsed turns yet, don't check for victories. I don't know why this is. But what it boils down to is that if you win a victory in less than 10 turns, you don't actually win until the 11th turn. I just played ten turns on a Duel map, then on the eleventh worldbuildered a Battleship III next to my enemy and destroyed him. I won a Conquest victory as expected.

So, yes, it IS because you're all cheating to get the victory earlier.

If you have tests to do regarding victories in FF+, you can use AI Auto Play (which I merged into FF+ when I merged in CAR). Otherwise you can just play out eleven turns- or win and then wait eleven turns.

It's set up this way in regular civ too.
Click to expand...

Ah. Good to know - thanks, TC01! ;)
 
I think I have found out what the occasional severe slowdown in the AI turn processing is, or at least one candiate. I don't know what is causing it, just what it is.

I have found that it can get stuck looping over a single construction ship's unit AI when it is trying to build a starbase. It loops 100 times, exactly, and then moves on. Each time through the loop, it does a full evaluation of the map for rating the locations of a starabse, which involves looping over every plot, if the plot is revealed to the AI it then loops over all the plots in a 5x5 area around it to check for resources (check them to see if they are revealed before checking for the resource) - on a fully reveled map it would check every plot on the map to see if it is reveled 26 times, check each for resources 25 times, and check each to see if it is an asteroid tile once, plus calculate the path distance from each to the civ's capital once. This is bad enough from a time perspective when it does it when it needs to. Doing it 100 times for the "stuck" unit every turn = a whole lot of slowdown. Especially with the debugging active as each time through the loop it writes some 1,375 lines to the log (as usual, more than half of which are empty - presumably it is using a non-Windows end of line character sequence).

As I said, I don't know what causes it. I don't know what makes it stop either. In the test game for which I have debugging logging turned on it has not stopped yet (I'm not sure how long it has been happening, at least half a dozen turns). I'm hoping it will stop after the number of turns it normally takes to build a starbase.
 
It is, ultimately, calling the AI_unitUpdate callback in CvGameUtils.py for the same exact unit 100 times.

The unit is a construction ship that is set to build a starbase. It is at the designated "best" location, as per the ranking system. It gives the "Able to build Starbase, pushing mission & setting override" from doConstructionShipAI in CvAI.py, which printed on the line right before it actually pushes the build mission so it must be doing that.

My current guess is that it is somehow actually in an invalid location to build the improvement (which is converted to the starbase unit when done). I've looked at the rating system and one thing I have noticed is that there isn't any check to see if the plot itself is inside someone else's territory. If the plot is in the territory of a player the AI doesn't have open borders with, I think the CyMap().calculatePathDistance function will return -1 and that is checked for, skipping the plot, but if the AI has open borders that should return a valid distance. Each of the surrounding plots that is checked for a bonus checks to see if the bonus is owned by someone, but I can see how there could be arrangements of tiles where bonuses are in the 5x5 area that are not owned by anyone but the plot where the starbase would be built is. An example would be 3 resources at 3 of the 4 corners of a square located near the edge of another player's territory such that the corner of their territory includes the center plot of the square (but not the 3 resources). Having 3 resources would give the plot a high rating, but it would be impossible to actually build the improvement at that location.

My guess is that when the pushed mission turns out to be impossible, the DLL reruns the AI and has a limit to prevent infinite loops of 100 tries. Since the Python code never does anything different it is stuck. The things which would break the unit out of the loop are if the borders with the other AI are closed or one (or more) of the resources is claimed by someone's expanding borders (or a starbase since the AI that controls the target tile could still build one there).

So, in short (too late), I think the plot rating system in CvAI.findBestResourcePlot needs to check to see if the plot that is being rated is owned by anybody else - not just the bonuses around that plot.
 
OK, I just tested my theory. It is evidently correct.

I modified the findBestResourcePlot function in CvAI.py by adding the following check immediately following the plot visibility check (at line 1045 in the unmoded FF file):
Code: 
			# CP - Check the plot being rated to see if it already belongs to someone else.
			iPlotOwner = pLoopPlot.getOwner()
			if ((iPlotOwner != -1) and (iPlotOwner != iPlayer)):
				continue

I loaded a saved game and ran one turn before doing this and got the large amounts of stuff being logged 100 times and relatively long AI turn processing time.

I then exited to desktop and made the change.

I loaded the same saved game and ran one turn. In the log, the very same construction ship ran a single pass through the algorithm and selected a different plot. It set course for that new plot. The AI turn processing time was noticeably shorter.
 
Yeah, awesome catch! I wanted to play a huge-map builder FF game but was scared off by reports of performance problems. Maybe now I will.

I think I found the 100 loop iterations in the DLL. Check out CvSelectionGroupAI.cpp starting at line 163.

Code: 
while ((m_bGroupAttack && !bFailedAlreadyFighting) || readyToMove())
{
	iTempHack++;
	if (iTempHack > 100)
	{
...
		pHeadUnit->finishMoves();
		break;
	}
...
line 206:	if (pHeadUnit->AI_update())
}

"TempHack" :lol:
 
I tried inserting this (with MOO2Civ):

God-Emperor said:
I modified the findBestResourcePlot function in CvAI.py by adding the following check immediately following the plot visibility check (at line 1045 in the unmoded FF file):
Code: 
            # CP - Check the plot being rated to see if it already belongs to someone else.
            iPlotOwner = pLoopPlot.getOwner()
            if ((iPlotOwner != -1) and (iPlotOwner != iPlayer)):
                continue
Click to expand...

but it resulted in no interface or planets showing up if I start a game.
 
JEELEN said:
I tried inserting this (with MOO2Civ):



but it resulted in no interface or planets showing up if I start a game.
Click to expand...

It's working fine for me... where did you insert it? It needs to go in CvAI.py in findBestResourcePlot under the section titled "If we're supposed to be checking for a player's visibility then only check this plot if it's revealed". I've put the change in red below.

Code: 
	def findBestResourcePlot(self, iPlayer=-1, bCheckForVisibility=false):
		
		pBestPlot = -1
		iBestValue = -1
		
		pPlayer = -1
		iTeam = -1
		if (iPlayer >= 0):
			pPlayer = gc.getPlayer(iPlayer)
			iTeam = pPlayer.getTeam()
		
		printd("\n    Checking for best plot to build a Starbase \n")
		
		for iPlotLoop in range(CyMap().numPlots()):
			pLoopPlot = CyMap().plotByIndex(iPlotLoop)
#			printd("Checking value of plot at %d, %d" %(pLoopPlot.getX(), pLoopPlot.getY()))
			
			# If we're supposed to be checking for a player's visibility then only check this plot if it's revealed
			if (bCheckForVisibility):
				if (not pLoopPlot.isRevealed(iTeam, false)):
					continue

			[COLOR="Red"]# CP - Check the plot being rated to see if it already belongs to someone else.
			iPlotOwner = pLoopPlot.getOwner()
			if ((iPlotOwner != -1) and (iPlotOwner != iPlayer)):
				continue[/COLOR]

I'll add it into the next version of Final Frontier Plus. Thanks, God-Emperor.
 
Remember that Python is white space sensitive. The inserted code needs to have exactly the right level of tabs. If the inserted code is all the way on the left, Python will interpret it as ending higher-level indent and code blocks, which could certainly explain why no interface or planets would show up.
 
I have discovered why in FF the control-A function doesn't work. In regular Civ4 this causes units with queued up orders to execute them immediately. (So, for example, your turn comes around and the currently selected ship becomes a construction ship sitting on a resource but the nearby construction ship that should finish the starbase this turn has not gone yet so the starbase doesn't exist yet so the tile is not in your borders so you can't tell it tp build the extraction facility. Ordinarily you'd be able to do a control-A which would cause the other construction ship to run its turn and finish the starbase thereby allowing you to click on your still selected construction ship's "build extraction facility" button, but this doesn't work in FF).

The problem is in a piece of debugging related code that was left in a bad state in CvFinalFrontierEvents.py which doesn't actually do anything except mess up the "A" key. On line 2007 it says "return 1". Change that to "return 0" and control-A starts working again. (In Final Frontier Plus v1.31, post Python simplification version, it is line 1422.)

That "return 1" is done there only if the "A" key is pressed, whether or not the control key is also active at the time, and it tells the DLL that the key press was processed by this function and it should not process it itself. Except that it isn't actually processed - the function currently exits before doing anything except sending the DLL the wrong return value.
 
You must log in or register to reply here.

Similar threads

FXS_Sar
Checking in from the dev team: June update is almost here!
11 12 13
Replies
247
Views
14K
CliffCo
CliffCo
The_J
  • Sticky
"Dante Update", version 1.0.28.4665, May 27, 2025
Replies
0
Views
287
The_J
The_J
The_J
  • Sticky
Old World update #135
Replies
7
Views
2K
PiR
PiR
planetmaker
Adding my planet Mod to Final Frontier Plus
4 5 6
Replies
102
Views
5K
PsiCorps
PsiCorps
beorn
My reaction to update 1.20
Replies
15
Views
2K
Yzman
Yzman
Back
Top Bottom