Unofficial Patch for 3.19

[Temudjin]

.. well at least it somewhat changed them . And yes, just about all of them too .

I just had a closer look at the way latitudes are generated by map scripts. There is a method CvPlot::getLatitude(), which generates a value between 0..90 and there are several problems with it. .. well I found two :

1) plot.getLatitude() divides by GridHeight instead of (GridHeight-1), which results into the absence of the northpole. .. or at least the highest row of plots won't have the latitude 90 as would be expected. To illustrate this, here is an example for a map with height 6 (yes it's a very small map):
For heights (0,1,2,3,4,5) plot.getLatitude() generates something like (90,60,30,0,30,60) with a south pole @ 0 and an equator @ 3, but no north pole. What should be generated is (90,54,18,18,54,90) with the equator between 2 and 3 and poles at both ends.

2) Actually what plot.getLatitude() will generate is (90,62,31,0,28,59), because of rounding errors introduced by using only int and multiplying/dividing by 100.

Here is the Python pseudo-code of how it is now

Spoiler :

# get latitude 0..90 for given plot - corrects error in build-in plot.getLatitude()
# Precision really should be 10000 or greater!
def getLatitude( plot ):
  if CyMap().isWrapX() or (not CyMap().isWrapY()):
    iLat = plot.getY() * 100 / CyMap().getGridHeight()
  else:	
    iLat = plot.getX() * 100 / CyMap().getGridWidth()
  iLat = iLat * ( CyMap().getTopLatitude() - CyMap().getBottomLatitude() ) / 100
  return abs( iLat + CyMap().getBottomLatitude() )

Here is the Python pseudo-code of how it should be

Spoiler :

# get latitude 0..90 for given plot - corrects error in build-in plot.getLatitude()
# using float - this gives the best results
def floatGetLatitude( plot ):
  if CyMap().isWrapX() or (not CyMap().isWrapY()):
    iLat = float(plot.getY()) / (CyMap().getGridHeight() - 1)
  else:	
    iLat = float(plot.getX()) / (CyMap().getGridWidth() - 1)
  iLat = iLat * ( CyMap().getTopLatitude() - CyMap().getBottomLatitude() )
  return abs( int( round( iLat + CyMap().getBottomLatitude() ) ) )

I'm not quite done here as the designers were pretty consistent in the way latitudes are calculated. In CvMapGeneratorUtil.py both, the TerrainGenerator and the FeatureGenerator make the same error of using (getGridWidth()) instead of (getGridWidth()-1). Only two lines need changing though.

Note that unless the mod provides it's own CvMapGeneratorUtil.py, the map generator uses the one in ..civilization 4\warlords\assets\python if installed or ..civilization 4\assets\python - BtS doesn't provide it's own.
Also note that TerrainGenerator deliberately returns a fuzzy result.

Changes in CvMapGeneratorUtil.py

Spoiler :

CvMapGeneratorUtil.TerrainGenerator.getLatitudeAtPlot():
# lat = abs((self.iHeight / 2) - iY)/float(self.iHeight/2)            # 0.0 = equator, 1.0 = pole
  lat = abs( ( (self.iHeight-1)/2.0 ) - iY ) / ( (self.iHeight-1)/2.0 )   # 0.0 = equator, 1.0 = pole

CvMapGeneratorUtil.FeatureGenerator.getLatitudeAtPlot():
# return abs((self.iGridH/2) - iY)/float(self.iGridH/2) 	       # 0.0 = equator, 1.0 = pole
  return abs( ( (self.iGridH-1)/2.0 ) - iY ) / ( (self.iGridH-1)/2.0 )  # 0.0 = equator, 1.0 = pole

At last a modified fractal.py map script for you to play with (that's what we do, don't we). Start a game and look into '...\My Documents\My Games\Beyond the Sword\Logs\PythonDbg.log' to see the results of different latitude generators.

 

[ripple01]

jdog5000,

Two XML errors in 3.19 that should be fixed:

1) In Civ4UnitClassInfos.xml, the Ship Of The Line entry reads as follows:

