[MAPSCRIPT] PerfectMongoose (PW3 Civ4 Port)

[AIAndy]

Originally Posted by [to_xp]Gekko

I'm getting errors when trying to use this with Master of Mana

hopefully this can be fixed easily cuz I'd love to use the script with MoM

The first one is likely caused by MoM differing from what the script uses to determine good starting positions. So it likely does not find any good ones and then tries to place some bonuses to spice it up which might not work properly according to the second error.

In general I think the map script will need some adapations to generate maps for MoM.

[[to_xp]Gekko]

ah, that's really sad. MoM recently got naval AI and I wanted to play a map with continents ( Cephalo-based maps are all I play nowadays ) . I've also noticed perfectworld2 has the same issue.

ErebusContinent ( based on FaireWeather for civ4 colonization ) works fine, but it's a pangea-style script and I wanted something different...

[AIAndy]

Originally Posted by [to_xp]Gekko

ah, that's really sad. MoM recently got naval AI and I wanted to play a map with continents ( Cephalo-based maps are all I play nowadays ) . I've also noticed perfectworld2 has the same issue.

ErebusContinent ( based on FaireWeather for civ4 colonization ) works fine, but it's a pangea-style script and I wanted something different...

What you can do as an easy workaround is to use the standard bonus placement and starting point finding instead of the one the PW map scripts implement (or check what the Erebus scripts use).

The entry functions are those:
def addBonuses()
def assignStartingPlots()

[[to_xp]Gekko]

Originally Posted by AIAndy

The entry functions are those:
def addBonuses()
def assignStartingPlots()

unfortunately I have no idea what this means

[AIAndy]

Originally Posted by [to_xp]Gekko

unfortunately I have no idea what this means

The easiest way is to delete those two functions I mentioned which should make the DLL use its default ones instead.

Otherwise you can look what the Erebus scripts call in those functions.

A short explanation:
To generate a map the DLL calls a sequence of functions of the chosen map script. The map script is supposed to do a certain job in each of them.
Like in addBonuses the bonus placement should be done.
Or in assignStartingPlots starting plots need to be found and set for each player.
Since several of the problems and specifics of MoM are in those, it should be better to use the default ones instead of the ones the PW scripts provide.

[[to_xp]Gekko]

weird, in perfectmongoose 3.2 def assignStartingPlots(): is called only once at the very end and all it says is :

def assignStartingPlots():
sf.SetStartingPlots()

which seems like it uses default civ4 starting plot selection... but I'm pretty sure that's not the case.

otoh def addBonuses(): gets called twice, once in class BonusPlacer where there's some specific code ( before def AddBonusType ) and once at the very end where all it says is

def addBonuses():
bp.AddBonuses()


all I know is that the only tweak made in MoM to a mapscript so far to make it fully compatible ( i.e. the script still worked even without it ) has been in ErebusContinent to add

if plot.getWilderness() < bonusInfo.getMinWilderness():
return False
if plot.getWilderness() > bonusInfo.getMaxWilderness():
return False

at the end of def PlotCanHaveBonus , which I think makes it so that powerful strategic resources like mithril require a high wilderness level ( which is dependent on distance from starting plots )

[AIAndy]

Originally Posted by [to_xp]Gekko

weird, in perfectmongoose 3.2 def assignStartingPlots(): is called only once at the very end and all it says is :

def assignStartingPlots():
sf.SetStartingPlots()

which seems like it uses default civ4 starting plot selection... but I'm pretty sure that's not the case.

That is not the call but the definition of the function. It calls a method of a class that is defined further up.

otoh def addBonuses(): gets called twice, once in class BonusPlacer where there's some specific code ( before def AddBonusType ) and once at the very end where all it says is

def addBonuses():
bp.AddBonuses()

That is the same as for the starting plot finding except that the name of the method is very similar to the name of the entry function.

all I know is that the only tweak made in MoM to a mapscript so far to make it fully compatible ( i.e. the script still worked even without it ) has been in ErebusContinent to add

