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.
Changes in what a 3.1 ruleset can do
Re: Changes in what a 3.1 ruleset can do
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.
"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.
Re: Changes in what a 3.1 ruleset can do
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...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.
Re: Changes in what a 3.1 ruleset can do
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
Re: Changes in what a 3.1 ruleset can do
Added minimum_turns property for multipliers. It tells how long multiplier/policy must be in effect before it can be changed again. Feature #908582
Re: Changes in what a 3.1 ruleset can do
"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.
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.
Re: Changes in what a 3.1 ruleset can do
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.
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.
Re: Changes in what a 3.1 ruleset can do
Will it now be possible to build camp/city only on cave on other special (for example giving food)?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.
Re: Changes in what a 3.1 ruleset can do
I just found out a new feature I was coding to use, got reverted because of comments here.
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.
I don't see disabling sentry in our rules to be likely. But that result of this comment was something else.Ignatus wrote:That's fine as long as it doesn't DISABLE any other functionalities tied to actions, right?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.
"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 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.
Re: Changes in what a 3.1 ruleset can do
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!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.