Changes in what a 3.0 ruleset can do

Contribute, display and discuss rulesets and modpacks for use in Freeciv here.
bard
Veteran
Posts: 121
Joined: Fri Jun 14, 2013 2:00 pm

Re: Changes in what a 3.0 ruleset can do

Post by bard »

Scenarios can be made so they work with multiple rulesets.
Thanks for that.
cazfi wrote:What little I've had time to do for 3.0 ruleset format lately have been about two concepts:
1) Resources as extras (merging resources to extras)
2) (Trade) Goods - trade route has a property that it's about certain Good. As the other new trade route property, direction, this still has no gameplay effect at all but just gets listed in the information of the route
I'd like to know more about this trade based on goods, if possible.
In 2.6 it is possible to trade the effect of resources, thanks to the condition range "Traderoute". I'm working on a ruleset that uses this feature, and I'd like to make it as compatible as possible with the features planned for 3.0, if already known.
Will it be possible to send the goods only to the city directly connected by a trade route, or also to other cities connected to the same network of trade routes? The bonus of goods are shared (both cities get the bonus) or exclusive (when one city gets the bonus, the other city loses it)?
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Post by cazfi »

bard wrote:In 2.6 it is possible to trade the effect of resources, thanks to the condition range "Traderoute". I'm working on a ruleset that uses this feature, and I'd like to make it as compatible as possible with the features planned for 3.0
"Traderoute" range is not going anywhere, so if you have a ruleset feature using its semantics it should still work in 3.0. Goods are a different concept, for which resources are only one possible requirement. Each traderoute carry exactly one Good. At the moment it's randomly chosen from the ones possible when traderoute is established, but in the future it might be selected by the user.

Documentation of the current stat of Goods implementation looks like this

Code: Select all

; /* <-- avoid gettext warnings
;
; Goods types:
;
; name                    = translatable name as seen by user
; rule_name               = (optional) name for savegames, rulesets etc; if not
;                           present, 'name' is used. Since the name used in
;                           savegames must not change, use this when renaming
;                           an good after a ruleset has been released.
; reqs                    = requirements for a city to provide goods (see effects.rul
eset
;                           and README.effects for help on requirements)
; from_pct                = Income for the sending end of the trade route. Default is
 100%
;                           This value is applied to both ends of bidirectional route
s.
; to_pct                  = Income for the receiving end of the trade route. Default 
is 100%
;                           This value is not used at all in case of bidirectional ro
utes.
; flags
;   - "Bidirectional"     = Trade route carrying the goods does not have "from" and "
to"
;                           ends, but both ends are considered the same.
;   - "Depletes"          = Trade route gets cancelled when the source city cannot pr
ovide
;                           goods any more. Bidirectional routes gets cancelled if ei
ther
;                           one of the involved cities cannot provide goods.
; helptext                = Optional help text string; should escape all raw
;                           newlines so that xgettext parsing works
;
; */ <-- avoid gettext warnings
Sandbox ruleset already has quite complex Goods rules in S3_0 as an example. Here's one snippet:

Code: Select all

[goods_gems]
name  = _("Gems")
reqs  =
    { "type", "name", "range"
      "Extra", "Gems", "City"
    }
from_pct = 135
to_pct   = 100
flags = "Depletes"

[goods_jewelry]
name = _("Jewelry")
reqs =
    { "type", "name", "range"
      "Good", "Gems", "City"
    }
from_pct = 250
to_pct   = 150
flags = "Depletes"
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Post by sveinung »

"Incite City" action split. See hrm Feature #660927

The "Incite City" action has been split in "Incite City" and "Incite City Escape". The former action consumes the actor unit. The latter action gives the actor unit a chance to escape. ("Incite City" used to consume the actor unit unless it had the Spy unit type flag. In that case it would give the spy a chance to escape.)

This makes it possible to create a ruleset where all actor units, including those with the Spy utype flag, are consumed when inciting a foreign city to revolt and join the actor's side. It makes possible a ruleset where all actor units, including those without the Spy utype flag, will try to escape after inciting a revolt. It also makes more complex rules, like "inciting a revolt consumes the unit unless the city belongs to a democracy", possible.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Post by sveinung »

"Suitcase Nuke" action split. See hrm Feature #661654

The "Suitcase Nuke" action has been split in "Suitcase Nuke" and "Suitcase Nuke Escape". The former action consumes the actor unit. The latter action gives the actor unit a chance to escape. ("Suitcase Nuke" used to consume the actor unit unless it had the Spy unit type flag. In that case it would give the spy a chance to escape.)

This makes it possible to create a ruleset where all actor units, including those with the Spy utype flag, are consumed when suitcase nuking a city. It makes the opposite (everyone, including non Spy units, escapes) possible too. It also makes more complex rules, like "only veterans has a chance of escaping after placing the suitcase", possible.
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Post by cazfi »

Tile:change_terrain() has been added to the scripting API: Feature #657140
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Post by cazfi »

This one is about scenario, not ruleset property, but listing it here anyway.

Individual units have a "stay" property. It tells if a unit can move normally, or is it prohibited from moving, i.e., if scenario author has meant it to stay defending the spot it's on. Currently this valuea can only be changed by manually editing the scenario file, but plan is to add lua scripting control and editor support for it. Feature #661437
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Post by cazfi »

Tile:is_enemy(against) added to scripting API for checking if tile is occupied by enemy: Feature #661538
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Post by sveinung »

ServerSetting requirement type. See hrm Feature #648804

Allows you to check the current value of visible game rule related server settings. Only server settings with a binary value (enabled or disabled) are currently supported.

This allows you to adjust the rules based on the server settings currently in use.

Example: A unit stack only protects against "Sabotage Unit" when the server setting killstack is enabled.

Code: Select all

[actionenabler_sabotage_unit]
action = "Sabotage Unit"
actor_reqs    =
    { "type",          "name",          "range", "present"
      "UnitFlag",      "Spy",           "Local", TRUE
      "DiplRel",       "War",           "Local", TRUE
      "UnitState",     "OnLivableTile", "Local", TRUE
      "MinMoveFrags",  "1",             "Local", TRUE
      "ServerSetting", "killstack",     "World", FALSE
    }
target_reqs    =
    { "type",         "name",   "range", "present"
      "CityTile",     "Center", "Local", FALSE
      "MinHitPoints", "2",      "Local", TRUE
    }

[actionenabler_sabotage_unit_killstack_enabled]
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
      "MinHitPoints",   "2",      "Local", TRUE
      "MaxUnitsOnTile", "1",      "Local", TRUE
    }
The two action enablers are identical except that the first requires that the ServerSetting killstack is disabled (present is FALSE) while the second requires that the target unit is alone at its tile ("MaxUnitsOnTile", "1", "Local").
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Post by sveinung »

"Steal Maps" action split. See hrm Feature #662943

The "Steal Maps" action has been split in "Steal Maps" and "Steal Maps Escape". The former action consumes the actor unit. The latter action gives the actor unit a chance to escape.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Post by sveinung »

The "Attack" action is now unit stack targeted. See hrm Feature #672612

The target requirement vector of action enablers for "Attack" is now evaluated against each unit in the target stack.
Post Reply