Changes in what a 2.6 rule set can do

[sveinung]

Allowing the action "Targeted Steal Tech" no longer allows stealing a random tech See patch #5757

This makes it possible to make it legal to steal a specific tech ("Targeted Steal Tech") without also making it legal to steal a random tech ("Steal Tech") .

Possible motivation for a rule like that: The probability of successfully stealing a specific tech is lower than the probability of successfully stealing a random tech.

[sveinung]

Allowing the action "Targeted Sabotage City" no longer allows sabotaging a random city improvement. See patch #5540

[sveinung]

It is now possible to kill a unit from Lua without doing anything else with it. See patch #5894

Details
Unit objects now have a kill(reason, killer) method. The edit module has unit_kill(unit, reason, killer). Unit is the unit that should die. Reason is the reason why the unit was lost. (See the unit_lost Lua signal.) Killer is the player that should be credited with the kill.

Valid reasons why the unit died can be found in the unit_loss_reason enumeration defined in the file server/unittools.h in the Freeciv source code. At the moment they are "killed", "retired", "disbanded", "barb_unleash", "city_lost", "starved", "sold", "used", "executed", "eliminated", "editor", "nonnative_terr", "player_died", "armistice", "sdi", "detonated", "missile", "nuke", "hp_loss", "fuel", "stack_conflict", "bribed", "captured", "caught" and "transport_lost".

Usage idea
Implement a building that defends against hostile spy actions. Use the action_started_unit_city signal. It is called before the action can cause any harm. Give the building a 50% probability of eliminating a unit trying to do any action the building protects against. If the unit is eliminated it won't be able to perform the action. Warning: The 50% probability of failure won't show up in the client of the player trying to perform the action.

[sveinung]

It is now possible to check if a tile is claimed (owned) using the requirement system. See patch #5929

Example:

Code: Select all

    { "type",      "name",     "range", "present"
      "CityTile", "Claimed", "Local", TRUE
    }

[sveinung]

What an action is called in the action selection dialog and what mnemonic it should have can now be set in the ruleset. See patch #4582, patch #5615, patch #5651, patch #5717, patch #5769 and bug #23127

The mnemonics of some actions had to change in 2.6 because a custom ruleset may enable them all at the same time. Adding this patch allowed setting those that wouldn't appear at the same time to their old mnemonics in the bundled rulesets. That was the primary motivation for adding this feature to 2.6.

The feature can also be used to give ruleset specific action names. A word of warning: other texts related to the action aren't ruleset configurable. Even if you tune the action UI names to preserve the suspension of disbelief unconfigurable texts may still break it.

The action UI names are set in the actions section of game.ruleset. If an action UI name isn't set it a default name is used.

Example 1: A ruleset where the action to sabotage a unit and the actions to sabotage a random city improvement never happens at once can use the same mnemonic for them both. In the case below it is 'S'.

Code: Select all

[actions]
ui_name_sabotage_unit = _("%sSabotage Enemy Unit%s")

ui_name_sabotage_city = _("%sSabotage City%s")

Example 2: A ruleset with a wonder called Federal Reserve. Its owner can send a Diplomat to the capital of any player he isn't at war with and... accept... a deposits of up to 90% of the other player's gold.

Set the action name.

Code: Select all

[actions]
ui_name_steal_gold = _("Accept %sGold Deposit%s")

Add the action enabler. Notice that the ruleset still refers to the action as "Steal Gold".

Code: Select all

[actionenabler_federal_reserve]
action = "Steal Gold"
actor_reqs    =
    { "type",   "name", "range", "present"
      "Building", "Federal Reserve", "Player", TRUE
      "UnitType", "Diplomat", "Local", TRUE
      "DiplRel", "War", "Local", FALSE
    }
target_reqs    =
    { "type",   "name", "range", "present"
      "Building", "Palace", "City", TRUE
    }

Set limit on how much may be stolen.

Code: Select all

[effect_steal_gold_capital]
type   = "Max_Stolen_Gold_Pct"
value   = 90
reqs   =
  { "type", "name", "range", "present"
    "Building", "Palace", "City", TRUE
  }

On top of this the Federal Reserve wonder must be added to buildings.ruleset

[JTN]

As of patch #6036, the amount of territory a city can claim permanently (can't be stolen by a stronger border source) is under ruleset control.

Up until now, the border rule was supposed to be "Once claimed, a tile that can be directly worked by a city can not change ownership unless the city does (or is destroyed)". Due to a bug that hasn't actually been the case since 2.3.0; that bug will be fixed in 2.5.1 (with no ruleset or setting control).

In 2.6, it will be controllable via the radius_sq_city_permanent option.

• 0 gives the current (fixed) behaviour
• A large negative value gives the behaviour the bug was giving (only city center is immune from stealing)
• Other effects are possible; for instance the inner ring of workable tiles can be locked to the first claimer, but the outer ring can be stolen, using a small negative value

[Alien Valkyrie]

As of patch #6036, the amount of territory a city can claim permanently (can't be stolen by a stronger border source) is under ruleset control.

Up until now, the border rule was supposed to be "Once claimed, a tile that can be directly worked by a city can not change ownership unless the city does (or is destroyed)". Due to a bug that hasn't actually been the case since 2.3.0; that bug will be fixed in 2.5.1 (with no ruleset or setting control).

In 2.6, it will be controllable via the radius_sq_city_permanent option.

• 0 gives the current (fixed) behaviour
• A large negative value gives the behaviour the bug was giving (only city center is immune from stealing)
• Other effects are possible; for instance the inner ring of workable tiles can be locked to the first claimer, but the outer ring can be stolen, using a small negative value

Will a positive value of radius_sq_city_permanent make the city permanently claim tiles outside of its workable tile radius? As in, the radius_sq for permanently claimed tiles is radius_sq_city_permanent + City_Radius_Sq effect?

[JTN]

Will a positive value of radius_sq_city_permanent make the city permanently claim tiles outside of its workable tile radius?

Yes, that's supposed to work.

As in, the radius_sq for permanently claimed tiles is radius_sq_city_permanent + City_Radius_Sq effect?

Actually radius_sq_city + sum(City_Radius_Sq effects) + radius_sq_city_permanent.

[sveinung]

The rule that a unit can't poison the water supply of a domestic city is no longer hard coded. See patch #6063

This can be used to allow scorched earth tactics. (Not as efficient as a hypothetical "burn city" action would be but better than nothing)

It can also be used to implement rules like: If the "United Nations" is built show the message "This horrible accident shocks the international community. You receive 25 gold in foreign aid to improve your water treatment system." and give 25 gold via Lua.

[sveinung]

The rule that a unit can't sabotage a domestic city or unit is no longer hard coded. See patch #6067

The rule that the actions "Sabotage City", "Targeted Sabotage City" and "Sabotage Unit" must have a foreign victim is no longer hard coded.

This makes the following rule possible: Each time an act of sabotage happens the victim gets 30 gold and is shown the following message: "The Committee Against Conspiracy Theories raise 30 gold from loyal donors to help you fight the terrorist saboteur conspiracy." This happens no matter who really was behind the sabotage.