flavour map script(s)

dreiche2

Prince
Joined
Apr 9, 2003
Messages
320
Ok folks I updated the code for FfH 0.2. I removed everything but the flavor aspect. And, I put all the code into a separate module, which makes it very easy for anyone to create their own "flavor" version of a map script. Just put the module file into the PublicMap folder and import it into a map script by adding some lines of code (actually just one line that does something, rest is comments... see below for the details.).

This also means there is one central file you can edit to change the flavor settings to your liking, and this will affect all scripts where you imported the module. For those that are reluctant to modify scripts themselves I attached examples of modified scripts.

From the module:
FILE: FfH_flavor_mapmod.py
VERSION: 3.00
AUTHOR: David Reichert (dreiche2)
PURPOSE: For the Fall from Heaven (FfH) mod: Have civs start in regions that match their flavor.
DESCRIPTION:
This module can be used in conjunction with other map scripts. It redistributes the original starting locations among the civs according to FfH flavor, i.e. Ljosalfar (elves) get a location with many forests, Lanun ("pirates") get a coastal start etc.

Note that this module does not change the map itself, and only uses the starting locations assigned by the base map script. Hence, if there are no forests on the map at all, the elves won't get any, either. So there will only be a tendency (albeit a clear one), no guarantee that all the relevant civs have 'flavory' staring positions. An advantage is that this module minimally interfers with what the map scripts does.


USAGE:
It is very simple to use this module in a map script of your choice (e.g. the default continents script). Just copy this file into the <civ4>/PublicMaps folder, and then open the map script file (e.g. Continents.py) with a text editor and copypaste the small code block below this paragraph into the script (preferably at the top), and uncomment the 'import' line by removing the '#'. Of course you're advised to backup the map script and rename your modified version to something like "FfH_whatever.py" so that you don't confuse the various versions. You can modify the flavor settings to your liking, see SETTINGS below.

Code:
## copy below, remove '#' in 'from...import' line.

###############################################################################
# This map script was modified to use the Fall from Heaven flavor map module. #
# See FfH_flavor_mapmod.py for details.                                       #
###############################################################################

#from FfH_flavor_mapmod import normalizeStartingPlotLocations

###############################################################################

## copy above

COMPATIBILITY
The flavor module should work with most map scripts. It uses the normalizeStartingPlotLocations() function, hence civ does not use its default implementation. That means that members of a team are no longer placed close together as by default.

A conflict occurs if the map script itselfs implements normalizeStartingPlotLocations(), though only few do. If that's the case you can simply remove/comment out the relevant code in the map script, although of course you remove any functionality that was implemented there.

SETTINGS
List of civs with preferred starting spots:

Malakim: desert
Lanun: coastal start
Ljosalfar: forest
Luchuirp and Khazad: hills
Doviello: tundra
Illians: tundra (low priority)
Hippus: like: grass, plains; dislike somewhat: hills, forests

Note: It should be easy to modify the settings to your liking, and add new flavor civs. Just look at the code below. Everything relevant happens in normalizeStartingPlotLocations().

So, here comes the module. Place this in your PublicMaps folder, then add the 'import' code block to the map script of your choice...

View attachment FfH_flavor_mapmod.zip

To get you started, here are some already modified versions of popular map scripts. Remember that essentially only one line has to be added, so it's really not complicated to do it for other scripts. Of course, credit for the map scripts themselves goes to the corresponding authors...

NOTE: just to make it clear, you need both the module file and the modified map script!

View attachment FfH_Fractal.zip

View attachment FfH_Lakes.zip

View attachment FfH_SmartMap.zip (SmartMap script by surt, version 9.1, see http://forums.civfanatics.com/showthread.php?t=154989)

View attachment FfH_Tectonics.zip (Tectonics script by LDiCesare, version 3.9, see http://forums.civfanatics.com/showthread.php?t=149278&page=5)

FfH_pangea.zip
 
Making the Malakim look for desert seems pretty crippling, because desert alone doesn't do anything for them (just gives them defense bonus I think). Maybe you should search for oasis/flood plain tiles.
 
Well, first of all, like I said this script is more for flavour than balance ;)

But, what you said actually isn't a problem here: The script only takes into account the starting position already determined by the base script, and these spots were selected because they are good starting positions... Basicallly, from the good starting positions, it selects that with the most desert around (for the Malakim).

Still, a 'good' desert start might still differ in quality from a 'good' grassland start, but it shouldn't be so much of a difference.
 
As someone who primarily plays Malakim, I have to say that starting in the desert might actually help me out.

1) If flood plains are counted as deserts, then that should start me right where I'd normally prefer to be.

