Final Frontier Plus BUG

God-Emperor · Nov 15, 2010

Note: This has now been merged into the main release of Final Frontier Plus, as of version 1.7. There is no longer any real need to download this, just get the regular release.

Beta test of merge of Final Frontier Plus with BUG.

This is a complete merge of BUG version 4.4 with Final Frontier Plus version 1.651. The only known problems are listed down in the "Knows Issues" section of this post. As of patch 2, all of the listed Known Issues are resolved.

The Current Version (Beta1) is attached at the end of this post.
Patch 2 for Beta 1 has been posted, see post #11 of this thread.
An update for the optional Advanced Unit Naming feature has been posted.

How to install:

1) Get Bug v4.4 and install it as a mod (not always active, i.e. not in Custom Assets). Here.
2) Get version 1.6 of Final Frontier Plus and patch 1.651 and install them. Both Here.
3) If you want to keep the BUG Mod, then copy the Mods\BUG Mod 4.4 folder into the same Mods folder and use that, otherwise you can use the original. Rename the folder (original or copy) to be exactly this: Final Frontier Plus BUG
4) You don't need the maps that come with BUG since they are regular maps for regular terrain, so delete everything in the PublicMaps folder in the new Final Frontier Plus BUG folder. Likewise, the .ini and uninstaller for BUG in the main folder are not needed so you can delete those too, leaving nothing but the folders in the Final Frontier Plus BUG folder.
5) Copy two of the folders in Final Frontier Plus into Final Frontier Plus BUG, allowing replacement of any files: Assets and PrivateMaps (the scenario in PublicMaps should still work so copy PublicMaps too, if you want).
6) Optional step - remove some FFP files that have different names in the FFPBUG Beta) Go into Final Frontier Plus BUG/Assets/Python and delete these files: CvFinalFrontierEvents.py (and .py.bak if there is one) and CvGameUtils.py. Note: There are some files that are not really needed from FFP since BUG uses different versions. It shouldn't be a problem.
7) Unzip the Final Frontier Plus BUG Beta 1 file somewhere and copy everything in it into the Final Frontier Plus BUG folder, allowing replacement of any files. (This includes merged files, plus a file or two that is the BUG version which copying FFP over BUG replaced.)
8) Unzip the Final Frontier Plus Bug Beta 1 patch 2 file somewhere and copy everything in it into the Final Frontier Plus BUG folder, allowing replacement of any files.
9) Optional: unzip the Advanced Unit Naming update file somewhere and copy everything in it into the Final Frontier Plus BUG folder, allowing replacement of any files.

Now load the mod and play.

In addition to BUG, there are a few additional modifications that ended up included since they are in my version of Final Frontier Plus:

Bugfix for issue in regular FFP:
- The description text key for the BUILDINGCLASS_AUDITOR_GENERAL in CIV4BuildingClassInfos.xml was invalid. Set to the correct value. This text never shows up anywhere in regular FFP so it was never noticed, but it is visible in BUG's domestic advisor.

Semi-random change also present:
- The FinalFrontier.py mapscript has changes to the info it prints to the debug log - it's a lot more compact and readable now. There is also a now commented out line that prints more stuff. All this was done when trying to figure out why the staring cities had no star systems under them (turned out to be a problem with a default setting BUG was applying to a callback). May as well keep it - more compact and easier to read output seems like a good thing.

Additional, unrelated, changes also in this beta:

all leaders have +5 to their iBuildUnitProb setting compared to regular FFP
the Streamlined Production, Vacuum Engineering, and Domestic Development techs have been moved from the 2nd era into the 1st, delaying the advance to the 2nd era. (Note: this is probably too much, the 2nd era may be coming a bit late now. Will probably move Vacuum Engineering, at least, back to the 2nd era.)
change Legendary culture level from 7500 to 10000 (Standard speed) and Iconic from 5000 to 6000. Also adjusted the culture levels for Fast since on Quick speed culture generation is at 67%, but the culture levels mostly were at about 50% - changed to be about 67% too.

----------

Known Issues - the list

Fixed 1) In the Sevopedia the text for techs is not hidden before you have researched them the way it was with the regular civilopedia. Fixed in B1 patch 2

Non-Issue 2) On the Tech screen the left panel that shows what the various great people would bulb is present even though there are no great people in the mod. B1 Patch 2 includes a BUG settings file that turns this off.

Fixed 3) Also on the Tech screen, the boxes for the techs are not wide enough. Fixed in B1 patch 1

