View Full Version : PerfectMongoose (PW3 Civ4 Port)


LunarMongoose
Dec 14, 2010, 04:25 AM
PerfectMongoose 3.2


DESCRIPTION

Major Update of LM's official Civ4 Port of Civ5's PerfectWorld3_v2, using PerfectWorld_2.06f as base.

The initial version of this project took a week of 24/7, every-waking-minute work to complete. The 3.1 update took 2 more weeks, and this 3.2 update has taken a whole month. It is posted with permission from the original author, Cephalo.

This is a definitive release: I am very confident everything is finally fixed and working properly, and all the improvements I had been planning to make are now implemented.


NOTICE

If you use this in a mod you need to give me credit... in addition to Cephalo of course. :) It took way too much time and energy, with a relatively-high level of difficulty programming-wise, to not insist on that, and to not be allowed to shamelessly insert my name into the project name. :p Besides, Sevo put his name in the Sevopedia and everyone worships it (including me), so I don't feel too bad lol.


FULL NOTES

Version 3.2

* Added AIAndy's square grid evaluation, float division and geostrophic fixes, his bonus placement and starting location speed enhancements, and his PythonRandom multiplayer support.
* Added a game option to continue using the old hex-grid-based Perlin Noise code if desired, since the previous PW3 landmass shapes are different and still fully viable.
* Merged in the remaining PW 2.0.8 functionality with a game option to select the PW2 landmass generator if desired.
* Changed the rainfall thresholds from absolute values to global percents like the temperature thresholds, set them to ignore Peaks, and merged the climate system constants back together.
* Enforced the current map's x and y wrap settings in a number of places in the code, which fixes some bugs with -1 data values near the edges and should get rivers wrapping only when they're supposed to.
* Fixed natural harbor bug, and added shape randomization to natural harbor creation on diagonals.
* Changed sea ice to vary with map size instead of always being 4 tiles thick, and to require water temperature to be near freezing so the bands have some limited shape to them.
* Switched to PW2's oversized internal grid when using the PW3 LMG with the PW2 climate system so the latter works correctly.
* Changed the +/- 10% tolerances on elevation, rainfall and sea level thresholds to +/- 2%.
* Removed MeteorCompensationFactor since the system does indeed work best without it. (My apologies Ceph; you were right!)
* Made a number of additional code improvements.

Version 3.1

* Fuyu's 2.0.6f bonus placement, starting location enhancement, minimum hill enforcement and bad feature removal code were added, along with his control variables.
* Reverted some more settings for use with vanilla that were still set for my mod.
* Added allowance in getPlotPotentialValue() for clearing features with negative food (ie Jungles), since it already accounted for cleared features with tile improvements that require it (only useful in mods).
* Added StartEra checks to verify the tech requirements are met for clearing features in both cases.
* Agreeing with Cephalo, I left the starting location production resource food override threshold at half the city plots being workable, rather than two-thirds.
* Changed the TechCityTrade requirement for resource valuation and placement to TechReveal since the former makes no sense: if a bonus is visible it enhances the tile, and if it isn't visible it doesn't enhance the tile, regardless of whether it can be harvested or traded with other cities.
* Added BonusMaxGroupSize option of -1 for setting Fuyu's clump limit based on WorldSize, clarified the description of what the 0 option there actually does, and fixed the random bounds.
* Added a minimum value to the StartEra checks to include all Classical resources, improvements and clearing abilities in the plot valuations.
* Changed allowWonderBonusChance to allow any strategic resource (not just Stone or Marble), and the city sweetener to allow non-strategic resources - both up through Classical (or later).
* Adjusted lake and river values again, and added separate controls for them for the two climate systems.
* Increased Desert slightly and Plains considerably in the PW2 system.
* Synchronized the PM3/PW2 code substantially more to make future updates easier.
* Scaled temperature from normal linearly down to zero in the top and bottom thirds of the map in the PW3 climate system, to get Tundra and Snow in the higher and lower latitudes as there should be.
* Lowered Tundra/Snow temperatures to compensate.
* Increased PW3 Grassland level slightly.

Version 3.0