2) It only selects starting locations that have already been picked, right? In that case, all the surrounding tiles will be workable anyway. So, no fear of deserts encroaching on the capital's radius.

3) Malakim units with one move get two when in the desert. That, combined with the defensive bonus, combined with the defensive penalty for others, means that I'll have a substantial military advantage against the barbs.

I look forward to trying this out. I'm glad someone has taken the time to attempt to do this! :thumbsup:
 
yeah, now that I started looking into it I have to say doing some more modding on your own becomes really tempting... if it wasn't for that 'real life' obligations :(

I wished civ 4 came out some years earlier, the possibilities are really great.. but whom am I telling this, we all know FfH, after all...:)
 
Great idea ... and implemented on my favorite generator to boot. Definitely worth the test drive! :goodjob:
 
A little thing : normalizeStartingPlotLocations is made to have a minimum path distance between 2 civs . So overriding it may cause some civs to start closer ( default implementation use a fix value minStartingDistanceModifier at the assignStartingPlot that may cause some civ to start close each other ,in function of the land generated by the script ) . you may start def normalizeStartingPlotLocations() with :

Code:
def normalizeStartingPlotLocations():
        #default implementaion
        CyPythonMgr().allowDefaultImpl()
	#reallocation
	NiTextOut("Redistributing starting positions (FfH_fractal) ...")

So the default implementation is launched and then your reallocation is taken in count (but i've made no test ... so you should make one . sometimes allowing default implementation and then make some changes doesn't work ).

Tcho!

edit : sorry , i was wrong ! normalizeStartingPlotLocations is made to place teams ... so you shouldn't put default implementation . that's depend on your priority : have a starting location that match with civ or teams that start close .
 
well, I was just about to post my answer but now I saw your edit :)

Thanks for the comments anyway. Yeah, I imagine the default implementation does something similar like my script, i.e. it redistributes the starting locations determined beforehand in order to place team members close together. So yes, this functionality is currently removed. Though I also wonder why this is the default behaviour anyway and not some kind of option...