Fixed 4) Worldbuilder saves do not load. At all. Fixed in B1 patch 1

Non-Issue 5) Dependencies. FFPBUG has not changed the path definitions for the theme files, so it only works if regular Final Frontier Plus is also present (it uses the theme files from that mod's folders).

Fixed 6) In the Domestic Advisor, the Military Overview has a Python exception in the early game before there are any units that could be produced via drafting. Fixed in B1 patch 2

Fixed 7) WorldBuild saves do not actually load properly. Fixed in B1 patch 2

Non-Issue 8) Planet displays on "city" screen and the system preview screen do not update. Turned out to be an options issue.

Know Issues - details

Fixed1) Sevopedia.
This is a minor issue. A FFP options tab may be added to the BUG options screen, if it is this will probably be made an option there that defaults to hiding the text. If not, it may be modified to hide the text sometime during the beta testing.

Non-Issue 2) Tech screen.
A minor issue that should be easy to deal with. There may already be a setting in the BUG options to turn this off, in which case just making the off setting the default would be fine. There is a BUG option for this - Advisors tab, Technology [F6] section, GP Research option. Will be turned off by default in the future. Patch 2 includes a BUG settings file that turns this off.

Fixed 3) Also Tech screen.
This problem is due entirely to the Orbital Engineering tech and the number of things that happen with it - even though the boxes have been widened some it still has an icon off the end of the box.

Fixed 4) Worldbuilder.
This is a pretty serious issue since it will prevent scenarios of any sort from working. I have the basic design for a fix, but have not started implementing it yet.
More info: I found two issues, the first was probably minor but the second is not.
In regular FFP (and probably present in almost every other mod, and base BTS too) there is a bug in the worldbuilder save file writing. It can not deal with unit names that have icons in them. This does not normally cause a problem because unit names are normally not even set and when they are they no not normally get characters outside the regular 8-bit range. BUG includes an automatic unit naming capability. The default for this incldues the unit type in the unit name. In FFP (and regular FF, of course) the unit types can include some non-standard charactgers - specifically the delta and omega icons. Saving these is not hard - simply setting the encoding to substitute HTML encodings for the characters works fine (a change to one location in CvWBDesc.py).
This brings us to the real problem. Now that the worldbuilder saves are actually saved, it turns out that they can not be applied. The reason is that the Final Frontier Plus even handler class has not been initialized at the time the data is loaded so there is no place to save the system data in the Python. My planned fix for this is to save the data instead of actually applying it and then apply it later in FFP's onGameStart.

Non-Issue 5) Dependencies.
A simple issue to fix, but I am expecting that when the beta is done it will just become the regular Final Frontier Plus and therefore there will be no separate "Final Frontier Plus BUG", so changing it now will just mean putting it back later. As it is, the "Final Frontier Plus BUG" name appears in the BUG configuration files, which will need to be fixed then.

Fixed 6) Domestic Advisor.
This is evidently a BUG bug. If there are no units that can be built that are draftable, it fails. Probably easy enough to fix. Should probably notify the BUG team about it too.
Addendum: "it fails" just means that this one particular domestic advisor display doesn't work - the table is not fully populated and if you have Civ set up to show Python exceptions you get the pop-up dialogs from that. Nothing else bad happens and you can switch to a different display from the list just fine.Fixed in B1 patch 2

Fixed 7) WorldBuild saves.
Weird stuff happened in my testing, like star systems with the plot showing wheat but a planet showing spices and one where the plot showed cotton but two different planets in the system showed as having spices. The issue is that the random star system generation and resource assignment was being run even for a worldbuilder save, resulting an additional set of resource assignments and a complete second set of systems being tacked on to the end of the list star system list. As for why this was happening, for some unknown reason the "map script" name is now coming through as all lowercase. For a WorldBuilder save this is the WorldBuilder filename complete with its path. The check to see if it is a WorldBuilder file has always been done by seeing if the text ".CivBeyondSwordWBSave" can be found in it. This is not working now since the way the check is done is case sensitive. The fix is to make sure the map script name is all lowercase (in case it changes again) by converting it and then check to see if ".civbeyondswordwbsave" is part of it. Fixed in B1 patch 2

Non-Issue 8) Planet displays. Instead of updating to show the planet rotating and moons and commercial satellites orbiting them, they are stationary. This is happening for both the system preview screen and the "city" screen. It turns out that this happens if you do not have your game set to High graphics on the Graphics tab on the standard BtS Options screen.

