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.
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. [...] 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."