Freeciv
Register
Advertisement

This document describes how to convert a Freeciv 2.5 compatible ruleset to a 2.6 compatible one.

Capability[]

Capability string of each ruleset file must be changed:

[datafile]
options="+Freeciv-2.6-ruleset"

General format[]

Separate file can be loaded in as a value for a string. Use asterisks to indicate that the value is a filename and not the string itself. See Ruleset Summary and Description for an example.

Ruleset information[]

Versioning[]

Optional versioning of the ruleset is now supported. You can add the version string of the ruleset to game.ruleset [about] section. That version is displayed to the user in client Help -> About Ruleset, and stored to savegames. Note that this ruleset version has nothing to do with freeciv version, though many rulesets prefer to have freeciv major version that the ruleset is compatible with in the beginning.

Summary and Description[]

Where older versions had only one description, now ruleset can have summary and description. Of these, summary works mostly like old description did, including the limited length. The new description field has no length limitations, and is typically loaded from a separate file.

[about]
summary = _("This is short summary of what the ruleset is like.")
description = *rulesetdir/README.ruleset*

Ruledit metadata[]

Ruleset editor freeciv-ruledit needs some metadata to function correctly with the ruleset, especially when saving it back again after editing.

Nations.ruleset[]

Metadata is in section [ruledit]. If nations.ruleset should not contain all the nations saved to it, but should include separate list of nations, such as default/nationlist.ruleset, that nationlist should be given in nationlist -entry.

[ruledit]
nationlist = "default/nationlist.ruleset"

Nations that are not part of such an nationlist, should be listed in embedded_nations. This is needed only if nationlist is defined, otherwise all nations are automatically embedded.

embedded_nations = "Animal Kingdom"

Game.ruleset[]

Metadata is in section [ruledit]. If description for the ruleset is to be read from a separate file using description = *README.description* format, ruledit.description_file should contain name of that file description_file = "README.description". Otherwise ruledit will save the description inlined to the game.ruleset.

Extras[]

All of old hardcoded specials, bases and roads are extras. You must add section for each extra to terrain.ruleset. Bases and Roads still have separate sections for their additional properties. These base and road sections are linked to specific extra section by field extra.

[extra_farmland]
name = _("Farmland")
category = "Infra"
causes = "Irrigation"
rmcauses = "Pillage"
graphic = "tx.farmland"
graphic_alt = "-"
activity_gfx = "unit.farmland"
act_gfx_alt = "unit.irrigation"
act_gfx_alt2 = "unit.irrigate"
rmact_gfx = "None"
rmact_gfx_alt = "-"
reqs =
  { "type", "name", "range"
    "Tech", "Refrigeration", "Player"
    "Extra", "Irrigation", "Local"
  }
build_time = 0
removal_time = 0
conflicts = "Mine", "Oil Well"

Requirements[]

Requirements are defined for all extras in their extra section. This replaces old requirement vectors in base and road sections for them. For old specials, proper requirements must be added. See classic ruleset for requirements matching old hardcoded behavior. For bases and roads you should just move the requirement vectors from base and road sections to extra section.

Categories[]

These categories match old hardcoded rules of specials:

  • Irrigation, Mine, Farmland: Infra
  • Pollution, Fallout: Nuisance
  • Hut: Bonus

All of bases and roads used to be handled as Infra but now that it's possible to define them one by one, you may want to adjust that (Rivers would normally be Natural rather than Infra, and some special bases Bonus)

Buildable property[]

Whether extra is buildable is defined for all extras in their extra section. This replaces old buildable fields in base and road sections for them. For old specials you may want to set this to FALSE if the extra should not appear in the game at all (leaving requirements vector empty would mean extra is buildable always). For bases and roads you should just move the buildable field from base or road section to extra section.

Pillageable property[]

Extra is defined to be pillageable by adding Pillage to rmcauses (removal causes) list. This replaces old pillageable fields in base and road sections. You should just add rmcause Pillage in extra section of all the bases and roads that have had pillageable property TRUE, and not for others. To keep old hardcoded behavior, only Pollution and Fallout of the old specials should get rmcause Pillage.

Names[]

Huts were called "Minor Tribe Village" in the clients and "Hut" in save games. To keep that add it like this:

[extra_hut]
name           = _("Minor Tribe Village")
rule_name      = "Hut"

Conflicts[]

There can be conflicts between any two extras defined in their extra sections. This replaces old conflict definitions between base types only. For old specials, some conflicts should be defined to get old hardcoded behavior; Mine should conflict with both Irrigation and Farmland. To keep old conflicts between bases, just move conflicts field from base section to their extra section.

Native to[]

All extras have list of unit classes it's native to in their extra section. This replaces old native_to fields in base and road sections for them. For old specials there's no need to define them native to any unit to get old behavior. For bases and roads you should just move the native_to field from base or road section to extra section.

NativeTile flag[]

NativeTile extra flag has replaced base and road flags with the same name. Just remove the flag from base and road sections, and define it in extra sections of those bases and roads that used to have it.

Movement between road types[]

When a unit is travelling along roads in terrain that it's not native to, it's now strictly enforced that the unit can only move along the road; even if tiles with two different native road types (for instance river and railroad) are adjacent, the unit will not be able to jump between them by default (it could in 2.5).

