Download Here

Patch 1.71 has been released, fixing errors that (mostly) resulted from the FFPBUG merge. Changelog:

-Fixed leader pages in the pedia to work properly with multiple favorite civics
-Fixed a handful of Python merging errors between FFPBUG and FF+ 1.7
-Fixed bug with military doctrines and free unit support
-Fixed bug with traits civilopedia page being empty
-Fixed logging error with BUG Core.xml and the onUpdate function
-Added Final Frontier Plus options tab to the BUG configuration menu
-Re-added advanced station construction AI (and remerged CvAI.py in general)
-Reset cultural levels to the FFPBUG ones
-Set default user settings to optimal for Final Frontier
 
The Civilopedia is much better now. But... (you knew that was coming) the Traits still have a minot issue that is caused by not having the updated Python\BUG\TraitUtils.py file. Without that, each of the FFP traits is marked with a simple globe icon in the list when you select Traits and on the each of the individual trait pages there is a big magenta square instead of an image. There might be a place or two in the game where these show up too, although I can't think of any at the moment.

OK - so off to actually play a game and poke around a bit looking for any other issues. I'll be paying attention to how many (if any) sensor stations the AIs build since they might build too many (or none at all), and just generally looking around and clicking on everything to see what I can see.

Edit: oops, this was supposed to be over in the bugs thread. Too late now.
 
The Civilopedia is much better now. But... (you knew that was coming) the Traits still have a minot issue that is caused by not having the updated Python\BUG\TraitUtils.py file. Without that, each of the FFP traits is marked with a simple globe icon in the list when you select Traits and on the each of the individual trait pages there is a big magenta square instead of an image. There might be a place or two in the game where these show up too, although I can't think of any at the moment.

OK - so off to actually play a game and poke around a bit looking for any other issues. I'll be paying attention to how many (if any) sensor stations the AIs build since they might build too many (or none at all), and just generally looking around and clicking on everything to see what I can see.

Edit: oops, this was supposed to be over in the bugs thread. Too late now.

Heh. Figures I'd forget something.

That file will be included in 1.72, whenever it gets released.
 
I finished playing my test game of 1.71 (winning via ascension, also maybe 36 turns from cultural victory). I tested a lot of stuff. Standard speed, standard size with default map settings on a Wormholes map on Noble difficulty. I researched every tech and built every building except a few wonders (the Red Syndicate beat me to 2 of them that I was building, one by 2 turns, and got a couple more before I got the tech to even try - they ended up ahead of me in tech for the second quarter of the game, about even for the 3rd quarter, and behind for the final quarter the game) and the other civ's UB (I was the Brotherhood).

The things I've been reporting came from this test game. Here are a couple more possible issues.

