Final Frontier Plus

Uh-oh.

I just ran into a problem that must exist in the original FF, although it would only have an effect for languages other than English.

The error:
Code: 
Traceback (most recent call last):

  File "CvWBInterface", line 18, in writeDesc

  File "CvWBDesc", line 1929, in write

  File "CvWBDesc", line 1521, in write

UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 97: ordinal not in range(128)
ERR: Python function writeDesc failed, module CvWBInterface
[CODE]

Note that the character it is talking about is an o with an umlaut over it. This is used in one of the constellation names I added to the list. It also appears in other places for other languages (like the German for Leo), as well as other accented characters which would also cause this problem.

It looks like the output needs to be messed with to either change the encoding of the output file from ASCII to one that allows characters past 128 (to 256), or to encode the text string for the name before it is passed to the write. Then the read needs to be able to handle whatever is done. Perhaps str.encode() and str.decode()?
 
God-Emperor said:
Uh-oh.

I just ran into a problem that must exist in the original FF, although it would only have an effect for languages other than English.

The error:
Code: 
Traceback (most recent call last):

  File "CvWBInterface", line 18, in writeDesc

  File "CvWBDesc", line 1929, in write

  File "CvWBDesc", line 1521, in write

UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 97: ordinal not in range(128)
ERR: Python function writeDesc failed, module CvWBInterface
[CODE]

Note that the character it is talking about is an o with an umlaut over it. This is used in one of the constellation names I added to the list. It also appears in other places for other languages (like the German for Leo), as well as other accented characters which would also cause this problem.

It looks like the output needs to be messed with to either change the encoding of the output file from ASCII to one that allows characters past 128 (to 256), or to encode the text string for the name before it is passed to the write. Then the read needs to be able to handle whatever is done. Perhaps str.encode() and str.decode()?[/QUOTE]

Aha!