There are a couple of ways to override this:

  • Add the JumpFrom and JumpTo flags to the "flags" definition in the [road_*] sections for the road types that provide native travel. The move cost will be that of the underlying terrain. This exactly restores 2.5 behavior.
  • Add "integrates" to the [road_*] sections of each road pointing to the other(s). This will allow free movement between them with the movement cost of the roads, and draw connections between the roads on the map. This is a new facility that didn't exist in 2.5, but may be more appropriate, depending on the ruleset.

ShowFlag flag[]

ShowFlag extra flag has replaced base flag with the same name. Just remove the flag from the base sections, and define it in extra sections of those bases that used to have it.

Refueling[]

Fuel using units no longer refuel on all native bases. Instead any extra that could act as refueling point for native units, must have Refuel flag. To keep old behavior, add flag to extra section of all bases.

Defense bonus[]

All extras have defense_bonus. This replaces old defense_bonus fields in base and road sections. Just move defense_bonuses of bases and roads to extra sections to get the old behavior.

Hidden by another extra[]

Any extra can hide any other extra with hidden_by property. This replaces similar feature that was limited to hiding roads with other roads. To just keep the old functionality, move hidden_by from the road section to the extra section of the same road extra.

AlwaysOnCityCenter and AutoOnCityCenter[]

Base and Road flags AlwaysOnCityCenter and AutoOnCityCenter have been replaced with extra flags with the same names. Simply move flags from base or road section to the extra section of the extra.

Graphics tags[]

All the extras have graphic and graphic_alt tags in their extra section. Move old tag definitions from base and road sections to their extra section, and add tags for the other extras.

Activity gfx tags[]

All the extras have activity_gfx, act_gfx_alt, and act_gfx_alt2 tags in their extra section. Move old tag definitions from base and road sections to their extra section, and add tags for the other extras. These tags are used for activities that add the extra. For activities that remove the extra see rmact_gfx tag. Special value None is supported for cases where no activity creates the extra, such as rivers and huts added by map generation only, pollution resulting from city pollution only.

Extra removal activity gfx tags[]

Extras have separate rmact_gfx and rmact_gfx_alt tags for activities that remove the extra. These are used for cleaning pollution or fallout. Special value None is supported here too for extras that have no special removal activity.

ConnectLand flag[]

Any extra can have ConnectLand flag that used to be specific to roads. For any road having such a flag, remove it from road section, and add to extra section.

Natural Road Flag[]

Road flag Natural has been removed as obsolete. The only use that it had in 2.5 was to provide sdl-client with information what defense bonuses are to be considered natural for the tile. Now it's determined from the extra's category.

NoBonus Road move mode[]

Road move mode NoBonus has been removed. Instead you should set move_cost to -1 for such roads instead. This allows you to set combination of -1 move_cost and the move mode you really want.

Extra build_time[]

Extras have build_time property, replacing that of roads and bases. Move old build_time definitions from road and base sections to extra section. For other extras you may set build_time as 0 to keep old behavior of using terrain specific build times.

Pillage time[]

Extra removal time works similar way to the build time. This means that even for pillage activity, terrain specific execution time, pillage_time, has been added. Set it to 1 for all terrain types to mimic old behavior. Set removal_time for all extras to 0 to use terrain specific times as was the case in 2.5.

Environment upset[]

Only extras with flags GlobalWarming or NuclearWinter count toward environment upset. To keep old hardcoded behavior, add GlobalWarming to Pollution and NuclearWinter to Fallout

Extra requirement type[]

Requirement types Special, Base, and Road have been replaced with Extra requirement type. As you have extra type defined for all the specials, bases, and roads, this requires simply changing the requirement type text

reqs =
  {
    "Special", "Irrigation", "Local"
    "Base", "Fortress", "Local"
    "Road", "Railroad", "Local"
  }

->

reqs =
  {
    "Extra", "Irrigation", "Local"
    "Extra", "Fortress", "Local"
    "Extra", "Railroad", "Local"
  }

Farmland tech requirement[]

Tech flag Farmland has been removed as obsolete. Instead you should have such a tech as requirement for Farmland extra. If you had multiple techs with the flag, you need to create user tech flag, give it to all those techs, and to make that tech flag requirement for Farmland extra instead.

Bonuses from Extras[]

For getting tile output bonuses from extras, one has to define them as effects. Old versions used to have pollution and fallout penalties defined in terrain.ruleset. Those are now removed as obsolete. Here are effects matching hardcoded bonuses, and in case of pollution and fallout old defaults from terrain.ruleset, from earlier versions:


; Irrigation gives 100% of terrain irrigation bonus
[effect_irrigation]
type    = "Irrigation_Pct"
value   = 100
reqs    =
    { "type", "name", "range", "present"
      "Extra", "Irrigation", "Local", TRUE
      "CityTile", "Center", "Local", FALSE
    }

[effect_irrigation_2]
name    = "Irrigation_Pct"
value   = 100
reqs    =
    { "type", "name", "range", "present"
      "CityTile", "Center", "Local", TRUE
      "TerrainAlter", "CanIrrigate", "Local", TRUE
     "Extra", "Mine", "Local", FALSE
   }

