Mod-Modders Guide to Fall Further

Using those brackets tells the computer "This is all really just 1 line of code, I promise!", if what you wrote really IS just 1 line of code, then you don't need them at all.

Thanks - learned something new.

I'm wondering about something else. I've read that Fall Further has a hell version of coast. Unfortunately I can't check myself how it looks in-game: I don't have FfH 2.34 anymore, and copying it over FfH2.40 gives some weird results: blackwater and blighted coast uses the hill and peak textures.

So I'm wondering, can you tell me if/how you have managed to make two coast terrains show up without conflicts? When I was experimenting with having two coast terrains, I got some rather bad results:

image removed
 
I'm pretty sure the issue you are seeing is still present in FF, but the darker colors just make it a bit more subtle.
 
So I'm wondering, can you tell me if/how you have managed to make two coast terrains show up without conflicts? When I was experimenting with having two coast terrains, I got some rather bad results:

I'm pretty sure the issue you are seeing is still present in FF, but the darker colors just make it a bit more subtle.

Aye - the FF version still isn't perfect, but I think it's a little closer to working than the screenshot. In Civ4ArtDefines_Terrain.xml, there's a field called "LayerOrder". From the screenshot I'm guessing that the new coast has this set to 50, same as the old coast? Dropping it down to 49 helps a little with the blending (but as Magister mentioned, doesn't seem to completely resolve it - I think the actual layout of the texture tiles needs a little work for that).
 
From the screenshot I'm guessing that the new coast has this set to 50, same as the old coast?

Nope, the layerorders were different. Layer order doesn't solve the problem. On that screenshot the trench (darkest blue) layer order seems to be the lower than the shelf layer order, with as consequence that the coastal sand part of the shelf texture extends over trench plots. Switching layer orders would also just switch the problem: trench coastal sands being displayed over shelf plots.

I don't know any graphical artists willing/able to do this, but perhaps you might, so I thought I'd throw out the idea: (I can only profit from it myself if you like it ;))

I had the idea that instead of terrain types, trenches (or in your case hell versions of ocean and coast) could be a feature type. They would then require nif files. The nif file culd be a flat coloured plane, of only minimal height/Z-axis, so that the nif would cover up the terrain textures, but still look completely flat.

One nif for all trenches/hell water would look bad though. There would be a sudden colour transition etc. Perhaps the icepack nif could be an inspiration. The icepack XML can be copied for trenches/hell. This would create some variety in trench connections, and there wouldn't be a straight line seperating trench/hell from ocean/non-hell. The dds could be the trench/hell colour of the current terrain textures, including at the side of the dds some colour transition from the trench/hell to ocean/non-hell colours.
 