Some Notes on the Merge:
The merge involved "BUGifying" Final Frontier Plus. As BUG does not use a custom DLL, the DLL is the one from FFP without any alterations. The event manager for FFP was converted to the BUG standard, so the FFP event handlers are now loaded into and managed by the BUG event manager. Since it is so different, I changed the file name from CvFinalFrontierEvents.py to just FinalFrontierEvents.py, and changed the anme of the class to match too.

Likewise, the Game Utils functions for the game's callbacks are now managed by BUG. These are loaded with the "override" property set to True. I also changed CvGameUtils.py to FinalFrontierGameUtils.py, and the class to FFGameUtils.

Since BUG is supplying the event manager, the various star system related functions in the FFP event manager class are no longer present in the class you get when you do a "CvEventInterface.getEventManager()". When the FFP event manager is initialized it now defines a value in the BUG event manager that points to the instance of the FFP event manager that was created, allowing it to be found via "CvEventInterface.getEventManager().FinalFrontier". All of the places where the former were done were replaced with the latter, making the star system functions, like "getSystemAt(iX,iY)", available to the rest of the Python. This is used in a bunch of places. Currently, the FinalFrontierEventsr class is inheriting all of the regular CvEventManager stuff. It doesn't relly need to - they only thing it is still using from that is the initialization to get some of the data set up. This will probably be copied into the init routine and the inheritance done away with (it just makes it needlessly use a bit more memory at this point). The various event handlers used to call the regular handler before doing anything, but they don't anymore since BUG already does that. Note: this was changed again in patch 1 as it still had difficulties when trying to load a WB save - see post #3 below.

BUG uses the script data on the CyGame object for it's own puposes, so the Tutorial data that was saved there had to be dealt with. BUG also makes available routines to set and save data (which is what it is put in the CyGame's script data) so I changed the saving and loading of the Tutorial data to use that.

All of the places where Great People and Great Generals show up (that I noticed) have been adusted so that they no longer show. This was necessary not just because FFP has none of these, but also because FFP swaps in the "delta" icon for the "great people" icon (and the "omega" icon for the "power" icon, which is a lot less troublesome since the concept of "you now have electical power" isn't needed in FF/FFP). Because of this, adding great people back in will require a bit more work than it would if FF had just added them instead of userping other icons.

Tied in with that last point, the GameFont_75.tga that comes with BUG has been modified, substituting the delta and omega icons for the great people and power icons (BUG does not change the GameFont.tga file). The original delta and omega icons are actually narrower than the ones they replace, but I did not shuffle everything around to make them that way - in this merge the versions in the GameFont_75.tga file are wider than they were, resulting in a little extra space around them when they are used. Not a significant issue, but it would probably look slightly better in some places if they were made narrower again.

God-Emperor · Nov 15, 2010

If anybody finds any problems, make a post about them here.

God-Emperor · Nov 18, 2010

Final Frontier Beta 1 patch 1...

Fixes these Known Issues:
3) Also on the Tech screen, the boxes for the techs are not wide enough.
4) Worldbuilder saves do not load. At all.

The Assets folder in this zip file should be put into the Final Frontier Plus BUG folder where it will replace 9 files down in the Python folder and its sub-folders.

Included is a text file explaining what was fixed, the contents of which are reproduced here:

Spoiler :

Code:

Fixed Known Issue 4: WorldBuilder save loading issue.
- To do this, the star system data storage array, apSystems,
	and the system count value, iNumSystems, have been moved out of
	the FinalFrontierEvents.py file (and the class of the same name). 
	So have these functions:
		getNumSystems()
		getSystemAt(iX, iY)
		addSystem(pSystem)
		resetSystems()
	The data is now stored as global data in CvSolarSystem.py, and
	the functions are also in there as module level functions.

	A new function has also been added: removeSystem(pSystem)
	
	All files which accessed the system data have been adjusted to
	use the new method.
	
	Modified files:
		FinalFrontierEvents.py
		CvSolarSystem.py
		FinalFrontierGameUtils.py
		CvAI.py
		CvWBDesc.py
		CvMainInterface.py
		CvPlanetInfoScreen.py
		CvWorldBuilderScreen.py
		
	Note: in making these modifications it was noticed that the
	file CvWorldBuilderScreen.py had not been modified for BUG at all,
	so in the original beta version the worldbuilder would open but would
	have failed if any attempt was made to add or remove a star system or
	add or remove buildings, and possibly fail for some other operations
	as well.