; Mine gives 100% of terrain mine bonus
[effect_mine]
type    = "Mining_Pct"
value   = 100
reqs    =
    { "type", "name", "range"
      "Extra", "Mine", "Local"
    }

; Pollution or Fallout reduce output by 50%. Together 75% (and not 50% + 50% = 100%)
[effect_pollution]
name    = "Output_Tile_Punish_Pct"
value   = 50
reqs    =
    { "type", "name", "range", "present"
      "Extra", "Pollution", "Local", TRUE
      "Extra", "Fallout", "Local", FALSE
    }

[effect_fallout]
name    = "Output_Tile_Punish_Pct"
value   = 50
reqs    =
    { "type", "name", "range", "present"
      "Extra", "Fallout", "Local", TRUE
      "Extra", "Pollution", "Local", FALSE
    }

[effect_pollution_fallout]
name    = "Output_Tile_Punish_Pct"
value   = 75
reqs    =
    { "type", "name", "range"
      "Extra", "Pollution", "Local"
      "Extra", "Fallout", "Local"
    }

Extra helptext[]

Manually written helptext are now property of extras, not just bases and roads. Move helptext from bases and roads to equivalent extra section. For extras like hut there's no longer hardcoded help in help browser, but if you have any such extras, you should add the help there.

Natural Defense Layer[]

Defense bonus from the extra can be counted towards one of the two defense layers. Within a layer bonuses are additive, then bonuses between layers are multiplied. To set extra to a Natural Defense Layer instead of default Infrastructure Defense Layer, give it NaturalDefense flag. This can be used to restore pre-2.5 behavior of Rivers defense bonus (multiplicative with Fortress bonus).

Mine appearance[]

Tilesets no longer have terrain specific sprite definition for mines, as there is no such hardcoded concept as mine any more, just generic extras. If you want to have distinct appearance for the mine on different terrains, you need to define distinct extras in the ruleset having suitable terrains as requirement (possibly via custom terrain flags to group them). Most of the supplied rulesets provide new extra named "Oil Well" to be used instead of "Mine" on terrains where most tilesets used to have oil derrick like mine graphics.

Nuke Contamination[]

Setting nuke_contamination from game.ruleset has been removed as redundant. You can control what kind of extras appear as an result to nukes by defining causes for the extras. If you define Fallout as cause for Pollution-extra, and maybe remove Fallout extra completely, then Pollution will appear as result of nuclear explosions. If you define Fallout as cause for Fallout-extra, then it will appear.

Terrains without pollution[]

NoPollution terrain flag is gone. If you need it, implement it as user terrain flag that is negated (not present) requirement for appearance of all pollution extras.

Extra ownership[]

Tile (borders) can now be owned by one player, and extras on it by another. This makes it possible to get rid of the common workaround of making bases (such as buoys) territory-claiming bases for their own tile at least, so that their owner will get their effects (e.g. vision).

Requirement definitions[]

Negated replaced with present[]

Old negated property of the requirements has been replaced with opposite meaning present so that ruleset author is not required to think in double-negations (negating negation).

reqs = 
  { "type", "name", "range", "negated"
    "Tech", "Masonry", "Player", FALSE
    "Tech", "Metallurgy", "World", TRUE
  }

->

reqs =
  { "type", "name", "range", "present"
    "Tech", "Masonry", "Player", TRUE
    "Tech", "Metallurgy", "World", FALSE
  }

Effect nreqs should be replaced with present=FALSE requirements[]

In none of the supplied rulesets do effects use nreqs any more. Those are listed as present=FALSE requirements in the normal requirements list instead. This is going to be the only supported way in the future versions.

reqs    =
    { "type", "name", "range"
      "Building", "Airport", "City"
      "UnitClass", "Air", "Local"
    }
nreqs   =
    { "type", "name", "range"
      "UnitFlag", "NonMil", "Local"
      "UnitFlag", "NoVeteran", "Local"
    }

->

reqs    =
    { "type", "name", "range", "present"
      "Building", "Airport", "City", TRUE
      "UnitClass", "Air", "Local", TRUE
      "UnitFlag", "NonMil", "Local", FALSE
      "UnitFlag", "NoVeteran", "Local", FALSE
    }

Action Enablers[]

Some previously hardcoded requirements for player actions have been made ruleset configurable with new action enablers concept in game.ruleset actions -section.

To disable help text auto generation about what enables and disables an action list it in the action section's quiet_actions field. This is useful if you already documented it your self.

Sabotage City[]

To have city sabotaging be restricted the way it used to be with hardcoded rules, add action enablers like this:

[actionenabler_sabotage_city]
action = "Sabotage City"
actor_reqs    =
    { "type",   "name", "range", "present"
      "DiplRel", "War", "Local", TRUE
      "UnitFlag", "Spy", "Local", FALSE
      "UnitState", "OnLivableTile", "Local", TRUE
      "MinMoveFrags", "1", "Local", TRUE
    }

