FlavourMod 2

That's right, but we can try. :)

The best thing someone could do would be to infer the humidity for each tile from the map we we see in front of us, when we play the game. One could assume a west wind, ocean currents etc affecting the climate, but to be honest, that's all rather complicated.

I propose a much simpler system with only four or 3 levels of humidity which I would simply base on the plot's terrain at the beginning of the game. I would assume 0 for Desert and Ice, 1 for Plains and Tundra, 2 for Grass and 3 for Marsh. The transitions, if you change the tempereature would look like this then:

0: Desert <-> Ice
1: Desert <-> Plains <-> Tundra <-> Ice
2: Desert <-> Plains <-> Grass <-> Tundra <-> Ice
3: Desert <-> Plains <-> Marsh <-> Tundra <-> Ice

This system would allow me to sneak in Marsh again and take care of most of problems mentioned in the latest posts. What do you think? Should I merge humidity level 0 into humidity level 1 (sounds reasonable to me).

I like it, but would keep level 0 and 1 separate. Seems to me that it would be easier to track what it should revert to that way, if nothing else.
 
More information on the new mechanic for the Illians:
The climate system allows the Illians to transform their territory automatically from any kind of terrain to snow. But they are not allowed to transform anything immediately. It will taky significantly more time to transform a desert into snow than tundra into snow for example, because you have to go through all climate levels in between first: Desert -> Plains -> Grass -> Tundra -> Snow. The plot you see in the screen shot below already went from Plains to Grass and is going to be Tundra soon. If the Illians lose territory this process reverses itself and the originally terrain will be restored over time.

I'm assuming this required an edited DLL? Would be nice if it was all python. :lol:
 
I'm assuming this required an edited DLL? Would be nice if it was all python. :lol:

Almost all the logic is in the dll and I'm certainly not going to make a Python version. Saving and managing data is so much easier with C++ than with Python. Only one little code snippet is done in Python and that's a triggered method. If the terrain of a plot changes because of a changing climate this method will be called. I'm currently using it for adjuasting the plot features to the new climate. You can find it in CvFlavourInterface.py. Its name is onClimateChange.
 
FlavourMod is my personal playing field for trying new stuff. I'll have to ask the other Fall Further team members first, before I start merging it with FF, but I suppose there won't be much objection, if it is working without too many quirks. I want to finish the humidity part first though and unfortunately I won't have the time before next week to do so. So please be patient. :)
 
That's right, but we can try. :)

0: Desert <-> Ice
1: Desert <-> Plains <-> Tundra <-> Ice
2: Desert <-> Plains <-> Grass <-> Tundra <-> Ice
3: Desert <-> Plains <-> Marsh <-> Tundra <-> Ice

This system would allow me to sneak in Marsh again and take care of most of problems mentioned in the latest posts. What do you think? Should I merge humidity level 0 into humidity level 1 (sounds reasonable to me).

I think level 0 is redundant. Otherwise it is ok, but a simpler method below would do, too:
desert <> (variable) <> tundra <> ice

where variable is grass/marsh/plains, depending on the starting terrain. If it was desert/tundra/ice , the default variable is plains.

I have problem with marshes in general, as these are less dependant on climate (be it temperature or humidity), but rather on relief (topography) and rivers. Even in desert areas you get places like Okavango Delta or Faiyum Oasis. Maybe it should turn to flood plains when warmed (or not change at all). Changing to tundra seems acceptable (peat bog feature anyone ;) ?)

Adit: Forgot to check the post, was opposite to what I wanted to say (lvl 0 not required...)
 
Is it possible to allow flavor values to be given for specific other Civilizations? Make it likely for the Bannor to start near the Clan, the two elven factions to start near one another, etc...? Could make it interesting to have semi-lore appropriate neighbor arrangements (obviously this would frequently conflict with the terrain based flavor, so in some cases the Lore would have the higher preference, and in others the terrain.
 
Does this not work with the newest (0.41) version of FfH2? Seems to result in a whole lot of XML errors.

Playing without fitting starting positions feels so... wrong.
 
Does this not work with the newest (0.41) version of FfH2?

No, it doesn't and unfortunately I won't have the time to release an update before the end of next week. There is a big exam approaching ... :scared:

PS: The work on the new promised climate system is reaching a point where I can start thinking about releasing a beta. Every plot has now a temperature and precipitation level which determines, which kind of terrain you'll get. Works pretty well. Scorch doesnt change the terrain type directly any more for example, it just increases the plots temperature by one level. Civ then decides automatically, if the terrain needs to change.
 
I checked the files (not the DLL yet) but I couldn't find how you get "Climate unnaturally cold!" to show when hovering a plot. I searched references to the TXT_KEY in the python files but there wasn't anything. I guess it's in the SDK then... is it?
 
Thank you :)