Fixed WorldBuilder "delta and omega symbols in unit names" difficulties.
(also part of Known Issue 4)
- This was fixed by changing the encoding of the unit names from
	"latin_1" to "unicode_escape". The unicode_escape codec is pretty
	much exactly what I have been looking for for some time - it has
	always been there in the table in section 7.8.3 Standard Encodings
	of the Python.org's Standard Library documentation, but until just
	now I never saw any reference to it. The output it produces is
	defined to be a "byte string", so it is presumably "latin_1" or
	somethign a lot like it (I havn't checked - it could also be plain
	ascii with characters above 127 encoded, even though the ones
	from 128-255 could be represented without encoding).
	
	I had set it to encode the unit name using latin_1 with the
	"xmlcharrefreplace" error handler so that any characters out of
	the 0-255 range would get an XML character code written, just
	like anything ooutside the ascii range is encoded for the
	TXT_KEY_* data in the XML/Text folder's files (the "& #nnn;" values).
	This did not works so good since they are not automatically decoded -
	not only that but the leading "&" disappeared somewhere in the
	process (possibly in the display code in the game engine itself,
	I didn't really check this out) so when loaded from this the delta
	units had a "#8687;" prefix instead of the delta character. There
	is no built-in way to decode these characters back into their original
	unicode characters using the regular string.encode() and string.decode()
	type fucntionality. It is presumably possible to do via the XML
	parser - XMLParser.translate_references(data) ought to do it.
	That seemes like overkill...
	
	Fortunately the "unicode_escape" codec is just what I wanted.
	The output looks to be pretty much what you'd get from the "latin_1"
	encoding with the error handler set to be "backslashreplace", but
	it can read back in what it wrote out. (I didn't check, but the
	"unicode_escape" codec might be able to decode the output from the
	"latin_1" codec with "backslashreplace".)
	
	Note: simply changing the encoding to use "utf-8" also worked fine,
	however when using an editor to look at the worldbuilder file it would
	show the actual unicode character, not an escape sequence. Of course,
	the unicode character at 8687 is apparently not actually defined (it is
	in the "arrows" character set but does not appear to have an actual
	definition, as far as I can tell) so you get the "undefined character"
	box. Forcing Notepad++ into ASCII mode just made it display as two 8-bit
	characters. I havn't checked to see what the omega works out to, but it
	is only a few characters later so it is probably also an unused character
	in the "arrows" range. The new solution looks much better.
	
	Anyhow, this only affects one file (in just two places):
		CvWBDesc.py
	

Fixed Known Issue 3: Tech boxes not wide enough
- The boxes have been widened enough for the Orbital Engineering tech to
	fit the icons for everythig the tech allows into the box.
	
	Sadly, they seem a bit on the "too wide" side for most of the rest now.
	The only fix for that would be to move something off Orbital Engineering
	so it has fewer things to show, then narrow them down a step. The best
	candidate is probably the Assault Missile, which could be shifted to
	any of several other early techs - perhaps Light Craft Manufacturing,
	or Military Academies (where the regular Anti-Ship Missile becomes
	available).
	
	Modifed File:
		CvTechChooser.py

Edit: attachment removed. Use v2 of the patch, found down in post 11 of this thread.

God-Emperor · Nov 25, 2010

The Known Issues in post 1 has been updated.

It turns out that the Great Person stuff on the left side of the tech tree screen is controllable via one of the options on the BUG options screen's advisor tab so nothing needs to be done for it. You can just turn it off. If you do so, until the next time you run the game it will continue to show a now-empty panel on the left side that just takes up space, but once you start a new game or load from a save that is gone.

God-Emperor · Nov 25, 2010

Known Issues in post 1 updated again.

I found a new issue. It turns out that WorldBuilder saves are not, after all, being loaded properly.

As indicated in post 1, issue #7, it turns out that the map script name data is now coming through as all lower case instead of mixed case. The check relies on an exact match, so the mixed case text it was looking for to indicate that it was a WorldBuilder save rather than a Python map script is not working. This results in a second random star system being generated for each solar system feature and appended to the end of the star system list, then the random planet based resource generation is run again. The second star system set in the list didn't actually have much (if any) effect since they are typically found by x,y coordinates and it just returns the first match it finds (which would always be the original system). The additional round of resource generation caused strange things to happen - mismatches between the resource shown on the map and the resource on the planet in the system, systems with resources shown on two different planets, and other bad things.

The fix is easy. In FinalFrontierEvents.py change this line

Code:

		if ('.CivBeyondSwordWBSave' in CyMap().getMapScriptName()):

to be this

Code:

		if not ('.civbeyondswordwbsave' in CyMap().getMapScriptName().lower()):

This will be fixed in the next update. (It will also always print out the name of the map script to the PythonDbg.log file.)

keldath · Nov 26, 2010

hi,

thats a very good merge, i tried to do this my self at some point (but with the babylon5 version) but i failed, i also tryed to merge revdcm , and bbai stand alone, but i had some ctd.

keep up the good work !

deanej · Nov 26, 2010

I believe Star Trek had a similar problem with the map script stuff. I tried your new code and now scenarios are automatically detected properly!

God-Emperor · Nov 26, 2010

Yes, this is not just an issue with FFPBUG, it also exists in regular FFP v1.651.

Actual map scripts are in mixed case. Worldbuilder saves are in all lowercase.

God-Emperor · Nov 27, 2010

keldath said:
hi,

thats a very good merge, i tried to do this my self at some point (but with the babylon5 version) but i failed, i also tryed to merge revdcm , and bbai stand alone, but i had some ctd.

keep up the good work !

Thanks.

When I started, I wasn't sure if it would work at all. I was originally just going to start with the extra scoreboard info but I thought I'd give a full merge a try (and then probably give up when it didn't work and just do the scoreboard anyway :lol:

).

God-Emperor · Nov 27, 2010

Having run CivCheck to try to track down the bug that is causing a test game of mine to crash (to no avail), I found a missing art file bug that actually exists all the way back to vanilla Civ4 (i.e. it is in FFPBUG, FFP, FF, BtS, Warlords, and vanilla Civ too).

From my notes:

Code:

Fixed a missing art file
- in CIV4ArtDefines_Misc.xml the definition of ART_UNITGROUP_COIN had
	a typo in the NIF entry. Fixed this. There is still a trio of missing
	art files listed by CivCheck:
	
		MissingArt: Art/Units/Selection Effect/Selection_Above.nif
			Used: FFP art/civ4artdefines_misc.xml at line 146
		MissingArt: Art/Units/Selection Effect/Selection_Above.kfm
			Used: FFP art/civ4artdefines_misc.xml at line 147
		MissingArt: Art/Interface\Buttons\WorldBuilder\Terrain_Peak.dds
			Used: FFP terrain/civ4terraininfos.xml at line 1100
   
 	none of which seems particularly important. I fixed the one I did
	because the file Art/Units/Flag/Medallions.nif does exist, but it
	was looking for the file "Art/Units/Flag/Mediallion.nif" which is
	just a typo.
	All 4 of these problems must in regular FF (and FFP) too. Wow - I just
	checked and the one I fixed is a bug in regular BtS, Warlords, and
	vanilla Civ also.
	
	Modifed File:
		CIV4ArtDefines_Misc.xml

I'm not entirely certain what this does, if anything, but I fixed it (and left the other 3). So it should now correctly load the nif file from Assets0.fpk, whatever it is that it does with it (if anything). Considering that this typo has always existed, I have to assume that it doesn't actually do anything.

God-Emperor · Dec 1, 2010

Here is Final Frontier Plus BUG beta 1 patch 2.

This replaces patch 1, and includes everything that was in it.

Everything in this zip file should be copied into the Final Frontier Plus BUG folder where it will replace several files down in Assets and one in UserSettings.

Fixes these Known Issues:
1) Sevopedia. [Mostly.]
2) Tech screen.
6) Domestic Advisor.
7) WorldBuild saves do not actually load properly.

