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.
OK I'm moving it here.
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.
OK, it's fireworks. You just said the ruleset should be about the game rules, but then you say you disagree with what I've spent pages and days to argue, that we must stop STOPPING the ruleset from making game rules. Then to me it seems you said, the ruleset should be forced to not have game rules and that user experience should make game rules. There is a communication failure here at some fundamental level.
I will compare:
1. Ruleset is about game rules. Ruleset is allowed to control game rules. Ruleset is allowed to invent game rules. So far we agree. Now we will disagree: Ruleset makes rules based on states. It is a pure State Machine. States can trigger states. Ruleset is the LORD of states. No one can tell it what it does with States, and every change of state, and what rules control which states can come from any other state. Because the essence of rules are CONTROL OVER STATES. Period. End of story. Ruleset is the LORD which makes rules over game states. Everyone else, get out of the way! Ruleset can make rules, such as, to get information from sentry, you need Smoke Signal tech. To sentry at all, do you need to be a non-fuel unit? Maybe in one ruleset yes. Maybe in another ruleset that has bizarre fusion-powered space units where everything is fuel unit, of course you can sentry as a fuel unit! I don't want some "User Experience" deciding these game rules and game states for rulesets. Let rulesets decide rules and game states. Maybe the sentry state is the exact state the rules need to look at, to trigger some other action like auto-attack, or report watch-guard information on movements, or a sentry state triggers a "run to nearest city" under some other condition. I'm trying to free our minds here, and this is a philsophical purity that is very empowering if you can understand it. It's about breaking out of old thinking and making a real STATE MACHINE. GIVE THE RULES POWER TO DECIDE. FREE THE RULES! LET THE RULES MAKE RULES, and do not let some subconscious invisible ruleset in the user experience, force restrictions on rules that are not needed at all, and only achieve limitations of possibilities with NO positive outcome in this forcing. This is the power of philosophy, if you discover this philosophy I'm teaching, freeciv will get a new free bonus advance. It's the philosophy of thinking more purely about what a ruleset is: it is a pure STATE MACHINE that is given as much power as we can, over GAME STATES. It can always access a game state (not have UX or server hide it from it), it can always decide the rule over game state, not have some UX or server decide for it.
Summary of my school of thought: "Rulesets manage game rules. Subconscious invisible hard-coded rules that live in other places, do not. Move all such things OUT of there and into rulesets. Never let "user experience" force game rules onto rulesets."
Your proposal (as it feels to me from the perspective of someone who feels my proposal is not being understood):
2. Ruleset is inferior and SUBMISSIVE to secret hard-coded ruleset in the user experience which is unconsciously hard-coding that your rules and game states must be Civ2, even though it's only 20 lines of code to free it to do many other things. UX gets to assume rules and make rules for the ruleset, and ruleset has no control and must accept dominance by UX. UX is really the secret master ruleset, a higher religion that ruleset must obey. Ruleset can only make rules as long as it obeys the secret higher rules of the secret ruleset inside the UX. This is a secret ruleset that assumes everyone is playing Civ1/2, and it doesn't allow rulesets to invent new things like Sentry actually being used for real sentry. It's EASY to let sentry do amazing things with 30 lines of code, but UX is selfish and haughty and demands it has more power over game rules than ruleset does. It is unconscious and unware of other possibilities of other rules. User experience makes the rules about when you can sentry. Are you a fuel unit? That's a user experience rule, not a ruleset rule. Sorry ruleset, you can't decide! User experience gets to make these rules! Did you want a rule for when you can sentry? Sorry ruleset, we don't want let rulesets decide these game rules. We want user experience to decide game rules. Do you want the act of sentry to maybe trigger something? Sorry rules, you don't get to make these rules. User experience makes these rules. User experience makes the rule over what sentry is. NOT the ruleset. Because user experience is a secret Higher ruleset that wants to force your ruleset to be the same as all the others, and it wants SENTRY to be forced to be Civ2, FOREVER !!!!! Even if 30 lines of code would free you into a real state machine with infinite possibilities, sorry ruleset, you're not allowed. UX makes the game rules, not you! Let's avoid rulesets becoming a pure state machine for game rules, let's always have little unneeded restrictions block it. The only way we can maintain this supremacy over rulesets is to secretly handicap them from their philosophical destiny of becoming a pure STATE MACHINE that has access to all state information. So for every little possibility, let's make other hard-coded things prevent it."
Now, I will apologize. I know you don't REALLY feel crusader over these words I put in your mouth. And probably you don't think that's your position at all and will tell some clarifications to it. But pause a minute because, if someone who talked this way really existed, he would have the same decisions of trying to forbid rulesets access to all states. If a certain new kind of game rules needed to define states in special new ways to invent new kinds of games, he would say things like "no, that's a UX state, and your ruleset has to follow this universal behaviour that assumes all games will be kind of similar to Civ2, even though only 30 lines of code would let you do other things." Do you see the point here, that it is UNNECESSARY to assume and force all rulesets to use sentry the same as Civ2? It's quite possible and easy to let them do so much more with just a few little lines of code? That the state machine apparatus for actionenablers and req vectors has now reached a level, that without knowing it, you were inventing an engine for a pure state machine, and you are only 20m away from the finish line in fulfilling this amazing vision. Every time UX is secretly forcing game rules on the ruleset, we have to think carefully. How important is this for universality or avoiding code maintenance issues and complexities? Do we really NEED to force it, or is it harmless in this case to let the ruleset get closer to its destiny of a pure state machine that can invent much greater possibilities and new kinds of rules that blow the mind of our current thinking? Do we need to always force the ruleset to be the least powerful in the triangle between server, client, and ruleset? Let's be VERY careful about "invisible game rules" that are stopping rulesets from controlling game rules. If there is a VERY good reason for it, then OK. But if we're handicapping and castrating and disabling rulesets for little reasons like "semantic consistency" or "this is a UX rule" or "this must be a server-side client state", I say no. I am constantly having to make tiny little one-line code changes to artificial stiffness to open up huge new features. Awesome new features that were crippled by one little line of restrictive code that was unnecessary. Just to let the ruleset actually be a ruleset that manages game states, instead of someone else managing rules and game states.