[actionenabler_sabotage_city_target]
action = "Targeted Sabotage City"
actor_reqs    =
    { "type",   "name", "range"
      "DiplRel", "War", "Local"
      "UnitFlag", "Spy", "Local"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
    }

Poison City[]

To have city poisoning be restricted the way it used to be with hardcoded rules, add action enabler like this:

[actionenabler_poison_city]
action = "Poison City"
actor_reqs    =
    { "type",   "name", "range"
      "UnitFlag", "Spy", "Local"
      "DiplRel", "War", "Local"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
    }
target_reqs    =
    { "type",   "name", "range"
      "MinSize", "2", "City"
    }

Bribe Unit[]

To have unit bribing be restricted the way it used to be with hardcoded rules, add action enabler like the following. This assumes you have user unit flag Unbribable defined. If you don't have units that needs such a flag, you can drop the line about Unbribable unit flag. If you don't make democracies immune to unit bribery remove the line about Democracy.

[actionenabler_bribe_unit]
action = "Bribe Unit"
actor_reqs    =
    { "type",   "name", "range", "present"
      "DiplRel", "Alliance", "Local", FALSE
      "DiplRel", "Team", "Local", FALSE
      "UnitState", "OnLivableTile", "Local", TRUE
      "MinMoveFrags", "1", "Local", TRUE
    }
target_reqs    =
    { "type",   "name", "range", "present"
      "UnitFlag", "Unbribable", "Local", FALSE
      "Gov", "Democracy", "Player", FALSE
      "CityTile", "Center", "Local", FALSE
    }

Sabotage Unit[]

To have unit sabotaging be restricted the way it used to be with hardcoded rules, add action enabler like this:

[actionenabler_sabotage_unit]
action = "Sabotage Unit"
actor_reqs    =
    { "type",   "name", "range"
      "Unitflag", "Spy", "Local"
      "DiplRel", "War", "Local"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
    }
target_reqs    =
    { "type",   "name", "range", "present"
      "CityTile", "Center", "Local", FALSE
    }

Incite City[]

To have city inciting be restricted the way it used to be with hardcoded rules, add action enabler like the following. If you don't wish to make democracies immune to city incitement remove the line about Democracy. If you don't wish to make capitals immune to city incitement remove the line about Palace.

[actionenabler_incite_city]
action = "Incite City"
actor_reqs    =
    { "type",   "name", "range", "present"
      "DiplRel", "Alliance", "Local", FALSE
      "DiplRel", "Team", "Local", FALSE
      "UnitState", "OnLivableTile", "Local", TRUE
      "MinMoveFrags", "1", "Local", TRUE
    }
target_reqs  =
    { "type",   "name", "range", "present"
      "Gov", "Democracy", "Player", FALSE
      "Building", "Palace", "City", FALSE
    }

Establish Embassy[]

To have embassy establishing be restricted the way it used to be with hardcoded rules, add action enabler like this:

[actionenabler_establish_embassy]
action       = "Establish Embassy"
actor_reqs    =
    { "type",   "name", "range"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
    }
target_reqs  =
    { "type",   "name", "range", "present"
      "NationGroup", "Barbarian", "Player", FALSE
    }

Investigate City[]

To have city investigation be restricted the way it used to be with hardcoded rules, add action enabler like this:

[actionenabler_investigate_city]
action       = "Investigate City"
actor_reqs    =
    { "type",   "name", "range"
      "UnitFlag", "Diplomat", "Local"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
    }

Steal Tech[]

Tech stealing has implemented as two different actions in action enablers framework. One is the kind of tech stealing where user decides tech to steal, the other one tries to steal random one. To have them restricted the way it used to be with hardcoded rules, add action enablers like this:

[actionenabler_steal_tech_random]
action = "Steal Tech"
actor_reqs    =
    { "type",   "name", "range", "present"
      "UnitFlag", "Spy", "Local", FALSE
      "UnitState", "OnLivableTile", "Local", TRUE
      "MinMoveFrags", "1", "Local", TRUE
    }
target_reqs  =
    { "type",   "name", "range", "present"
      "NationGroup", "Barbarian", "Player", FALSE
    }

[actionenabler_steal_tech_target]
action = "Targeted Steal Tech"
actor_reqs    =
    { "type",   "name", "range"
      "UnitFlag", "Spy", "Local"
      "UnitState", "OnLivableTile", "Local"
      "MinMoveFrags", "1", "Local"
    }
target_reqs  =
    { "type",   "name", "range", "present"
      "NationGroup", "Barbarian", "Player", FALSE
    }

Establish Trade Route[]

To have trade route establishing be restricted the way it used to be with hardcoded rules, add action enabler like the following. This assumes you have user unit flag TradeRoute defined.

[actionenabler_traderoute]
action       = "Establish Trade Route"
actor_reqs    =
    { "type",   "name", "range"
      "UnitFlag", "TradeRoute", "Local"
    }

Enter Marketplace[]

To have entering marketplace be restricted the way it used to be with hardcoded rules, add action enabler like the following. This assumes you have user unit flag TradeRoute defined.

[actionenabler_marketplace]
action       = "Enter Marketplace"
actor_reqs    =
    { "type",   "name", "range"
      "UnitFlag", "TradeRoute", "Local"
    }