At this point, all the Known Issues in post 1 are fixed except KI5: Dependencies. KI5 is not going to be fixed, since this will be folded into the main FFP release for v1.7. Also unfixed is, perhaps, part of issue 1. The Sevopedia currently displays the Techs' text when you are at the main menu before you start a game (the original FF Civilopedia did not show it when run from here). This may or may not be changed.

This update also makes several other changes, not all directly related to the merge, which were never added to the Known Issues list.
- Fixed an incorrect art file definition. [A bug that exists all the way back to vanilla civ4]
- Added a Final Frontier Plus tab to the BUG options screen.
- Fixed a bug in autologEventManager.py
- Added checks on team related operations. [Fixes for issues in FF/FFP and BUG]
- Fixed some issues with the data shown in the Sevopedia.
- Changed the Military type civcs' free units. [Game tweak - wasn't doing what I thought.]

Included is a text file explaining what was fixed, the contents of the new part are reproduced here:

Spoiler :

Code:

The stuff below was in beta 1 patch 2 (including everything in patch 1)

---

Known Issue 2: On the Tech screen the left panel that shows what the various
	great people would bulb is present even though there are no great
	people in the mod.
	
	This is now known to not be an issue since there is a BUG option
	that can turn this off.
	
	Including a .ini file that has this turned off.
	
	Modifed File:
		UserSettings\BUG Advisors.ini