* The PW2 HeightMap and ClimateMap have been replaced with their PW3 counterparts.
* PW2's high-altitude randomization was removed since it was causing 80-100% of land tiles to be Peaks regardless of settings.
* PW2's SmallMaps were removed since the new Perlin Noise landmass generator does not require an oversized map to avoid looking bad.
* The YToXRatio hex grid scale factor has been removed.
* PW2 control variables that are now unused have been removed, and the necessary PW3 ones have been added. Values have also been adjusted as needed or desired.
* mc.MeteorCompensationFactor was added to try and help preserve total land percent when using Break Pangaeas. It is currently set to 1.1 which just adds a little style to my version... crank it up to around 2.0 if you want full compensation (though the result may not look as good).
* The Sea Level menu option has been enabled, and mc.SeaLevelFactor was added to support it.
* The Use menu option has been added, and a slightly-modified version of the PW2 ClimateMap was added back in, to support having a choice between the PW2 and PW3 climate systems.
* PW3's north and south attenuation were removed.
* PW2's code that forced Snow to be at higher elevation than Tundra, Tundra to be higher than everything else, and Desert to not be, well, something... was removed.
* Plains in the PW3 ClimateMap were set to have a null rainfall window and a relatively large temperature window, so that they form exclusively as a result of cold deserts; this helps create Great Plains type areas. (You also don't seem to get enough Grassland unless you max it out by doing things this way.)
* RiverThreshold's dependence on PlainsPercent (via PlainsThreshold) was removed so that its value can be set reliably.


DOWNLOAD

PerfectMongoose 3.2 (http://forums.civfanatics.com/downloads.php?do=file&id=16192)


SCREENSHOTS

These were taken while running MongooseMod so it's not vanilla terrain graphics, sorry.

EARTH!!! Well, minus Africa lol. (http://homepage.mac.com/klwelch/Civ4/Components/PerfectMongoose/LM_PM_SS0.jpg) - It coughed this up in an early test generation. Look at the minimap. :)

Perlin Noise + Pangaea Breaker (http://homepage.mac.com/klwelch/Civ4/Components/PerfectMongoose/LM_PM_SS1.jpg) - Just a random cool-looking map.

The Great Plains... have arrived. (http://homepage.mac.com/klwelch/Civ4/Components/PerfectMongoose/LM_PM_SS2.jpg) - This happens fairly often with my settings.

The Great Plains... have returned. (http://homepage.mac.com/klwelch/Civ4/Components/PerfectMongoose/LM_PM_SS3.jpg) - Most of these screenshots had the Pangaea Breaker on just since it's the default menu option; I'll post some with it off when I get a chance.

cephalo
Dec 14, 2010, 11:49 AM
Those coastlines look great! One comment I have is that you should really fill in all lakes below a certain size before running your rivers. It looks bad to have a major river flowing into a tiny lake. The AreaMap class is good to use for that. Let me know if you have any questions regarding its use.

The_J
Dec 14, 2010, 11:59 AM
Those coastlines look great!

Very natural imho :yup:.

LunarMongoose
Dec 14, 2010, 06:52 PM
Those coastlines look great! One comment I have is that you should really fill in all lakes below a certain size before running your rivers. It looks bad to have a major river flowing into a tiny lake. The AreaMap class is good to use for that. Let me know if you have any questions regarding its use.

I still do that. The minSize for the fill-in procedure got reduced from 100 to 50 b/c 50 was the new default value in PW3... I also changed the lake generator's default values a fair bit (reducing minimum elevation, increasing drainage->size factor a little and turning off siltification completely) since I thought lakes were way too too small and infrequent in general before and had never really thought to adjust them til now.

I dunno, I think they look great the way they are, and you had rivers flowing in or out of size 2-3 lakes all the time in PW2 before just b/c ALL lakes were size 2-3 almost heh... But yeah I can try changing the settings some more in a future version. Those are all user-adjustable for now though if people want to look at the values in PW 2.06 and revert them. :)

cephalo
Dec 14, 2010, 10:02 PM
I could have sworn I got rid of that in PW2, but maybe I'm mis-remembering. I remember eliminating small lakes entirely, and then adding them back in a way that didn't interfere with the river system. I mentioned it because several of your screenshots have a long river leading into a small lake. No big deal if you think that's ok, it was something that really bugged me from PW1 so I worked extra hard to get rid of it.

OnmyojiOmn
Dec 15, 2010, 06:05 PM
Thanks for this, but I'm disappointed that you didn't base it on PerfectWorld2f. I would never play 2.06.

LunarMongoose
Dec 15, 2010, 07:23 PM
Edit - Oh wait, you mean Fuyu's version. Well I can probably switch it over to that pretty easily actually, but I'll have to look and see what it does differently first to see if I want to. Sorry, I did download 2f a while ago but I kinda forgot about it heh.

Oh, and you're probably right Ceph; I was only paying attention to lake size and frequency and not to rivers flowing into them or not. I definitely remember getting only a few small lakes with your settings, but that doesn't mean they had rivers... dunno why I jumped to that conclusion heh. Sorry. I probably messed it up switching to PW3's minOceanSize value of 50 for the lake filler.

LunarMongoose
Dec 15, 2010, 07:46 PM
Okay, just took a quick look at 2f vs 2.06 in WinMerge, and it's just a few changes to resource placement and player starting location modification (plus a couple control variables for those things). None of which has anything to do with the PW3 components or my own changes or additions, so it'd take about 5 minutes to convert my files over to being based on 2f, heh.

Let me read up on exactly what 2f does and make sure I agree with it first, and I probably need to mess with the river/lake values some more, but I may post an update fairly soon for these two things.

OnmyojiOmn
Dec 15, 2010, 09:51 PM
My first game with PerfectMongoose:

http://img406.imageshack.us/img406/2164/fffffffffffffffffffffffaf.jpg

Edit - my second, game lawls:

http://img820.imageshack.us/img820/4581/fffffffffffffffffffffffx.jpg

LunarMongoose
Dec 15, 2010, 11:02 PM
Well I tested it heavily and tweaked the control variables for two solid days pretty much... Grass, Plains and Desert should all be roughly equal in quantity, in general, on most maps (though Desert gets killed by really small map sizes which is unavoidable; mountain ranges dictate it spawning). You can also try the PW2 Climate menu option which will give you exactly what you're used to on PW2f, terrain-type wise.

But yeah I was specifically shooting for Great Plains areas with this new PW3 climate system, since someone in the PW2 thread was complaining he wanted to see those, and they are kinda cool. :)

OnmyojiOmn
Dec 15, 2010, 11:43 PM
I'm sorry if I seem overly critical, because I am happy to see someone update PW2. I'm glad you worked on the plains, too. You never got many large plains and the donut desert gots old.

The problem with PW2 was always that the starting locations were completely broken, and that's why PerfectWorld2f is so much better.

cephalo
Dec 16, 2010, 09:46 AM
One problem I had in Civ4 with plains is that for BtS it is plains tiles can't feed themselves, making them far, far less valueable. You can't farm brown because if you build a farm on it then it can only feed itself, making it basically useless. Somebody starting on all plains needs a major food boost, and adding bonuses is only barely adequate for that. A town on green is basically more powerful than any bonus. That's why I had to keep plains under tight control. Deserts at least have floodplains so you can work the surrounding hills, with plains you can't even do that.

By having fewer plains, I could somewhat limit those "all plains" starts that everyone hates.

OnmyojiOmn
Dec 16, 2010, 11:07 AM
One problem I had in Civ4 with plains is that for BtS it is plains tiles can't feed themselves, making them far, far less valueable. You can't farm brown because if you build a farm on it then it can only feed itself, making it basically useless. Somebody starting on all plains needs a major food boost, and adding bonuses is only barely adequate for that. A town on green is basically more powerful than any bonus. That's why I had to keep plains under tight control. Deserts at least have floodplains so you can work the surrounding hills, with plains you can't even do that.

By having fewer plains, I could somewhat limit those "all plains" starts that everyone hates.
The solution is to simply allow the floodplains feature on plains. In real life, floodplains exist in places all over the world that are certainly not what you'd call deserts, including the Mississippi river! To balance this, have the script only place floodplains in fewer, more suitable desert areas rather than every single desert in the world.

Regarding starting locations, the issue in PW2 is that when the location is improved for the starting city, food resources are considered after other resources are placed. Reverse this, and even a plains location will be reasonably good. The surrounding area may not be, but that's true of other starting situations, like tundra and jungle.

cephalo
Dec 16, 2010, 01:44 PM
Regarding starting locations, the issue in PW2 is that when the location is improved for the starting city, food resources are considered after other resources are placed. Reverse this, and even a plains location will be reasonably good. The surrounding area may not be, but that's true of other starting situations, like tundra and jungle.

That shouldn't be true in the recent versions of PW2. I can't remember exactly how I did it now since it was a long time ago, but I'm pretty sure I always placed food any time there was not enough food to support some other resource.

That said, there were also some continent rules that could prevent things like wheat being placed on plains, and since wheat is the only food resource that can be placed there, you could have a situation where the rules prevented food bonuses because they were present on different continents.

OnmyojiOmn
Dec 16, 2010, 02:42 PM
That shouldn't be true in the recent versions of PW2. I can't remember exactly how I did it now since it was a long time ago, but I'm pretty sure I always placed food any time there was not enough food to support some other resource.

That said, there were also some continent rules that could prevent things like wheat being placed on plains, and since wheat is the only food resource that can be placed there, you could have a situation where the rules prevented food bonuses because they were present on different continents.
I had it wrong. When PW2 is sweetening starting spots it places resources in the order of production, commerce, and then food, but the first two passes will place food resources instead if there isn't enough food to work half of the city tiles. In PW2f it will switch to food resources if there isn't enough food to work 2/3 of the tiles, and then it does a fourth pass for more production resources.

Also, there's a 5% chance per resource placed in the starting spot to ignore terrain restrictions.

LunarMongoose
Dec 26, 2010, 07:41 PM
Version 3.1 posted, which is a fairly major update. Please see above for details.

@Cephalo: If you load up plain ordinary PW 2.06 in vanilla BTS and run a couple of test games, you will see that there are still plenty of size 2 and 3 lakes that have rivers, both short and long, coming out of them, so this wasn't something I broke in my versions here heh.

@OnmyojiOmn: I have actually gone ahead and added Flood Plains on flat Plains tiles with rivers to my mod since I liked your idea so much, but it requires either a new Feature entry in the XML, or else a modification in the SDK of how yields are calculated... unless you're willing to let the tiles have a value of 4 food 1 hammer 1 commerce which is a bit much imo. So I am not including it in this vanilla version of PerfectMongoose since it is beyond the scope of a mapscript alone.

Jabarto
Dec 27, 2010, 06:58 PM
I'm getting a "page not found" error when I try to download this.

LunarMongoose
Dec 27, 2010, 07:22 PM
I'm getting a "page not found" error when I try to download this.

Gah, sorry. It's fixed now. Thanks for speaking up. :) Forgot to update the link string in the CF entry for the new version number in the filename. I'd successfully avoided making that mistake a number of times with a number of files up til now, but I guess it had to happen sooner or later. In my defense I was/am super busy and distracted finishing my big mod update hehe.

I will post some neat and more current screenshots too when I get a chance here.

OnmyojiOmn
Dec 28, 2010, 02:16 AM
Thank you so much for the update!

Regarding flood plains, you could check to see whether a modded feature with a certain name (FEATURE_FLOODPLAINS_PLAINS or whatever) is present in the game, and use that.

LunarMongoose
Jan 14, 2011, 01:25 AM
Regarding flood plains, you could check to see whether a modded feature with a certain name (FEATURE_FLOODPLAINS_PLAINS or whatever) is present in the game, and use that.

I'm not gonna release a whole update just for this, but I'll be happy to show you how to add it if you want, since it's pretty simple. :)

In PerfectMongoose_v310.py, search for "def addFeatures" and scroll down slightly, or just go to line 5036. Then replace:

if cm.RainfallMap.data[i] > tm.plainsThreshold * mc.TreeFactor and PRand.random() < mc.MaxTreeChance:#jungle

with:

if plot.isRiver() and tm.data2[i] == mc.PLAINS and tm.data1[i] == mc.LAND:
plot.setFeatureType(fPlainsFloodPlains, 0)
elif cm.RainfallMap.data[i] > tm.plainsThreshold * mc.TreeFactor and PRand.random() < mc.MaxTreeChance:#jungle

Finally, define your new feature type at the top of the function, probably inserted at line 5016 would be good. Something like:

fPlainsFloodPlains = gc.getInfoTypeForString("FEATURE_PLAINS_FLOOD_PLAINS")

The procedure is the same for PerfectWorld_v208.py, except "tm.data2" is "sm.terrainMap", and "tm.data1" is "sm.plotMap" (as you can see by looking around the addFeatures() function).

For the new feature itself, you'll want to just copy/paste a duplicate version of the existing Flood Plains entry in XML/Terrain/CvFeatureInfos.xml, then set the food/production/commerce stats to either 2/0/0, 1/0/0, or 2/-1/0.

Be advised that while I can't think of anything off the top of my head that would be affected in regular BTS, any events, animal FeatureNative settings, unit/promotion feature movement/combat effects, or custom DLL code that references specific FeatureTypes directly, that involve Flood Plains will not support the new Plains Flood Plains feature by default (which is part of why I didn't do it this way in my mod, heh).

OnmyojiOmn
Jan 14, 2011, 05:08 AM
Okay, thanks.

The starting location resources can still be pretty frustrating. I get whales a lot, which should never happen on ancient starts. I had one game where I started on a large continent and two civs each started on their own little island chains. Their starting warrior/scout was placed on the large continent, separated from the settler.

Just aesthetically speaking, large plains areas could have a check to make sure there's some kind of feature or resource placed per x number of contiguous plains tiles. I've had like a third of the world land area bunched up in one gargantuan plain that was nothing but empty plains terrain. Looks pretty weird.

Overall it's a great script and I don't see myself going back to PW2f any time soon.

LunarMongoose
Jan 14, 2011, 08:36 AM
The starting location resources can still be pretty frustrating. I get whales a lot, which should never happen on ancient starts.

In regular BTS, Whales have no TechCityTrade value, which is what all previous versions of PW used, and no TechReveal value either. There is therefore no reason Whales shouldn't be part of Ancient starts... or that they shouldn't have been part of them in previous PWs either. (PW has never checked how far out in the tech tree the ability to harvest a resource is.) Sorry if I'm not being much help with this heh. I don't have time to test it vs older versions relative to Whale sightings right now, but I just double-checked the code so I'm quite sure about that part...

I had one game where I started on a large continent and two civs each started on their own little island chains. Their starting warrior/scout was placed on the large continent, separated from the settler.

That's obviously odd, but I'm almost certain it's nothing I did directly. The starting location selection code should be line-for-line identical to PW2.06. It's probably just a result of the more interesting/diverse landforms generated, and not a problem I would expect to see on larger map sizes in any case. (It also matters a great deal whether you're using the Old World setting or not.)

Just aesthetically speaking, large plains areas could have a check to make sure there's some kind of feature or resource placed per x number of contiguous plains tiles. I've had like a third of the world land area bunched up in one gargantuan plain that was nothing but empty plains terrain. Looks pretty weird.

I've seen that effect as well, to some degree. Directly calculating the size of a contiguous block of a terrain type is certainly doable, but I'd have to write it myself since there's no existing function to do that. What you're describing is exactly how resources are placed as it is though. The problem has more to do with the vanilla resources' XML placement settings, so even if I did calculate it I wouldn't necessarily have any good options for what to place.

Luxury resources are designed to clump, and they are also restricted to only one landmass per type so they're bad examples. Strategics can be limited in total quantity and also tend to be revealed much later. If you just look at health resources which it tries to spread out evenly across the world, there are only 3 in regular BTS that can spawn on Plains: Cows, Sheep and Wheat. They're complicated and I haven't used them in a while so I don't remember the details atm, but there are some XML settings for each that are extremely relevant: iPlacementOrder, iConstAppearance, iMinAreaSize, iMinLatitude, iMaxLatitude, Rands, iPlayer, iTilesPer, iMinLandPercent, iUnique, iGroupRange, iGroupRand and bArea. I suspect some of these values on vanilla Cows/Sheep/Wheat, the fact that there are only 3 Plains health resources, and lack of advanced tech to reveal all the strategic resources, is the basic problem.

I have a lot of those values set differently in my mod, and I also have more resource types like Bison, so there tends to be stuff on the Great Plains it generates, but I haven't run any tests in a couple weeks now and I wasn't paying much attention to this issue to begin with, so I'm not sure how much better it actually is (if any).

SeekTruthFromFacts
Feb 09, 2011, 04:40 AM
Can this be used with Warlords, or is it BTS only?

remiller66
Feb 12, 2011, 01:21 PM
Every time I use PW2f (or a map script based on it, like this one) I end up with a world of nothing but grassland and rivers. I get no mountains or ocean.:confused: I do get resources scattered on the map. Now, PW2 map script gives me great maps. Any ideas what may be causing this for me? The only mods I use are BUG AI and Blue Marble.

LunarMongoose
Feb 12, 2011, 02:56 PM
Can this be used with Warlords?

I actually don't know, but it wouldn't surprise me if it didn't. This is not something that's even worth my time to bother testing, honestly. BTS costs so little it's practically free at this point, it was/is a great expansion, and most mods require it; I strongly recommend picking it up.

Every time I use PW2f (or a map script based on it, like this one) I end up with a world of nothing but grassland and rivers. I get no mountains or ocean.:confused: I do get resources scattered on the map. Now, PW2 map script gives me great maps. Any ideas what may be causing this for me? The only mods I use are BUG AI and Blue Marble.

I know for a fact PW2, PW2f, and my two scripts here all work correctly with a clean BTS installation. "Nothing but grassland, rivers and resources" is the standard failure mode of all map scripts, meaning whenever anything goes wrong in their code, that's almost always what you get. That's true of all maps, not just these.

PW2f's changes over PW2 are fairly minor code-wise though so just from memory I'm not sure why that'd be happening for you. I'm quite certain the maps themselves are all fine, so all I can suggest is the usual default suggestion... make sure your MyDocuments/CustomAssets folder is empty, and failing that, reinstall BTS. Though as I said above, I'm not sure if vanilla Civ4 or Warlords will work.

remiller66
Feb 12, 2011, 05:19 PM
Wow! Thanks LunarMongoose. Emptying the customassets folder did the trick. Your map script works great, now. Thanks, again!

OnmyojiOmn
Feb 13, 2011, 04:32 PM
Every time I use PW2f (or a map script based on it, like this one) I end up with a world of nothing but grassland and rivers. I get no mountains or ocean.:confused: I do get resources scattered on the map. Now, PW2 map script gives me great maps. Any ideas what may be causing this for me? The only mods I use are BUG AI and Blue Marble.

I play mods that install under the game folder, and I have this problem whenever I try to run a map script from My Games\BTS\PublicMaps. I have to install the script in the PrivateMaps folder for the mod. Not really a big deal.

Manfred Belheim
Mar 16, 2011, 11:21 AM
Is it possible to modify the script slightly to allow an extra choice for starting positions? Basically I'd like to add a "Random" choice as well as "Old World" and "Everywhere", that way I can't be sure if there's going to be a New World or not, just to add an extra bit of spice to the exploration.

Well I'm sure it IS possible, but can I be pointed in the right direction? I've found the part of the script where the option is, but I don't really know how to modify it to get this option.

LunarMongoose
Mar 16, 2011, 03:23 PM
Is it possible to modify the script slightly to allow an extra choice for starting positions? Basically I'd like to add a "Random" choice as well as "Old World" and "Everywhere", that way I can't be sure if there's going to be a New World or not, just to add an extra bit of spice to the exploration.

Adding a third menu option is a little bit of work. Search for "mc.AllowNewWorld" to see the 4 or so places you'll have to make changes; you'll have to change that global to be handled as an int instead of a bool, enter a name for the new menu item, etc... which is actually very easy if you just base it on the code that's already there.

Much simpler is just overriding one of the existing two menu choices to do what you want. Since that only amounts to two lines of code (plus you may want to rename the menu item), I'm gonna go ahead and give it to ya. :) Search for the function "def generatePlotTypes()", go down to where it says "if mc.AllowNewWorld", and insert this extra "if" block just before it:

tm.Initialize()
tm.GeneratePlotMap()
tm.GenerateTerrainMap()
rm.generateRiverMap()
if mc.AllowNewWorld: # or "if not mc", depending on the menu item to override
mc.AllowNewWorld = (PRand.random() < 0.5) # or whatever chance you want
if mc.AllowNewWorld:
continentMap.generateContinentMap()
plotTypes = [PlotTypes.PLOT_OCEAN] * em.length

Btw I'm only 95% sure this will work, since the global is also referenced down in assignStartingPlots() which is another core hook function, and without checking the SDK code I'm not positive it's called after generatePlotTypes() like it would need to be. It should be though.

Assuming this does work, I'll consider adding it as an option if there's an update in the future, which you would think there would be, at some point... ;)

Manfred Belheim
Mar 16, 2011, 05:52 PM
Thanks :)

Before coming back to this thread I already had another look and changed

def getCustomMapOptionDefault(argsList):
return 0


def isRandomCustomMapOption(argsList):
return False

to

def getCustomMapOptionDefault(argsList):
return 0


def isRandomCustomMapOption(argsList):
return True

Which has added a "Random" option to pretty much every menu option. I thought it was probably a bit too crude to work though, but I tested it by generating a map with the same random seed a few times. One time a large continent at the bottom had no starting civs and the other times it did so it seems like it might be working. Not sure though.

But even if it does I think I'd prefer your neater solutions :)

LunarMongoose
Mar 16, 2011, 08:23 PM
Which has added a "Random" option to pretty much every menu option. I thought it was probably a bit too crude to work though, but I tested it by generating a map with the same random seed a few times. One time a large continent at the bottom had no starting civs and the other times it did so it seems like it might be working. Not sure though.

But even if it does I think I'd prefer your neater solutions :)

What the heck? ... Holy carp. I didn't know that flag even existed! (Edit: Actually I think I did, and completely forgot. Oops.) I'd have to take a closer look which I don't have time to do atm, but based on how I already know the menu options work, I would strongly suspect what you did will in fact work perfectly, and would even be the preferred solution. (It's actually "neater" to use built-in functionality than to add more of one's own, though you can still control the random chance with my version if you wanted something other than coin-flip odds.)

I'm guessing it just causes the exe (not the dll since this stuff is hardcoded sadly) to pick a menu option randomly when the script starts, as if a user had picked it. The option probably exists precisely b/c of the problem I mentioned with different hook functions referencing the same settings at different times potentially, so that you need to know where the first thing that runs in the map script is so you can do your own randomizing there, so every function sees the same value of it. (Just be glad the game isn't trying to multithread this process, heh heh.)

Anyway, if what you found and did does what I think it will, it should run the same code that gets run when the user manually chooses a given option, even if it's a custom option... So yeah, if/when I ever post a new version I will probably turn that on. Thanks for reminding me of it. :)

strategyonly
Apr 13, 2011, 10:37 PM
How would these mapscripts work with a completely revised edition of Civ4, ie, I have Prehistoric era, a TransHuman Era and a Galactic Era, all included in my mod?

I tried the PerfectMongoose_v310 one, but dont know if things need to be revised for my mod, and PerfectWorld_v208 didnt work at all?

LunarMongoose
Apr 14, 2011, 10:04 AM
How would these mapscripts work with a completely revised edition of Civ4, ie, I have Prehistoric era, a TransHuman Era and a Galactic Era, all included in my mod?

The mapscripts don't care about new techs, units, buildings, civics, or leaders. They DO care about new terrain types, features, and resources. If you have only added new ones then it will probably work but won't make use of them in many cases. If you have changed or removed any existing vanilla terrain/feature/resource types, that may crash them.

MongooseMod comes with customized versions of 3.1/2.08, for example, due to the extra content in the mod. Some of the t/f/r types are handled on a case-by-case basis in the mapscript code, so I'd have to see your mod to give you very detailed, specific answers. Updating these files for custom content isn't THAT hard, but it can be kinda tricky.

The best advice I can give ya is to compare the vanilla PM files from this thread with the custom versions that come with MM, and figure out what you need to do from there. I apologize, but I really don't have time to do it myself for other people's mods, heh.

Tholal
Apr 19, 2011, 08:48 AM
Excellent! Glad to see the Civ4 mapscript getting some love!

But where are the rivers? I created a couple of maps with default settings, standard size map, and 90% of the rivers are only 1-2 tiles long. The longest I ever saw was 4 tiles. What happened to the real rivers?

LunarMongoose
Apr 19, 2011, 12:44 PM
But where are the rivers? I created a couple of maps with default settings, standard size map, and 90% of the rivers are only 1-2 tiles long. The longest I ever saw was 4 tiles. What happened to the real rivers?

Well, I tweaked some of the control variables around several times trying to get better rivers and lakes, so I'm not sure what to tell ya. Admittedly I mainly tested it on Huge maps, so it's possible my settings didn't scale down to smaller map sizes very well.

You can try adjusting them; they're clearly labelled and described at the top of the file just like they've always been (just open it in any text editor). You can also try the PW2 climate menu option, since that uses a mostly-separate set of control values (and a completely different moisture map).

I'll take a look at smaller maps when I have time, though just offhand I'm not sure there are really supposed to be rivers longer than 4 tiles on something the size of Standard, from a realism standpoint. I could easily be wrong though.

Edit - Though come to think of it, I was actually left wanting rivers to be a bit longer in the PW3 climate system. (Sorry, it's been a while now since I've worked on this so I kinda forgot, heh.) I basically plugged the new climate map, which includes a new moisture/rainfall map, into the old PW2 river generator since PW3 didn't come with one (because Civ5, for which PW3 was written, handles river placement automatically, or something). SO BASICALLY I need to write a new river function for the PW3 climate system, but it's a hard/complicated subject and the existing one worked well enough I thought, so I didn't bother. I'll look into it if/when I have time, though it's a low priority atm.

Again, just to be clear, the PW2 climate setting in the PM3 file does NOT make it work the same as the PW2 file; it still uses the PW3 landmass generator, which is the other big half of the equation. In a future version I was going to try to combine the two map files, basically adding a PW2/PW3 landmass type menu option to go with the existing climate menu option. This will also be a lot of work though, so it's a low priority too. :)

LunarMongoose
May 25, 2011, 10:12 AM
I really hope the small flood of MM downloads the last few weeks hasn't just been to get the custom versions of this mapscript, lol. Oh well, don't forget to try the mod while you're at it then! :p

AIAndy
Sep 09, 2011, 06:55 AM
Something seems to be really wrong with the PW3 rainfall model compared to the PW2 one. While with PW2 all plots get at least a bit of rain, with PW3 you get many land plots with exactly zero rain. That is neither realistic nor do I think that is intended.
The result in your script is that temperature makes those plains or deserts and nearly all plots with at least a bit of rainfall become grassland.

LunarMongoose
Sep 10, 2011, 11:07 PM
Something seems to be really wrong with the PW3 rainfall model compared to the PW2 one. While with PW2 all plots get at least a bit of rain, with PW3 you get many land plots with exactly zero rain. That is neither realistic nor do I think that is intended.

You might be surprised, heh. The code that generates the rainfall maps is copied out unchanged from PW3 for Civ5. In the thread for that version Ceph talked about this issue a fair amount, though atm I don't remember all the details. Something about rain shadows from mountains, and trying to actually be more realistic. I do know PW3 uses a completely different rain system, rewritten from scratch since PW2.

The result in your script is that temperature makes those plains or deserts and nearly all plots with at least a bit of rainfall become grassland.

I do remember checking the rainfall values numerically in a bunch of tests to make sure the code was working right when I was porting it. I definitely wasn't getting 0's very often. I did wind up changing the terrain threshold values for rain and temperature a fair amount, but I was pretty sure it was working right and that what I changed was just preference. (I was trying to get them to show up in roughly equal quantities overall.)

I could, of course, be completely wrong - that's always possible. ;) But I am reasonably sure I reproduced Ceph's original code correctly. I don't claim to understand that part of it; he's the climate/statistics/modelling/mathematics expert, heh.

You can try setting the threshold values back to their Civ5 defaults... If you get significantly different results at that point from what happens with Ceph's original version in Civ5, THEN I probably DID do something wrong. :)

AIAndy
Sep 11, 2011, 04:51 AM
What I was trying to do is adapt the script for the extra terrain now being added to the C2C mod. With PW2 that worked fine, computing rainfall thresholds in the same way from the percent of plots you want with a certain terrain.
With PW3, using that same plot percent to threshold calculation, huge amounts of plots end up as salt flats. So I printed the rainfall map to see what happens and those plots simply had 0 rainfall resulting in the threshold calculation fail.

LunarMongoose
Sep 11, 2011, 04:05 PM
So I printed the rainfall map to see what happens and those plots simply had 0 rainfall resulting in the threshold calculation fail.

Okay. Well like I said, I'm 90% sure that's just how PW3's rainfall system works. Ceph made a big deal about mountains creating "rain shadows" when he wrote it, among other effects, and this was heavily discussed in the Civ5 PW3 thread.

I did specifically allow PM to use the PW2 climate system (temperature and rainfall) with the PW3 terrain system (better-looking landmasses) because I recognized the major difference with the new climate system, and I knew that if I might want the old system, then others might too, heh.

But I don't think it's anything I did wrong in the port.

AIAndy
Sep 11, 2011, 05:23 PM
Okay. Well like I said, I'm 90% sure that's just how PW3's rainfall system works. Ceph made a big deal about mountains creating "rain shadows" when he wrote it, among other effects, and this was heavily discussed in the Civ5 PW3 thread.

I did specifically allow PM to use the PW2 climate system (temperature and rainfall) with the PW3 terrain system (better-looking landmasses) because I recognized the major difference with the new climate system, and I knew that if I might want the old system, then others might too, heh.

But I don't think it's anything I did wrong in the port.
After extensive debugging I found the bugs:
1.) Integer division instead of floating point division in the latitude from y calculation
2.) Only 6 monsoon neighbor plots (which is Civ5 hex setup) instead of 8 neighbor plots (as it should be in Civ4)
3.) Geostrophic rain deactivated (was commented out but disfunctional with the other bugs anyway)
4.) Bugs in the plot list generation for geostrophic rain (sorted geo map)