I think that this MIGHT be all the new fields added since 043:
  1. CIV4LeaderHeadInfos.xml
    1. <Images> & <DefeatQuotes> - These tags are used to display the pop-up when you defeat a leader without the requirement of specifying each leader seperately in Python

  2. CIV4BuildingInfos.xml
    1. <PrereqTeamBuildingClassANDs>, <PrereqTeamBuildingClassNOTs>, <PrereqTeamBuildingClassORs>, <PrereqGlobalBuildingClassANDs>, <PrereqGlobalBuildingClassNOTs> & <PrereqGlobalBuildingClassORs> - These can list any number of buildingclasses and any number of each of those as a prereq (or limit) for construction of another building. Formatting is the same as <PrereqBuildingClasses> (which depends only on the buildingclasses that the player himself owns, if you wonder how that is different than the new TeamANDs field)

  3. CIV4CivilizationInfos.xml
    1. <bLimitedSelection> - Setting this boolean forces all UnitClasses to be initialized as NONE for this civilization, the only units they will have access to are those you specifically allow them by stating the normal UNIQUEUNITS area.

  4. CIV4GoodyInfos.xml
    1. <BarbarianCivilization> - Specifies which Civilization the units listed in BarbarianClass will spawn for. During validation of CvPlayer::canReceiveGoody it will not allow this goody type if you are at peace with this civilization

  5. CIV4HandicapInfos.xml
    1. <iUnownedWaterTilesPerGameAnimal> - XML exposed control for how many tiles of a water area are required unowned/at peace with animals for an additional animal to spawn. Previously the game just divided the BarbarianWater field by 5 or something like that, so it was hard to tweak how many Serpents/Tortoises you got
    2. <iAnimalEscalationTurnsElapsed> - Combines with a new Global Define (MAX_ANIMAL_ESCALATIONS) to control the automatic strengthening of units belonging to the Animal Civilization. Every turn multiple of this number after birth the animal unit will gain a point of strength, up to the defined limit (So if you leave an elephant alive too long, he'll be even harder to take down, but even more worthwhile when you make him into a war elephant)
    3. <iLairSpawnChance> - Discarded field, lair generation mechanism was revised and I forgot this field existed. So till it has a purpose it is a nice "blank" which mod-mod-modders can use for their own designs (since it is python exposed)
    4. <iLairsPerCycle> - Each Lair cycle (determined by new field in GameSpeedInfos) this is how many new lairs will attempt to spawn on the map. In general this many WILL spawn, but it is possible if all land is claimed and nobody is at peace with any Barbarians that there won't be any new lairs at all
    5. <iPercentDemonsPerUnownedEvilPlot> & <iDemonGlobalCountSpawnBoostInterval> & <iDemonGlobalCountSpawnBoostRate> & <iDemonSpawnRateGlobalCounterEnhancementPercent> - Controls for spawning of Demons. Demons only spawn in Hell Terrain (well, in tiles with a Plot Counter over 9, so also in Ice and Tundra), the number of demons allowed to spawn is controlled by the number of evil (hell) tiles in the world (just plain unowned tiles don't matter, and it doesn't matter if they are owned or not). The PercentPerEvilTile is inflated by the BoostRate for every multiple of the BoostInterval of the current AC (at higher difficulty levels, this means that when approaching 100 AC you will wind up with a max limit of demons in the area which is MORE than 1 per Hell tile). The EnhancementPercent increases how many of the "missing" demons from the max allowed will spawn per turn. By default it is 1/8 of the missing demons that spawn, and on Settler you won't change from this value much. On deity, somewhere around 85 AC you begin respawning ALL demons which are allowed in the area every turn (ie - Deity Armageddon probably hurts. Lots. Unless you have Pax Diabolis...)
    6. <iDemonGlobalCounterFreeXPPercent> - Percentage of the AC which is granted as free XP to every demon civilization unit upon spawning. This is in addition to any free XP for all AI civs due to Kael's Handicap settings.
    7. <iDemonPerTurnKnownTechsPercent> - Each turn, for every player who knows a tech that the demons do not have, they gain this percentage toward knowing it themselves. ie - If set at 10, and only 1 player knows the tech, the demons will gain that tech 10 turns later. If that player immediately traded the tech to 4 other players, then the demons will know the tech within 3 turns (gaining 50% rounded down each turn, so if the beaker cost is an even number they'll know it in 2 turns). Techs are the primary control over what type of units the demon Civilization will spawn
    8. <iDemonBonus> & <iAIDemonBonus> - Bonus that the Human and the AI gain against units from the Demon Civilization. It should be noted that the corresponding field for Barbarians applies to the Orc Savages only, and that the Animal bonus now applies to the Animal Civilization and NOT to units marked with bAnimal.

  6. CIV4VictoryInfos.xml
    1. <LinkedVictories> - Victories specified in this field cannot be selected at the same time as this victory (they can all be turned off, but turning this one on turns the others off automatically). This is mainly just so that the F8 Victory Progress screen doesn't waste your time by listing multiple possible Religious Victories when one of them is obviously going to happen before any of the others (due to having lower settings)

  7. CIV4ProjectInfos.xml
    1. <ForcePeaceWithCivilization> - If the Civilization listed in this field is in the game, it forces peace with them. This is meant for use with the Barbarian Civilizations, but can be used on other Civilizations as well if one really wanted to. Setting this field also means that you MUST be at war with some player of that Civilization type in order to perform the ritual

  8. CIV4GameSpeedInfos.xml
    1. <iTurnsPerLairCycle> - Specifies the number of turns which must elapse between each Lair Cycle, at which point the HandicapInfos field controls how many lairs will attempt to spawn throughout the map

  9. CIV4TechInfos.xml
    1. <BonusCostShifts> - Adjusts the cost of the technology based on Bonuses (Resources) which the player has access to. Number listed is directly added to the cost of the tech
    2. <TechCostShifts> - Adjusts the cost of the technology based on Technologies which the player has learned. Number listed is directly added to the cost of the tech
    3. <BonusCostMods> - Adjusts the cost of the technology based on Bonuses (Resources) which the player has access to. Number listed is multiplied as a percent value adjustment of the TechCost (plus any Shifts). By default this field is 100, listing a lower value makes the tech cheaper, listing a high one makes it more expensive.
    4. <TechCostMods> - Adjusts the cost of the technology based on Technologies which the player has learned. Number listed is multiplied as a percent value adjustment of the TechCost (plus any Shifts). By default this field is 100, listing a lower value makes the tech cheaper, listing a high one makes it more expensive.

  10. CIV4ImprovementInfos.xml
    1. <SpawnUnitCiv> - Specifies which Civilization the unit listed in SpawnUnitType will spawn for. Assuming that Civilization is in the game (intended for use with Barbarians, can be used with other civilizations as well though, but then it must be combined with bSpawnOnlyForOwner
    2. <bSpawnOnlyForOwner> - Prevents the units the improvement spawns from being spawned unless the improvement is owned by the appropriate Civilization (For Barbarians this means unowned, or the owner is at peace with the Barbarian Civ)
    3. <iSpawnPerGameLimit> - Improvement is unable to spawn more than this many units per game. If the improvement is removed and rebuilt, the counter starts over
    4. <iSpawnAtOnceLimit> - Improvement is unable to spawn more than this many units at once time. If the improvement is removed and rebuilt, the counter starts over. Can be combined with iSpawnPerGameLimit if desired (ie - AtOnceLimit of 1, and PerGameLimit of 5 means that each time the unit is killed the lair is allowed to spawn another one, but after 5 have been killed it never spawns again, till rebuilt elsewhere, or destroyed/rebuilt in the same time)
    5. <bExplorable> - Tells any unit on Automated Exploration to stop at this tile and wake up (request user input). Also makes them desire to move to this tile like it was a GoodyHut. This last part MIGHT get a bit annoying if you don't WANT to explore the lair and attempt to re-automate the unit without first moving him away a little bit. (NOTE: This field makes it so that the AI rather aggressively pursues Lairs to explore. Also note that since most units spawned from a lair are spawned by Goody, it isn't easy to have units popping up too close to your only city, or too early in the game)
    6. <iLairCreationWeight> - Weight for the Improvement to be selected for spawning during each LairCreationCycle (All weights of all improvements with a weight are added, and one is selected randomly from that weighted list to try and spawn. A valid tile must be found for the improvement to spawn though, otherwise another one is selected instead)
    7. <iBasePlotCounterModify> - Modifies the PlotCounter by this value. True value of the Plot Counter still cannot go above 100 or below 0, so this field if set under -92 will make the tile incapable of becoming Hell, and if set over 10 will make it impossible for the tile to NOT be Hell.

  11. CIV4UnitInfos.xml
    1. <AllowPromotions> & <DenyPromotions> - Replaces the above modification to WeaponTier with an ability to handle non-linear weapon progression/availability. Works just like <PromotionAllows> and <PromotionExcludes> fields in PromotionInfos.
    2. <Quote> & <Quotes> - Matches up with <Image> and <Images> fields to provide a quote for the unit pop-ups
    3. <Images> - Matches up with <UniqueNames> field to provide Images for each Uniquename option for pop-ups
    4. <AllowPromotions> - Grants the unit permission to gain listed promotions regardless of unit-centric prerequisites (PrereqUnitClass, PrereqUnits, PrereqTier, PrereqWeaponTier). Also the unit must list any promotion in this field if the promotion is flagged as <bRequiresPermission>
    5. <DenyPromotions> - Unit is capable of having any promotion listed in these fields (Would be useful on the Flesh Golems for instance)
    6. <PythonOnDeath> - Function run any time that the unit attempts to be killed. If the function returns a 1, the kill process will not continue (like Immortality). This call is made AFTER Immortal rebirth stops the kill function. There is a python exposed command to disable this call from being made by the unit anymore (PyUnit.setDisablePyDeath(true)), and this function will not run when the unit is killed at the end of converting.

  12. CIV4PromotionInfos.xml
    1. <iPromotionRandomApplyChance> - Controls the probability of the promotion listed in PromotionRandomApply (Fair Winds, Enraged) being applied each turn
    2. <iPromotionRandomApplyChance> - Percent Chance per turn that the promotion listed in RandomApply will actually be applied
    3. <iNoBadExplore> - Percent chance to avoid a bBad Goody result when gaining Lair rewards via Goody Validation. In most cases there is a list of possible results which gets populated, then one is chosen randomly from that list. This field in those cases just means a slightly smaller list. If you manage to dodge all possible bad results and there weren't any non-bad possibilities, typically you gain Goody_Small_Gold
    4. <PrereqPromotionsNOTOnTile> & <PrereqPromotionsOnTile> - Promotion is only allowed when a unit in the same tile has (doesn't have) the listed promotions (All listed promotions are required to be on the tile to pass the second check, none of the listed promotions are allowed to be on the tile to pass the first)
    5. <PrereqUnitClassesNOTOnTile>, <PrereqUnitClassesOnTile>, <PrereqUnitTypesNOTOnTile> & <PrereqUnitTypesOnTile> - As with the Promotion On Tile fields, either all the units listed have to be present, or none of them can be present, depending on which is used.

  13. CIV4SpellInfos.xml
    1. <Quote> - Specifies the text displayed in the pop-up for Global Spells (Image used is the LeaderHead image)



Also added by Jean Elcard is the new file CIV4StateNameInfos.xml which controls what state name modifications will happen and what conditions are required to gain them. I haven't checked out all of the inner workings, so he'll correct me if I am guessing some of these wrong off of just the XML field name :)

CIV4StateNameInfos.xml
  1. <iMinNumCities> - Number of cities required to gain the statename
  2. <iMaxNumCities> - Limit of number of cities owned for name to be valid
  3. <bNoMinor> - Prevents Minor Civilizations from having the statename
  4. <bNoVassal> - Prevents a Civilization from having this statename if they are current vassalized
  5. <PrereqCivics> - Civics required active to gain the statename
  6. <PrereqAlignments> - Alignment required for the name to be valid
  7. <PrereqCivilization> - Civilization for which the name is valid
  8. <PrereqReligion> - Religion required to gain the name

Once all valid names have been decided, there is a routine to choose precisely which one will apply. Note that when you change multiple civics at once you might go through a couple of names as each civic is changed internally one-by-one.


EDIT: As for Gameplay changes and tweaks... I didn't keep track. The one I remember right now is that Groups with a BuildOrder will not "wake up" to ask you to promote them when they gain a level. This means if you give your workers a huge list of chores, and then they promote, they remember their list instead of having you issue them all over again! But this also means if you have a warrior defending that worker and he gains XP somehow then he will NOT wake up to ask for a promotion either (though normally such XP would be gained by combat, and having an enemy nearby will have woken them up anyway)
 
Also added by Jean Elcard is the new file CIV4StateNameInfos.xml which controls what state name modifications will happen and what conditions are required to gain them. I haven't checked out all of the inner workings, so he'll correct me if I am guessing some of these wrong off of just the XML field name :)

CIV4StateNameInfos.xml
  1. <iMinNumCities> - Number of cities required to gain the statename
  2. <iMaxNumCities> - Limit of number of cities owned for name to be valid
  3. <bNoMinor> - Prevents Minor Civilizations from having the statename
  4. <bNoVassal> - Prevents a Civilization from having this statename if they are current vassalized
  5. <PrereqCivics> - Civics required active to gain the statename
  6. <PrereqAlignments> - Alignment required for the name to be valid
  7. <PrereqCivilization> - Civilization for which the name is valid
  8. <PrereqReligion> - Religion required to gain the name

You were guessing right. Congratulations. :)