Fixed Known Issue 7: WorldBuild saves do not actually load properly.
- WorldBuilder save loading was not recognized so regular game start
	initialization of star systems was being done. Fixed by removing
	case sensitivity from the check - the text being checked is forced
	to lowercase (just in case - it currently comes through that way)
	and the text being looked for is now all lower case.
	
	Modified File:
		Assets\Python\FinalFrontierEvents.py

Fixed a missing art file
- in CIV4ArtDefines_Misc.xml the definition of ART_UNITGROUP_COIN had
	a typo in the NIF entry. Fixed this. There is still a trio of missing
	art files listed by CivCheck:
	
		MissingArt: Art/Units/Selection Effect/Selection_Above.nif
			Used: FFP art/civ4artdefines_misc.xml at line 146
		MissingArt: Art/Units/Selection Effect/Selection_Above.kfm
			Used: FFP art/civ4artdefines_misc.xml at line 147
		MissingArt: Art/Interface\Buttons\WorldBuilder\Terrain_Peak.dds
			Used: FFP terrain/civ4terraininfos.xml at line 1100
   
	none of which seems particularly important. I fixed the one I did
	because the file "Art/Units/Flag/Medallions.nif" does exist, but it
	was looking for the file "Art/Units/Flag/Mediallion.nif" which is
	just a typo.
	All 4 of these problems must in regular FF (and FFP) too. Wow -
	I just checked and the one I fixed is a bug in regular BtS, Warlords,
	and vanilla Civ also.
	
	Modifed File:
		Assets\XML\Art\CIV4ArtDefines_Misc.xml
		
Added a Final Frontier Plus tab to the BUG options screen.
- Currently this has only one option: "Hide Tech Text". Currently defaulting
	to True, this causes the Sevopedia to not display the quote or the
	civilopedia text for a tech until you have researched it. This fixes
	most of Known Issue 1: Sevopedia.
	
	Since BUG options are not actually loaded until a game is starting
	this does not allow blocking the text from the pre-game menu (the
	function that gets the value of the BUG option is returning False
	when there is no such option defined yet). Currently the relevant
	part of SevoPediaTech.py file is set to attempt to use this option
	even then, so it is showing the text.
	
	Modified Files:
		Assets\Config\init.xml
		Assets\Config\Final Frontier Plus.xml
		Assets\Python\BUG\Tabs\FFPOptionsTab.py (new file)
		Assets\Python\Contrib\Sevopedia\SevoPediaTech.py
		Assets\XML\Text\FFP Options.xml (new file)
		
		(When the game is run it also creates UserSettings\FFP.ini)
		
Fixed Known Issue 6: Domestic Advisor draft unit display bug
- The calculatePotentialConscriptUnit function was blindly using
	the return value from CyCity.getConscriptUnit() which results
	in a value of -1 (UNIT_NONE) when there is no unit that can be
	drafted. This is causes the getUnitInfo that is run with that
	value to fail. So now calculatePotentialConscriptUni checks what
	the unit is and if it it not valid it returns an empty string.
	
	Modifed File:
		Assets\Python\Screens\CvCustomizableDomesticAdvisor.py

Fixed a bug in autologEventManager.py
- In multiple places this used a hardcoded value of 5 for the number
	of civic categories when FFP only has 4. All of these have been
	changed to use the value returned by gc.getNumCivicOptionInfos().
	
	Modified File:
		Assets\Python\Contrib\autologEventManager.py

Added checks on team related operations.
- In multiple places there are operations on teams that do not check to make
	sure the team ID they are using is valid. This causes assertion
	failures if you are using a debug DLL. It also results in the return
	value being junk (whatever happens to be in memory one pointer step
	before the start of the array when it looks for element -1).
	
	Note that these sorts of thigns are present back to regular FF,
	but I also found one in BUG.
	
	Modifed Files:
		Assets\Python\FinalFrontierEvents.py
		Assets\Python\pyWB\CvWBDesc.py
		Assets\Python\Screens\CvExoticForeignAdvisor.py