I have attached the file I debugged it on but since it is an adaption for C2C it has several other changes as well.

LunarMongoose
Sep 11, 2011, 10:35 PM
Awesome, thank you very much! I'll try to post an updated version in the next few days. :)

This would explain why it seemed to mostly work, but I had to change the terrain type threshold values to get the best results.

Hopefully there's nothing wrong with the landmass generator code. I'll double-check a few things based on these bugs.

p.s. -- Sorry for screwing up, lol. I hate making mistakes. It's harder to avoid when you're working on someone else's code, and you understand most of how it works but not most of what it's doing. At least I didn't claim I was certain there were no bugs. ;) Thanks again for your help, I'm really glad to be able to improve this.

AIAndy
Sep 16, 2011, 04:31 AM
Actually it seems the landmass generator has the same hex neighbor problem. It does not use the right part of the perlin noise which definitely changes the way landmasses look, a lot.

I have also done some profiling and it seems that both bonus placement and starting plot finding is very inefficient and claims the majority of the time it takes to create a map, especially with a mod that adds a lot of bonuses, features and improvements.
Every single time it calculates the value of a plot (and it does that not only once but a lot of times for the same plot), it analyses the technology of the mod (feature removal, improvements buildable). That is very expensive as it is done with a loop through all feature and improvement infos.

LunarMongoose
Sep 16, 2011, 01:45 PM
Actually it seems the landmass generator has the same hex neighbor problem. It does not use the right part of the perlin noise which definitely changes the way landmasses look, a lot.

Heh, yeah I kinda figured. ;) I'm just wall-to-wall busy at the moment with my parents visiting and us doing a lot of misc work on the condo. I'm hoping to be able to work on this very soon.

I really like how the landmasses look as it is though, so maybe I'll leave the current version as an option lol.

