1. We have added the ability to collapse/expand forum categories and widgets on forum home.
    Dismiss Notice
  2. All Civ avatars are brought back and available for selection in the Avatar Gallery! There are 945 avatars total.
    Dismiss Notice
  3. To make the site more secure, we have installed SSL certificates and enabled HTTPS for both the main site and forums.
    Dismiss Notice
  4. Civ6 is released! Order now! (Amazon US | Amazon UK | Amazon CA | Amazon DE | Amazon FR)
    Dismiss Notice
  5. Dismiss Notice
  6. Forum account upgrades are available for ad-free browsing.
    Dismiss Notice

PerfectMongoose (PW3 Civ4 Port)

Discussion in 'Civ4 - Map Scripts' started by LunarMongoose, Dec 14, 2010.

  1. AIAndy

    AIAndy Chieftain

    Joined:
    Jun 8, 2011
    Messages:
    3,334
    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.
     
  2. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    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 :lol: ) . 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...
     
  3. AIAndy

    AIAndy Chieftain

    Joined:
    Jun 8, 2011
    Messages:
    3,334
    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()
     
  4. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    unfortunately I have no idea what this means :blush:
     
  5. AIAndy

    AIAndy Chieftain

    Joined:
    Jun 8, 2011
    Messages:
    3,334
    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.
     
  6. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    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 )
     
  7. AIAndy

    AIAndy Chieftain

    Joined:
    Jun 8, 2011
    Messages:
    3,334
    That is not the call but the definition of the function. It calls a method of a class that is defined further up.

    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.

    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.
     
  8. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    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 :lol:
     

    Attached Files:

  9. LunarMongoose

    LunarMongoose Chieftain

    Joined:
    Jan 29, 2006
    Messages:
    720
    Location:
    Boston, MA, USA
    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. :)
     
  10. AIAndy

    AIAndy Chieftain

    Joined:
    Jun 8, 2011
    Messages:
    3,334
    The error message says that there is still some code in assignStartingPlots that tries to call SetStartingPlots that I assume you removed.
     
  11. LunarMongoose

    LunarMongoose Chieftain

    Joined:
    Jan 29, 2006
    Messages:
    720
    Location:
    Boston, MA, USA
    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.
     
  12. AIAndy

    AIAndy Chieftain

    Joined:
    Jun 8, 2011
    Messages:
    3,334
    I think you can also call
    CyPythonMgr().allowDefaultImpl()
    to make the DLL run the default code.
     
  13. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    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...
     
  14. AIAndy

    AIAndy Chieftain

    Joined:
    Jun 8, 2011
    Messages:
    3,334
    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).
     
  15. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    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.
     
  16. LunarMongoose

    LunarMongoose Chieftain

    Joined:
    Jan 29, 2006
    Messages:
    720
    Location:
    Boston, MA, USA
    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.
     
  17. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    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 :D
     
  18. modifieda4

    modifieda4 Chief Time Waster

    Joined:
    Sep 3, 2006
    Messages:
    384
    Location:
    Gold Coast
    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:
    Code:
    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?
     
  19. LunarMongoose

    LunarMongoose Chieftain

    Joined:
    Jan 29, 2006
    Messages:
    720
    Location:
    Boston, MA, USA
    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".

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

    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.
     
  20. [to_xp]Gekko

    [to_xp]Gekko WM junkie

    Joined:
    Dec 16, 2005
    Messages:
    7,790
    Location:
    Seyda Neen, Vvardenfell
    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 :lol:

    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 :D


    Thanks in advance :)
     

    Attached Files:

Share This Page