Fixed some issues with the data shown in the Sevopedia.
- This was specifically intended to get the Traits category to work. In
	the process of doing so it brough in some other stuff.
	
	Merged the BUG New Concepts file into the FFP version. Also added the
	data necessary to get the FFP traits listed (and commented out the
	entries for the standard traits), including adding some basic pedia
	text for each. This also involved adding the FF traits to BUG's
	TraitUtil.py file which assigns a gamefont icon to each trait (I
	picked a set that are in some way representative) and also a button
	(fortunately, copying the atlas reference for the button from
	CIV4ArtDefines_Civilization.xml works so we don't have to include
	separate DDS files for each - although I do have them extracted
	from the atlas already).
	
	This has resulted in the inclusion of some spurious things, like
	guides for the regular game that talk about its civilizations,
	civics, traits, and such.
	
	Modified files:
		Assets\Python\BUG\TraitUtil.py
		Assets\XML\BasicInfos\CIV4NewConceptInfos.xml
		Assets\XML\Text\TraitsPedia_CIV4GameText.xml
		
Changed the Military type civcs' free units.
- It turns out that the free military units property of some of the military
	civics were having no effect. This is because the per unit cost of
	military units is 0 unless you are running a civic that makes
	military units have a cost. The only civic that does this is
	Pacifism. SInce that is a military civic, you can't be running
	both it and one of the other 3 military civics that was giving
	free military units...
	
	So the number of free military units that the Traditional (at 2),
	Light Ship Doctrine (4), and Squadron Doctrine (8) civics were
	allowing have been changed from "free military units" to
	"free units". This counters the 1 credit per unit cost (not
	counting difficulty level adjustments) that every unit has
	that is past the number free units (which is actually set
	to 4 + 24% of your population, plus what these civics now give).
	
	Modified File:
		Assets\XML\GameInfo\CIV4CivicInfos.xml

God-Emperor · Dec 4, 2010

God-Emperor said:

- Changed the Military type traits free units. [Game tweak - wasn't doing what I thought.]

Spoiler :

Oops.

I just noticed that I said "traits" in several places in the above stuff. This is wrong...
Where it says "traits" it should say "civics".

Edit: OK, I went back and fixed it in the post, but it is still wrong in the text file that comes with the update.

God-Emperor · Dec 21, 2010

A previously unnoticed/unreported issue fixed:

The automatic unit naming has an "advanced" option. It relies on a settings file that is empty in the current version. Because of that, it doesn't work.

Here is a patch for it that improves the unit naming.

Currently the automatic naming's default for the non-advanced setting produces names in the form "<unit type> <number of type ever built> (<name of city where it was built>)". The game then appends more to it in the form "(<actual unit type>)", which is different than the unit type in the name when you upgrade a unit since that doesn't change the name. As you might guess this can produce names that are really long. Too long, really - they can extend well past the end of the area provided for them on the lower left of the screen, for example: "Planetary Defense Ship 7 (The Bellows) (Planetary Defense Ship)".

The attached file allows you to set unit naming to the Advanced option and get some pretty good results. It produces names in the form "<designation>-<number of type ever built> (<city where it was built>)", which looks very similar. However, the "<designation>" part is designed to be short. Instead of the unit type "Planetary Defense Ship" the designation is "PDS". For a delta PDS it uses <delta symbol>PDS. For a battleship it uses "BB". Invasion ships are "IS". And so on. Much shorter. The same example as in the previous paragraph would be "PDS-7 (The Bellows) (Planetary Defense Ship)".

The only problem I know of is the minor issue that unique units get the same names as the units they replace, so it has things like the Battlecruiser getting the same "CA" that the regular cruiser gets. This is because in the file the units are listed by unit class rather than unit type.

EDIT:

To use this, extract the file contents of the zip file and put the two files in the matching folders in the mod - you should be able to copy it over the mod, replacing the existing files.

I had actually fixed this a couple weeks ago and posted the pre-edit stuff that was here as a spur of the moment thing. In the process I forgot that this change isn't just the settings file for the advanced unit naming... In order to get the delta and omega icons to work in that file I had to do a minor update to the file that uses the information.

This is my note for this update:

Spoiler :

Edit: Re-revised version.

God-Emperor · Dec 23, 2010

Oops.

The update in the previous post was not complete. I have edited the post and attached the full fix.

God-Emperor · Jan 7, 2011

Wow.

Weeks later, I have discovered that the updated version of the FFPBUG ADvanced Unit Naming.zip file was also wrong. It included autologEventManager.py instead of UnitNameEventManager.py like it was supposed to. No only that, but somehow my own updated version of that file went missing (probably why it had the wrong file in it).

So I have recreated a fixed verion of UnitNameEventManager.py, put it in the zip file with the fixed .ini, and am reposting the thing yet again. Hopefully for the last time...

So see post #13 above for the re-revised patch for the advanced unit naming feature.

God-Emperor · Jan 10, 2011

New Known Issue.

I've noticed this a couple times before, but keep forgetting to add it to the list.

8) Planet displays on "city" screen and the system preview screen do not update.