I have also done some profiling and it seems that both bonus placement and starting plot finding is very inefficient and claims the majority of the time it takes to create a map, especially with a mod that adds a lot of bonuses, features and improvements.

Unlike the previous issues, this is definitely not my fault, haha. I do know PW3 already generates maps a lot faster than PW2 did, but if the speed can be further improved that'd obviously be good. (I think Ceph may have even mentioned this somewhere before... not sure, my memory's a little fuzzy on it.)

Once again, a deep and heartfelt thanks for your work on this, btw. I'm not a debugging expert. I should be, but I'm not. (I've always been able to fix problems the hard way, by reading the code til I realize what's wrong. This mapscript was one of the first times I'd ever worked on something this complex, that'd also been written by someone else originally. Oh well, a little public embarrassment is good for the soul. :p)

cephalo
Sep 16, 2011, 02:49 PM
My memory of this stuff is very fuzzy since its been years since I looked at PW2, but the value of a land plot is very relativistic. For example, if you have a cluster of gold resources way out in the desert, you can't give them all the same value because the available food might only let you work 1 or 2 of them. Also, it can happen that a resource is actually on a different continent than the city site being evaluated. It's all in the context of potential city building.

It would be cool if you guys could improve the speed, but I'll warn you that the problems with starting plot finding on a map like this are non-trivial. I never thought much about efficiency because I figure if I'm willing to spend 10 hours playing Civ I could handle waiting 10 minutes for the map. :)

AIAndy
Sep 16, 2011, 04:14 PM
When you create the 100th map without playing to find bugs and look how the whole bunch of extra terrain looks like you tend to start to like efficiency :) (Although I guess you went through all that as well).
And the way the starting plot assignment is done is good and I don't plan to change that.
Profiling just showed me that on a standard size map the computer evaluated a plot over 50000 times. So each plot was checked over 50 times on average and every single time there is a loop over all features and improvements. That might not be much in standard Civ4 but I adapted it for C2C which has loads more.
So I have already done some plot value caching but a good part of that city and plot value checking is done in the loop that adds extra resources to city spots and that loop actually changes the value of plots so simple caching is not enough. Some incremental change of cached plot values would be needed here.
Simplifying the mod technology analysis and moving it out of the plot value function would also reduce the amount of time needed a great deal. Not entirely simple though if you want to store that information efficiently for use in the plot value analysis.

That reminds me that I still need to check why in my changed Mongoose mod the starting plot finder tends to fail nearly every single time (might be because of technology analysis issues).

LunarMongoose
Sep 16, 2011, 11:00 PM
That reminds me that I still need to check why in my changed Mongoose mod the starting plot finder tends to fail nearly every single time (might be because of technology analysis issues).

Interesting. I wouldn't mind knowing that myself, heh. I've noticed something fails with PM in unmodified-MM like 10-20% of the time, which wasn't enough of a problem to force me to look into it, but it's probably this.

p.s. - Hi Ceph! *hugs*

AIAndy
Sep 17, 2011, 06:00 AM
Interesting. I wouldn't mind knowing that myself, heh. I've noticed something fails with PM in unmodified-MM like 10-20% of the time, which wasn't enough of a problem to force me to look into it, but it's probably this.

p.s. - Hi Ceph! *hugs*
Thinking about it the reason is probably that in MM (modified and unmodified) the removal of forest and most improvements are not in the starting era.

cephalo
Sep 17, 2011, 08:44 AM
Wow, 50000 times for one plot? I don't remember what I was doing, but I would have never imagined so many. That's gotta be a bug. The most I would expect would be once for each city location that contained the plot in the fat cross. Inefficiencies might double that, but 50000 seems way way off.

AIAndy
Sep 17, 2011, 09:39 AM
Wow, 50000 times for one plot? I don't remember what I was doing, but I would have never imagined so many. That's gotta be a bug. The most I would expect would be once for each city location that contained the plot in the fat cross. Inefficiencies might double that, but 50000 seems way way off.
A profiling on my current version (starting plot finding only):
4024193 function calls in 52.129 CPU seconds

ncalls tottime percall cumtime percall
21711 0.155 0.000 0.221 0.000
C2C_PerfectMongoose_v310:4101(getPlotPotentialValu e)

39074 36.417 0.001 47.659 0.001
C2C_PerfectMongoose_v310:4112(getPlotPotentialValu eUncached)

6 0.209 0.035 45.169 7.528
C2C_PerfectMongoose_v310:4208(boostCityPlotValue)

That is already with caching of the plot value except in the boost city part when plot value is increased.
So 60000 calls to evaluate a plot in total, the majority called by boostCityPlotValue. For some reason it evaluates 5000 plots each of the 6 times it boosts a city.

AIAndy
Sep 17, 2011, 10:47 AM
I found the reasons.
1) The mod had the bNormalize flag set for very few resources so the loop that sets the bonuses ran all the way to the end usually with loads of city and plot evaluation without actually setting a bonus.
2) The mod has a city radius of 3, but not at the start. Still the code returned the city plot number at 37 instead of the 21 it should be. So a lot more evaluation per city evaluation.

Fixing both of that (in addition to the caching) reduced the time the starting plot finding to few seconds.

cephalo
Sep 17, 2011, 10:53 AM
Another thing I noticed in my original code is that when boosting plots I call getCityPotentialValue for each plot within a city site because the loop in question might change the value of the city. I'm sure there's alot of room for improvement there.

AIAndy
Sep 17, 2011, 05:26 PM
Another thing I noticed in my original code is that when boosting plots I call getCityPotentialValue for each plot within a city site because the loop in question might change the value of the city. I'm sure there's alot of room for improvement there.
Indeed, that is what I thought about when I first looked at it. Caching it in an incremental way (meaning the placing of the bonus changes the cache value but does not do a full reevaluation). But with the changes it tends to run a LOT less so the improvement is not really needed any more. The run time of the starting plot finding is now down to very few seconds.
Next I rather look at the bonus placement.

LunarMongoose
Sep 17, 2011, 07:33 PM
1) The mod had the bNormalize flag set for very few resources so the loop that sets the bonuses ran all the way to the end usually with loads of city and plot evaluation without actually setting a bonus.
2) The mod has a city radius of 3, but not at the start. Still the code returned the city plot number at 37 instead of the 21 it should be. So a lot more evaluation per city evaluation.

Heh, oops. :) However turning normalization off was intentional... I didn't want players getting any more resources than the basic terrain would specify, if possible. Which ones did you turn bNormalize back on for? Just curious.

AIAndy
Sep 18, 2011, 03:55 AM
Heh, oops. :) However turning normalization off was intentional... I didn't want players getting any more resources than the basic terrain would specify, if possible. Which ones did you turn bNormalize back on for? Just curious.
Actually that is a misunderstanding. Your mod has that flag set for many bonuses. It was the C2C mod I was profiling on which has that flag set on very few bonuses.

Sir Spanky
Oct 04, 2011, 10:25 AM
Perfect World 2 and Perfect mongoose are great scripts. AIAndy thanks for going back over them and tweaking them out.

I play on the 60x40 map sizes pretty regularly (almost exclusively), and use these 2 scripts. They create some awesome worlds!

Can't wait to see how it works when you are done Andy

Bloodstone
Oct 14, 2011, 03:59 PM
Sorry if I post this in the wrong spot. I'm a tech dweeb and not sure how mapscripts work. I just downloaded the PW3 Mongoose, is there anywhere that tells me a step by step on how/where to put these files? I normally run games with BAT, LoR, or RevDCM and I've got those set up. Just trying to make sure if these scripts work there. Is there a read me or something? I got the mod loading thing down, just have never done anything with maps or mapscripts. Thanks for any help.

And
Nov 11, 2011, 11:48 AM
Good Evening,
is there a way to get updated map script mentioned here? I mean the one with bug fixes coded by AIAndy.
Thank you very much for your work, really.

AIAndy
Nov 11, 2011, 01:16 PM
Good Evening,
is there a way to get updated map script mentioned here? I mean the one with bug fixes coded by AIAndy.
Thank you very much for your work, really.
I fear I never applied them to normal BtS.
The main version I maintain is in the Caveman2Cosmos mod and contains quite some extra code for the new terrain and everything.
I have also made a version for the MongooseMod which contains most of the fixes (I use that one for some multiplayer games with friends). It should not be too far off from a version for normal BtS (but still requires some removal of code). I'll attach it.

And
Nov 11, 2011, 01:50 PM
Oh, I see, I guessed I could use it with normal BtS... Maybe LM will be able to update it one day. Thank you very much for the quick answer!

LunarMongoose
Nov 24, 2011, 09:30 AM
Serious, major, heavy-duty apologies for the delay - Real Life™ kinda eggsploded on me the last 6 months. (Even though I still don't have a job, it's amazing how busy I've been... sigh.)

I am eggspecting to be able to work on Civ stuff again starting this weekend (and next week at the latest if I'm wrong, which I usually am, lol), and this mapscript update is first on the list.

Btw, thanks for making an update for MM already, Andy; I didn't anticipate that, and it'll make doing the plain BtS version a lot easier. I was gonna do some other things too though, in terms of merging the two files in my download so all the generator options are in one script, and add an option for using the existing "broken" hex-square evaluation even after I apply your fix, since I really like it the way it is. :p

Tholal
Dec 01, 2011, 09:56 AM
Looking forward to the update!

LunarMongoose
Dec 01, 2011, 12:42 PM
Looking forward to the update!

Whelp, as you might easily have guessed, I was right about being wrong, lol. I really am almost done now though. I screwed up my big Black Friday Zazzle order which took a whole extra day to fix, people keep buying the stuff I have listed on Amazon which takes time to package and carry over to the post office every day, AND I've been eating too much lately which, in turn, makes me sleep more than usual. (Not to mention I've had to keep a close eye on the stock market given how volatile it's been lately.)

... That was in case you cared about the details, which I doubt... though I'm telling you anyway. :p

Should be starting this tomorrow afternoon (or possibly tonight if my Brain Gerbils spin their wheels really fast), and I don't really expect it to take more than a couple full days to do. The usual disclaimer still applies though - I am terrible at making time predictions on my own work. Just saying. ;) Sorry again for the delays, and thanks for your interest.

LunarMongoose
Dec 06, 2011, 01:11 AM
IT! ... HAS! ... BEEEGUNNN!!!

/end Mortal Wombat Announcer

Okay so I'm another 4 days late. I stopped to watch the whole golf tournament since Tiger was, you know, mostly not sucking for once... Then I discovered a wonderful tv show (The Big Bang Theory) which was on during ad breaks in the golf... Then the stock market continued to require my attention Monday. Umm... Blame Europe, not me. :p

Anyway, I'm officially working on the PM update now - gimme a couple days. A MongooseMod update should follow sometime in the next 6 weeks, since I have to get that done before Diablo 3 comes out on January 17... But at least the real-life pressure is reduced and I'm feeling relatively happy and unstressed now, finally. :)

('Course I'd be a lot HAPPIER if I weren't single, but any potential gf would have to be Dying for Diablo(tm) as a prerequisite, so what can ya do... I know, I'm hopeless.)

Alright, I'm pretty sure I'm rambling again, so I'm going to stop typing now. Feel free to continue on with your lives.

LunarMongoose
Dec 07, 2011, 02:50 AM
Quick update:

I've gone through all of AIAndy's code, and made all his quick obvious bugfixes. I also found one additional place where there was an int that was supposed to be a float, though I don't know if it actually matters in this case. I've added the new option to use the old hex tile evaluation math in the landmass generator if the user wants to. @AIAndy: Really clever idea to use the sync'd DLL function to seed the Python random generator so it can still be used in multiplayer games! :worship:

I'm just getting into Andy's rainfall fixes and feature / bonus placement code changes. The latter was just for efficiency and the changes are extensive, so I could skip it if I had to, but I guess I'll muck through it. :p

Then I still have to merge in the PW2 landmass generator. It's gonna be a couple more days before this update is ready, but I'm working on it!

Edit - @AIAndy again: I'm curious about the drainList North/South swap you made in generateRiverMap, cuz that should've been copied verbatim from PW2, but for now I'll assume you're right. :) Also, I'm pretty sure the gc.getNUM_WHATEVER() calls you replaced with literals are wicked fast - they're mapped to one-line DLL functions that read "return self.constant;" basically. So I'm not sure you're saving more than a few microseconds per pass with this, but I understand why you did it - they're obviously in the heart of the beast as far as the loops go.