Thing I never saw: a unit doing a defensive withdrawal. Admittedly, most of the combat happened out of my line of sight. The one occasion where I had a high withdrawal chance unit (an omega invasion sip with all 3 stealth promotions at +15% each and possibly a smidge from something else for probably 45 or 50% withdrawal chance on attack - I don't know if the defensive chance is the same as chance on attack) get attacked it didn't happen, but that is not statistically significant. So this may need more testing unless you've verified that it does happen.

I checked the building of sensor stations, going into world builder after the game ended to check the areas I didn't see in game. A few of them got built. Pretty much all of them were next to nebula plots and almost all of them had several inhospitable plots in their vicinity (radiation clouds or supernova areas in particular). Attached is a piece of a screenshot that shows the typical situation. The Avowers were not shy about building stations well outside their territory. The locations also appear to be a little too surrounded by features. My assessment of things from this one game is that there are a couple of adjustments I will probably make: first, the value of the inhospitable terrain should be decreased a little, especially when there is a bunch of it; and second, the distance part of the evaluation should be adjusted to make them want to stick a bit closer to their own star systems. I'm not sure what to do about placing them by a nebula that is so close to the edge - fixing that would require expanding the search area around the plot being checked which would slow the entire process down, although just adding 4 plots (one 3 north, one 3 east, etc. and only checking to see if these 4 plots are off the map, reducing the plot's value for each that is, could give good results).

By the way - I never once saw a pirate wipe out a sensor station. I'm not sure why, although most of the time I could only check the three in the attached image which ended up in an area protected by my star system's culture and a starbase I built. In my next game I may build a few and see if the pirates attack them or not (I didn't build any in this game).
 

Attachments

  • Stations.jpg
    Stations.jpg
    60.7 KB · Views: 328
When will patch 1.72 be available?

That depends on whether you think I should wait to fix the mapscript bug, which I'm making no progress on.

I could release it today with that mapscript thing unsolved.
 
That depends on whether you think I should wait to fix the mapscript bug, which I'm making no progress on.

I could release it today with that mapscript thing unsolved.

Well, i've been trying to merge the B5 mod with 1.71 and am getting a lot of errors once I actually start a game. It's possible it is linked to the mapscript problem you mention so I will probably be best waiting.
 
The mapscript issue is not huge and only shows up if you redo the map. If, after you have started playing, you exit the game to the main menu and start again you get a pretty messed up map or a crash. Currently the workaround is to always exit to desktop and start over from scratch.

I, too, have been thinking about the situation but have not yet tested my idea. My current thoughts are that it may only take just 3 changes:

1) Force the global arrays in the new mapscript stuff to be reinitialized before they are used by the script (perhaps at the start of the feature generation code - in fact, in the Wormholes, FinalFrontier, and FinalFrontierFlat scripts there are already commented out sections of code that would do this at this location). This would need to be done for each map script.

2) Do the same for the star system data by calling the resetSystems() function in onGameStart in FinalFrontierEvents inside the if block that is for map scripts. By the time it gets this far, the star system data has already been loaded for WB saves, so reseting would wipe out the correct data - it has to be done earlier for them, which is why it needs to be inside that if block to only reset it for mapscripts. Since CvSolarSystem is being imported into the local namespace it would just literally be "resetSystems()".

3) Also put a call to resetSystems() in the code that loads a worldbuilder save at a point before it actually starts to load any map data, probably at the start of the CvWBDesc class's read() method shortly after opening the file before much of anything is actually loaded from it.

It is already being done when loading a regular savegame file as the first thing in loadSystemsFromPlots(), so you should be able to load a saved game from inside an already running game and not have it mess things up.

That may be all it takes to get it to work, but I could also still be missing something in there somewhere.

I expect to try this out later today.
 
The mapscript issue is not huge and only shows up if you redo the map. If, after you have started playing, you exit the game to the main menu and start again you get a pretty messed up map or a crash. Currently the workaround is to always exit to desktop and start over from scratch.

I, too, have been thinking about the situation but have not yet tested my idea. My current thoughts are that it may only take just 3 changes:

1) Force the global arrays in the new mapscript stuff to be reinitialized before they are used by the script (perhaps at the start of the feature generation code - in fact, in the Wormholes, FinalFrontier, and FinalFrontierFlat scripts there are already commented out sections of code that would do this at this location). This would need to be done for each map script.

2) Do the same for the star system data by calling the resetSystems() function in onGameStart in FinalFrontierEvents inside the if block that is for map scripts. By the time it gets this far, the star system data has already been loaded for WB saves, so reseting would wipe out the correct data - it has to be done earlier for them, which is why it needs to be inside that if block to only reset it for mapscripts. Since CvSolarSystem is being imported into the local namespace it would just literally be "resetSystems()".

3) Also put a call to resetSystems() in the code that loads a worldbuilder save at a point before it actually starts to load any map data, probably at the start of the CvWBDesc class's read() method shortly after opening the file before much of anything is actually loaded from it.