EDIT:

It turns out that this is not a bug. It's a pity that it took me about 6 hours of messing around looking for bugs before I realized this...

This was caused by me setting my graphics level down to Medium in the regular BtS Options screen, on the Graphics tab. (Hoping to have fewer difficulties playing the Master of Mana mod, which my low memory graphics card has problems running. I think it did actually help with that, a little.)

So if you are on the High graphics setting the planets on the right hand panel in the city screen and on system preview screen are animated (planet spins, has day/night cycle, moons orbit, commercial satellites orbit, stuff like that). If you are on Medium they are not. (Ditto for Low, I must assume.)

God-Emperor · Apr 6, 2011

I ran into a case where I got a bunch of Python error popups (163, to be exact). Two different types of error with one root cause.

It happens in the PLE code (that creates the unit list across the bottom of the display).

The trigger for this was apparently building a starbase. I think it only happens when you currently have a unit at that location selected, I'm not sure if it has to be a different unit or if it can be the construction ship itself, in this case where it happened had a different unit on the same plot (a ship there to protect the construction ship) that I think was the one I had selected at the time. Normally there isn't a problem due to the timing of things. In this case I did a control-A which forced the worker to do its action immediately which cased the worker unit to go away on screen and the starbase to show up, amongst the long sequence of pop-up error messages.

The root cause is likely to be that the PLE holds a list of units on the plot and while there is a check to see if the unit exists, there is no check to see if it is marked as dead.

My current guess at a fix is to change line 290 in PLE.py (in the Python\Screens folder) from

Code:

				if (pLoopUnit):

to

Code:

				if (pLoopUnit and not pLoopUnit.isDead()): # G-E bugfix - don't show dead units

That will probably fix it.

Note that this probably has no noticeable effect if you do not have the Python error popups enabled. At worst it would probably delay the appearance of the starbase button in the unit list for a screen update or two (say 1/30th of a second unless there is something else going on slowing things down), and maybe also slightly delay the appearance of the unit model on screen too.

God-Emperor · Apr 10, 2011

Another small tweak.

On the Victory screen the 'Human Ascension" part just shows "Apollo Project Not Built".

You can fix this by turning off the BUG enhancements to the victory screen in the BUG options. That turns off all the enhancements (there are 4 things), including the number of turns until the top cities hit Legendary influence at their current influence generation rate. Since I prefer to keep the other enhancements, I disabled the changes to the "spaceship" part like so:

In Python\Screens\CvVictoryScreen.py, line 1249 looked like this:

Code:

				if AdvisorOpt.isVictories():

I changed it to be this:

Code:

				if false and AdvisorOpt.isVictories(): # GE - disable the new project/spaceship display as it is wrong

which forces it to do the "else" code, which is the old version that handles the Astral Gate Pieces a lot better.

It may also be possible to fix this by setting the Astral Gate Design's bSpaceship value to 1, but I didn't try that. That might allow the original BUG CvVictoryScreen.py to be used, although the text key that mentions the Apollo Project not being built by anybody would need to be changed too.

Deon · Apr 28, 2011

Hey, just when I wanted to play some old good FFP I come here and find this

. Thank you!

Morkonan · May 3, 2011

Thank you very much for making FF an enjoyable game!

With BUG, it's going to be just that much better!

Final Frontier Plus BUG

Deity

Attachments

Deity

Deity

Deity

Deity

LivE LonG AnD PrOsPeR

Deity

Deity

Deity

Deity

Deity

Attachments

Deity

Deity

Attachments

Deity

Deity

Deity

Deity

Deity

Lt. of Mordor

Warlord

Similar threads