Sourceforge!

[TC01]

A few days ago I created a Sourceforge repository for Final Frontier Plus.

The main reason for this was to avoid the merging nightmare of version 1.7, when God-Emperor did FFPBUG but I had already done a few things and I had to merge these projects. If you look at the list of bugs fixed in patches 1.71 and 1.72, you'll see that I didn't do a perfect job (to say the least). So having a svn repository should make committing code to the project much easier.

Aside from the svn repository containing the source, it serves as a alternate mirror for downloading both versions of the current release and the patches. We also won't lose older copies of the mod now.

Then there's the bug tracker. I'd encourage you to submit bugs there as well as posting them in the bug thread or the forum thread simply because Sourceforge provides a nice organized interface for doing so, but you don't have to. (And while you're at it you could also use the Feature Requests tracker to submit, well, Feature Requests if you have any).

And yes, there is also a little web site which is horribly primitive right now. Aside from links to a bunch of places, I'm not really sure what else would belong there.

 

[God-Emperor]

I have done an SVN update. I decided to go with just adding things to the trunk for the moment, since I have tested this stuff well enough that I don't think I added any crash-inducing bugs.

See the SVN log for exactly what was updated.

I added some additional BUG related folders with files in them that are different from the base BUG 4.4 files (or entirely new).

The AI should perform slightly better now in that it ignores some things in the Python override when it can't do anything about them.

It still does not build enough units in general, although I have been subjected to a couple of attacks when using these adjustments that could have worked (although just barely) if it wasn't for my squadrons.

 

[God-Emperor]

In retrospect, perhaps I should have committed things in smaller groups, as doing it this way left out a lot of the usual explanations of what exactly is changed. I suppose I could have included the whole list in the log message for it.

Anyhow, here is my change log for this set of changes:

CIV4BuildingInfos.xml
- AstroTech needs a little boost.
	- +25% production bonus for AstroTech to build a Habitation Facility
- It would be really nice if the AIs valued the commercial satellites more
	- change the iAIWeight from 2 to 12 for both BUILDING_COMMERCIAL_SATELLITES
		and BUILDING_PBS (all buildings that increase planet yields had this set to 2)
- Change the help text for BUILDING_MINING_FACILITY to show +2 for Forge
	from TXT_KEY_BUILDING_MINING_FACILITY_HELP to TXT_KEY_BUILDING_MINING_FACILITY_HELP_NEW
- Fix Nanotech Hospital and Extended Habitation System: they are both missing the <iCostModIncrease>2</iCostModIncrease>
	- add that line to both BUILDING_NANOTECH_HOSPITAL and BUILDING_EXTENDED_HABITATION_SYSTEM
	
FFP BUG Text.xml
- Added new XML file to Text folder. This should have been added with the BUG merge,
	it includes some text used with the BUG autolog feature and the new
	TXT_KEY_BUILDING_MINING_FACILITY_HELP_NEW
	