<UnitClassInfo>
			<Type>UNITCLASS_SHIP_OF_THE_LINE</Type>
			<Description>TXT_KEY_SHIP_OF_THE_LINE</Description>
			<iMaxGlobalInstances>-1</iMaxGlobalInstances>
			<iMaxTeamInstances>-1</iMaxTeamInstances>
			<iMaxPlayerInstances>-1</iMaxPlayerInstances>
			<iInstanceCostModifier>0</iInstanceCostModifier>
			<DefaultUnit>UNIT_SHIP_OF_THE_LINE</DefaultUnit>
		</UnitClassInfo>

The Description entry should read TXT_KEY_UNIT_SHIP_OF_THE_LINE. To my knowledge this bug only affects modded games.

2) In Civ4ArtDefines_Unit.xml, most (all?) of the unique units added in BtS have an incorrect <TrainSound> entry. It should read AS2D_UNIT_BUILD_UNIQUE_UNIT to match the unique units from Vanilla and Warlords?

Cheers,
ripple01

 

[Chrill]

I found a small bug when scrolling through the various barbarian events in the cvrandominterface.py file .

in cvrandominterface.py

def getHelpThGoths1(argsList):

should of course be (at least according to civ4eventinfos) (</3 typo errors):

def getHelpTheGoths1(argsList):

 

[EmperorFool]

Or you could put the typo into the XML file since the patch already requires a new XML file.

 

[jdog5000]

Update: Unofficial Path for 3.19 version 1.0 will be up on Wed or Thurs, including fixes for the three issues just above this post.

All the SDK changes for the patch have been checked in to the BBAI sourceforge repository and tested, I just need to split the new UP into its own project and give it one final pass of testing as a standalone mod.

 

[jdog5000]

Version 1.0 has been released! The download links will always be in the FP of this thread, for convenience:

Download

SDK files if you're merging mods

Also, here is the full change list for 1.0:

Spoiler :

Unofficial Patch v 1.0 fixes:

1) CvUnitAI::AI_paradrop - fixed bug with valuation of terrain bonuses causing paradrops to avoid bonuses in some circumstances when intention is clearly to encourage landing on bonuses and pillaging

2) CvUnitAI::AI_settleMove - fixed bug when settler cannot reach a city site in an area (blocked by mountains, other player). Caused settler to wait infinitely in city instead of loading into transport.

3) CvTeamAI::AI_doWar - use bFinancesProLimitedWar for limited war calc instead of max war version

4) CvPlayerAI::AI_calculateUnitAIViability - Fixed incorrect integer usage which caused function return to be meaningless, blocked AI logic for building privateers

5) CvPlayerAI::AI_isFinancialTrouble, CvCityAI::AI_updateBestBuild, and CvPlayerAI::AI_getMinFoundValue - Fixed bug in calculating expenses when AI has negative gold per turn

6) CvPlayerAI::AI_getTotalFloatingDefendersNeeded - Fixed poor decision by AI if it has captured one or two cities on someone else's continent, it would minimally defend its new cities

7) CvPlayerAI::AI_getStrategyHash - Fixed incorrect counting of destroyers as mobile anti-air

8) CvPlayerAI::AI_doDiplo - Fixed issue where team is sneak attack ready but hasn't declared war, AI would still demand tribute. If other team accepted, it blocked war declaration for 10 turns but AI still launched invasion and was then bounced when it could eventually declare.

9) CvPlayerAI::AI_bestPlotEspionage - relevant weights are 0, +- 50, +- 100, so comparison for Agg AI should be < 51 instead of < 50

10) CvPlayerAI::AI_commerceWeight - Governors now do smarter things when human player sets culture slider to 100%

11) isPotentialEnemy in CvGameCoreUtils - Fixed bug leading to AI launching invasions when unable to declare war, troops eventually got bounced when war was declared

12) CvGame::addPlayer - No longer invalidate color choice for added civ if it's taken by this player slot

13) CvCityAI::AI_cityThreat - Fixed bug when AI is running crush strategy, wrong int was divided

14) CvCity:opOrder - Kept overflow fixes from 3.17 unofficial patch

15) CvCityAI::AI_neededDefenders - Improved efficiency and minor tweaks