Speaking of default implementations, it would be easier if those where available in python, then I could reuse the code (though in this case it wouldn't be that hard to re-implement the functionality).

Btw, my original idea was to modify assignStartingPlots(), and let the default implentation handle it before redistribution happened, similar to what you suggested. But a call to

CyPythonMgr().allowDefaultImpl()

didn't seem to do anything, after that the starting plots were still not set. So maybe that line doesn't really do something apart from telling some "Python Manager" that it can use the default c++ implementation, but not necessarily at this point in time (probably c++ takes over after the python function is processed, and only then the starting plots will be assigned, before the next Python function is called...).

Though, even if I used assignStartingPlots(), I'd still have to override assignStartingPlots() to stop it from interfering with my allocation. The current method actually has the advantage that is should be easy to add the code to other scripts, cause most don't mess with assignStartingPlots() (or have only a dummy implementation). Maybe I'm going to add that team functionality later, on the other hand, like I said, I wonder why it's like that per default anyway...
 
just for info :

dreiche2 said:
Yeah, I imagine the default implementation does something similar like my script, i.e. it redistributes the starting locations determined beforehand in order to place team members close together. So yes, this functionality is currently removed. Though I also wonder why this is the default behaviour anyway and not some kind of option...

you're right , this is exactly what it does . But this is an option by itself because you can override it and only works for teams , i think .

dreiche2 said:
Btw, my original idea was to modify assignStartingPlots(), and let the default implentation handle it before redistribution happened, similar to what you suggested. But a call to

CyPythonMgr().allowDefaultImpl()

didn't seem to do anything, after that the starting plots were still not set. So maybe that line doesn't really do something apart from telling some "Python Manager" that it can use the default c++ implementation, but not necessarily at this point in time (probably c++ takes over after the python function is processed, and only then the starting plots will be assigned, before the next Python function is called...).

But i use CyPythonMgr().allowDefaultImpl() in my scripts and i think the problem is not that the function is called after python ( i'am sure there is no switch of functions by using CyPythonMgr().allowDefaultImpl() a lot of time ) .I think the problem is that when you have an entry point in python (especially with mapscripts) , you are only able to change a specific set of variable . So calling CyPythonMgr().allowDefaultImpl() may close changes made after in python . But i'm not sure of that , i try to learn C++ especially to understand that ( i've got some wreid thing trying to add unit during map generation and this is the most obvious for me )

anyway , your function is the best way to change starting locations without changes into assignStartingPlots() :goodjob:

Tcho !
 
well, I rather come from the c/c++ corner... but if I now start with all that fancy SDK stuff, my real life is going to kill me... uh...:crazyeye:
 
Here I was so eager to try this out, then I remember that I have no idea how to use custom map scripts. I put it in the _Civ4CustomMaps folder, but the game crashes when I try to start up a custom game with it. Am I doing something wrong?
 
Well, that's interesting. After shuffling it about my folders for a bit, it works fine. So, no issue there.

Played as Varn, and only had two floodplains in the workable radius. However, there's a big desert to the NE. Seems that this also checks for the terrain surrounding the starting location, very important. I'll play this one through, then try some of the others. Until then, maybe we ought to brainstorm for what terrains other Civs might start in?
 
As far as I know it should simply go into the public maps folder in the civ4 directory. At least it seems to work that way.

Yes, it simply checks a square shaped region from the center tile, currently 6 tiles in in every direction, if I remember correctly (you can actually easily change that value in the script, you find the parameters near the top). Furthermore, the script values plots in a somewhat closer vicinity higher.

Often you end up near a desert instead of in one, which is ok with me. It adds some variety. If you really want to check if the script works you probably have to open up the world builder and compare the starting positions. I think the effect is least visible with the dwarves, because hills usually don't appear in big clusters.

Now, personally I wished there was a map script that more often produces big mountain ranges, large forests etc.

Like I said, if anyone has a favourite map script and wants this feature add it, tell me...
 
I'm in the middle of playing a Malakim game (not the one I started first), and I'm really satisfied with how it turned out. I never played fractal in the past, only continents and pangaea, but I think it's a much better generator. It dropped me in the middle of some floodplains and a little grassland, with bits of pure desert scattered outside to speed my warriors. It works out very nicely. I might even suggest Kael incorperate it into the main download.

Edit: this just occured to me- is it possible to also base starting locations off resources? I'm thinking Khazad starting by gems/gold, Amurites by mana, etc.
 
In principle, yes. However, with the current method you only get to choose from as many starting positions as there are players, so depending on that it might be unlikely to actually find a position with all the nice things around.

Btw, the more intuitive way of doing it would be considering the civs while selecting the possible starting locations in the first place, but then you basically have to reimplement the whole procedure that determines good locations, which is way more complicated, and often has to look different depending on the base script (e.g., archipelago uses a different algorithm for that than fractal, smartMap another one, etc.).

Finally, it would be rather easy to simply drop some additional boni around the civ after the flavour positions are selected. But then it becomes more of a balance issue (and, well, maybe you actually don't want to always start near the same ressources, even if you do want to start in a matching terrain...).

So the way it is now it is kind of a compromise. It creates a tendency, but the outcome is not that predictable.
 
well, it's not that much a question of 'precision', after looking into the code I'd say almost everything is possible, in theory. It's rather a question of effort. And for that I'm pretty satisfied with the result, especially if you actaully do want a soft option instead of fully forced one.

If I had the time, I'd rather look into fortresses next, or modify the tectonics script, or something like that.

Btw, I also have a modified smartMap version ready to upload, however I'm waiting for a OK by the creator.

So, what about other civs? Are the Illians Tundra lovers?
 
Ok, I wanted to wait until the author gives his ok, but it remains pretty silent in the map scripts forum. So before it starts decomposing on my hard drive I'll post it now:

I updated the first post with a modified version of the SmartMap script.
 
nice work! :D

i was wondering one thing though, do teams work with this? i seem to remember something stated about that to the contrary, and when me and chand played a team game as lanun and malakim we ended up on different continents for the FfH fractal map
its not horrible or anything, and i imagine its hard to get manage all the optimals with teams in mind, but figured id ask :p
 
Top Bottom