autologEventManager.py
- Copy over the version from FFPBUG, replacing the one currently in FFP.
	This has added logging stuff for inhabited planets, avoiding a python bug
	(key error, since it doesn't find the added goody types in its dictionary)
	if you are logging and hit one. The one in FFP 1.72 incldues no changes in
	that function, only the corrections for civic category count.
	
CvAI.py
- A few too many squadrons being forced
	- reduce target number of fighters and bombers by 1 (iEnoughUnits, 2 places)
	- reduce chance to force the build of a squadron factory from 75% to 50%
	
CIV4LeaderHeadInfos.xml
- All of the leaders are set to be rather sociopathic - as bad as Montezuma, or worse.
	It appears that the original values wer set with the assumption that lower numbers
	for iMaxWarRand, iLimitedWarRand, and iDogpileWarRand decrease the warmongering level.
	That is not the case - higher numbers are less warlike.
	Regular BtS values:
		Montezuma = 50/40/24
		Gandhi = 400/200/100
	FF(P or not) values:
		HECTOR_ALVAREZ = 25/15/8
		LUKAS_VON_REUTHER = 25/40/20
		LU_TIANQU = 13/10/13
		JOHN_RICHARDS = 25/60/10
		LEONARD_PRITCHARD = 75/25/8
		KANJI_TAKENO = 25/30/15
		VLADIMIR_KOROVIN = 75/50/20
		RAUL_COLOMBO = 10/10/8
	So Vladimir Korovin is the least crazy, but is only slighly less crazy than Montezuma,
	and Raul Colombo makes Montezuma look positively peaceful (with Lu Tianqu right behind).

	- new values for iMaxWarRand/iLimitedWarRand/iDogpileWarRand, based on some
		of my opinions of how warlike they should be (they all have somewhat mid
		to high chances of joining a dogpile; none are as peaceful as Gandhi):
			HECTOR_ALVAREZ = 90/95/80
			LUKAS_VON_REUTHER = 100/100/80
			LU_TIANQU = 200/100/75
			JOHN_RICHARDS = 50/60/50
			LEONARD_PRITCHARD = 125/90/50
			KANJI_TAKENO = 90/100/100
			VLADIMIR_KOROVIN = 125/95/80
			RAUL_COLOMBO = 50/50/50
			
- Also adjusted a couple of the UnitAIWeightModifiers UnitAIType settigns and
	added a new one for each leader: they all now also get an entry for
	a UnitAIType of UNITAI_CITY_DEFENSE with a weight of 25 except
	for Kanji Takeno who gets it at 50 (since his UU has this unit AI type
	for its default).


CvVictoryScreen.py
-The Astral Ascention display has issues.
	- fixed "Apollo Program" text 
		on lines 1255 and 1264 changed the text shown
			from TXT_KEY_PROJECT_APOLLO_PROGRAM to TXT_KEY_PROJECT_ASTRAL_GATE_DESIGN
	- removed acess to spaceship screen from victory screen:
		disabled the conditional block at line 1363
	- changed how the enabling project for the "build peices to win" VC is determined:
		modified isApolloBuiltbyTeam function

CvAI.py (again)
-Adjusted the Python AI overrides. In particular, the health check and any adjustment
	(or lack thereof) that is done when the system is already at it's max pop.
	When at max pop, we certainly do not need to be increasing the health with any urgency.
	Therefore, I have tweaked the health weight computation.
- Ditto for food weights.
	Also tweaked it to not want more food if at pop cap, not just over it.
	Also reduced the weight a little if we have an excess of 6+, and more if at 9+.
- Also tweaked production and commerce weights to account for (somewhat) the potential 2nd level upgrades
- Tweak sensor station location selection, the findBestChokepoint function.
	Reduce the desired amount of bad terrain slightly and
	adjust distance penalty (narrow down the "flat spot" to increase the penalty at longer distances a little) and
	added a small bonus for having a few plots in the test area that belong to that player, or a penalty
	for too many, and a small penalty for plots owned by someone else (hopefully encouraging them to 
	build a couple near the edges of their territory instead of far away from it).
- Moved the bailout if at war check from the military weights section to be before the first weight
	calculation to save time and effort - why calculate stuff that will never be used when we bail?
	This is now right after the number of wars is calculated (whcih was moved here a while ago).
- Added a new check to see if the AI has a war plan of either of the two planning types,
	WARPLAN_PREPARING_LIMITED or WARPLAN_PREPARING_TOTAL. If it has at least one of either of
	these active against some other team, then there is a 25% chance (as a first guess) to bail out now.
	Added the code right after the bailout for actually being in at war.


CIV4UnitInfos.xml
- Missile frigate (all 3 generations):
	These are weaker than the regular ship for the AI. They are also weaker
	(for everyone) against missiles and squadrons since they have the same
	+100% vs. those but the base strength is lower.
	- Fixes:
		changed +100% bonus vs. squadrons and missiles to +150%
			(making them slightly stronger vs. these than the regular destroyers)
		added a 5% withdraw chance
- Starbases don't come out of sentry mode when an enemy unit is in weapon range
	and visibile due to the 1-past-culture-borders visibility but not
	within the unit's onwn visibility, which is currently 1 less.
	- Fix: gave all 3 generations of starbase the first sensor upgrade for free

SevoPediaTech.py
- Copy over the version from FFPBUG which has the code necessary to make the
	new FFP BUG "Hide Tech Text" option.
	
CvSolarSystem.py
- In the interest of making things a little easier to spot in the log file:
	changed the production swapping routines to only do a printd if the value is non-zero

 

[TC01]

I realized I never replied to your PM...

As part of his speed tweak modcomp, Sephi disabled the doCulture() function for barbarian cities because it apparently slowed the game- here is the relevant section of CvCity::doTurn with his comment (and mine).

/*************************************************************************************************/
/**	SPEEDTWEAK (BarbCities) Sephi                                            					**/
/**	This function can be very slow for barbarian cities(adds 1-3sec to turn time).Reason unknown**/
/**	If this has an influence, gameoption it (TC01)                                   			**/
/*************************************************************************************************/
/** orig
	doCulture();
**/
    if (!isBarbarian())
    {
        doCulture();
    }
/*************************************************************************************************/
/**	END				                                                       						**/
/*************************************************************************************************/

It would be really easy to undo, or make optional.

 

[God-Emperor]

I spotted that.

Currently, when the pirates capture star systems they spend a lot of time building influence which (with that change) does exactly nothing. I have seen them build other things, but not very often and most of them seem to be things they are forced to build by the Python AI override code.

So the question is, is that OK? Do we want the Pirates to actually be able to do something productive with a star system that they capture, or is the current situation acceptable?

I would note that there are usually fewer pirate systems under FFP then there are barbarian cities in BtS. For most of the game, there are none. At various points in the mid and late game they often have some and occasionally in the late game quite a few. I think the most I have ever seen them have was on a large size galaxy map when they ended up with 9 in the late game. In BtS, particularly on maps with a "new world" type situation, they can have more than that. With fewer cities to check the slowdown for us might be less than the comment indicates.

Edit: I forgot to say that I think an option might be the way to go. Some people might like pirate cities to be useful to the pirates, others not so much.

 

[TC01]

I spotted that.

Currently, when the pirates capture star systems they spend a lot of time building influence which (with that change) does exactly nothing. I have seen them build other things, but not very often and most of them seem to be things they are forced to build by the Python AI override code.

So the question is, is that OK? Do we want the Pirates to actually be able to do something productive with a star system that they capture, or is the current situation acceptable?

I would note that there are usually fewer pirate systems under FFP then there are barbarian cities in BtS. For most of the game, there are none. At various points in the mid and late game they often have some and occasionally in the late game quite a few. I think the most I have ever seen them have was on a large size galaxy map when they ended up with 9 in the late game. In BtS, particularly on maps with a "new world" type situation, they can have more than that. With fewer cities to check the slowdown for us might be less than the comment indicates.

Edit: I forgot to say that I think an option might be the way to go. Some people might like pirate cities to be useful to the pirates, others not so much.

Yeah, I agree; perhaps called "Productive Pirate Colonies" or something?

Either that, or we could try to mess around with the city AI to get pirate cities to not build culture.

 

[God-Emperor]

One problem with the pirates inability to get any culture is that it limits the size of a star system to the amount of population supportable by the food generated on planets in the inner zone. If the pirates capture a system with more people than that is will starve down and never grow back (well, maybe if they are forced by the overrides to build habitation systems and nutrition facilities it could grow some). This is not a huge problem.

The main issue I have with it is really that you can currently just ignore them. They will never produce a ship. In BtS you can expect a barbarian city to send a fairly steady stream of units at its neighbors. In FFP currently you will never get a pirate from a pirate star system. It is no threat at all to have it near you. The only extra pirates you might get from it are some occasional spawns that can now happen in that area due to the old owner's cultural area no longer being there to block the spawning. Whether this mean blocking them from building culture or allowing them to do so to pop their borders and get on with building other things is not clear.

For the sake of simplicity I would just go with what we know and have the option allow them to run the doCulture routine (rather than tracking down how to block the build culture process for them, which we don't currently know).

 

[God-Emperor]

Commited a couple of tweaked .cpp files to the trunk to allow both terrain and feature defensive modifiers to work and be displayed in the combat data. Didn't submit a modified DLL (yes, I am set up to build the DLL now - have been for almost 3 weeks).

Coming soon: things in the Experimental AI branch.

 

[God-Emperor]

I have added an updated Release DLL, named CvGameCoreDLL-1.73a.dll (anybody interested in using it needs to remove the "-1.73a" suffix).

It is an up to date version of what is in the Trunk, so it includes the r19 bugfix (for Trait's FreePlanetBuildingClass usage) and r20 change (allow both terrain and feature defensive bonuses simultaneously, so the armor part upgrades will now work in asteroid fields and star systems and such). In regular FFP the bug had no effect, but the defensive bonus change does. Armor is more useful now.

You can find it here: http://civ4ffplus.svn.sourceforge.net/viewvc/civ4ffplus/civ4ffplus-dll/release/

 

[God-Emperor]

I posted another new release DLL. It includes a two changes and a bugfix that I also committed to the trunk (rev 26).

 

[God-Emperor]

Lest anybody think nothing is happening, there have been SVN updates during the last month and a half since my last post here. Mostly to my Experimental AI branch (a few of which should have gone to the trunk - like changing the buttons for the two Neural Interface promotions and fixing the text for the trade route yield modifiers to show that they are a percent change), but also a few to the trunk. Today I added individual icons for the various shrines so they now show the correct symbol (instead of all showing the Judaism symbol). Last Tuesday I updated the SpiralGalaxy mapscript to remove the flood-plain placeholders - the WormholeSpiralGalaxy mapscript had already been fixed but not the version without the wormholes. Et cetera.

Sometime pretty soon, I should be merging the Experimental AI branch back into the trunk. Ships that can carry missiles often do. Ships, including starabses, that can carry squadrons often do. It may occasionally bring along a few invasion ships when attacking. Many other small adjustments (there is some slim chance that some AI may even use the Technocracy or Planned Economy civic, and they research the Planetary Networking tech before they need to get it as a prereq slightly more often than they used to). No extra crashes (maybe slightly fewer since I fixed a couple of bugs).

Not too long after that there will probably be a new version released. I hope.

 

[tesb]

what about the alien races?