Page 10 of 14

Re: Changes in what a 3.0 ruleset can do

Posted: Thu Nov 10, 2016 11:54 am
by sveinung
Auto attack "Provoking" unit type flag. See patch #7943

The new unit type flag "Provoking" now controls what unit types should be auto attacked even if the attacker has better odds defending against it than attacking it. The old hard coded rule was to autoattack diplomats and transporters even if the defense odds were better.

You can now make new unit types like GamleLoss units provoke auto attacks, make units only capable of transporting innocent units non provoking or make all units non provoking.

Re: Changes in what a 3.0 ruleset can do

Posted: Sun Nov 13, 2016 10:43 am
by cazfi
Added support for extras that hide units inside them from opponents: patch #4101

Re: Changes in what a 3.0 ruleset can do

Posted: Tue Apr 04, 2017 3:58 am
by bard
Thank you for all the info in this topic. There are lots of new features that I'm eager to start testing.
One question, is it possible to use action enablers to allow/disallow certain diplomatic agreements?
For example, disallow interchange of maps until discovery of map making. Or disallow to create an alliance until you have created a real embassy.

Re: Changes in what a 3.0 ruleset can do

Posted: Tue Apr 04, 2017 9:10 am
by Alien Valkyrie
bard wrote:Thank you for all the info in this topic. There are lots of new features that I'm eager to start testing.
One question, is it possible to use action enablers to allow/disallow certain diplomatic agreements?
For example, disallow interchange of maps until discovery of map making. Or disallow to create an alliance until you have created a real embassy.
Since diplomatic agreements aren't actions performed by units, I'd assume that action enablers aren't the way to go for these. I'm still hoping that some time in the future, the actor ↔ target dynamic is extended to effects (or maybe even the entirety of effects and action enablers generalized into one higher level), which could (presumably) make this, as well as combat bonuses, comparatively simple to implement ruleset-wise.

Re: Changes in what a 3.0 ruleset can do

Posted: Tue Apr 04, 2017 9:14 pm
by bard
Caedo wrote: Since diplomatic agreements aren't actions performed by units, I'd assume that action enablers aren't the way to go for these. I'm still hoping that some time in the future, the actor ↔ target dynamic is extended to effects (or maybe even the entirety of effects and action enablers generalized into one higher level), which could (presumably) make this, as well as combat bonuses, comparatively simple to implement ruleset-wise.
You might be right about action enablers, and I agree your suggestion would be much better for us ruleset modders, but I guess such extended effects would affect performance. I'm still amazed how every freeciv version introduces so many moddable features without worsening the performance (v2.6 runs better in my old laptop than previous versions).

Another question: when I open a ruleset file, is there any way to differentiate a hardcoded flag (for example TradeRoute), from a custom flag that do not include any hardcoded effect (for example AirAttacker)?
I'm thinking of the new "Infra" flag, compared to "Airbase" (in units.ruleset). They look the same, but "Infra" does not seem to require an specific req in terrain.ruleset, while "Airbase" does.

Re: Changes in what a 3.0 ruleset can do

Posted: Tue May 02, 2017 12:32 pm
by sveinung
"Investigate City" action split. See hrm Feature #655676

The "Investigate City" action has been split in "Investigate City Spend Unit" and "Investigate City". The former action consumes the actor unit. The latter action doesn't. ("Investigate City" used to consume the actor unit unless it had the Spy unit type flag)

This makes it possible to create a ruleset where no actor units, including those without the Spy utype flag, are consumed during city investigation. It makes a ruleset where all actor units, including those with the Spy utype flag, are consumed during city investigation, possible. It also makes rules like "investigating a city with a police station consumes the actor unit" (assuming a visible Police Station) possible.

Re: Changes in what a 3.0 ruleset can do

Posted: Tue May 02, 2017 1:14 pm
by sveinung
"Establish embassy" action split. See hrm Feature #656188

The "Establish Embassy" action has been split in "Establish Embassy Stay" and "Establish Embassy". The former action consumes the actor unit. The latter action doesn't. ("Establish Embassy" used to consume the actor unit unless it had the Spy unit type flag)

This makes it possible to create a ruleset where all actor units, including those with the Spy utype flag, are consumed during embassy establishing. It makes a ruleset where no actor units, including those without the Spy utype flag, are consumed during embassy establishing possible. It also makes more complex rules, like "establishing an embassy during war consumes the actor unit", possible.

Re: Changes in what a 3.0 ruleset can do

Posted: Fri May 05, 2017 5:31 am
by cazfi
Extras have a visibility_req property. It's a single tech, not requirement vector. The extra is visible only to players knowing that tech. It only affects visibility of the extra. For the purpose of all other rules, it's still there (client side may miscalculate things since it doesn't know the extra to be there)

Re: Changes in what a 3.0 ruleset can do

Posted: Fri May 05, 2017 4:01 pm
by cazfi
Scripting API has three new calendar access functions; game.current_year(), game.current_fragment(), and game.current_year_text()

Re: Changes in what a 3.0 ruleset can do

Posted: Mon May 15, 2017 7:11 pm
by cazfi
Scenarios can be made so they work with multiple rulesets.

This feature is not exposed to the editor, but requires manual editing of the scenario file. If the feature is enabled ("scenario.ruleset_locked" is FALSE), scenario should list some capability strings, which any compatible ruleset should in turn define. We're still to define exact criterion for the capabilities that supplied rulesets will have.

For example all of classic, civ2civ3, and civ2 ruleset have:

Code: Select all

capabilities = "minimum-default-sets"
civ1 ruleset does not have that capability as it has less techs and units than what belongs to "minimum-default-sets"

Scenario file that has units, terrains, buildings, etc. from the minimum-default-sets only, can define:

Code: Select all

[scenario]
ruleset_locked=FALSE
ruleset_caps="+minimum-default-sets"
Such a scenario can be loaded to a server that uses any of classic, civ2civ3, or civ2 (or any other compatible) ruleset, but not to one with civ1 ruleset.