Edit 2 - Yep, you were right, but it doesn't matter: generateRiverMap() assumes wrapX is true and wrapY is false, so if the map settings don't match that, it will get into trouble b/c GetIndex() will return -1 for out-of-bounds queries. I've changed all four drainList neighbor checks to check for ii being -1. This will allows rivers to link on the top and bottom of a Toroidal map, for example, and avoid an averageHeightMap[-1] query on a Flat map, for example. Though the latter should be causing a crash and it isn't, which is weird...

God-Emperor
Dec 07, 2011, 07:01 PM
... and avoid an averageHeightMap[-1] query on a Flat map, for example. Though the latter should be causing a crash and it isn't, which is weird...

Negative array indexes in Python are valid. They count back in from the end of the array, so if array A has items 0 through 9 then item -1 is item 9, -2 is 8, and so on. (Item "-0", if you can get such a thing, is still item 0.) Essentially it is the same as having wrap in the coordinates of a map.

LunarMongoose
Dec 07, 2011, 08:36 PM
Negative array indexes in Python are valid. They count back in from the end of the array

Ahhh. Well I'd about concluded they had to be valid since it wasn't causing a crash, but I assumed they just returned a value of -1 or something. Figures it'd be some silly safety mechanism for a non-compiled scripting language lol. Also goes to show my limited experience with scripting languages. :p Anyway, thanks for the info! (My ii -1 checks will still work though cuz they're a simple way to allow x and y wrapping when and only when the map allows them.)

Progress-wise, I've made some more very minor code optimizations in several places, and turned on the geostrophic system (which was probably disabled b/c I guess I disabled it in the original port when I couldn't get it to work due to the other bugs... and then I promptly forgot about it b/c I didn't understand how important it was... oops). I need to run some tests and be sure I'm happy with the fine-tuning of the terrain percent constants now that the system is actually working properly.

I'm also doing some testing on various combinations of settings for the new "messed-up-math hex evaluator option", which it turns out is even more broken in PM 3.1 than Andy and I thought (b/c range(1, 7) includes the N and S directions that GetNeighbor() ignores, so it wasn't even evaluating all 6 hex directions lol).

Then I have to muck through Andy's feature / bonus rewrite, and merge in PW2. Still gonna be a couple more days. :)

LunarMongoose
Dec 08, 2011, 07:37 PM
Making good progress. I've finished merging in Andy's code, and am most-of-the-way done with tweaks and adjustments and checks. I also found one nasty little copy-paste-type bug in makeHarbor(), which is from the original PW 2.0.6 code so all versions of this mapscript have had the problem for a long time, heh.

I still need to merge in PW2's LMG and then convert the file for vanilla BTS, and my parents are arriving tomorrow which will get me busy with real-life stuff again, but I'm still gonna try to finish this update over the weekend... Keep your feathers crossed. ;)

@AIAndy:

I disagree with you removing the "no bonuses of different types in adjacent tiles" rule; this has always been a standard rule in Civ4, and is present in the DLL's default bonus placement code if a mapscript doesn't provide any, so I'm leaving it in.

All the MongooseMod feature removal Builds (Chop Forest, Chop Jungle, Dredge Marsh, Scrub Fallout) have no tech prereq (b/c their tech prereqs are in the feature-removal subsections only). However I don't need to consider them in getPlotPotentialValueUncached(), b/c Cottages will be available in the minimum era range (Classical), and those plus Mines can go anywhere that Jungles and Marshes can (and any improvement is automatically better than just a chop). SO, I'm leaving this line of code the way it was as well, since skipping over the chop builds is another slight speed boost. :)

My generation time with a Huge map on PM 3.2 averages around 4min 10sec, whereas on PM 3.1 it's around 5min 20sec. Thus, I love your caching. :D Taking into account your info about most of the time being spent in getPlotPotentialValueUncached() however, I'm going to try exposing the DLL's version of this function to Python and calling that instead in the MM Edition. I don't remember if you can run all the DLL's code from mapscript Python, but if it works it should be a lot faster. More importantly it's also a much better version of the function computationally, as it's a lot longer and includes a lot of BetterAI work by Fuyu and others. So it'd be worth using anyway.

AIAndy
Dec 12, 2011, 06:23 PM
@AIAndy:

I disagree with you removing the "no bonuses of different types in adjacent tiles" rule; this has always been a standard rule in Civ4, and is present in the DLL's default bonus placement code if a mapscript doesn't provide any, so I'm leaving it in.
For MongooseMod that is fine. I mainly decided to remove it to make bonus placement easier for C2C as it has a lot more resource types so placement fails to find proper spots often for some bonus types.

My generation time with a Huge map on PM 3.2 averages around 4min 10sec, whereas on PM 3.1 it's around 5min 20sec. Thus, I love your caching. :D Taking into account your info about most of the time being spent in getPlotPotentialValueUncached() however, I'm going to try exposing the DLL's version of this function to Python and calling that instead in the MM Edition. I don't remember if you can run all the DLL's code from mapscript Python, but if it works it should be a lot faster. More importantly it's also a much better version of the function computationally, as it's a lot longer and includes a lot of BetterAI work by Fuyu and others. So it'd be worth using anyway.
If calling that function is fine from C++ at that point, then calling it from Python will work as well.

@AIAndy again: I'm curious about the drainList North/South swap you made in generateRiverMap, cuz that should've been copied verbatim from PW2, but for now I'll assume you're right.
Iirc that code had north and south confused and did not prevent wrapping in y direction as it should which could then later cause an infinite loop in river placement.

LunarMongoose
Dec 13, 2011, 02:46 AM
I'm almost done with the update, just got swamped with other stuff to do the last few days. Since my last post I've improved sea ice placement significantly, and finished testing and tweaking everything... I just need to finish the PW2 LMG merge and adjust the file for vanilla BTS. If I can get some more blocks of time to work on it it'll be done pretty soon.

For MongooseMod that is fine. I mainly decided to remove it to make bonus placement easier for C2C as it has a lot more resource types so placement fails to find proper spots often for some bonus types.

Yep, I kinda figured that might be why. ;)

If calling that function is fine from C++ at that point, then calling it from Python will work as well.

Right... I just know there were some restrictions on calling DLL functions in some places (like the Civ4 main menu areas, and the initialization phase of a new game right after the mapscript finishes running) and I didn't remember for sure if this was one of em.

Iirc that code had north and south confused and did not prevent wrapping in y direction as it should which could then later cause an infinite loop in river placement.

Yep, I said in "Edit 2" that you were indeed right, but it turned out to not matter cuz I had to rewrite that code anyway. :p Good find on the north/south lines being mixed up though; it got me thinking about all the edge-checking code in the script.

AIAndy
Dec 13, 2011, 04:07 AM
Right... I just know there were some restrictions on calling DLL functions in some places (like the Civ4 main menu areas, and the initialization phase of a new game right after the mapscript finishes running) and I didn't remember for sure if this was one of em.
You mainly have to be careful that everything the function you call uses has been initialized. In case of doubt, add the call and use a debug DLL to see if the C++ code runs fine.

LunarMongoose
Dec 20, 2011, 04:02 PM
Toldja not to trust my time estimates of my own work. :p Sorry (again); whenever my parents are here we get a lot of work done on the condo, so I got swamped this past week (again).

I finally got to work on this again today. After much frustrating effort that felt like trying to attach a classic car's body to a modern car's chassis (which was a cool IWCC episode!), I have successfully forced the PW2 landmass generator to live, work, eat and play in my PM3 code environment.

I had to write some kludgy code to get it working, which I need to go back and update now that I trust it. I also need to convert it to vanilla BTS, and check a few final things, but there's a good chance it'll be ready later tonight... gimme a few more hours. :)

LunarMongoose
Dec 24, 2011, 03:18 PM
I'm actually not going to bother with the code cleanup I mentioned... It'd take too long, I'm a little burnt out on this thing at the moment, and it works fine the way it is. Besides, there's a lot more redundant functions to consolidate than just the new PW2 LMG stuff. I might do it in a minor future update, but for now just be aware there's an annoying "if mc: em = e3, else: em = e2" assignment at the top of almost every function, lol.

Since my last post I've further improved floating sea ice placement beyond what I did before (it's really awesome now), further tweaked the climate constants, made a speed optimization of my own (very minor, but it takes two lines out of a loop like Andy did in another spot, so I'm proud of it :p), updated the version history for 3.2, and rewrote my feature placement code (separately from Andy's rewrite of it, but with the same effect - fixing a bloated mess).

At the moment I'm tackling a problem I discovered yesterday, which is that the PW3 climate system yields temperatures much higher than they should be when used with the PW2 landmass generator, and I haven't figured out why yet. (The other combinations all seem to be working properly: 3 LMG + 3 climate, 2 LMG + 2 climate, and 3 LMG + 2 climate as was available in PM 3.1.)

So anyway, if I can get it fixed tonight or tomorrow I will, otherwise I just need to remove the MongooseMod stuff and it'll be out the door. (At which point Ceph and Andy can figure out the problem for me. ;))

LunarMongoose
Dec 27, 2011, 01:47 AM
After 2 weeks of on-and-off work, followed by a week of 12-to-16-hours-a-day work, followed by a 20-hours-of-work-in-a-single-day day, followed by 12 more hours of work today... Version 3.2 has been posted.

This file has now been heavily tested, and I am very confident everything is as it should be. There are several major improvements in this update, and I even managed to further reduce the time the script takes to run beyond what Andy did (from 4min 10sec to 3min 30sec on average on my computer) with some of my most recent code (though at the moment I'm not sure exactly which changes caused this, lol).

I missed Christmas by 2 days, but I only missed the one-year anniversary of the PerfectMongoose 3.1 release by 5 hours and 27 minutes, so I feel like I did okay. :) Enjoy your holiday present guys!

p.s. - I am burnt out to hell with working on this thing, and completely drained mentally and exhausted physically. PLEASE don't find anything wrong with this file, or think of anything you would like me to change or add, for at least another 9 months. Thanks. ;)

p.p.s. - As promised I will be resuming my work on the also-much-delayed MongooseMod 3.2 update soon, so the MME version of PM 3.2 will be released later with the rest of the mod. I've already made several mod-specific improvements in it, like Marsh placement that is rainfall-sensitive instead of random.

[to_xp]Gekko
Dec 30, 2011, 09:55 AM
awesome work man, you deserve some rest while we players reap the rewards of your toil ;)

LunarMongoose
Dec 30, 2011, 11:51 AM
Gekko;11156373']awesome work man, you deserve some rest while we players reap the rewards of your toil ;)

Thank you, I'm glad you like it. :) I may actually release a 3.2.1 update here in a bit btw... In addition to getting a lot of sleep, stopping to relax, and noticing how much I missed out on in the stock market over the last 2 weeks (gah, srsly?! grr...), I've updated Oasis placement to be rainfall-sensitive (and to have a slightly wider minimum spacing), and changed Jungle (and Deciduous vs Evergreen Forest while I was at it) temperatures over from absolute values to being percent-based (like I already did with Snow and Tundra in v3.2).

The latter change may be somewhat controversial since it will create jungles at higher latitudes than normal if necessary, but I've decided I really like having consistent amounts of every type of terrain on the map each time, including Jungle, even if it happens to create a world with no major landmasses in the tropics. It's good for gameplay balance, and it's not really THAT different from how South America is on Earth anyway. :p Feel free to debate this though.

Terkhen
Dec 30, 2011, 03:10 PM
I have tested the new script, the results are awesome. Thank you :)

modifieda4
Jan 11, 2012, 10:22 PM
so far my experience, on a standard size map, pw3 settings seem to generate alot of deserts. The pw2 settings seem more balanced.

by the way i love the pw seies of maps :)

LunarMongoose
Jan 11, 2012, 11:36 PM
so far my experience, on a standard size map, pw3 settings seem to generate alot of deserts. The pw2 settings seem more balanced.

