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

[God-Emperor]

Another bug.

Quite some time ago I noticed that AI controlled starbases can attack units in places where it wouldn't be able to do so if it were controlled by me. Specifically, with an attack range of 3 they can attack units in tiles near the four corners of the 7x7 area that are actually 4 units away from the starabase (the actual target area should be the same as it is for a human player, select a starbase to see what it is) and they can attack units on the other side of asteroid fields. It would be even worse for omega starbases, attacking in more tiles that should be excluded due to the range calculation and even targets that it can not actually see since the attack range of an omega SB exceed's it's visual range, except I have never seen the AI use an omega starbase.

The attacking across asteroid fields would be a hard problem to solve in the Python (possible, but hard - and slow) - it is actually a bug in the DLL in the CvUnit::rangeStrike function. I have reported this bug in the Unofficial Patches forum here, it is bug "1.a" in that post that is causing this problem. Fixing it will also fix the ability to attack locations that ought to be out of range.

In addition to this, I'm pretty sure that every AI controlled starbase it trying to do a ranged attack every turn whether there are valid targets available or not. If there are no valid targets then the DLL will not actually to the attack, but time is wasted making the attempt.

So here is a fix for both the "attack even when there are no valid targets", the "attack things that are actually out of range", and the "attack targets out of visual range" (just in case the AI ever has an omega starabase) problems.

In CvAI.py, in the doStarbaseAI function:
Original code:

					pLoopPlot = CyMap().plot(iActiveX, iActiveY)
					
					iPlotValue = 0
					
					# Look at all the units on this plot
					for iUnitLoop in range(pLoopPlot.getNumUnits()):
						
						pLoopUnit = pLoopPlot.getUnit(iUnitLoop)
						
						# At war with this unit's owner?
						if (pTeam.isAtWar(pLoopUnit.getTeam())):
							
							# The greater the cost of the unit the more we want to kill it :)
							iCost = gc.getUnitInfo(pLoopUnit.getUnitType()).getProductionCost()
							
							if (iCost > 0):
								iPlotValue += iCost
					
					aiBombardPlotValues.append([iPlotValue, iActiveX, iActiveY])
					
			# Any valid plots to hit?

New code:

					pLoopPlot = CyMap().plot(iActiveX, iActiveY)
					
					if pLoopPlot.isVisible(iTeam, false) and (plotDistance(pUnit.getX(),pUnit.getY(),iActiveX,iActiveY) <= pUnit.airRange()): # CP - bugfix for AI starbases attacking things they shouldn't be able to see or reach
						iPlotValue = 0
					
						# Look at all the units on this plot
						for iUnitLoop in range(pLoopPlot.getNumUnits()):
						
							pLoopUnit = pLoopPlot.getUnit(iUnitLoop)
						
							# At war with this unit's owner?
							if (pTeam.isAtWar(pLoopUnit.getTeam())):
							
								# The greater the cost of the unit the more we want to kill it :)
								iCost = gc.getUnitInfo(pLoopUnit.getUnitType()).getProductionCost()
							
								if (iCost > 0):
									iPlotValue += iCost
									
						if iPlotValue > 0: # CP - bugfix for trying to attack when there are no valid targets
							aiBombardPlotValues.append([iPlotValue, iActiveX, iActiveY])
					
			# Any valid plots to hit?

 

[deanej]

I don't know how the ranged system works exactly, but this might not be a bug. AI units are able to see every tile in their movement range regardless of weather a human could see there.

 

[God-Emperor]

The visibility problem may be a non-issue for the AI.

Actually, in the buggy version of the DLL's rangeStrike and canRangeStrikeAt it does currently check the visibility of the target plot. If it is not visible it does not do the attack. This is somewhat coincidental due to the influence of 2 different bugs, one in each of the functions. If only the rangeStrike function were fixed it would attack the target plot regardless of its visibility.

The main problem is not so much the visibility (a normal starbase can see every tile it could shoot at anyway) as it is the range itself. The currently buggy CvUnit::rangeStrike function will allow an attack regardless of range (it checks to see if an attack from a plot is possible, sadly it uses the target plot instead of the plot the attacking unit is in). The only reason every enemy starbase is not attacking units halfway across the map every turn is that the loop to look for plots to attack in the python uses the unit's defined air range - but this allows attacks to plots near the corners of the area that would be out of range for a human controlled starbase. The second test in the first new "if" takes care of that by calculating the distance the way it is done for the human, which rules out those tiles near the corners.