Help Wonder[]

To have Wonder building helping be restricted the way it used to be with hardcoded rules, add action enabler like the following. This assumes you have user unit flag HelpWonder defined.

[actionenabler_help_wonder]
action       = "Help Wonder"
actor_reqs    =
    { "type",   "name", "range", "present"
      "UnitFlag", "HelpWonder", "Local", TRUE
      "DiplRel", "Is foreign", "Local", FALSE
    }

New in 2.6[]

The brand new action "Steal Gold" has been added. It didn't exist in 2.5. It is completely optional. To keep 2.5 behavior you shouldn't enable it at all.

Forcing Trade Routes to get established[]

By default "Enter Marketplace" action is available even when there would be still free trade route slots to establish one. To force old behavior of automatically establishing trade route if possible, and entering marketplace only if it's not possible, set new actions.force_trade_route in game.ruleset to TRUE.

Buildings obsolescence[]

Normal Buildings and Small Wonders can get obsolete by means other than their owner gaining certain tech, and Great Wonders means other than anyone in the whole world gaining certain tech. Building obsolete_by is now requirement vector, with any one of the listed requirements being true obsoleting the building. To recreate old behavior, add player range tech requirement for normal buildings and Small Wonders, and world range tech req with "survives" flag for Great Wonders.

For example for a Great Wonder:

obsolete_by     = "Electricity"

->

obsolete_by     =
    { "type", "name", "range", "survives"
      "Tech", "Electricity", "World", TRUE
    }

Building replacement[]

Buildings no longer have replaced_by field, but such an replacing building should be added as one of the obsolete_by requirements. If there was a chain of replaced_by buildings, make sure that the first ones still get obsolete if the last ones are present (but middle ones are not)

Barracks:

replaced_by = "Barracks II"

Barracks II:

replaced_by = "Barracks III"

-> Barracks:

obsolete_by =
  { "type", "name", "range"
    "Building", "Barracks II", "City"
    "Building", "Barracks III", "City"
  }

Barracks II:

obsolete_by =
  { "type", "name", "range"
    "Building", "Barracks III", "City"
  }


Revolution Unhappiness[]

Boolean Revolution_When_Unhappy effect replaced with Revolution_Unhappiness effect. Its value defines how many turns city can be in disorder before the nation revolts. Value 0 disables such revolutions completely. Old hardcoded count of turns was 2, so usually you can recreate that situation by replacing Revolution_When_Unhappy effects Revolution_Unhappiness effect with value 2. If you had multiple such effects possibly being active at the same time, be careful to use nreqs if you don't want values (i.e. count of turns) from multiple effects to sum up.

Unit bribe cost[]

Unit bribe cost can be modified by effect Unit_Bribe_Cost_Pct. This effect is also used to get rid of old hardcoded rule that city founder units are 50% cheaper to bribe. If you want to keep that old rule, add effect like:

[effect_unit_bribe_cost_settlers]
type    = "Unit_Bribe_Cost_Pct"
value   = -50
reqs    =
    { "type", "name", "range"
      "UnitFlag", "Cities", "Local"
    }

Unbribable flag[]

Hardcoded unit type flag Unbribable has been removed. You need to define it as user unit flag if you have units that have it, and you need to make unit bribing action enabler to require target not to have it.

Unbribable_Units effect[]

The Unbribable_Units effect has been removed. Use not present requirements in the target requirement vector in Bribe Unit action enablers in stead.

No_Incite effect[]

The No_Incite effect has been removed. Use present = FALSE requirements in the target requirement vector in Incite City action enablers in stead.

NewCityGamesOnly flag[]

Consider adding this flag to your settler-type units, so that scenario authors for your ruleset can prevent those units from being built by setting the "Prevent New Cities" flag in their scenarios, if it would make no sense to build those units in such a scenario. (However, the supplied rulesets do not set this flag for any units.)

Achievements[]

Achievements are new feature in 2.6. You can define them in game.ruleset, but that's optional and to keep old 2.5 behavior you should not add any achievements.

Animals[]

Animals are new barbarian type. To keep old behavior of not having them, one simply does not define special nation for them. However, following changes to rulesets needs to be done.

Animals for terrains[]

Field animal should be added for all terrain types. That's unit type that would appear as animal on that terrain. For old behavior of not having animals one can simply use special value None for all of them.

Tech tree holes[]

You need to add booleans tech_steal_allow_holes, tech_trade_allow_holes, tech_parasite_allow_holes, tech_trade_loss_allow_holes, and tech_loss_allow_holes to research -section of game ruleset to define in which situations one may get a tech for which prerequisites are not known, or lose one which is prerequisite for another known tech. Old hardcoded rules allowed any available tech to be gained/lost in all of these situations, so to mimic that you should set them all to TRUE.

Research values in [research][]

All the research related values in game.ruleset have been moved to [research] section. The values to move are tech_cost_style, base_tech_cost, and tech_leakage.

Technology cost and technology leakage methods are now defined by descriptive words instead of magic numbers. Here the conversion tables between old and new values:

Freeciv 2.5 Freeciv 2.6
tech_cost_style = 0
tech_cost_style = "Civ I|II"
tech_cost_style = 1
tech_cost_style = "Classic"
tech_cost_style = 2
tech_cost_style = "Classic+"
tech_cost_style = 3
tech_cost_style = "Experimental"
tech_cost_style = 4
tech_cost_style = "Experimental+"
Freeciv 2.5 Freeciv 2.6
tech_leakage = 0
tech_leakage = "None"
tech_leakage = 1
tech_leakage = "Embassies"
tech_leakage = 2
tech_leakage = "All Players"
tech_leakage = 3
tech_leakage = "Normal Players"

Bonus tech message[]

Message to be shown when first player research a tech that gives another tech as a bonus should bow contain '%s' to show where the name of the gained tech is placed.

Terrain and Resource Names[]

All references to other resources and terrains in terrain.ruleset must be changed to use their rule_name instead of old practice of using the name of the section where the terrain or resource is defined.

National styles[]

Old city_style has been replaced by three-part hierarchy. Each nation has a style. Each city has city_style that's usually (but not necessarily) derived from the national style by using it as requirement. There's also music_style that controls what kind of music client of the player should play. This too can require certain national style. Styles are defined in new ruleset styles.ruleset For recreating exactly same kind of city_styles as ruleset used to have in 2.5, you need to create one national style for each initial (those which were not replaced_by of any other) city_style, and to make those initial city_styles to require equivalent national style.

National Styles[]

Add necessary [style_xxx] definitions to styles.ruleset. For each nation, unless you are using default ones from freeciv distribution, you need to replace old city_style -entry with style -entry. If you have named national styles in styles.ruleset to have the same name as the initial city style enabled by it, all you need to do is to replace word city_style with style. Similarly in nations ruleset [compatibility] section allowed_city_styles must be replaced with allowed_styles.

City Styles[]

Move city style definitions from cities.ruleset to styles.ruleset. Remove now unused replaced_by field. Make sure the city styles are in correct order. Last for which requirements are fulfilled, will be used. If you had separate gfx for oceanic cities, you now need to define those oceanic cities as separate city styles, by having requirement like "TerrainClass", "Oceanic", "Local". Make sure the order of city styles is correct, or also add requirement like "TerrainClass", "Land", "Local" for land city styles, so that the land style does not get selected for oceanic cities too. Remove oceanic_graphic definitions from all the city styles.

Music Styles[]

Add at least one music style definition to styles.ruleset. If you are building entire modpack with ruleset, tileset, and soundset, you may want to add also musicset now.

Traderoutes[]

New types[]

Old IN (International) and INIC (International & Intercontinental) traderoute types have been split to more types depending on the diplomatic relations between the nations doing the trade. Ally and AllyIC apply to trade between allied players. Enemy and EnemyIC apply to trade between enemies. Team and TeamIC apply to trade between team members. All other relations, including transitional ones such as armistice and cease-fire, still use IN & INIC. To keep old behavior just copy definitions of IN/INIC as Ally/AllyIC, Enemy/EnemyIC, and Team/TeamIC definitions in game.ruleset

One-time bonus definition[]

Each traderoute type should have bonus type defined. For always receiving both gold and bulb bonus when traderoute is established, like the old hardcoded behavior was, set it to Both for all traderoute types.

ZOC terrains[]

Hardcoded rule that ZoC is created only by units on Land terrains, as well as limiting only those units, has been replaced with NoZoc terrain flag. To keep old behavior, add the NoZoc flag to all oceanic terrains.

Removal of unit ZOC[]

It's now possible to arrange that certain units do not impose ZoC, with the "HasNoZOC" unit type flag. To keep the old behavior, no change is required. However, you may wish to take the opportunity to remove ZOC for units like settlers, explorers, etc.

Fortifying[]

Terrains[]

Hardcoded rule that units can Fortify only on land terrains, has been replaced with NoFortify terrain flag. To keep old behavior, add the NoFortify flag to all oceanic terrains.

Units[]

Hardcoded limitation that workers cannot fortify has been removed. New unit type flag Cant_Fortify controls which units cannot fortify despite their class having CanFortify flag. To keep old hardcoded behavior, add Cant_Fortify unit type flag to all units with Settlers flag.

Trait ranges[]

AI traits are now defined as three separate values, which are used depending on traitdistribution server setting. Two of the values define a range instead of exact value. Random value from the given range will be assigned to the player when game starts. To keep old exact values even when range is being used, just define range to contain only that one value. Ranges are given by replacing each old trait entry with two; one with suffix "_min" and other with suffix "_max". Both default trait values and nation specific traits need to be changed. The exact value to be used for all players when random trait distribution is disabled is given as "_default". If that's omitted, midpoint of the range given above is used.

[default_traits]
expansionist = 50
...
[nation_abkhaz]
...
trait_expansionist = 200

->

[default_traits]
expansionist_min = 50
expansionist_max = 50
expansionist_default = 50
...
[nation_abkhaz]
...
trait_expansionist_min = 200
trait_expansionist_max = 200
trait_expansionist_default = 200

Airlifting[]

Unit class airliftability is now unit class flag. To keep old hardcoded behavior, give flag Airliftable to all land moving unit classes.