16) CvPlayerAI::AI_isFinancialTrouble, CvCityAI::AI_updateBestBuild, and CvPlayerAI::AI_getMinFoundValue - Fixed bug where spending gpt for resources reduced calculation of expenses (thanks DanF5771)

17) CvPlayerAI::AI_conquerCity - Fixed bug where cityAcquiredAndKept event reported wrong player in some circumstances (thanks Maniac)

18) CvPlayerAI::AI_unitValue - Fixed potential crash bug in looking up AI_unitValue for UNITAI_MISSIONARY units without passing a valid CvArea*

19) CvUnit::isIntruding - Kept 3.17 unofficial patch feature that vassal spies are never caught in master's territory

20) CvUnit::collateralCombat - Kept 3.17 unofficial patch feature which allows mods to enables barrage promotions for collateral damage units

21) CvUnitAI::AI_assaultSeaMove - Fixed bug where unit type was used when unit AI type was intended

22) CvUnit::canMoveInto - Capturing an undefended city is now considered an attack action, like capturing a worker. Mainly affects paratroopers, who now cannot capture undefended cities right after paradrop. Previously, paratroopers could capture undefended cities but not cities with only a worder or ship in them.

23) CvTeam::shareCounters - Fixed bug in permanent alliances when No Tech Brokering is turned on, where a civ would often become unable to trade a tech they had researched after entering a permanent alliance.

24) CvNetDoCommand::Execute - Fixed bug causing "Upgrade All" action to sometimes only do a fraction of the available units.

25) CvPlayerAI::AI_unitValue - Stealth boats do not make good escorts since they often don't defend, so AI is now very unlikely to use them as escorts for transports.

26) CIV4UnitInfos.xml - Removed UNITAI_ESCORT_SEA from Stealth Destroyer (stealth doesn't defend first, so not a good escort). Set iPower weighting for Missile Cruiser to much more appropriate 42 from 14 (iPower ratings for boats were increased by Firaxis a while back, but they missed this one).

27) CvCityAI::AI_yieldValue - Fixed issue causing city governor and AI to heavily weight food when building gold or any other form of commerce. Produced unexpected and poor results for human player, did not help AI either.

28) CvCity::setCultureLevel - Removed behavior where a city building culture would cancel order when reaching next level. Completely unnecessary for AI, human player is unlikely to be expecting this. Also appears to cause a bug with extra overflow production.

29) CIV4UnitClassInfos.xml - Fixed description entry for ship of the line (thanks ripple01)

30) CIV4ArtDefines_Unit.xml - Fixed many discrepancies in TrainSound between unique and non-unique units (thanks ripple01)

31) CvRandomEventInterface.py - Fixed function name from getHelpThGoths1 to getHelpTheGoths1 (thanks Chrill)

32) CvMapGeneratorUtil.py - Fixed function getLatitudeAtPlot in both FeatureGenerator and TerrainGenerator so that it properly returns 1.0 for both north and south poles and correctly locates equator (thanks Temudjin)

33) CvPlot::getLatitude - Fixed so that it properly returns highest latitude value for both north and south poles and correctly locates equator, improved integer rounding errors which caused slight skew in terrain types between northern and southern hemisphere (thanks Temudjin)

 

[PieceOfMind]

27) CvCityAI::AI_yieldValue - Fixed issue causing city governor and AI to heavily weight food when building gold or any other form of commerce. Produced unexpected and poor results for human player, did not help AI either.

TMIT will be pleased.

On the whole, great work jdog5000!
I'll be merging this into any mods I have soon.

 

[GravityWave]

Firstly, thanks for the patch!

The only small quibble is the "removed behavior where a city building culture would cancel order when reaching next level." I personally use this a lot, usually after capturing a city (I queue build culture followed by culture buildings etc.), but also sometimes for cities bordering other civs. Maybe it's just me who does this(?), but I prefer the old behaviour (I know I'll miss a border pop having to rely on the event log, and having to manually switch production on all the cities I capture will be a pain). Perhaps I'm just being lazy or have bad strategy..., but otherwise great work.

 

[Roland Johansen]

Great job jdog.