The other problem is that is is putting 0 valued plots (those with no enemy units in them) into the aiBombardPlotValues list. This means the list will always have every plot in the checked area in it. The condition to not pick a plot is the list being empty, but it is never empty. So it then picks the highest value plot (even if it is 0 value) and tries to attack it, which is a waste of time.

The problem that the posted fix does not deal with is the ability of AI controlled starbases to shoot at targets on the other side of asteroids or nebulas. The player can't do this, the AI can. As I said: it is possible to fix in Python, but relatively difficult (it would require duplicating the CvPlot::canSeePlot function since that method of the CvPlot class isn't accessible from Python). So I didn't fix that in the Python.

Once the DLL is fixed, the original Python will work, although it would still waste time trying to attack empty plots and plots that are just out of range in the corners of the search area.

 

[God-Emperor]

OK, another bug in doStarbaseAI in CVAI.py

This one is in both the original FF code and in my fix that I just posted (well, it isn't in the fix since the code I posted started after these lines - but it isn't fixed by the fix).

The bug is in the range() functions used to set up the loops used to search for valid targets. The problem arises from the way the range(i,j) function works. The second argument is the upper cutoff, but the highest number that will be generated is strictly less than its value. It won't produce the number itself. Example: range (1,3) will produce the numbers 1 and 2, but not 3.

Old code:

			# Check plots within range to see what's around us
			for iXLoop in range(pUnit.getX()-pUnit.airRange(), pUnit.getX()+pUnit.airRange()):
				for iYLoop in range(pUnit.getY()-pUnit.airRange(), pUnit.getY()+pUnit.airRange()):

Fixed code:

			# Check plots within range to see what's around us
			for iXLoop in range(pUnit.getX()-pUnit.airRange(), pUnit.getX()+pUnit.airRange()[COLOR="DarkRed"]+1[/COLOR]):
				for iYLoop in range(pUnit.getY()-pUnit.airRange(), pUnit.getY()+pUnit.airRange()[COLOR="#8b0000"]+1[/COLOR]):

 

[PsiCorps]

Hi all, i've compiled all of the corrections included in this thread, including the DLL into the B5 mod but now when i load the B5 mod i have no planets or interface showing. Not sure which of the corrections caused this, does anyone have a working version of FF that includes the corrections made here but doesn't go as far as Finaler Frontier does?

 

[Xoatl_169]

Im having a problem, when i start the game an error pops up saying "GFC error: failed to initialize primary theme" or something like that. This is my first mod so i dunno how to fix this.

 

[God-Emperor]

Im having a problem, when i start the game an error pops up saying "GFC error: failed to initialize primary theme" or something like that. This is my first mod so i dunno how to fix this.

There are only two things that I know of that can cause this, other than a plain old messed up BtS install.

1) There is something in Custom Assets that is interfering.
- You may be able to fix this by finding the "Final Frontier.ini" file and changing the line in it that says "NoCustomAssets = 0" to "NoCustomAssets = 1".