I guess adding that kind of text when hovering a tile needs to be done in the DLL? Say, if I wanted to add any other text in the same fashion, I would have to do it by the DLL instead of python?
 
I found out I still had some ancient FfH mapscripts which somehow do work with the new version, which should tide me over.

Eagerly awaiting for this mod, though. The climate system sounds almost Dwarf Fortress level insane-awesome in its detail. :D
 
Any idea of what is causing this error?
Code:
Traceback (most recent call last):

  File "CvFlavourInterface", line 457, in generateFlavour

  File "CvFlavourInterface", line 682, in assignFlavourfulStartingLocations

  File "CvFlavourInterface", line 612, in __getCivProfitMatrix

  File "CvFlavourInterface", line 1340, in evaluateStartingPlots

  File "CvFlavourInterface", line 1381, in evaluateStartingPlots

  File "CvFlavourInterface", line 1475, in getYield

TypeError: unsupported operand type(s) for *: 'int' and 'NoneType'
ERR: Python function generateFlavour failed, module CvFlavourInterface

Edit: Well, after a bit research, it seems that
Code:
iYield += int(max(iYieldChanges) * GetBonusRevealEraWeight(gc.getTechInfo(eTech).getEra()))
is trying to do a multiplication with an integer and a "noneType". I guess it's GetBonusRevealEraWeight which is not working correctly.

Edit2: Okay, I know where is the problem:
Code:
def GetBonusRevealEraWeight(iEra):
	if iEra == gc.getInfoTypeForString("ERA_ANCIENT"): 
		return 3/3
	elif iEra == gc.getInfoTypeForString("ERA_CLASSICAL"):
		return 2/3 
	elif iEra == gc.getInfoTypeForString("ERA_MEDIEVAL"):
		return 1/3
Orbis is using another era. I'll try to understand what you've done here and I'll see how to repair that.

I did that:
Code:
def GetBonusRevealEraWeight(iEra):
	if iEra == gc.getInfoTypeForString("ERA_ANCIENT"): 
		return 4/4
	elif iEra == gc.getInfoTypeForString("ERA_CLASSICAL"):
		return 3/4 
	elif iEra == gc.getInfoTypeForString("ERA_MEDIEVAL"):
		return 2/4
	elif iEra == gc.getInfoTypeForString("ERA_RENAISSANCE"):
		return 1/4
I'll test to see if it works.

I think this bug prevented some civs (all?) to begin in a flavourful area.

FinalEdit: Seems to work! :goodjob:
 
Congratulations for fixing the bug. :)

I had to do something similar for Fall Further, because it also adds one more era. The weights are there to prevent the yields from bonuses which won't be revealed till late in the game to have the same influence on the starting plot choice as the yields from a bonus which is available from the get go.
 
:blush:

The bug is mine and did not have much to do with the flavour mod.
I did not know that I have to update it when adding a new era.

But anyway, thanks a lot for finding and fixing it Opera. :)
 
:blush:

The bug is mine and did not have much to do with the flavour mod.
I did not know that I have to update it when adding a new era.
At first, I thought it has to do with the FlavourMod, since it was bugging in CvFlavourInterface. But then, I discovered the Truth! That's why I posted here first... I should have searched before posting, in fact :lol:

But anyway, thanks a lot for finding and fixing it Opera. :)
You're welcome ;)

Jean Elcard said:
I had to do something similar for Fall Further, because it also adds one more era. The weights are there to prevent the yields from bonuses which won't be revealed till late in the game to have the same influence on the starting plot choice as the yields from a bonus which is available from the get go.
Thanks for answering :)
 
Version 2.7.3 changelog:
  • Change: Compatibility to Fall from Heaven 0.41a
  • Change: Installer now copies FfH first before it applies its changes.
  • Change: Removed the Unaltered Gameplay version.
  • Add: Optional Desktop Shortcut
  • Add: Uninstaller
Download link in the first post.

The promised new climate system will have to wait. Sorry. I'm constantly without time lately. That's also the reason why there is no unaltered gameplay version available in this version. Will have to decide, if it's worth reintroducing it. The new installer should prevent some issues we had in the past. Every new installition will be a clean one and your original Fall from Heaven stays unchanged, if you install FlavourMod. Have fun.
 
Top Bottom