Nope. In 3.2 they will both generate exactly 18% of total landmass as Desert. I'm not saying that JUST b/c of my code; I also wrote some diagnostic code that counts up each type of terrain at the end and prints the actual percentages to the debug text file. I ran it a whole bunch of times on different sizes, and the values were always within 1% or so of what they were supposed to be.

I left it in, actually. You can find it at the bottom of "def generatePlotTypes()"; just uncomment it and enable Python logging. :)

[to_xp]Gekko
Jan 12, 2012, 07:52 PM
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 :)

AIAndy
Jan 13, 2012, 03:52 AM
Gekko;11187219']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
Jan 13, 2012, 04:40 AM
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...

AIAndy
Jan 13, 2012, 05:53 AM
Gekko;11187678']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...
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
Jan 13, 2012, 07:18 AM
The entry functions are those:
def addBonuses()
def assignStartingPlots()

unfortunately I have no idea what this means :blush:

AIAndy
Jan 13, 2012, 07:40 AM
Gekko;11187930']unfortunately I have no idea what this means :blush:
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
Jan 13, 2012, 08:12 AM
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
Jan 13, 2012, 08:22 AM
Gekko;11188042']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
Jan 13, 2012, 09:11 AM
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:

LunarMongoose
Jan 13, 2012, 09:19 AM
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
Jan 13, 2012, 09:25 AM
Gekko;11188156']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:
The error message says that there is still some code in assignStartingPlots that tries to call SetStartingPlots that I assume you removed.

LunarMongoose
Jan 13, 2012, 09:40 AM
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
Jan 13, 2012, 10:09 AM
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
Jan 13, 2012, 10:10 AM
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
Jan 13, 2012, 10:27 AM
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
Jan 13, 2012, 10:39 AM
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
Jan 13, 2012, 11:48 AM
Gekko;11188340']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
Jan 13, 2012, 12:10 PM
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

modifieda4
Jan 14, 2012, 12:04 PM
@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
Jan 14, 2012, 06:11 PM
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".

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? :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.

[to_xp]Gekko
Jan 15, 2012, 04:38 PM
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 :)

LunarMongoose
Jan 15, 2012, 05:28 PM
Sorry Gekko, I'm literally working 24/7 on my MM update at the moment. I might be able to look at it in 2 weeks or so, but hopefully Andy can help you sooner hehe.

Couple additional points on my previous post:

It's actually slightly more complicated than that, b/c I set the percentages to ignore Peaks in the 3.2 update. Peaks do have terrain types underneath them, but their values are irrelevant for gameplay purposes since all Peaks are functionally the same, so Desert is really "18% of non-Peak landmass tiles". If you have a lot of Peaks running through your big deserts, for example, you'll see a lot of sand at the bases of your mountain ranges, but it won't affect global terrain composition like it did before.

Early on in the 3.2 update, I DID experiment with giving low rainfall priority over low temperature. By that I mean the 18% lowest-rainfall tiles were set to Desert first, then the coldest of the remaining 82% of land tiles were set to Snow and Tundra, then the tiles remaining after that were split into Plains and Grassland based on rainfall. The idea was to live or die by the "desert means dry, not hot" rule they teach you in school. ;) The problem was that yellow/orange sand just looks freakin terrible in the polar regions. I'm sorry, but it does. :p

So I wound up doing it the way I did instead, which is also how Cephalo had it. He just didn't use locked percentages on the rainfall-based stuff, so while Snow and Tundra were constant before, Desert, Plains and Grassland amounts varied widely depending on landmass shapes in previous versions of PM and PW. While that's technically more realistic, I decided it was much better for gameplay to make sure all terrain types were always well-represented in every game. It can marginalize too many techs - and the units, buildings and improvements they unlock - otherwise.

This is also why I converted Jungle over to being percent-based as well in version 3.2.1, which I haven't released b/c it's a more questionable thing to do than locking all terrain amounts was. In order to guarantee the required amount of Jungle, it will spawn it fairly far away from the equator when necessary (due to lack of land in the tropics some of the time), which can look a little weird. I still prefer it this way though, b/c otherwise Jungle-based game elements can get short-changed. (Or they can be overpowered if the reverse is true and there's tons of land in the tropics, heh.)

But I'm not releasing this change unless people want me to. It WILL be in the MongooseMod version though, so the code can be lifted from there once I post it if you really want it. ;) (I also changed Oasis placement to be rainfall-based, but without the Scrub feature to reinforce that design I'm not sure it'd be a good idea to do in vanilla, vs random Oasis placement.)

Okay, shutting up now, gotta get back to work. :p

[to_xp]Gekko
Jan 15, 2012, 05:46 PM
of course people want you to upload those changes :D

LunarMongoose
Jan 15, 2012, 07:41 PM
Gah, I'm sorry, I had that backwards. Cephalo had rainfall-based things (Desert, Plains, Grass, Jungle-Rain) as locked percents, and temperature-based things (Snow, Tundra, Jungle-Temperature) based on fixed values.

So in previous versions the amount of Snow and Tundra varied widely depending on landmass shapes, and the rest stayed at constant percents. BUT! They were at constant percents of the remainder since temperature is applied first, AND the size of the remainder was varying widely (b/c of Snow and Tundra), SO the amounts of rainfall-based terrain you wound up seeing were still highly variable. I didn't even realize the full scope of that problem til now, haha.

Gekko;11193011']of course people want you to upload those changes :D

Well you're the first and only person so far to ask for it, and I did ask what people thought about the Jungle issue back when I released 3.2... with no responses. :) And as I said, for vanilla I think Oases are actually better off the way they are.

Having jungles occasionally stretch down toward (though not into) the polar regions IS kinda similar to what South America looks like on Earth (though I think the real jungle is still mostly tropical)... But Cephalo was very clear in his PW2 notes that he prefers temperature-based stuff to remain strictly controlled by latitude. So I'm just not sure how popular a change this would be overall.

It's a realism vs gameplay argument, and while people easily sense how realistic things are (or aren't) in video games all the time, thinking about things from a balance standpoint is NOT something most people do naturally. (I would actually argue that even a majority of the professional game designers out there suck at it... Professionals in all creative fields also seem to suffer from a strong desire to fix things that aren't broken, usually breaking them in the process, sigh.)

And like I said, it will be fairly straightforward to steal the relevant code from the MME version once I release it, so you should be okay. :p

[to_xp]Gekko
Jan 16, 2012, 01:14 AM
I think it's mostly lurkers nowadays and that's why you didn't get many responses ;)

LunarMongoose
Jan 16, 2012, 03:04 AM
Gekko;11193632']I think it's mostly lurkers nowadays and that's why you didn't get many responses ;)

Yeah, I know... But I didn't really get that many responses to my stuff in the more distant past either (no matter how awesome it was ;)), and I still firmly believe in challenging lurkers to come out of hiding and post by confronting them with opportunities to seize their own destinies and control their own fates. For example by letting them choose which type of jungle they want. :p

Plus I know there's a good number of lurkers lurking, cuz I see the thread view and file download counts going up at a respectable pace. Maybe I should set up some mousetraps and gerbil wheels...

Redarg
Jan 16, 2012, 04:49 PM
Gameplay balance is very important for me, as I play mostly Pitboss Multiplayer Games. So I have no problem having Jungle in weird places.
A map should be playable. For everyone.
Creating a perfect planet simulation is another thing.

Redarg

modifieda4
Jan 17, 2012, 06:29 AM
as a lurker i made somce changes :)

land water/ratio is set at 42% vs 29% default
deserts is set to 14% vs 18% default

using PW3 settings, it makes nice maps which can support alot of civs on a standard sized map and with alot of opportunity for early land combat :)

Tholal
Jan 17, 2012, 09:15 AM
The idea was to live or die by the "desert means dry, not hot" rule they teach you in school. ;) The problem was that yellow/orange sand just looks freakin terrible in the polar regions.

Polar deserts wouldn't be sand. They would be snow and ice. The ice caps have deserts and some tundras are also considered deserts.

Maybe you should fudge the 18% desert amount downwards a bit based on the amount of ice and tundra?

I also think it would be cool to occasionally replace a desert area with plains, ala the Great Plains in the U.S.

As for lurking, I've found that watching how many downloads you get is a better indicator than thread activity. People tend to post more often if they have a problem or bug or something to complain about, so if you're getting downloads and minimal complaints, then you're doing well!

And I would also be interested in seeing this file updated with whatever changes you incorporate into your mapscript. Thanks for all the work!

LunarMongoose
Jan 17, 2012, 01:07 PM
Gameplay balance is very important for me, as I play mostly Pitboss Multiplayer Games.

Ooh! Then do you mind if I ask if you've tried MM? I highly recommend it for multiplayer. :) Though at the moment you might want to wait for the forthcoming big update, haha.

land water/ratio is set at 42% vs 29% default
deserts is set to 14% vs 18% default

Yep, I'm sure that works well. I tend to balance around Huge maps so I don't have much experience with Standard.

You can also try turning meteors off; smaller maps may work a lot better that way (I know meteors take out almost all the land on Duel size).

Polar deserts wouldn't be sand. They would be snow and ice. The ice caps have deserts and some tundras are also considered deserts.

Yeah, I know that now. But initially I was like, wait a minute, snow and ice (and tundra's permafrost) are water, which means they aren't dry at all! So dry polar should be desert! Then I tried it and was like, wow, what a terrible idea! ... Just saying. :p

Maybe you should fudge the 18% desert amount downwards a bit based on the amount of ice and tundra?

Nah... The "consensus" 20% I came to was for "real" desert, ie sand. If you include other types of "desert", the numbers you get on Google and other places are more like 35-45%. (Give or take; I don't remember this one exactly.) PM is currently 18% desert + 20% tundra + 15% snow, so that's 53%, but I'm not sure tundra should be included (in which case it's only 33%), and I like it this way for keeping all biospheres well-represented in a balanced way.

I'm actually very happy with the terrain composition... There were too many Grassland and Plains tiles before and it made it too easy for everyone (especially the high-difficulty AIs lol). These numbers also look very Earth-like... I literally generated dozens of Huge maps with dozens of different variations in the percents while working on this thing, heh.

Besides, you can always change them yourself; since the beginning Cephalo has always had them right at the top of the file so it's easy to do. :)

I also think it would be cool to occasionally replace a desert area with plains, ala the Great Plains in the U.S.

The PW3 climate system is supposed to do that automatically already. (There was a lot of discussion about it earlier in the thread.) The Great Plains regions aren't AS big as before b/c I had the system completely broken before, and they probably won't show up much on smaller sizes, but yeah. Hrm.

As for lurking, I've found that watching how many downloads you get is a better indicator than thread activity. People tend to post more often if they have a problem or bug or something to complain about, so if you're getting downloads and minimal complaints, then you're doing well!

I know, I know... :p I just like hearing from people. Probably b/c I don't interact with other living creatures very often in real life, mwa ha ha.

And I would also be interested in seeing this file updated with whatever changes you incorporate into your mapscript. Thanks for all the work!

Alright, fine, that's two of you, which is a big deal as far as people posting goes, so I'll release 3.2.1. ;) I might wait til I'm done with what I'm currently working on though, just to be thoroughly cruel and evil beyond all reckoning and measure... Mwa Ha HAAAAAAAAAAAA!!!

modifieda4
Jan 17, 2012, 03:13 PM
You can also try turning meteors off; smaller maps may work a lot better that way (I know meteors take out almost all the land on Duel size

yup, I have turned off meteors. I also manually check for peak-only isthmus..which are sort of lame :)

Redarg
Jan 18, 2012, 05:56 PM
Ooh! Then do you mind if I ask if you've tried MM? I highly recommend it for multiplayer. :) Though at the moment you might want to wait for the forthcoming big update, haha.


just screwed my posting, once a again, a brief version:
No I didn't. Just casual gamers. How tremendous are your changes to game mechanics? I probably can't force all the people I'm playing with to learn a new mod/game, complex as Civ4, just for one Pitboss game, so I'll just play Civ4BTS. Which is fine. I still haven't tried out all strategies I want to.

Redarg

