Page 11 of 14

Re: Changes in what a 3.0 ruleset can do

Posted: Wed May 17, 2017 2:09 am
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)?

Re: Changes in what a 3.0 ruleset can do

Posted: Wed May 17, 2017 2:59 am
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"

Re: Changes in what a 3.0 ruleset can do

Posted: Wed May 17, 2017 11:13 am
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.

Re: Changes in what a 3.0 ruleset can do

Posted: Fri May 19, 2017 2:16 pm
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.

Re: Changes in what a 3.0 ruleset can do

Posted: Fri May 19, 2017 10:07 pm
by cazfi
Tile:change_terrain() has been added to the scripting API: Feature #657140

Re: Changes in what a 3.0 ruleset can do

Posted: Sat May 20, 2017 7:38 am
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

Re: Changes in what a 3.0 ruleset can do

Posted: Sat May 20, 2017 12:30 pm
by cazfi
Tile:is_enemy(against) added to scripting API for checking if tile is occupied by enemy: Feature #661538

Re: Changes in what a 3.0 ruleset can do

Posted: Wed May 24, 2017 10:38 am
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").

Re: Changes in what a 3.0 ruleset can do

Posted: Mon Jun 26, 2017 1:00 pm
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.

Re: Changes in what a 3.0 ruleset can do

Posted: Mon Jun 26, 2017 1:31 pm
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.