if plot.getWilderness() < bonusInfo.getMinWilderness():
return False
if plot.getWilderness() > bonusInfo.getMaxWilderness():
return False

at the end of def PlotCanHaveBonus , which I think makes it so that powerful strategic resources like mithril require a high wilderness level ( which is dependent on distance from starting plots )

The ErebusContinent map script has been made with FFH2 in mind from the very start so it is easy to adapt to MoM while on the other hand the assumptions behind the code in the PW scripts are for vanilla Civ4.

[[to_xp]Gekko]

well removing the whole setstarting plots section results in the error changing to this, and the starting plots indeed got better ( no more people in snow ) so I think it's successfully using the default civ4 code for that now. I'm gonna see if I can just plug in the code from erebuscontinent now

[LunarMongoose]

Yep, Andy is right about all of this. And it definitely would be the same problem with PerfectWorld 2, as you saw, b/c the custom starting placement code has been left essentially unchanged since then.

@AIAndy: Btw, I DID try hooking up the DLL's plot-value-calculator-for-starting-position-purposes function that has all the BetterAI code, and replacing the relevant part of the PW code with that. Which was actually a bit of work to do, heh. It didn't really reduce the mapscript generation times by any significant amount, and it seemed to yield wonkier / worse final starting positions, so I ultimately didn't use it. But I did try it, and I saved the alternate code in case it's worth looking at again in the future.

@modifieda4: It is true that the PW2 climate system generates fewer contiguous deserts, but they are larger, and definitely result in the same total number of Desert tiles on the map, as I said. PW3 has more of them in smaller patches, but this is actually more realistic, as it uses a much more advanced and accurate climate simulation. This is exactly why I wanted to leave both PW2 options available in the mapscript though; I knew some folks might legitimately still prefer the old generators.

[AIAndy]

Originally Posted by [to_xp]Gekko

well removing the whole setstarting plots section results in the error changing to this, and the starting plots indeed got better ( no more people in snow ) so I think it's successfully using the default civ4 code for that now. I'm gonna see if I can just plug in the code from erebuscontinent now

The error message says that there is still some code in assignStartingPlots that tries to call SetStartingPlots that I assume you removed.

[LunarMongoose]

Originally Posted by AIAndy

The error message says that there is still some code in assignStartingPlots that tries to call SetStartingPlots that I assume you removed.

I think he actually has to delete assignStartingPlots() entirely, or else the DLL will think the mapscript is gonna take over so it won't run its own code. It sounds like he deleted the SetStartingPlots() function instead.

[AIAndy]

Originally Posted by LunarMongoose

I think he actually has to delete assignStartingPlots() entirely, or else the DLL will think the mapscript is gonna take over so it won't run its own code. It sounds like he deleted the SetStartingPlots() function instead.

I think you can also call
CyPythonMgr().allowDefaultImpl()
to make the DLL run the default code.

[[to_xp]Gekko]

that's what I did yep, I'm trying again deleting def assignStartingPlots() instead, it's just two lines of code right?

I'll also have to add

if plot.getWilderness() < bonusInfo.getMinWilderness():
return False
if plot.getWilderness() > bonusInfo.getMaxWilderness():
return False

to the end of def plotcanhavebonus as was made by Sephi for ErebusContinent, however I'm not sure it's correct since plotcanhavebonus is a bit different in PW3...

[AIAndy]

If both bonus placement and starting plot finding use the default now you likely won't need to add those lines (unless the default code in the DLL does not care for wilderness).

[[to_xp]Gekko]

I didn't delete def addBonuses() though, since it's not causing errors after I removed def assignStartingPlots()

Map seems to be working fine now, at least it's not throwing python exceptions on startup anymore. I do notice bad starting locations though, like tons of jungle and it seems to ignore Start on Old World.

[LunarMongoose]

Originally Posted by [to_xp]Gekko

I do notice bad starting locations though, like tons of jungle and it seems to ignore Start on Old World.