I was wondering if BTS 3.19 had copied the fix to the starting area enhancement/equaliser algorithm that was present in unofficial patches 0.21 and 0.19.1 of BTS 3.17. Without this fix to the starting area enhancement, the algorithm would add forest to the starting area and then tried to add food resources and such to the starting area. Because of the already present forests, the food resources couldn't be added anymore. The unofficial patch changed something in this algorithm so that there would still be room for the food resources that were supposed to be added to equalise the starting areas.

 

[ruff_hi]

The only small quibble is the "removed behavior where a city building culture would cancel order when reaching next level." I personally use this a lot, usually after capturing a city (I queue build culture followed by culture buildings etc.), but also sometimes for cities bordering other civs. Maybe it's just me who does this(?), but I prefer the old behaviour (I know I'll miss a border pop having to rely on the event log, and having to manually switch production on all the cities I capture will be a pain). Perhaps I'm just being lazy or have bad strategy..., but otherwise great work.

I use this too - a valuable addition that stops you building culture for nothing (ie after first border pop).

 

[jdog5000]

I use this too - a valuable addition that stops you building culture for nothing (ie after first border pop).

Alright, I'll see if I can find a way to fix the extra production overflow you've been getting by doing this ... didn't know you'd been cheating, did you?

That's okay, the AIs been cheating too (even though it doesn't need this feature at all).

 

[GooglyBoogly]

1st post needs to include a copy of the changes noted in the readme.

 

[jdog5000]

Great job jdog.

I was wondering if BTS 3.19 had copied the fix to the starting area enhancement/equaliser algorithm that was present in unofficial patches 0.21 and 0.19.1 of BTS 3.17. Without this fix to the starting area enhancement, the algorithm would add forest to the starting area and then tried to add food resources and such to the starting area. Because of the already present forests, the food resources couldn't be added anymore. The unofficial patch changed something in this algorithm so that there would still be room for the food resources that were supposed to be added to equalise the starting areas.

Yes, the starting location changes came over to 3.19.

 

[EmperorFool]

3.19 had nearly every change from UP 0.21. Unfortunately I didn't keep a log of the ones that didn't make it as I looked them over.

 

[Roland Johansen]

Yes, the starting location changes came over to 3.19.

Thanks. One of the changes mentioned in the 3.19 change log looked as if it could be about the starting changes but it only mentioned sea-starts so I wasn't sure.

3.19 had nearly every change from UP 0.21. Unfortunately I didn't keep a log of the ones that didn't make it as I looked them over.

I was just checking for this small change as it wasn't clearly mentioned in the 3.19 change log. The problem with nearly every change is in the crucial word nearly. It causes you guys extra work to get things back to the UP standard in various mods. With the new UP things will hopefully become standardised again among various mods.

 

[BigBubba]

Hey, I am a noob with a question. I want to play a mod that requires patch 3.19. I cant downlaod the patch b/c I have the digital version. Will this unofficial patch allow me to play the mod?

Also, how do I install this up properly?

 

[jdog5000]

Hey, I am a noob with a question. I want to play a mod that requires patch 3.19. I cant downlaod the patch b/c I have the digital version. Will this unofficial patch allow me to play the mod?

Also, how do I install this up properly?

No, sorry. This mod requires 3.19 to be installed already, then makes a few tweaks and fixes on 3.19.

 

[Breunor]

Thanks for the updates - is there any way we can get installation instructions? Sorry if I missed them.

Best wishes,

Breunor

 

[phungus420]

In this thread http://forums.civfanatics.com/showthread.php?t=328325 The_J asks for help in debugging the Mars Now mod and I told him to build a a debug dll because it has been invalueble to me for degugging and in my response I told him the degug dll has been very good at directing me toward issues. But I realized there is a cause of critical crashes that gives no such information. If you screw up and leave a comma in the button path when there is no atlas or leave the comma out if there is an atlas you just get a crash with no assert. Would it be possible to add in a failed assert message for bad button paths? I realize this would only help modders but it seems like something that should throw an assert as it causes a critical bug. Anyway great job as always jdog, course I get all the benifits from the UP by using RevDCM

 

[EmperorFool]

I would bet that's handled entirely in the EXE.