Changes in what a 3.1 ruleset can do

Contribute, display and discuss rulesets and modpacks for use in Freeciv here.
sveinung
Elite
Posts: 528
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Postby sveinung » Tue Feb 09, 2021 9:23 am

"Pillage" can now be made tile extras targeted See Feature #919305

You can now choose if "Pillage" should be targeted at tiles (requirements and casus belli apply to tile owner) or tile extras (requirements and casus belli apply to extras owner) with the new ruleset variable actions.pillage_target_kind. Note that there currently only is one "Pillage" action (see osdn #41526) so you won't be able to have one for each target kind.

Example:
Lexxie wrote: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?

Now you can.

sveinung
Elite
Posts: 528
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Postby sveinung » Tue Feb 09, 2021 9:36 am

Action enabler controlled hut popping See Feature #919139

You can now use an action enabler to control what happens when a unit enters a tile with a hut. If "Enter Hut" or "Enter Hut 2" is enabled the hut is entered. If "Frighten Hut" or "Frighten Hut 2" is enabled the hut is frightened. Note that a unit currently can't do both: the unit class's hut_behavior still determines witch action, if any, can be enabled.

You can now add restrictions to hut popping.

sveinung
Elite
Posts: 528
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Postby sveinung » Tue Feb 09, 2021 7:06 pm

"Conquer Extras" has been fake generalized See osdn #41513

"Conquer Extras 2", a copy of "Conquer Extras", has been introduced. You can enable it under different circumstances and give it different ruleset defined consequences than "Conquer Extras" has. The bundled rulesets that has the slow invasions rule uses it to take movement when an extra conquest happens from a transport under the circumstances slow invasion punishes with the loss of all remaining moves.

sveinung
Elite
Posts: 528
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Postby sveinung » Wed Feb 10, 2021 5:03 am

You can now force a unit to (try to) perform an action from Lua See osdn #41520

You can now make a unit perform an enabler controlled action from Lua. The action is subject to the same rules as if the player ordered it performed himself. You can therefore use this knowing that your rules about when an action is enabled and what consequences performing the action will be respected.

Example 1: force a unit to disband.

Code: Select all

actor:perform_action(find.action("Disband Unit"))


Example 2: force a unit to establish an embassy in the target city.

Code: Select all

actor:perform_action(find.action("Establish Embassy Stay"), target)


Example 3: force a unit to sabotage the target city's walls.

Code: Select all

actor:perform_action(find.action("Targeted Sabotage City Escape"),
                     target, find.building_type("City Walls"))


Example 4: force a unit to steal Banking from the target city.

Code: Select all

actor:perform_action(find.action("Targeted Steal Tech Escape Expected"),
                     target, find.tech_type("Banking"))


Example 5: force a unit to build a road at the target tile.

Code: Select all

actor:perform_action(find.action("Build Road"), target, "Road")

sveinung
Elite
Posts: 528
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Postby sveinung » Fri Feb 12, 2021 9:25 am

The post action forced action list of "Bribe Unit" and "Attack" has moved to the ruleset See osdn #41524

The actions "Bribe Unit" and "Attack" will under certain circumstances force an enabler controlled action or a move if the action is successful. You can now control what actions will be tried with the new ruleset variables bribe_unit_post_success_forced_actions and attack_post_success_forced_actions.

Example: Force a unit to disembark its transport after a successful attack but don't conquer any cities, extras or pop any huts.
Set

Code: Select all

"occupychance", 100
in settings.set and

Code: Select all

attack_post_success_forced_actions = "Transport Disembark", "Transport Disembark 2"
in actions.attack_post_success_forced_actions

sveinung
Elite
Posts: 528
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Postby sveinung » Fri Feb 12, 2021 9:35 am

Configurable target kind for "Explode Nuclear" and "Nuke City" See osdn #441552

You can now set the target kind of "Nuke City" with nuke_city_target_kind and "Explode Nuclear" with explode_nuclear_target_kind to "individual cities" or to "tiles". The default is "tiles". (Yes, this default makes the name of "Nuke City" awkward.)

You can now have a city targeted nuke action that can target its own tile (switch "Explode Nuclear") or a tile targeted nuke action that can't target its own tile (switch "Nuke City").

Lexxie
Veteran
Posts: 79
Joined: Fri Jun 23, 2017 4:18 pm

Re: Changes in what a 3.1 ruleset can do

Postby Lexxie » Tue Feb 16, 2021 2:52 am

Caedo:
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.


You confuse philosophy for politics. Freeciv is a game engine and I am making a philosophic point. When making rules, you tie rules to states. Everything is about states, conditions, and what is triggered from those states and conditions. You are saying it is BS my claim, but, is it true? Do you make that claim that "under no conditions in existence, ever, would a different trigger/cause or result come, from a unit being on sentry guard, vs. that same unit being idle." I would argue, sir, that this claim of yours is BS. In reality, wars can be won or lost based on whether a unit was on sentry or was sleeping, eating a meal, or writing a letter back home. The situation here is that you can't conceive of Sentry ever being an actually important function or state of being that in some cases with some kinds of units in some kinds of rules. At FCW, it already is. It is a false claim that being on sentry would NEVER have a different result from that same unit smoking marijuana by the jungle campfire (idle activity state.) What you didn't think about is, rulesets already exist which need to distinguish this exact difference in state, and the subject came up precisely for that reason, because the feature was wisely being put in by someone, then someone who is stuck in status quo Civ1/2 thinking said we would never need that.

Lexxie
Veteran
Posts: 79
Joined: Fri Jun 23, 2017 4:18 pm

Re: Changes in what a 3.1 ruleset can do

Postby Lexxie » Tue Feb 16, 2021 3:30 am

sveinung wrote:
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. :cry:

Sentry is an implementation detail for the user interface. :cry:

Lexxie wrote:But somehow it led to reverting the super awesome excellent idea of the great new ACTION_SENTRY action. [...] 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.



OK I apologise that I have a lot to say here.
1. Sentry and Idle are different. At FCW, we do not want sentry and idle as having "equal yet different" states, with the only difference being whether it bothers the client to ask an order. Philosophically, we disagree with: "The Server triggers different behaviour for a state it claims it doesn't know is different from another state, except it does know it's different and does different things because of it--but, the server insists that rulesets are not allowed to know it's different." I see it a lot , people thinking like this: the server is godlike, the client is an obedient angel allowed to know most things the server allows, and the ruleset is always the one not allowed to know or do things. This is backward, the ruleset is really the commanding governor of the whole game experience, let's try to adjust our thinking to this.

At FCW we are running server code already, where if you are on Sentry, it reports information back to players on what that unit has seen while the user was logged out but the unit was doing its real distinctive activity of ACTUALLY BEING ON SENTRY!!! Sentry? What's that? 1.n. A guard on watch; especially a soldier whose job is to report what he sees while on watch, for the purpose of alerting authorities higher up about key information or intelligence. (See pic at end of post.) This ipso facto is a different state of being, from idle. A != B. There is an actual different behaviour that comes from idle vs sentry. AND a much bigger difference to game play. A different result in intel gathered. When you see that Phalanx sentry instead of Fortify, you know some different purpose is going on here! It's doing a real different action, it is doing an ACTION_SENTRY: an action the ruleset might need to know about, especially if the ruleset has its hands tied from severe, janky, hard restrictions on other things like diplomacy reqs or casus belli. One day, a ruleset might want the special powers of sentry to have requirements to do it: e.g., you can't do it unless you have moves left, or you can't order civilians to do it unless you're a Despot, or until you discover the Telescope technology. Here is my vote if it matters to anyone:
ACTION_SENTRY was a brilliant idea and shouldn't be reverted because someone else was thinking only about old ways in old rulesets.
It allows a rainbow of different possibilities later. Think of things like "special ninja assassins get first initiative 10% combat bonus because they were waiting, knowing you would come." Of course you'd want this to be conditionally triggered by rules, like special UnitClass, certain number of moves left, special smoke signal or radio tech to report what you see back to base, or whatever you can dream of. You can't do any of this with sentry being "only-a-client-state-stored-on-server"

sveinung said:
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)