LunarMongoose
Jan 18, 2012, 10:06 PM
How tremendous are your changes to game mechanics? I probably can't force all the people I'm playing with to learn a new mod/game, complex as Civ4, just for one Pitboss game, so I'll just play Civ4BTS. Which is fine. I still haven't tried out all strategies I want to.

I've changed so much from vanilla at this point I can barely keep track of it all, but at the same time, the whole point of my mod is that it still feels like vanilla BTS. (The other big mods... I didn't really get that impression, heh.) Plus it's specifically built for multiplayer.

Neverminding the enormous pile of direct bugfixes most mods have from the Unofficial Patch project (and which no player should ever be without; plain Civ4 has a LOT of broken stuff in it, sadly)... There's a full list of my most major changes in the Stuff To Know sticky in my subforum, so I'm not gonna repeat everything here. And I'm certainly not asking you or your friends to do anything you don't want to do, but I've put my heart and soul into this project for the last 6 years, and I honestly think it deserves at least a quick look. :p

Anyway, sorry for going off-topic. It's actually not much work to move my 3.2.1 changes back to the vanilla PM file, so maybe I'll get it out the door soon afterall... I'm just super-swamped atm. I seriously can't wait til I have nothing I have to do, again. ;)

[to_xp]Gekko
Jan 21, 2012, 06:00 AM
guys, how would I re-add the "start anywhere" and "break pangeas" toggles to a PW-based script that's got them removed?

the variables are still there ( self.AllowPangeas and self.AllowNewWorld ) so all it needs is those 2 dropboxes that allow you to change it via custom game ( as opposed to having to open the file with a text editor )

thanx in advance as usual :)

OnmyojiOmn
Jan 24, 2012, 12:49 PM
LunarMongoose, I just don't understand your thought process regarding starting city locations. The first thing I did with 3.2 was to generate several maps (small, 7 civs, default script settings) and look through the starting spots. Almost every spot is full of jungle, tundra, and peaks. How is it even possible for your generator to pick a spot that doesn't break even on food, even with max output from improvements?

This is really frustrating, and disappointing.

LunarMongoose
Jan 24, 2012, 08:14 PM
LunarMongoose, I just don't understand your thought process regarding starting city locations. The first thing I did with 3.2 was to generate several maps (small, 7 civs, default script settings) and look through the starting spots. Almost every spot is full of jungle, tundra, and peaks. How is it even possible for your generator to pick a spot that doesn't break even on food, even with max output from improvements?

It's not "my thought process"... The starting location code is unchanged from all previous versions, except for some speed improvements which shouldn't be affecting anything. The code is actually specifically designed to ensure adequate food, moreso than on other maps or the original Cephalo version, thanks to Fuyu's update.

Meteors tend to eliminate almost all the land some of the time on smaller maps, so it can be hard for it to pick locations b/c it has to also try and keep the players from starting right next to each other. Please try it some more, either with meteors off or on larger map sizes.

I can try to figure out what's going on later but I don't have time to work on it right now. I know it works fine on Huge maps b/c I tested a ton of those. It's possible Andy's optimizations broke something, but I doubt it... I should probably force meteors to be off on Duel and Tiny, and maybe on Small, though.

Edit -- Ooh, and the upcoming Jungle change in 3.2.1 should help with this a lot, b/c right now, as I've said, it's still based on absolute temperature (which is how Cephalo always wanted it). If the only land on the map is all in the tropics, the Grassland component is going to be almost all Jungle as a result. On larger maps this isn't a huge problem b/c there's always at least SOME land everywhere just from the sheer size of the map, but I can see it potentially being a big problem here, heh. Whelp I was already convinced I should go ahead and release this change, but this is another good reason to do it. :)

OnmyojiOmn
Jan 24, 2012, 10:07 PM
You mean you don't clear jungle in starting spots? At all?

LunarMongoose
Jan 24, 2012, 11:07 PM
You mean you don't clear jungle in starting spots? At all?

It does clear them, and it also adds food resources, as needed to get up to a certain minimum required amount of food for a starting location. Again, this is not something "I" do or don't do; this is Cephalo's original starting location code, modified a little by Fuyu. I've never touched it. It's exactly the same as in previous versions.

(The only real difference in 3.2 is that Snow and Tundra are percentage-enforced, so you will still get some even if all the land is in the tropics. But as far as Jungle and Peaks go, the starting location situations should be no different than before.)

Heretic013
Feb 06, 2012, 01:35 PM
any way to change max map size?

Pojman
Feb 09, 2012, 07:46 PM
I know I am a noob but... Can someone explain to me how to enable this script? I have downloaded it, but I do not know how to make it work.

Thanks

[to_xp]Gekko
Feb 15, 2012, 02:17 AM
put it into Beyond The Sword/Privatemaps folder

Antmanbrooks
Apr 21, 2012, 05:18 AM
Hello, excellent map script for the record. I love it!

How easy would it be to make this map script add terrain features like swamps and scrub to grassland and desert respectively? I'm playing Realism:Invictus mod at the moment and within that mod they have swamps and scrub but as is to be expected these features don't get added to most scripts.

The mod comes with PerfectWorld and Tectonics as two of the most realisttic world generation scripts and I've added PerfectMongoose to the list in my version. For some reason Tectonics adds the above terrain features but this and PerfectWorld don't?

If it's easy enough can someone explain what I need to do and if it's a massive headache that requires a certain kind of upbringing then is there any kind souls out there willing to help?

Antmanbrooks
Apr 21, 2012, 02:28 PM
Hello, excellent map script for the record. I love it!

How easy would it be to make this map script add terrain features like swamps and scrub to grassland and desert respectively? I'm playing Realism:Invictus mod at the moment and within that mod they have swamps and scrub but as is to be expected these features don't get added to most scripts.

The mod comes with PerfectWorld and Tectonics as two of the most realisttic world generation scripts and I've added PerfectMongoose to the list in my version. For some reason Tectonics adds the above terrain features but this and PerfectWorld don't?

If it's easy enough can someone explain what I need to do and if it's a massive headache that requires a certain kind of upbringing then is there any kind souls out there willing to help?

Actually ignore this, I've just figured that you have realeased a PerfectMongoose_v321_MM_Edition as part of your MongooseMod. That seems to add scrub anyway and by replacing your FEATURE_MARSH for FEATURE_SWAMP it seems to work pretty well anyway! Do you mind if I introduce this to the Realism:Invictus team?

LunarMongoose
Apr 22, 2012, 07:46 AM
Oops, didn't see this, sorry. Re-posting my PM response, for the record:

Actually ignore this, I've just figured that you have realeased a PerfectMongoose_v321_MM_Edition as part of your MongooseMod. That seems to add scrub anyway and by replacing your FEATURE_MARSH for FEATURE_SWAMP it seems to work pretty well anyway!

Yep; my Marsh placement got a lot more advanced in the 3.2.1 update! But it wasn't posted publically til I FINALLY released MM 4.0 a month ago. It sucked that my biggest mod update ever (by far) delayed the release of the custom version of the mapscript for 3 months, b/c I thought it was awesome. :)

And to everyone else: don't worry, I'm still planning to release vanilla 3.2.1 here as well, I just haven't had time yet (and I wanted to give MM users first crack at it :p).

Do you mind if I introduce this to the Realism:Invictus team?

No, of course not... Only my more recent SDK code is sealed away in a deep dark vault of eternal silence and shadow. :p

I do have to make sure you give me a nice big credit mention though!

Cykur
Jul 22, 2012, 11:24 PM
Anyone have a copy of the Perfect Mongoose 3.2 script? I only have 3.1 and all the download links for Perfect Mongoose stuff seems to be dead. Hopefully Lunar Mongoose checks in some time, he did some great work tuning up the PW2 script.

kxta
Jul 23, 2012, 06:35 AM
Anyone have a copy of the Perfect Mongoose 3.2 script? I only have 3.1 and all the download links for Perfect Mongoose stuff seems to be dead. Hopefully Lunar Mongoose checks in some time, he did some great work tuning up the PW2 script.

I second this. The shutdown of MobileMe was announced a long time ago so I suspect it has been orphaned now, someone from the community will have to post on MediaFire or something.

vktj
Jul 24, 2012, 08:32 AM
I'll post Perfect Mongoose 3.2 (here called LM_PerfectMongoose) here. Heck, I'll do one better: Here is Perfect Mongoose 3.2 and every other map script I could find for Civ4.

The version of my own Totestra included in this zip file is an older one, and the zip file doesn't include the SandBar map scripts, but I have posted the latest Totestra in its thread and a link here on CivFanatics to the latest SandBar in its thread.

Also: The "SM-DOWN" and "SM-UP" files are not map scripts, but text files with the file size and RadioGatun[32] sums of all the other files.

- Sam

Cykur
Jul 24, 2012, 09:15 AM
Thank you so much!

kxta
Jul 25, 2012, 05:46 AM
I'll post Perfect Mongoose 3.2 (here called LM_PerfectMongoose) here. Heck, I'll do one better: Here is Perfect Mongoose 3.2 and every other map script I could find for Civ4.

The version of my own Totestra included in this zip file is an older one, and the zip file doesn't include the SandBar map scripts, but I have posted the latest Totestra in its thread and a link here on CivFanatics to the latest SandBar in its thread.

Also: The "SM-DOWN" and "SM-UP" files are not map scripts, but text files with the file size and RadioGatun[32] sums of all the other files.

- Sam

A gentleman and a scholar you is :D

LunarMongoose
Jul 28, 2012, 09:19 PM
I second this. The shutdown of MobileMe was announced a long time ago so I suspect it has been orphaned now, someone from the community will have to post on MediaFire or something.

Yes, I knew it was coming ever since they didn't renew my billing last fall and said they'd given me 6 extra months free b/c of the shutdown. Unfortunately, this is me we're talking about, so I pretty much ignored the problem until the day it was killed.

From there, I was playing Diablo 3 every waking second (which I badly need to get back to), then on to being sick for 3 weeks, then on to a frenzy of research about PC watercooling parts for the last 2 weeks so I don't screw up my new build with corrosion and ruin it.

It actually took a couple hours of research to track down all the free hosting options available and find out their exact rules about size limits, bandwidth, inactivity, etc - the info is not always made easy to find. I've settled on FileFactory for my really big files (MongooseMod is up on there now after 5 long-and-ultimately-failed upload attempts), and MediaFire for small files due to their friendlier inactivity policy (any file downloaded refreshes the timer on all of them, in particular). I should have those posted here in a bit.

And yes, I still owe you a slightly-bugfixed-and-updated version of this mapscript file, which should hopefully be soon since I have to work on my mod more too, and I've put my Civ obligations off as long as I can at this point. :p

Don't worry, I expect to still be around on this forum at the age of 100, just not necessarily all the time. :) Thanks for the compliment btw, Cykur!

tdfriese
Aug 01, 2012, 04:42 PM
Hi LunarMongoose - first let me say that this is a great port of a great script, the best out there in my book. Most importantly, it seems that the rainfall donut of PW2 has been fixed, leaving true tropical and desert bands.

Today I'm here with a problem to fix - one thing I keep seeing in my recent Realism Invictus games is the presence of stranded squares of jungle at the border between the subtropical plains and deserts.

I'm attaching a biome map below which shows that there is usually a slow transition from jungle to mixed savanna to arid grassland to full desert. This is particularly clear in the Sahel region of Africa.