It is already being done when loading a regular savegame file as the first thing in loadSystemsFromPlots(), so you should be able to load a saved game from inside an already running game and not have it mess things up.

That may be all it takes to get it to work, but I could also still be missing something in there somewhere.

I expect to try this out later today.
:lol:I guess it is just my inept use of Winmerge and not the issue here that is the problem for me then.
 
OJ, I tested my ideas and it seems to work for loading from mapscripts twice.

Test method: Play Now, once in game play a turn and then Exit to Main Menu, the Play Now again. I played 50 turns of the second iteration of the map and saw no problems).

I have not tested WB saves, but they should work now too.

I only modified one map script, byt chaning all of the others in the same way should do the trick, along with the other changes.

So:

1) I each map script, add code to reinitialize the two global arrays. In the non-spiral galaxy based map scripts there is already some commented out code in the correct location, although that code is missing the pair of "global" statements necessary to modify the global variables. This is what the one I tested it with (FinalFrontierFlat.py) now looks like around the affected section of code:
Code:
		# Reset globals which have to do with player starting positions
#		#print("Clearing global arrays when new map is made")
		[B][COLOR="DarkRed"]global g_aiPickedPlotForPlayer
		global g_apSolarSystemPlotList
		g_apSolarSystemPlotList = []
		g_aiPickedPlotForPlayer = [][/COLOR][/B]
#		#print("g_apSolarSystemPlotList")
#		#print("g_aiPickedPlotForPlayer")
#		#print(g_apSolarSystemPlotList)
#		#print(g_aiPickedPlotForPlayer)
In FinalFrontierFlat.py that first comment line is line 282.

2) reset the star system data when loading a map. This is in FinalFrontierEvents.py, where I inserted the resetSystems() call into a previously blank line, which is line number 139:
Code:
		if not ('.civbeyondswordwbsave' in CyMap().getMapScriptName().lower()):
			[B][COLOR="#8b0000"]resetSystems() #FFPBUG[/COLOR][/B]
			self.initMembers()

3) In CvWBDesc.py I added a call to resetSystems() after line 2185, so that section of code now looks like this:
Code:
		if (version != self.getVersion()):
			CvUtil.pyPrint("Error: wrong WorldBuilder save version.  Expected %d, got %d" %(self.getVersion(), version))
			return -1	# failed
		
		[COLOR="DarkRed"]resetSystems() #FFPBUG[/COLOR]
		
		print "Reading game desc"
Note: I have not tested this particular part.
 
Patch 1.72 has been released. This patch fixes various errors, including the "exit to main menu" error and finally gets the FFP tab on the BUG options screen. Changelog:

-Fixed bug with FFP tab on BUG option screen still not working
-Fixed incorrect text for capital ship, carrier ship, and missile construction feats
-Fixed SpiralGalaxy mapscript creating invisible floodplains
-Fixed a Python exception in onCityRazed
-Fixed a Multiple Favorite Civics-related Python exception that occured in a handful of places
-Fixed a few missing icons in various places
-Fixed bugs that resulted in odd behavior when exiting to main menu and starting another game
-Fixed a bug when the Pirate AI checks if it can build fighters
-Added a cleanup script to the installer to fix other potential bugs

Note that there is a checkbox that would let you stop the cleanup script from running. You should not uncheck it!

If you do, the script is installed to Mods\Final Frontier Plus\CleanInstall.bat. You can run it manually by double-clicking it (like an executable file).
 
Re: my statements in post 24 about never having seen a defensive withdrawal...

In my latest game, I finally saw a defensive withdrawal. So it does happen from time to time. The frequency seems rather low since this is, I think, my 5th game since 1.7 came out and this is the only time I specifically noticed it happening (it may have happened without my noticing, but certainly not very many times).