That's the python exception I was getting. I had no idea what that character was and so put it down to the resource icon being placed in the planet name. I still don't like that idea (that is, adding the resource icon to the planet's name) but the umlaut makes much more sense.

Unfortunately, I have no idea how to do the former, so I'll probably do the latter instead.

Other strings in the game use that too- "str.encode(fileencoding)" and "str.decode(fileencoding)" (fileencoding being defined as "latin_1" in CvWBDesc.py).
Click to expand...
 
I agree that actually adding the resource symbol to the name was a bad plan (I did it because it only required changing the code in one place). My little update (FFP-1-4-b.zip) only adds it to the display in the various places where it is needed rather than making it an actual part of the name returned by CvPlanet.getName() like I had been doing.
 
I've released the v1.41 patch. It contains the 1.4b and 1.4c (and, I suppose, 1.4a) patches that God-Emperor has posted. It also fixes several issues with Worldbuilder, including the one where names with nonstandard characters (such as an umlaut) caused errors, as well as a problem where Worldbuilder was failing to properly load files (due to an error I made with the planet resource code).

Full Changelog:

-Fixed bug with the chance to keep some wonders
-Tweaked some other building conquest probabilities
-Invasion Ship III now does collateral damage
-Q-Missile can now be spawned at Starbases after you research required tech
-Planetary resources are now marked using their icon on Planet Info Screen and City Screen
-Fixed bug with Worldbuilder if planet names contained umlauts (and other nonstandard characters)
-Fixed bug with Worldbuilder loading and saving planet bonus types

You can get it here. It's set up as an installer, an installer that I made using phungus420's NSIS mod patching script.

You do need to have v1.4 already installed, since this not a full download.
 
It looks like the code to have golden ages increase planets production and commerce is not in. At the moment, the only thing a golden age does is make changing civics or state religion have no anarchy (which makes them completely useless for Halis since they don't get any anarchy anyway).

In CvSolarSystem.py at the end of CvPlanet.getExtraYield I have the following code in Finaler Frontier:
Code: 
		# CP - add golden age effect, thanks for the idea of doing it here go to TC01
		if pPlayer.isGoldenAge():
			if (self.getBaseYield(iYieldID) + iExtraYield) >= gc.getYieldInfo(iYieldID).getGoldenAgeYieldThreshold() :
				iExtraYield += gc.getYieldInfo(iYieldID).getGoldenAgeYield()

Looks like you forgot your own idea.

With the default golden age threshold settings, any planet that makes at least 1 production will get +1, and likewise for commerce. Since every planet produces at least 1 commerce, the effectively gives +1 commerce per population working the planets. The only planets that don't get a +1 production/pop are the white 2/0/3/ planets without a mining facility.
 
God-Emperor said:
It looks like the code to have golden ages increase planets production and commerce is not in. At the moment, the only thing a golden age does is make changing civics or state religion have no anarchy (which makes them completely useless for Halis since they don't get any anarchy anyway).

In CvSolarSystem.py at the end of CvPlanet.getExtraYield I have the following code in Finaler Frontier:
Code: 
		# CP - add golden age effect, thanks for the idea of doing it here go to TC01
		if pPlayer.isGoldenAge():
			if (self.getBaseYield(iYieldID) + iExtraYield) >= gc.getYieldInfo(iYieldID).getGoldenAgeYieldThreshold() :
				iExtraYield += gc.getYieldInfo(iYieldID).getGoldenAgeYield()

Looks like you forgot your own idea.

With the default golden age threshold settings, any planet that makes at least 1 production will get +1, and likewise for commerce. Since every planet produces at least 1 commerce, the effectively gives +1 commerce per population working the planets. The only planets that don't get a +1 production/pop are the white 2/0/3/ planets without a mining facility.
Click to expand...

I thought I copied that over... anyway, I'll add it back in the next patch/version.

Any recommendations for different settings? Perhaps 2 instead of 1, or should the threshold be higher?

Or do you think that it's okay for all planets to get +1 commerce and +1 production (except in the case of the 2/0/3 planet you mentioned)?
 
I think it is OK like that for now. At the moment all the players but one can only have one golden age, started by building the National Epic national wonder. The exception is the player that builds the Founders Monument world wonder which also starts a golden age so that player gets 2. Since there are so few, a pretty large benefit seems like a good thing.

If great people are added back in and they can start golden ages, it might need to be scaled back a little by setting the thresholds higher or it might be OK as it is even then. It's pretty much a matter of opinion as I don't think that it affect the game balance much since everyone can get them (although with great people the human may have an advantage since the AI might not run a GP farm as well as a human). Some people might like a very large boost from a golden age, some might like a smaller amount.

I don't mind the golden age boost being pretty high. I wouldn't mind if it was even higher than it is now given the current low limit on the number of them that can happen.
 
By the way, the v1.41 patch does not break savegames. So if you are in the middle of a game with v1.4, you can apply the patch.

Well if you really are in the middle of a game I'd save, exit the game, apply the patch, run the game, and load the saved game. Applying the patch while the game is running might not be a good plan.

Any omega invasion ships you've already built probably won't gain the ability to do collateral damage, but new ones will have it. Aside from that, all the changes should work. It won't wipe out "bad" buildings in systems you've already captured (like the Palace in a capital you captured that was mistakenly kept), but will apply the correct capture chance to buildings in systems captured after the patch is applied.
 
Something strange is still happening when it comes to which buildings survive in a star system that is captured.

Apparently there are two bugs, one in the DLL and one in the Python:

I just captured a Capitol building, according to the list of buildings on the left side of the city screen. But neither of the two planets in the inner influence zone lists a Capitol as being present. So this must somehow be a DLL bug - somehow the "pCity.setNumRealBuilding(iBuildingLoop, 0)" in the python that is run for buildings with bNeverCapture = true is not removing the building. ADditional strange symptom: I had earlier captured their original capital star system and it did not leave the Capital behind. In retrospect, this must have been the problem that happened when I captured the Capitol before - I forgot about the bNeverCapture and only checked the iConquestProb values (I should go through and make sure the bNeverCapture values of the buildings are what they should be too). I went back to a save game from when I first reported this and found something I hadn't noticed back then: it too had the Capitol listed on the left but not on a planet. Something is preventing the Capitol buildigns, at least, from being removed some of the time. In this case, the star system that had it left there was their last, so there may a connection to trying to move their capital to a new system but failing since it was their last system (and their civ is now wiped out).

Also, I didn't initially notice that it wasn't present on either of the planets so I checked the Python code. In doing so I found a bug that probably isn't related to this specific problem: it is treating iConquestProb as the chance the building will be destroyed instead of the chance it will survive. Line 1247 in CvFinalFrontierEvents.py is
Code: 
						if (iRand [COLOR="#ff0000"]<[/COLOR] gc.getBuildingInfo(iBuildingLoop).getConquestProbability()):
but it should be
Code: 
						if (iRand [COLOR="Red"]>=[/COLOR] gc.getBuildingInfo(iBuildingLoop).getConquestProbability()):
in order to make it the chance to survive. 0 = always destroyed (iRand = any number in its full range from 0 to 99), 99 = 1% to be destroyed (so only destroyed if iRand is 99).
 
Thinking about the "captured Capitol" problem I realized something:

This bug must also exist in the original FF, my Finaler Frontier, and probably every other FF based mod.

The reason all this is happening can be found in the answer to one simple question: What happens to the Capitol building when you capture a capital city?

The answer is that the DLL moves it to another city. When it does so it just changes the count for the Capitol building type in the new city via "setNumRealBuilding(eCapitalBuilding, 1)". No python callback is ever called. The new Capitol building is never placed on a planet. Since it is not on a planet, the loop over the planets in the system to remove buildings that is done when a system is captured does not remove it. Thus the appearance of Capitol buildings when capturing a system to which the Capitol has been moved after the original capital system was captured (it doesn't happen when capturing the original capitol since the Capitol is placed on a planet by the createRandomSystem function).

I think the simplest fix is to have the DLL trigger the buildingBuilt callback when the Capitol is moved, right at the end of CvPlayer::findNewCapital() just after the line that says "pBestCity->setNumRealBuilding(eCapitalBuilding, 1);". The code should probably look something like:
Code: 
CvEventReporter::getInstance().buildingBuilt(pBestCity, eCapitalBuilding);
The Python this triggers will cause it to be put onto the currently designated build planet in the system to which it has been relocated.

(Which planet the new Capitol is on doesn't really matter, as long as it is on one. This could change if unique Capitols were ever added which were to give some per-population yield improvement or pop cap increase.)

EDIT: (More thinking done.)

Part of this particular bug probably does not exist in non FF-Plus versions of FF or mods based on FF. The regular DLL's building deletion code should have insured that the Capitol building did not survive the city being captured, however FF-Plus removed that code and relies on the Python. But the new Capitol building still would not be on a planet, although this does not actually seem to have any effect - this particular DLL vs. Python data discrepancy does not seem to cause the problem that it often causes, specifically the inability to build any buildings anywhere.
 
I've added in that line to the DLL, and also changed the Python for iConquestProb. (Though as you say, that's probably not related).

Then I ran a test, started a game with the AI opponent as New Earth (since their cities start with two population and therefore their capital wouldn't be auto-razed), gave them another solar system, and then conquered their capital system with a battleship. After capturing it, I checked and the Capitol building had been removed from the city properly.

So it looks like it's working now- maybe I'll release a patch 1.42 with this fixed.


On a different topic- currently, while you can start a game, in, say, the Expansion, Galactic, or Far Future eras, you don't actually get any different buildings in your cities (FreeStartEra) or any different starting units if you do so. You still get a Planetary Defense Ship I and a Nutrition Facility and a Mining Facility.

Any recommendations on what buildings/units you should start with in the different eras?
 
The Capitol building was being removed properly from the original capital system since that one is added to a planet. The problem arises when capturing the city to which it has been moved after that. With the new line in the DLL, it ought to be putting the Capitol on some planet which ought to make it remove the thing correctly when the second capital system is captured (the building removal loop goes over the planets' building lists so if a building isn't on a planet it isn't removed).
 
God-Emperor said:
The Capitol building was being removed properly from the original capital system since that one is added to a planet. The problem arises when capturing the city to which it has been moved after that. With the new line in the DLL, it ought to be putting the Capitol on some planet which ought to make it remove the thing correctly when the second capital system is captured (the building removal loop goes over the planets' building lists so if a building isn't on a planet it isn't removed).
Click to expand...

Ah, I misunderstood.

Anyway, I just ran another test- this time, I captured the second New Earth city after capturing the first one, and the Capitol was removed properly both times.
 
Not sure if it has been mentioned, but in multiplayer the game goes OOS when a player is attacked and loses a ship to an enemy star base (maybe squadron as well, not tested). If non host player blows up a ship with squadron or starbase (ranged attacks) it will OOS for a moment then correct itself.
 
timelord89 said:
Not sure if it has been mentioned, but in multiplayer the game goes OOS when a player is attacked and loses a ship to an enemy star base (maybe squadron as well, not tested). If non host player blows up a ship with squadron or starbase (ranged attacks) it will OOS for a moment then correct itself.
Click to expand...

This post reminded me that there are some problems with AI controlled starbase's ranged attacks.

In looking at it, I found bugs in the DLL and in FF's doStarbaseAI python function.

I have posted about the bugs in CvUnit::rangeStrike and canRangeStrikeAt over in the Unofficial Patches forum starting this thread.

I have posted a fix for the doStarbaseAI python function in the Final Frontier: Problems and Issues thread in this post.

The fix for problem "1.b" in the DLL might stop the ranged attack related OOS problems.
 
God-Emperor said:
This post reminded me that there are some problems with AI controlled starbase's ranged attacks.

In looking at it, I found bugs in the DLL and in FF's doStarbaseAI python function.

I have posted about the bugs in CvUnit::rangeStrike and canRangeStrikeAt over in the Unofficial Patches forum starting this thread.

I have posted a fix for the doStarbaseAI python function in the Final Frontier: Problems and Issues thread in this post.

The fix for problem "1.b" in the DLL might stop the ranged attack related OOS problems.
Click to expand...

I've incorporated the Python fix, and fixes 1.a and 2 in the DLL.

Not sure what to do about 1.b yet, but thanks for investigating this.
 
I just posted another bugfix applying to the doStarbaseAI function in CVAI.py. It is here, in the usual Final Frontier: Problems and Issues thread.

The loops for the coordinates of the plots to check are actually wrong, so neither the highest X value or the highest Y value that should be checked will never be generated. For a regular, or delta, starbase it is only checking a 6x6 area instead of 7x7.
 
Two more issues, one XML and one Python.

In CIV4BuildingInfos.xml, BUILDING_CAPITAL_SHIPYARD has iCost = 0, it should be 50 (give or take).

In CvFinalFrontierEvents.py in onBuildingBuilt there is no UB related check, so the New Earth UB (same class as the Star Fortress) is having the pSystem.setSingleBuildingRingLocation() run for it which is wrong. It results in an orbiting red blob since there is no model specified to display in the orbit.

Current:
Code: 
		# Is it one of the single-building types which gets added to the map?
		if gc.getBuildingInfo(iBuildingType).isOnePerSystem():
			if iBuildingType != gc.getInfoTypeForString('BUILDING_STAR_FORTRESS'):		#Handled specially, since it's placed in the center of a star system.
				pSystem.setSingleBuildingRingLocation(iBuildingType)

Fixed:
Code: 
		# Is it one of the single-building types which gets added to the map?
		if gc.getBuildingInfo(iBuildingType).isOnePerSystem():
			iBuildingClass = gc.getBuildingInfo(iBuildingType).getBuildingClassType()
			if iBuildingClass != gc.getInfoTypeForString('BUILDINGCLASS_STAR_FORTRESS'):		#Handled specially, since it's placed in the center of a star system.
				pSystem.setSingleBuildingRingLocation(iBuildingType)
 
I noticed (and fixed) the first bug. But I didn't notice the second one, since I haven't played a New Earth game yet.

However, I did notice that as the Forge, you have no way to build your UB. addBasicBuildingsToBestPlanet adds a Mining Facility and Nutrition Facility irrespective of Unique Buildings. And on other planets, the game forces you to build the Mining Facility, not the Forge UB.

EDIT: Never mind... I just noticed that the Forge UB doesn't replace the Mining Facility, it replaces the Nanoextraction Upgrade. Oops.

Still, the changes I made to CvSolarSystem now should allow a UB to replace one of these buildings without problems.


I'll try to get a patch out soon which fixes all of this stuff.
 
You must log in or register to reply here.

Similar threads

primem0ver
Genetic Era Mod - Repost... and Revival?
Replies
15
Views
1K
keldath
keldath
S
[WIP] 1350AD Mod v0.848
Replies
1
Views
1K
Tungan Ninja
T
CSD
[BTS] Normable
Replies
0
Views
852
CSD
CSD
s0nny80y
Civ 4 BTS Final Frontier 2 as Starships 2
Replies
0
Views
2K
s0nny80y
s0nny80y
Sword_Of_Geddon
[BTS] Chiyu's Extra Mod
Replies
1
Views
3K
Luke1195
L
Top Bottom