Once all valid names have been decided, there is a routine to choose precisely which one will apply.

First of all, a state name is only valid for you, if you meet all conditions. Of course, it may happen, that you meet the conditions for multiple state names. What happens then? Then it applies the state name, you need and fulfill the most prerequisites for. If there should be still more than one left, you get the one further down in the XML file (should be a very rare case).
 
Would it be possible to create a new "Would you please stop building..." option under the "Lets Discus Something Else" choice on the diplomacy menu, which would allow a human with an AI Permanent Ally to tell it to stop the production of a certain World Unit/Building/Ritual?
 
Why would you want them to stop?

Because you want to make that unit/wonder/ritual yourself? :p

Example: Having Basium and then watching him beat you to Sphener/Yvain/whoever.
 
Not being able to build a hero or wonder because a permanent ally is doing so (especially if it is doing sow in a low production city and so won't be able to beat a rival to it anyway) is extremely annoying, thats why. It is even worse in games where you are allied with another leader of the same civ. Kael had to block the AI from building Heroes in the Splintered Court if it has a human ally to stop that annoyance, but that block is only in that scenario and probably isn't the best way to do in in the main game, as you sometimes would want them to build the unit.
 
Been trying to get some code for Oasis creation working, and while I can create an Oasis, the moment I try to go into python to require a minimum distance between Oases, the code completely fails. Stole it from the Pirate Cove code, no idea what I'm doing wrong here. Any help would be much appreciated. ;)

Edit: Code removed, got it working.
 
Actually, I noticed that just after posting, and fixed it. Had it in thinking I might not be understanding the code. Still not working after making the fix.


Edit: Nevermind, I'm an idiot. Forgot to define iOasis, working now. ;) Also, is there anyway to put in a minimum distance between improvements without making it a spell?
 
Top Bottom