I was painful to see. My battleship was attacking a stack of damaged units and the defending battleship withdrew leaving my now damaged battleship attacking a different battleship. So, of course, it was killed by that other battleships in the stack that was probably slightly more damaged than my original target had been at the start of my attack but was now less damaged than I was. This clearly makes those withdrawal granting promotions the AI like to take more valuable than they were - possibly as valuable as the AI has always thought they were (it has always taken them far more often than I do).
 
Patch 1.73 has been released!

This includes everything God-Emperor or I have fixed in the past three months or so, and is almost certainly the last 1.7x patch. Here is his changelog:

-Fixed a Python exception in onCityRazed (really, this time)
-Added missing Multiple Production code (Multiple Production game option now works)
-Changed text shown by Mining Facility to indicate +2 production for The Forge
-Fixed and Added some BUG merge related text
-Fixed potential crash from inhabited planets
-Include an adjusted settings file for the Domestic Advisor screen
-Changed AI Python and civilization XML a bit to (hopefully) improve the AI behavior
-Fixed the Astral Ascension section of the Victory screen
-Buffed Astrotech a little: +25% to build habitation facility and slight improvement to UU
-Changed Starabses to have free Improved Sensors upgrade to improve behavior when in sentry mode
-Added new Productive Pirate Cities game option
-Changed City Screen to show direct yield bonuses from traits for trade routes
-Fixed Nanotech Hospital and Extended Habitation System to increase in cost as more are built in a system
-Fixed nuke effects (as per Doomesday Missile) on star systems
-Fixed building meltdown effects on planet (no building does this currently in FFP, done for Star Trek)
-Fixed theme file issue

For the future? We'll likely have 1.8 out by/around the end of the year. At that point, I'd like to implement my new release schedule idea, where every three or four months we'll just take everything (in a releasable state) in the subversion repository and release it.

I'm intending that the alien civs will (start?) to go in at version 2.0. We'll see how that ends up coming.
 
For the future? We'll likely have 1.8 out by/around the end of the year. At that point, I'd like to implement my new release schedule idea, where every three or four months we'll just take everything (in a releasable state) in the subversion repository and release it.

Hey guys!
How far is the 1.8 release?
 
Hey guys!
How far is the 1.8 release?

No idea... maybe it'll happen around Christmas, but it'll probably be a much smaller release than 1.7 was (since not a lot has really changed since 1.7 anyway).
 
1) Download version 1.7 via the links in the first post in the thread: either from the first link (if you still have FF installed) or the second link (if you removed FF).
2) Download the 1.73 patch via the third link.
3) Unzip the file from step 1 to get the main version installer (and a "readme.txt" file).
4) Unzip the file from step 2 to get the patch installer (and a "1.73 Patch Changelog.txt" file).
5) Run the program you got in step 3. You can read the text file if you want.
6) Run the program you got in step 4. You can read the text file if you want.
7) Play.

That should be it.
 
Would be simpler if there was a 1.8 version. Btw, any progress on that (as it was supposed to be released last year)? :confused:
 
Would be simpler if there was a 1.8 version. Btw, any progress on that (as it was supposed to be released last year)? :confused:

Yeah, I'm sorry about that. :(

I have been... rather busy lately. It's true that I originally intended to work more on 1.8 around Christmas time. Due to a bunch of reasons that did not happen.

But I hope God-Emperor and I will be able to post in about a month saying "Here's 1.8, guys."
 
I too have not been working on it as much as I had expected.

Relatively recently, I had intended to finally merge my experimental AI branch of the SVN back into the trunk two weeks ago (even PMed TC01 that I was going to) and that hasn't happened yet even though it was already a month and a half past when I originally expected. This latest delay happened because of a significant bug that I introduced from just changing a ">" to a ">=", which got me thinking that I need to run some more test games but I haven't actually been playing them much.

And, of course, I made the mistake of finally trying out Caveman 2 Cosmos (even though my computer is nowhere near capable of actually finishing a game of it). Way too much time spent messing with rocks and learning to make fire and suchlike in the last week and a half.
 
Top Bottom