Movement cost[]

You need to add pythagorean_diagonal entry to [parameters] section of terrain.ruleset, controlling if diagonal movement is more expensive than cardinal movement in square tile maps. To preserve old hardcoded behavior, set it to value FALSE.

Unit move_type obsoleted[]

Unit move_type definition, already optional in 2.5, for unit types has been completely removed from units.ruleset. Just remove it from all units that still had it.

IgWall unit type flag removed[]

Hardcoded IgWall unit type flag has been removed. You should add such units as present = FALSE requirements for all Defend_Bonus effects. If you had just one such unit type, you can use UnitType requirement type. If you had several affected unit types, you may want to reintroduce IgWall as user unit type flag and use UnitFlag requirement type.

StartUnit Roles[]

Roles have been rearranged to give ruleset author finer control over what units are used as starting units. Now there's a role for every kind of start unit used for the purpose only. All of these roles have a name ending "StartUnit". Old roles that had no other use than startunit selection have been renamed, for other ones new startunit role has been added. Note that there are several unit type flags that use same names as these roles, but are in no way affected by the change. To maintain exactly the old behavior, do the following changes to roles of all unit types:

  • "Cities" -> Rename role as "CitiesStartUnit"
  • "Settlers" -> Add role "WorkerStartUnit"
  • "Explorer" -> Add role "ExplorerStartUnit"
  • "GameLoss" -> Rename role as "KingStartUnit"
  • "Diplomat -> Rename role as "DiplomatStartUnit"
  • "Ferryboat" -> Add role "FerryStartUnit"
  • "DefendOk" -> Add role "DefendOkStartUnit"
  • "DefendGood" -> Add role "DefendGoodStartUnit"
  • "AttackFast" -> Rename role as "AttackFastStartUnit"
  • "AttackStrong" -> Rename role as "AttackStrongStartUnit"

Culture Victory[]

You need to add minimum culture settings for culture victory to game.ruleset [culture] section. If you just want to keep the old behavior of game having no culture effects, any positive values will suffice here, as nobody can ever reach over 0 culture points.

[culture]
; Minimum culture points for cultural domination victory
victory_min_points = 1000

; How big lead relative to second best player is needed for victory
victory_lead_pct   = 200

; How much each culture point affects the migration
; from/to the city. Each culture point count as this many permilles
; of a migration point.
migration_pml = 50

Policies[]

Policy multipliers are new feature in 2.6. You can define them in governments.ruleset, but that's optional and to keep old 2.5 behavior you should not add any multipliers.

Population pollution[]

The tech flag "Population_Pollution_Inc" has been replaced by effect "Pollu_Pop_Pct_2".

To continue with existing behaviour, add this base effect:

[effect_pollu_pop_base]
type    = "Pollu_Pop_Pct_2"
value	= -100

and an effect like this for every tech that had the 'Population_Pollution_Inc' flag:

[effect_pollu_pop_automobile]
type    = "Pollu_Pop_Pct_2"
value	= 25
reqs    =
    { "type", "name", "range"
      "Tech", "Automobile", "Player"
    }

(Also you probably want to add a helptext to these techs, since the automatically generated one has gone away.)

Gold Upkeep[]

Gold upkeep method is now defined by descriptive words instead of magic numbers. Here the conversion table between old and new values:

Freeciv 2.5 Freeciv 2.6
gold_upkeep_style = 0
gold_upkeep_style = "City"
gold_upkeep_style = 1
gold_upkeep_style = "Mixed"
gold_upkeep_style = 2
gold_upkeep_style = "Nation"

World-ranged tech requirement behaviour changed[]

"Tech" requirements with "World" range no longer implicitly survive every player losing that tech. If you want to preserve the old behavior, you should add an explicit "survives" flag.

   { "type", "name", "range"
     "Tech", "Space Flight", "World"
   }

->

   { "type", "name", "range", "survives"
     "Tech", "Space Flight", "World", TRUE
   }

Local-ranged building requirement behavior changed[]

"Building" requirements with "Local" range no longer implicitly requires that the corresponding requirement is fulfilled in the "City" range too. To preserve the old behavior add the corresponding "City" ranged requirement to each requirement vector with a local building requirement.

   { "type", "name", "range"
     "Building", "City Walls", "Local"
   }

->

   { "type", "name", "range"
     "Building", "City Walls", "Local"
     "Building", "City Walls", "City"
   }

Barbarian unit retirement[]

There is no longer hardcoded barbarian unit retirement. To recreate the barbarian unit retirement and barbarian leader escape, Retire_Pct effects can be used. Below example assumes that both barbarians have also been put to single Barbarian NationGroup. Otherwise one would need separate effects for both Barbarian and Pirate nations

[effect_barb_disappear]
type    = "Retire_Pct"
value   = 10
reqs    =
    { "type", "name", "range", "present"
      "NationGroup", "Barbarian", "Player", TRUE
      "Age", "5", "Local", TRUE
      "CityTile", "Center", "Local", FALSE
    }