World Biome Map (http://earth.rice.edu/mtpe/bio/biosphere/topics/biomes/biomes_map.html)

I don't have a good sense of how the script works, but my suspicion is that these areas at the edge of deserts have a high temperature but middling rainfall and somehow become jungle. In that case, the solution might be to raise the rainfall threshold for jungle slightly. I don't have screenshots with me right now, but I can bring some if you want me to.

Cykur
Aug 01, 2012, 09:17 PM
I haven't been able to download Mongoose Mod from Filefactory, after making me go through all the steps of waiting, it doesn't seem to make a connection to the download server. I'll try it again later at off-peak times, maybe it is just a temporary problem.

I tried out the PerfectMongoose v320 script that vktj was kind enough to upload, and after several tests it doesn't seem to generate any Marsh terrain. I tried both the PW2 & PW3 climate and land models a few times each but no Marsh.

I do see how v320 appears to create more defined climate bands. The maps are very nice. One small request if you should happen to ever update this script again; can you look into an option to reduce or smooth coastal mountain ranges?

vktj
Aug 03, 2012, 02:28 PM
can you look into an option to reduce or smooth coastal mountain ranges?

When I fixed this in my old Totestra.py script, this is what the code looked like. The code also eliminates mountain peaks with more than three adjacent mountain peaks.


#break up large clusters of hills and peaks
for y in range(mc.height):
for x in range(mc.width):
i = GetIndex(x,y)
if self.plotMap[i] == mc.HILLS and mc.smoothPeaks == 1:
allHills = True
for direction in range(1,9,1):
xx,yy = GetXYFromDirection(x,y,direction)
ii = GetIndex(xx,yy)
if self.plotMap[ii] != mc.HILLS:
allHills = False
if allHills == True:
self.plotMap[i] = mc.LAND
if self.plotMap[i] == mc.PEAK and mc.smoothPeaks == 1:
allPeaks = True
peakCount = 0
nextToOcean = False
#print "peak at %d %d" % (x,y) #DEBUG
# While we're here, let's eliminate seaside peaks
for direction in range(1,9,1):
xx,yy = GetXYFromDirection(x,y,direction)
ii = GetIndex(xx,yy)
if self.plotMap[ii] != mc.PEAK:
allPeaks = False
else:
peakCount += 1
if self.plotMap[ii] == mc.OCEAN:
#print "nextToOcean %d %d" % (x,y) #DEBUG
nextToOcean = True
if allPeaks == True or peakCount > 3:
self.plotMap[i] = mc.HILLS
if nextToOcean == True:
self.plotMap[i] = mc.HILLS


As a point of comparison, Cephalo's original PerfectWorld code:


#break up large clusters of hills and peaks
for y in range(mc.height):
for x in range(mc.width):
i = GetIndex(x,y)
if self.plotMap == mc.HILLS:
allHills = True
for direction in range(1,9,1):
xx,yy = GetXYFromDirection(x,y,direction)
ii = GetIndex(xx,yy)
if self.plotMap[ii] != mc.HILLS:
allHills = False
if allHills == True:
self.plotMap[i] = mc.LAND
if self.plotMap == mc.PEAK:
allPeaks = True
for direction in range(1,9,1):
xx,yy = GetXYFromDirection(x,y,direction)
ii = GetIndex(xx,yy)
if self.plotMap[ii] != mc.PEAK:
allPeaks = False
if allPeaks == True:
self.plotMap[i] = mc.HILLS


- Sam

LunarMongoose
Dec 08, 2012, 05:11 AM
Hi guys. Sorry for being awol/mia so long, the last year in particular has been kinda crazy for me. Also apologize for the FileFactory thing, it wasn't on purpose, I'll be moving all my files somewhere better pretty soon.

Interesting with the peak reduction code, vktj. I'll try it out. Thanks.

Main point of this post: As part of my latest big and overdue MongooseMod update (currently in 24/7 eat/breath/sleep-Civ4 development mode once again), I've been working heavily on PM the last week. Initially that was all about supporting the boatload of new terrain and feature types I'm adding in my MM-specific version of the mapscript (not copying C2C's PM code for the same content either, doing it all from scratch, and pretty sure I'm doing it better hehe).

BUT, I finished all that up two days ago, and now I'm trying to tackle something else that's been bothering me for a long time: rivers. Basically, there are two things I don't like about Cephalo's river code (which no one has ever updated since the early PW2 days afaik, btw): they're mostly very short with a few medium-length rivers at most, and they're always ultra-dense in the tropics and very, very sparse in most other parts of the map (no matter HOW low you set the RiverThreshold global).

These both stem from his fundamental design, which is based on his RainfallMap and his ElevationMap. Obviously connecting rivers to rainfall and geography is realistic, but imo it's not good for game balance to have anything other than an even distribution over the whole map. (Plus I really, really miss the super-long snaky kind that I used to have in my games many years ago.) The obvious solution is to switch back to the default normal vanilla river generator contained in the SDK code.

I've already tried this on PM, and it works, but the rivers are STILL a little sparse just in general (I guess that's vanilla's original balance though), they start on flatlands more often than I'd like, and they seem to cause fewer lakes to spawn (though I can probably compensate for that in the mapscript control globals).

I've spent most of the last two days trying to write my own river generator. The idea was to force it to always start in hills, peaks, or lakes, and always run to (other) lakes, or coast. As well as increase the overall density a bit versus the vanilla Civ4 generator. However, writing a full river system is actually pretty hard, and I didn't want to copy the vanilla code verbatim into Python because it's awfully long, lol. So I'm currently trying to decide if I should keep plugging away at my own code, start over and translate the SDK code, or just keep the vanilla system engaged and try to fix the lakes.

But I really think a system that starts in random locations (rather than rainfall-based to avoid ultra-dense river-tropics), and goes in random directions once started (rather than ElevationMap-steepness-based to avoid all-pipsqueak rivers) is better for gameplay, even if less realistic in principle. (In practice it's probably more realistic though, and I'm not sure how to bridge that gap, to be honest. I tried a number of variations on using the rain and height data already, and couldn't really make anything good come out of it.)

LunarMongoose
Dec 08, 2012, 07:25 AM
So I've looked at it more closely now, and it turns out the vanilla river generator isn't that long afterall... How they got it working so well with less code than I'd already written in my still-only-half-working version, I have no idea...

Anyway, that led me to discover the PLOTS_PER_RIVER_EDGE xml global. When boosted from its vanilla value of 12 to a nice sparkling 8, it produces results on PM that I'm VERY happy with. Plus Cephalo's lake code seems to be highly dependant on how many rivers were placed just prior in the AddRivers() function, so cranking that up fixed the lake situation automatically.

Would you guys be okay with me just distributing a single-entry xml global file with the next version? I could port the whole vanilla generator to Python and then make the change there, but I really don't want to bother, lol.

(The standard vanilla mapscripts do get a bigger increase from this change than PM does, but that's unavoidable given that they have larger and more uniform landmasses, and they still don't really feel "overloaded" on rivers.)

cephalo
Dec 09, 2012, 10:10 PM
One easy thing you might try is using a constant value for rainfall instead of using values from the rainfall map. That should be uniform and highly adjustable, while also accurately using the altitudes to guide the rivers. Then it all depends on just watershed size.

LunarMongoose
Dec 10, 2012, 10:12 AM
One easy thing you might try is using a constant value for rainfall instead of using values from the rainfall map. That should be uniform and highly adjustable, while also accurately using the altitudes to guide the rivers. Then it all depends on just watershed size.

Ooh, hi Ceph! Great to see you still around. :)

Yes, I did think of that, and it was one of the things I mentioned having already tried. It does even them out so you get equal numbers of rivers in all areas, but it still leaves them all being very short. They mostly bee-line straight to the nearest Coast tile, which is usually not far away b/c of the jagged non-uniform landmass shapes. Even on Huge (and above) map sizes, the longest you get are "medium" length at best, and they're not very snakey.

On PM I am ecstatically happy using the vanilla generator now with its density value increased, and can't wait to play again based on that. I did want to make it a map menu option for which river system gets used, but b/c of the way the vanilla SDK code calls Python code, that would require porting the whole generator to Python, heh.

(Technically there IS another way, a brilliant workaround hack I thought of ;): let the SDK code always do its rivers, then in the next Python hook function, if and only if the map option is set to use Python rivers instead, delete all the rivers from the map that were just placed, and do the Python ones. But given how much better the SDK rivers are for gameplay imo, I was leaning towards just doing that...)

LunarMongoose
Jan 18, 2013, 02:39 AM
Just a heads-up, in addition to the other somewhat-significant stuff I've already done (vanilla river option, absolute height option, new proximity code for Old World landmasses, slightly updated Oasis placement, meteors disabled on the smallest 3 map sizes regardless of setting), I'm currently working on a full bugfix-slash-major-improvement update of the Player Starting Location Code.

No offense to Cephalo (b/c his mapscripts themselves are wonderful and amazing and I honestly couldn't live without them :worship:), but his still-in-use starting plot code from PW2 is really, REALLY awful, lol.

Already I've found two CRITICAL bugs, two MAJOR bugs, and several minor bugs with it, as well as there being a LOT of room to add missing or enhanced functionality. I haven't tested it yet b/c I'm only half done so far, but I think it's safe to say it should be working at least slightly better pretty soon. ;)

The Vanilla Edition™ of PM v3.3 will be released as soon as I'm done with the big MongooseMod 4.1 update I'm still working on. I currently expect to have THAT out around next Weds (Jan 23), give or take, so allow an extra day for this. :)

LunarMongoose
Jan 20, 2013, 11:45 AM
Whelp, as usual, the Mongoose emerges from the Dragon Cave battered, beaten, scarred, and a little singed... but victorious. :viking:

* Fixed a HUGE number of bugs in getPlotPotentialValueUncached().
* Added a HUGE number of missing evaluations (and modified a large number of existing ones) in getCityPotentialValue() and getPlotPotentialValueUncached(), which should now be pretty much perfect.
* Rewrote the player assignment code in SetStartingPlots() from scratch so it scales proportionally instead of only adding and removing players from the largest landmass til it hits the right number, AND did it directly with floats instead of an iteration-based refinement loop. (Okay so technically I still have one, but it's not the MAIN loop any more! :p)
* Allowed starts on very small islands, but added detection for being Coast-linked with other landmasses to form a "region", which must meet a higher minimum size requirement.
* Blocked starting locations that are walled-off by Peaks into very small areas.
* Blocked starting locations on terrain/features that don't allow city founding.
* Took the corners off the PlotList Eatery™ Bar and Grill.

And yes, it works pretty darn well now. :D

(So much so, in fact, that my attention has suddenly turned to the SDK city location evaluator, since it keeps making the AIs found their first cities on worse tiles right next to my perfect mapscript-selected ones, lol. Unfortunately THAT function is much more complicated...)

This was SUPPOSED to be a quick update, which I had originally budgeted only "a few hours" for, lol. Well, 3 full days of work later, I'm finally happy with the results. The delay will push the release back a few days, but I'm working as fast as I can... Keep an eye on MongooseMod 4.1 for an idea of my schedule, hehe.

Farsight
Jun 14, 2013, 12:53 PM
The download doesn't seem to be working. :(

The_J
Jun 14, 2013, 02:42 PM
See further up the site ;).

I've now updated the entry in the download database with that link.

TheLadiesOgre
Jun 29, 2013, 05:54 PM
Just a heads-up, in addition to the other somewhat-significant stuff I've already done (vanilla river option, absolute height option, new proximity code for Old World landmasses, slightly updated Oasis placement, meteors disabled on the smallest 3 map sizes regardless of setting), I'm currently working on a full bugfix-slash-major-improvement update of the Player Starting Location Code.

No offense to Cephalo (b/c his mapscripts themselves are wonderful and amazing and I honestly couldn't live without them :worship:), but his still-in-use starting plot code from PW2 is really, REALLY awful, lol.

Already I've found two CRITICAL bugs, two MAJOR bugs, and several minor bugs with it, as well as there being a LOT of room to add missing or enhanced functionality. I haven't tested it yet b/c I'm only half done so far, but I think it's safe to say it should be working at least slightly better pretty soon. ;)

The Vanilla Edition™ of PM v3.3 will be released as soon as I'm done with the big MongooseMod 4.1 update I'm still working on. I currently expect to have THAT out around next Weds (Jan 23), give or take, so allow an extra day for this. :)

I hope everything is alright with you LM, I've been hoping and waiting patiently for PM 3.3 for a while now. Do you still plan on releasing it? Any insight would be much appreciated.

TheLadiesOgre
Aug 14, 2014, 03:54 PM
Bump for my favorite Mapscript

vktj
Aug 14, 2014, 11:30 PM
The good news is that there is an update for Perfect Mongoose which was released in January of 2013. The bad news is that you need to load the Mongoose Mod to use the map script. Adapting it to work with BTS 3.19 is left as an exercise to the reader (probably involving removing any and all references to PM terrain, map sizes, etc.)