The Jungle thing could be due to any number of complicated reasons, but your other point is correct: Old World vs New World is a concept specific to the PerfectWorld series of mapscripts. As such, only the PW starting location Python code knows how to handle it. It's just not something that exists in the DLL or any other mapscripts (typically).

In disabling the PW code, you also bypassed Old World support. Sorry, heh. An ideal solution would require rewriting the PW Python to support specific mods, which is kinda the responsibility of the mod owners. I have my hands full enough as it is working on my own mod, heh.

[[to_xp]Gekko]

I've noticed I don't need to remove assignstartingplots if I just remove the normalization code that adds bonuses to players' starts. the issue lies in that as AIAndy pointed out, I'm gonna need to find a way to set it up so that it evaluates MoM bonuses correctly..

I'll be looking forward to 3.2.1 btw

[modifieda4]

Originally Posted by LunarMongoose

@modifieda4: It is true that the PW2 climate system generates fewer contiguous deserts, but they are larger, and definitely result in the same total number of Desert tiles on the map, as I said. PW3 has more of them in smaller patches, but this is actually more realistic, as it uses a much more advanced and accurate climate simulation. This is exactly why I wanted to leave both PW2 options available in the mapscript though; I knew some folks might legitimately still prefer the old generators.

more on deserts...

a simple google search shows "desert" to be 30% of the land ("real desert" to be 14%). the 30% numbers include frozen areas, mountains, and arid areas.

i started looking into the code and this seems strange:

self.DesertPercent = 0.18 / (1.0 - self.TundraPercent)

the comment says real desert percent is 18% yet if you do the calculation DesertPercent comes out to be 27%. while this jives with my google statement above, i think this is a coincidence. Does the code uses the 27% to place actual terrain_desert features?

[LunarMongoose]

Originally Posted by modifieda4

a simple google search shows "desert" to be 30% of the land ("real desert" to be 14%). the 30% numbers include frozen areas, mountains, and arid areas.

I read a LOT of Google search results on this, and some other things. There were a lot of different claimed values, but the consensus I personally came to was 20% for "real desert".

Originally Posted by modifieda4

the comment says real desert percent is 18% yet if you do the calculation DesertPercent comes out to be 27%. while this jives with my google statement above, i think this is a coincidence. Does the code uses the 27% to place actual terrain_desert features?

Sigh...Why doesn't anyone ever just trust me by default?

It may seem suspicious, but the code is correct for 18%, as the comment says. It calculates Snow and Tundra first, based on temperature. They come out of the total 100% of landmass tiles. The remaining 65% of the total, the "warm tiles", are then split into Desert, Plains and Grass based on rainfall. 27.7% of 65% is 18%.

And as I said, there's a counter to verify the results at the end if you want to turn it on. Desert fluctuates between approximately 17.5 and 18.5% in practice just b/c of how threshold values work.

[[to_xp]Gekko]

sorry for the OT, but can any of you kind people help me with this? It's cephalo's code so it should be easy as pie to read for you guys

it's a script that simulates a global climate like PW, but based on FaireWeather instead.

if you search for "duel" you'll get to the section where minimum starting distances based on mapsize are listed, from left to right high-medium-low cohesion.

since some civs love close neighbours they subtract 1 by that number ( a couple of them subtract 2 ) , and starting AI settlers can move away from their starting tile ( how far depends on mapsize, 3 tiles on large/huge) , I've set them to the bare minimum to make sure that you never get settlers trying to settle closer than the minimum "3 tiles separation between cities" ( it's 3 instead of BTS's 2 ) .

However, I'm noticing that with low cohesion, high sealevel maps it's overriding those values and using the default ( lower ) ones in order to try and settle as many people on the largest continent , which means if all continents are small you can get civs starting way closer than intended on the same small continent.

Would there be a way to avoid this happening? the only brute force method that comes to mind here is giving every civ a negative modifier to minimum starting distance so that they start further away even when this issue happens and they use the default values. of course, I'd like to avoid axing the script like that for something that only happens in 1 out of 9 cohesion-sealevel combos...

hope I made myself clear since I'm no coding wiz


Thanks in advance