; Lone Leader might escape on coast (33% chance)
; Complement of the two effects should be 0.9 * 0.66 = 0.594
; (100 - 59) - 10 = 31
[effect_leader_escape]
type    = "Retire_Pct"
value   = 31
reqs    =
    { "type", "name", "range"
      "UnitType", "Barbarian Leader", "Local"
      "Age", "5", "Local"
      "TerrainClass", "Oceanic", "Adjacent"
      "MaxUnitsOnTile", "1", "Local"
    }

Calendar fragments[]

New calendar related definitions need to be added for sub-year turns. To keep using full years, just set fragments in game.ruleset [calendar] to 0.

Cost of illegal actions[]

If diplomat or caravan fail to execute their orders due to reasons player was not aware beforehand, attempt may cause them movement points. This cost is no longer hardcoded to 1 movement point, but it's controlled by Illegal_Action_Move_Cost effect. To have old one movement point cost for any failing order, add effect like:

[effect_illegal_action_cost]
type    = "Illegal_Action_Move_Cost"
value   = 1

Barbarian Nations[]

Barbarian NationGroup[]

Default nationlist.ruleset now has hidden NationGroup Barbarian and included barbarian nations belong to that group. If you use these, you now may simplify effects written separately for each barbarian nation to be combined to single one where requirement NationGroup Barbarian is used instead of Nation requirements.

Barbarian Nations to be included separately[]

Default nationlist.ruleset no longer contains any barbarian nations. You need to include them directly to your nations.ruleset.

*include "nation/barbarian.ruleset"
*include "nation/pirate.ruleset"

Remember to set embedded_nations accordingly:

embedded_nations = "barbarian", "pirate"

Incite cost of empty cities[]

Hardcoded rule that incite cost is halved for empty cities has been removed. One can have the same rule via Incite_Cost_Pct effects with MaxUnitsOnTile 0 requirement.

[effect_incite_cost_empty]
type = "Incite_Cost_Pct"
value = -50
reqs    =
    { "type", "name", "range", "present"
      "MaxUnitsOnTile", "0", "Local", TRUE
    }

Borders claimed by cities[]

With the adjustments to border claiming rules new field, radius_sq_city_permanent, is required in game.ruleset. Set it to value 0 to keep old behavior.

Caravan unit type flags unhardcoded[]

There is no longer hardcoded flags TradeRoute or HelpWonder. Define them as user unit type flags if you need them in your trade route or help wonder action enablers.

Nuke_Proof effect[]

The Nuke_Proof effect, used for buildings like SDI Defense, is no longer hardcoded to be suppressed for explosions triggered by a city's owner, their teammates, or their allies.

To recreate previous behavior exactly needs an effect like:

[effect_sdi_defense]
type    = "Nuke_Proof"
value   = 100
reqs    =
    { "type", "name", "range", "present"
      "Building", "SDI Defense", "City", TRUE
      "DiplRel", "Is foreign", "Local", TRUE
      "DiplRel", "Team", "Local", FALSE
      "DiplRel", "Alliance", "Local", FALSE
    }

(However, supplied rulesets no longer include the "Alliance" clause, since it allowed some epic backstabbing.)

Frozen terrains[]

There is a new terrain flag "Frozen". If you don't add it to any terrains, your rulesets will behave as before.

Consider adding it to terrains like Glacier and Arctic that are generated at the poles. It has these effects:

  • Poles will appear grey rather than green on the minimap (even without the terrain relief layer).
  • The new optional terrain.ruleset parameters 'thaw_requirement' and 'freeze_requirement' apply to conversions between Frozen and non-Frozen terrain (by units, climate change, etc). If you want no restrictions on such conversions (as before), set both of these to zero. If you leave them at the defaults, it will not be possible to change between Frozen and non-Frozen terrain.

UI strings[]

Action Names[]

You should define UI names of the diplomat and caravan actions your ruleset is using in game.ruleset actions -section. See classic ruleset for the list of traditional actions.

Base building commands by gui_type[]

You should provide extraui -section to terrain.ruleset with entries to show in the UI for the commands to build any base by their gui_type; Fortress or Airbase.

[extraui]
; Player visible names of the base gui types.
ui_name_base_fortress = _("?gui_type:Build Land base")
ui_name_base_airbase = _("?gui_type:Build Airforce base")

Gfx tags[]

Hardcoded activity tags[]

In addition to unhardcoding number of extras related tags, the name of the still hardcoded terrain changing Mine activity has changed to Plant and activity icon tag is now unit.plant. If you have referenced old unit.mine tag in some other context, you may want to update those references. Supplied rulesets and tilesets do still have unit.mine tag, but it refers to an extra named Mine.

Help text[]

Combat bonus help[]

A unit type's combat bonuses is automatically listed in its help text. To avoid that a help text is auto generated for a combat bonus set its quiet property to TRUE. This is useful when the bonus already is documented in the help text. It is also useful when the generated help text is ugly or misleading.

See also[]

Editing Rulesets
Editing BuildingsEditing CitiesEditing EffectsEditing GameEditing Governments
Editing NationsEditing StylesEditing TechsEditing TerrainEditing Units
Update from 2.2 to 2.32.3 to 2.42.4 to 2.52.5 to 2.62.6 to 3.03.0 to 3.13.1 to 3.23.2 to 3.3
Advertisement