Changes in what a 3.1 ruleset can do

Contribute, display and discuss rulesets and modpacks for use in Freeciv here.
User avatar
Alien Valkyrie
Elite
Posts: 513
Joined: Sun Feb 10, 2013 10:21 pm
Location: Stuttgart, Germany

Re: Changes in what a 3.1 ruleset can do

Post by Alien Valkyrie »

Lexxie wrote:For example, casus belli if someone sentries
"Sentry" is a state without any gameplay effects whatsoever. If you add repercussions for sentrying, players will simply have units skip their turn, every turn. The only thing it changes is making things more cumbersome for players. The same thing applies to Goto orders, where you could instead move the unit by hand every turn, or auto-explore orders, or "Connect with road/irrigation/whatever" orders, and so on and so forth. That's why they're not supposed to have any rule significance – so that they can basically be used as shorthand to reduce the need for micromanaging.

I agree that having more actions and unit states with ruleset-defined effects would be useful, but trying to shoehorn Sentry into that role is bs.

Also, cut out the melodramatic politics-y talk. It doesn't help anyone, it doesn't add to the discussion, the only thing it does is make people take you less seriously. If you have concerns, voice them, but please don't do... whatever this is.
Lexxie wrote:
sveinung wrote:User actions can now target tile extras See Feature #918887

You can now make user actions where the action's enablers target_reqs is evaluated against the target tile's extra owner by setting its target_kind to "tile extras". This makes player requirements like local DiplRel requirements and player range target requirements apply to the tile's extra owner.
I'm trying to understand this. Does it mean, for example, you found an enemy buoy in your allied territory, so you can Pillage the buoy without making an incident for pillaging in allied territory? I'm very interested to know an example of this, to think about testing it. Thanks!
I think that is the basic idea, except this is for user actions, i.e. rather than the hard-coded Pillage, this is for things that don't have a regular effect, but instead only trigger a lua script. So you can now make your own actions that depend on the extra's owner rather than the tile's owner.
~ AVL
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

Lachu wrote:Will it now be possible to build camp/city only on cave on other special (for example giving food)?
That is possible already in 3.0. Use an action enabler for "Found City" with an Extra requirement.
cazfi
Elite
Posts: 3069
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.1 ruleset can do

Post by cazfi »

Caedo wrote:rather than the hard-coded Pillage
We're talking about 3.1 here. Pillage is not hard-coded, but action enabler controlled action. So what Lexxie suggested should work AFAIK.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

Is non-existence a state, or is it the state of having no state; and if it's the state of having no state, what essence or being is it that has "the state of not having a state?"
Non existence to "Activity" requirements is the idle state. A unit in the sentry state is seen as that.
"The current rules?" Whose rules? Freeciv is a generalised engine for many rules.
The current hard coded rules. Sentry is an implementation detail for the user interface.
Lexxie wrote:But somehow it led to reverting the super awesome excellent idea of the great new ACTION_SENTRY action. And for ACTIVITY_SENTRY to transcend mere human mortals and be in the forbidden heaven of the gods. I propose we open this conversation up again. Maybe I'm really wrong in my current thinking and would like people to point out other arguments, methods, and so on.
Specific rule changes I add support for in the engine but then forget about tends to end up in your rulesets. I assume this is because you often see the same possibilities that I see and - unlike me - take time to implement and balance them. I therefore suspect that what you saw when looking at ACTION_SENTRY was something closer to my end goal than to the current thing. My end goal is ruleset defined activities (or similar) controlled by ruleset defined actions with user interface hints that allows the clients to tie them to server side client state. (The hints aren't as useful in your case since you control both the ruleset and the client of your users)

There are two paths to this. One is hacky. My original plan was to do this the non hacky way. Then the Activity requirement ended up giving access the Sentry, moving it from state for the user interface to something a rule can depend on and therefore real game state. This began the hacky path so I continued it with the "Sentry" action. I'm now back to the original plan of going one full step at the time rather than multiple steps halfway done at once and then cleaning up the result. My next step will either be a ruleset defined activity controlled by an action that can be used as a requirement of the Galactic Federation Fuel Pod Aid Package to be captured by the recipient or to start implementing hints for reasoning/ai/user interface.
Last edited by sveinung on Sat Feb 06, 2021 12:11 am, edited 1 time in total.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

Lexxie wrote:I'm trying to understand this. Does it mean, for example, you found an enemy buoy in your allied territory, so you can Pillage the buoy without making an incident for pillaging in allied territory? I'm very interested to know an example of this, to think about testing it. Thanks!
The incident would go the the extras owner if the action is extras targeted and to the tile owner if the action is tile targeted. Pillage is at the moment tile targeted. I plan to add ruleset variables to allow you to choose the target kind for non user actions too. I will need this for generalized actions anyway. I could start with pillage as the first example if you want it. Pillage should at least be able to support tile and extra tiles targets.
Last edited by sveinung on Sat Feb 06, 2021 12:11 am, edited 1 time in total.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

"Conquer Extras" action enabler control See Feature #850508

You can now add restrictions to when a unit should be allowed to conquer a tile's extras (forts, castles, etc). You can also allow extra capture against extras belonging to players you aren't at war with as that restriction moved to the ruleset.

Note that only territory claiming extras can be captured.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

Action target kind (but not sub target kind) access in the Lua API See osdn #41446

Action objects now have a method for getting the action's target kind as a string called target_kind().

Example: Call a different function stored in a table you have called target_describer based on action target kind.

Code: Select all

function action_started_callback(action, actor, target)
  log.normal(_("%d: %s (rule name: %s) performed by %s %s (id: %d) on %s"),
             game.current_turn(),
             action:name_translation(),
             action:rule_name(),
             actor.owner.nation:name_translation(),
             actor.utype:name_translation(),
             actor.id,
             target_describer[action:target_kind()](target))
end
The full example, including the filling out target_describer, can be found in the Lua section of 3.1's doc/README.actions
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

Tile extra owner access in the Lua API See osdn #41445

Tile objects now have a method for getting the owner of an extra on that tile called extra_owner. It takes the name of the extra to check as a parameter even if all extras at a tile currently has the same owner for forward compatibility reasons.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

An action can now block a regular move See Feature #919110

An action being enabled against a tile can now make regular moves illegal. A list called move_is_blocked_by is stored in game.ruleset's actions section. It contains the names of all actions that will block a regular move.
sveinung
Elite
Posts: 548
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Post by sveinung »

More flexible action blocks action See Feature #919172

In 2.6 and 3.0 you could specify that certain actions would block a hard coded list of other actions by setting a ruleset variable force_name_of_action to true. This has been replaced by each action that could be blocked by the force_x variables getting a list over the actions that block them.

The new blocked_by ruleset variables are "enter_marketplace_blocked_by", "bombard_blocked_by", "bombard_2_blocked_by", "bombard_3_blocked_by", "explode_nuclear_blocked_by", "nuke_city_blocked_by", "nuke_units_blocked_by", "attack_blocked_by", "suicide_attack_blocked_by", "conquer_city_blocked_by" and "conquer_city_2_blocked_by".

You can now make one of the actions with a "force_x" variable block only a subset of the actions it used to block with force_x being true. You can also have an action blocked by an action it couldn't be blocked by before.
Post Reply