2. I can't say if that was my goal because I don't understand those three concepts yet, but my guess is that they sound really amazing! Anyway, I will try to say what I was thinking here. Since sentry is de facto different from idle, we want rules to be aware of it when it comes to cause/effect/triggers/requirements, and results. Must you have a certain tech to sentry a particular kind of unit? Does the special Amazonian Watchman Warrior get ability to report what he sees after discovering Smoke Signal tech?
When advancements come 3 years from now like Stealth is an effect or Unreachability is an effect, or it's now an effect like "Defender gets x free rounds of combat before combat starts", or 99 other possibilities, do we want sentry/watch/readiness to only be a "client-state-on-server", or do we want ruleset authors to differentiate a unit with special reactive abilities from a unit who ran out of moves or doesn't even have the ability to sentry at all? Are there conditions needed to sentry, and would a ruleset designer use it as a condition for getting some other advantage we will do later such as auto-attack or auto-bombard for 1 free round?

Maybe some don't care and think only of their own favourite rules on their own favourite client. For them I say this: Clients already have infinite power to do WHATEVER they want in how they decide to handle units in the orders queue. For example, at FCW we have: no orders, wait, advance to next unit of same type, advance to next unit of different type, and to be honest, we could invent 99 more of these that the server never needs to know or care about--they are pure client/UI considerations. So I don't understand people fighting so hard for Sentry to be "client-only-state-on-the-server", when they can just hit J for no-orders or invent some other client-only-state on the client.

What the server needs is for things that really matter in game results, such as Sentry, to not be "existing but non-existing" at same time. I wish I could make this philosophical point better, but it's very important. For those people who only want Civ 1/2/3, you are unharmed by letting others advance and evolve the power of the engine!

