Changes in what a 3.1 ruleset can do

Contribute, display and discuss rulesets and modpacks for use in Freeciv here.
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.1 ruleset can do

Post by cazfi »

Base flag "NoAggressive" has been turned to an extra flag by the same name. Feature #897492.

This means that any extra, not just bases, can have the "NoAggressive" property.
This was also the last remaining base flag, and with it gone entire base flags concept has been dropped.
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 »

Update (2021-02-21): The "Sentry Unit" action is gone. See Feature #918768

"Sentry Unit" action enabler control See Feature #879674

You can now control when a unit should be allowed to sentry. This may be useful if you have rules that give advantages or disadvantages based on a unit's sentry state and wish to control a unit's access to those.

Warning: You should probably just enable this action without any requirements. Sentry is, in the current rules, server side client state: a user interface detail that is completely irrelevant for the rules. The server will set it when a unit boards a transport to avoid the passenger getting focus while transported. The client will end its "Return to Nearest City" order with it if the unit needs to heal. The server will unset it to bring the player's attention to events like a hostile unit moving too close, restored hit points and the unit being bounced. If you block this with a rule a user could just modify his client to do the same and even get his own unit state changes into savegames using client only data.
Last edited by sveinung on Mon Feb 01, 2021 9:59 am, edited 1 time in total.
Ignatus
Elite
Posts: 644
Joined: Mon Nov 06, 2017 12:05 pm
Location: St.Petersburg, Russia
Contact:

Re: Changes in what a 3.1 ruleset can do

Post by Ignatus »

sveinung wrote:Warning: You should probably just enable this action without any requirements. Sentry is, in the current rules, server side client state: a user interface detail that is completely irrelevant for the rules.
Was it a good idea to make us to enable what we don't ever want to disable? Yes, sentrying has gameplay value and might get more of it, but its main reason is to stop units grabbing focus until certain events happen, and we need it for any game (side note: with my modded 2.6 client I often use single "wait full mp" order to silence units until turn end). Rigid rules have their advantages that are countered seemingly by nothing here. You didn't have to make it an action to control things depending on "Sentry" activity. Making it an action in the protocol is comfortable, but some guy wrote a text not to make an action what is not really an action, with auto-settlers as counter-example, and I don't see a cardinal difference...
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.1 ruleset can do

Post by cazfi »

New Popcost_Free effect can be used to make a city not to shrink in size when it builds units with population cost Feature #659540
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: Changes in what a 3.1 ruleset can do

Post by cazfi »

Added minimum_turns property for multipliers. It tells how long multiplier/policy must be in effect before it can be changed again. Feature #908582
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 »

"Extras Owned" tile property See Feature #918819

You can now create a rule than an action only can be done if the target tile has a Buoy that really grants vision to someone since it has an owner to grant vision to. This rule works even if the Buoy is at an unclaimed tile.
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 »

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.
Lachu
Elite
Posts: 472
Joined: Sat May 04, 2013 2:19 pm

Re: Changes in what a 3.1 ruleset can do

Post by Lachu »

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.
Will it now be possible to build camp/city only on cave on other special (for example giving food)?
Lexxie
Veteran
Posts: 127
Joined: Fri Jun 23, 2017 4:18 pm

Re: Changes in what a 3.1 ruleset can do

Post by Lexxie »

I just found out a new feature I was coding to use, got reverted because of comments here.
Ignatus wrote:
sveinung wrote:Warning: You should probably just enable this action without any requirements.
That's fine as long as it doesn't DISABLE any other functionalities tied to actions, right?
Sentry is, in the current rules, server side client state: a user interface detail that is completely irrelevant for the rules.

"The current rules?" Whose rules? Freeciv is a generalised engine for many rules.

In the current rules of Freeciv-Web, sentry is absolutely relevant to mechanics and gameplay. You invite some philosophical argument from Sartre or something: 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?" Back to the practical world, this is a REAL state and entering this state is a real action. The minute you disallow rulesets or clients access to these things, you are creating "Heavenly States" which transcend, forbid, create circumvention, exploitation, and blocked abilities. You disallow rulesets, clients, and even new server code, from handling conditions that may arise from that state.
I don't see disabling sentry in our rules to be likely. But that result of this comment was something else.

I can think of hypothetical rulesets that would want this. Who knows, Sentry is a requirement of the Galactic Federation Fuel Pod Aid Package, for it to be captured by the recipient. Otherwise it's assumed to be under encrypted deadlock security state. I'm not making that ruleset, but someone might.

I'm not really concerned about disabling ability to sentry. I'm concerned about what happened after you said that. You suggested the action should always be enabled...

But now it's not an action at all, and we're FORBIDDEN from looking for it in requirements as an activity. Are you sure this is what your comment wanted, Ignatus/ All potential functionality, conditions, triggers, future features, which are tied to activities and actions, to get lost? For Sentry to be Transcendental Heavenly State that is the Exception, and transcends all rulesets, clients, and possible new server features?

At FCW, we want to be able to consider ALL states, actions, and situations. The ability to cover ALL states and ALL actions, inclusively, as a way to trigger other things.

For example, casus belli if someone sentries, fortifies, roads, moves, or builds a base in your territory. Basically, has any state or does any action at all. Let's not make sentry the One Pure State that is transcendent all others, is exceptional to detection, regulation, or condition. The state of Zen or existing-without existing. Once you make one of the states transcendent, you allow the unit in that state to transmogrify into heaven in the existing but not existing state.

I don't see though, how Ignatus comment really wanted all that. 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.

https://github.com/freeciv/freeciv/comm ... 159620b5a5

Ban "Sentry" in unit "Activity" requirements. This makes it pure server side
client state again. This makes Sentry a non action. Remove the "Sentry Unit"
action introduced in hrm Feature #879674.

I don't think the rules should change based on what the client does to
implement a better user interface. Not having to think of upgrading rulesets
that requires it gives us more freedom to move it to a server side client
state sub system in the future.

Ban "Sentry" from appearing in any "Activity" requirement. Make the
requirement system see a unit performing "Sentry" as being idle. Remove the
"Sentry Unit" action.

This reverts commit fc6101e.

Done because of negative feed back on the "Sentry Unit" action from Ignatus
on the Freeciv forum.
Lexxie
Veteran
Posts: 127
Joined: Fri Jun 23, 2017 4:18 pm

Re: Changes in what a 3.1 ruleset can do

Post by Lexxie »

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!
Post Reply