2) The name of the mod has been changed. (I'm not sure, but this might include moving the entire game by just moving the folders instead of uninstalling and reinstalling the game to a different location.)
- You should be able to fix this by changing the name back. (Or possibly moving the entire game back to where it was.)

There is a 3rd possibility, but it only happens with additional mods downloaded from places like here. In that case, this can happen if you install them in the wrong place. Just for general informational purposes, since it shouldn't be relevant to a mod that came with BtS: My Documents\My Games\Beyond the Sword\MODS is the wrong place (unless, perhaps, it was specifically designed to go there). The correct location depends on where you installed the game but if the default install location was used and you are not using a Steam or other download service's version then the right location is going to be something like C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods.

 

[acivguy55]

Hi, so I heard the ridiculous cost for the resource extracting machine thingy had gone down (was fixed) . Is there a patch for this?, Where?

Thanks

 

[God-Emperor]

I'm not sure what you mean, but if you have BtS patched to 3.19 then you have FF patched to its last official version since the game patches also patch the mods that come with the game. There has been no official patch for this mod (or anything else) since 3.19.

For unofficial updates to this mod (including all the bug fixes in this thread, and other stuff including game turn speed improvements) see the Final Frontier Plus mod.

 

[Bringe]

I've really been wanting to play this mod but I get just a few turns into a game then the screen goes black and civ crashes. I remember reading something about this ages ago but can't remember where.

Any help would be very much appreciated.

 

[Snonskoid]

I like Final Frontier, but it runs very slowly, taking around 90 seconds to give a new turn each time, even at the start of the game.
I use an iMac 5 and ordinary CivIV, BTS, runs perfectly well on my set-up.
Any helpful hints??

 

[T-hawk]

Snonskoid, one cause of that was found and fixed upthread here: http://forums.civfanatics.com/showthread.php?p=8950782#post8950782

 

[Snonskoid]

Thanks, THawk. Now I know what the problem is, but playing on a Mac, I don't know how to fix it!

 

[God-Emperor]

If it is slow at the start of the game, then it isn't the starbase location search problem that I found. That only happens from time to time later in the game, when there are construction ships evaluating plots to build starbases on and, most likely, other starbases around to block some locations where they might want to build one.

 

[Durnaria]

Hi folks. I'm new to playing Final Frontier so forgive me if I'm being obtuse, but my squadron units don't seem to be receiving upgrades from +prestige buildings. In fact I'm not noticing any "#/#" for experience in their unit info box at all. Any thoughts on why the upgrade options aren't showing?

 

[God-Emperor]

Because they aren't supposed to, based on how they are defined in the mod's XML. They prestige from the buildings that give it only applies to the regular ships not the squadrons, exactly like the experience from a barracks does not apply to a fighter in regular BtS.

In unmodified FF, the only way for a squadron to gain prestige is to fight another squadron either by intercepting or by being intercepted. Well, there is one exception: the 4 prestige that the Brotherhood gets for free on its units does apply to squadrons as well as the regular ships.

In Final Frontier Plus there is a Flight School building which gives squadrons prestige. And a bunch of other stuff, including all the bug fixes mentioned in this thread.

 

[Durnaria]

Thank you very much. I didn't notice how the type difference worked. I assume you'd recommend ignoring the vanilla mod in favor of all the pluses you nice folks have designed into Plus?

 

[amrod]

Hi, I got the following message when a pirate razed a city:

"Error in cityRazed event handler <bound method FinalFrontierEvents.onCityRazed of <FinalFrontierEvents.FinalFrontierEvents instance at 0x257995D0>

There were no problems with gameplay, it went on w/o problems.

Also, as a note: Scouts/Recon ships could maybe get some promotions more suited for scouts (as they can't really use combat promotions, esp. the weak scouts). Such as visibility (already there, but not in first selection), more movement, hiding esp.

Also, there are two seemingly identical promotions of +1 visibility (as I remember they have the same name, text and icon). Do they add up? They should have a different name (like Visibility 1 and Visibility 2).

 

[God-Emperor]

This should probably be over in the Final Frontier Plus forum, since it is about that.

Hi, I got the following message when a pirate razed a city:

"Error in cityRazed event handler <bound method FinalFrontierEvents.onCityRazed of <FinalFrontierEvents.FinalFrontierEvents instance at 0x257995D0>

There were no problems with gameplay, it went on w/o problems.

This particular bug is fixed in FFP version 1.72. It may seem like it is going OK after that, but there may be an issue when the system is resettled if any buildings were built there other than the two you get for free (if it belonged to Paradise then the free mag-lev networks Paradise gets can cause the problems if not resettled by Paradise).

Also, as a note: Scouts/Recon ships could maybe get some promotions more suited for scouts (as they can't really use combat promotions, esp. the weak scouts). Such as visibility (already there, but not in first selection), more movement, hiding esp.

Also, there are two seemingly identical promotions of +1 visibility (as I remember they have the same name, text and icon). Do they add up? They should have a different name (like Visibility 1 and Visibility 2).

They can get engine and sensor upgrades, although those both have prereqs that require you to take a couple of other promotions first (I go with two armor and then an engine, the only problem with the armor upgrades are that they don't apply when in an asteroid field so with both you trade the +15% from each for the +50% from asteroids instead of adding them together, ditto when in other features like radiation clouds - this might be fixed at some point in the future). I don't normally take the sensor part upgrades for scouts for two reasons: 1) since it already starts with the first one it is harder to get to the next one and if you do manage it then you are just where you'd be if you just upgraded the ship to the delta version (if it lives that long puttering along at speed 1, and you manage to get it back into your territory to do the upgrade) except that you are an upgrade short of where you could be, and 2) more speed is better than more sensor range since you can run away from destroyers (you are much more likely to survive with +1 speed than with +1 sensor range). This doesn't entirely apply to the Recon ship UU since it already starts with speed 2.

The two "+1 Visibility" upgrades stack with everything else. They can not be selected as earned upgrades. They are used by the Recon ship family as free promotions, currently nothing else uses them (they might be used if more generations of sensor station are added). That lets the Recon ships take the regular sensor upgrades on top of them (which can lead to a very high visibility range).

 

[amrod]

Yup, sorry, mixed up the forum
Btw, didn't know that asteroid fields negate the armor bonus
is it mentioned in the pedia? (is it me again not reading carefully enough?)