2a. I am trying to understand more this idea of "ruleset defined activities", and hope you can talk more about it with examples? But I should say this, if it means keeping sentry as pure client-only-state-stored-on-server, and making us do huge work to code a different kind of sentry later, it doesn't get away from the problem of this: IF A STATE HAS A DIFFERENT real game result, it should never be a client-only state. Let the client program 1 or 100 of its own ways to skip the orders queue, prioritise who gets asked an order or delayed from asking, or whatever. This is not something for the server to be concerned about. Server shouldn't even know such client states EXIST! But ACTIVITY_SENTRY is a real thing with a real different result in game play, and we NEED to know to differentiate it from idle, we need to make conditions on when you can do it, we need it to be a requirement vector for consequences that come from it. If we can require actionenabler "Attack" must never be a missile, which didn't accomplish so much in my opinion, why can't we make actionenabler "Sentry", which would accomplish infinite possibilities?
2c. More importantly, we need to be able to check "The State of Existing" itself, in a req vector. If there is a particular kind of activity which "exists but does not exist", then you create a state of existence that can ESCAPE the conditional net of conditions. We don't want the fundamental flaw of having "states which don't exist." In computers, non-existence is a state too. Imagine you're not allowed to check if a pointer is null because null doesn't exist. That disallows the logic-tree of state-condition-checking to be fully inclusive or exclusive of certain states of being.
2d. I really want to know more on this idea of user defined activities though, because I hate to be giving opinions without understanding the full vision you are pursuing with this other thing.

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.

3. My partial understanding of what you're doing, makes this seem like a huge leap forward, and I wish I only understand better. How would that solution fit with the concerns of Sentry being REAL as trigger/cause/effect/requirement vector, and for also, some poor beginner who is Republic with cease-fire ending next turn, watching units come in his territory and sentry certain spots to gather intel on his domestic troop movements. Obviously it's a casus belli, but the Senate tells him, "no, you have to wait for them to attack us, because spying on our troop movements is a non-existing activity, and the act of them getting orders to do this action from their general, is a non-existing action, and the state of existing at all inside our territory, is a non-existing state of being because being idle is not a real activity."

Image
Last edited by Lexxie on Tue Feb 16, 2021 5:47 am, edited 2 times in total.

Lexxie
Veteran
Posts: 79
Joined: Fri Jun 23, 2017 4:18 pm

Re: Changes in what a 3.1 ruleset can do

Postby Lexxie » Tue Feb 16, 2021 4:06 am

sveinung wrote:
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.


It's an excellent and subtle increase to ruleset possibilities, very approved and much encouraged! How great!

sveinung
Elite
Posts: 528
Joined: Wed Feb 20, 2013 4:50 pm

Re: Changes in what a 3.1 ruleset can do

Postby sveinung » Wed Feb 17, 2021 3:09 pm

We got off topic for this thread. Let use move this discussion out of it. I'll send you a private message. Feel free to respond in a public thread on this forum if you prefer public discussion over private discussions. I'll respond to the stuff that may have public interest here but won't continue the discussion in this thread.

Lexxie wrote:Philosophically, we disagree with: "The Server triggers different behaviour for a state it claims it doesn't know is different from another state, except it does know it's different and does different things because of it--but, the server insists that rulesets are not allowed to know it's different." I see it a lot , people thinking like this: the server is godlike, the client is an obedient angel allowed to know most things the server allows, and the ruleset is always the one not allowed to know or do things. This is backward, the ruleset is really the commanding governor of the whole game experience, let's try to adjust our thinking to this.


I disagree. The ruleset should - in my view - be about the game rules, not about the user experience. The user experience is the responsibility of the client, the server and - sometimes - agents. I think that the ruleset should be able to give hints to those responsible for the user interface, agents etc.

Lexxie wrote:ACTION_SENTRY was a brilliant idea and shouldn't be reverted because someone else was thinking only about old ways in old rulesets.
It allows a rainbow of different possibilities later. Think of things like "special ninja assassins get first initiative 10% combat bonus because they were waiting, knowing you would come." Of course you'd want this to be conditionally triggered by rules, like special UnitClass, certain number of moves left, special smoke signal or radio tech to report what you see back to base, or whatever you can dream of.

Lexxie wrote:Since sentry is de facto different from idle, we want rules to be aware of it when it comes to cause/effect/triggers/requirements, and results. Must you have a certain tech to sentry a particular kind of unit? Does the special Amazonian Watchman Warrior get ability to report what he sees after discovering Smoke Signal tech?
When advancements come 3 years from now like Stealth is an effect or Unreachability is an effect, or it's now an effect like "Defender gets x free rounds of combat before combat starts", or 99 other possibilities, do we want sentry/watch/readiness to only be a "client-state-on-server", or do we want ruleset authors to differentiate a unit with special reactive abilities from a unit who ran out of moves or doesn't even have the ability to sentry at all? Are there conditions needed to sentry, and would a ruleset designer use it as a condition for getting some other advantage we will do later such as auto-attack or auto-bombard for 1 free round?

Doable with a user activity. A hint for the user interface could even integrate it with the server side client state of Sentry (or, should the server side client state be renamed - what ever the "Do not bother me unless you are healed, bounced or an enemy passes near you and report visible unit movements if this is is Lexxie's server or that feature has been merged into Freeciv" server side client state ends up being named.