Changes in what a 3.0 ruleset can do

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

Re: Changes in what a 3.0 ruleset can do

Postby bard » Wed May 17, 2017 2:09 am

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: 1269
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Postby cazfi » Wed May 17, 2017 2:59 am

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: 412
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Wed May 17, 2017 11:13 am

"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: 412
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Fri May 19, 2017 2:16 pm

"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: 1269
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Postby cazfi » Fri May 19, 2017 10:07 pm

Tile:change_terrain() has been added to the scripting API: Feature #657140

cazfi
Elite
Posts: 1269
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Postby cazfi » Sat May 20, 2017 7:38 am

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: 1269
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.0 ruleset can do

Postby cazfi » Sat May 20, 2017 12:30 pm

Tile:is_enemy(against) added to scripting API for checking if tile is occupied by enemy: Feature #661538

sveinung
Elite
Posts: 412
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Wed May 24, 2017 10:38 am

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: 412
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Mon Jun 26, 2017 1:00 pm

"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: 412
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.0 ruleset can do

Postby sveinung » Mon Jun 26, 2017 1:31 pm

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.