Saturday, January 18, 2025

Proposal: [Core] [Appendix] Upholstery and Rejection

Reached quorum, 5-0. Enacted by JonathanDark.

Adminned at 20 Jan 2025 03:29:40 UTC

In the core rule “Calls for Judgement”, change

It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.

to

It does not specify changes to the gamestate nor ruleset, does not specify that any attempt to perform an action should be upheld or rejected, and does not specify corrections to any gamestate-tracking entities.

In the “Other” section of the appendix rule “Keywords”, add a definition of “Reject” between the definitions of “Quorum” and “Resolve”:

To reject an attempt to take an action is to retroactively declare the attempt to have been unsuccessful, and to declare that all attempted game actions taken after that attempt were attempted as though that attempt had been unsuccessful. An attempt to take an action can be rejected even if it were originally legal. The opposite of rejecting an attempt to take an action is upholding it.

and change the definition of “Uphold” to:

To uphold an attempt to take an action is to retroactively declare the attempt to have been successful, and to declare that all attempted game actions taken after that attempt were attempted as though that attempt had been successful. An attempt to take an action can be upheld even if it were originally illegal (in which case the retroactive change is made by pretending, for the purpose of calculating the results of that change, that the action was legal). The opposite of upholding an attempt to take an action is rejecting it.

 

“Starting to build up a corpus of case law” has highlighted a couple of issues in the CFJ system. One of them is that, because it attempts to revert an action that is generally considered to have been illegal, it doesn’t actually make any gamestate changes; the only reason it couldn’t be failed right now is that we have left the tracker in an incorrect state, so that the CFJ can be processed correctly (in other words, the CFJ has had the unwanted side effect of discouraging players from fixing the tracker). The incorrect tracker has the side effect of halting gameplay (we apply actions by updating the tracker, but the tracker is wrong so it can’t be updated correctly).

But the other issue is that, quite apart from the issue with the tracker, the CFJ itself also has the issue of halting gameplay; that’s because instead of reverting the attempt to perform an action by simulating a revert at the time the action was performed, it instead changes the current gamestate to match the gamestate immediately before the rejected action was attempted. That’s much easier to word in the current rules, but means that it’s impossible for my team to score while the CFJ is pending, as it would revert any scoring attempt once it were enacted.

As such, what’s needed to stop the same issue happening again is to add definitions into the core rules that would make it easy to word the CFJ in a way that allows gameplay to continue while the CFJ is pending. A while ago, we added “uphold” into the ruleset to deal with situations of “this illegal action happened ages ago, but we were playing assuming that it worked and don’t want to recalculate the gamestate”. The new definition “reject” is the opposite, dealing with situations of “someone attempted an action I think is illegal, and want to change the gamestate to what it would be if it were illegal, without preventing gameplay while the CFJ is pending”. In particular, it is possible to correct the tracker while a “reject an action” CFJ is pending – and even repeat the action via legal means – because after the action is rejected, that just looks like a routine “correct tracker to match gamestate” / “revert the effects of an illegal action” tracker update. The CFJ rule is modified slightly so that “reject an action” CFJs can’t be failed simply because someone reverted the action in the tracker (and likewise so that “uphold an action” CFJs can’t be failed simply because the action was originally legal, which under the current rules might be a problem if someone tried to uphold an action that some people felt was legal and other people felt was illegal).

With this definition, a CFJ to correct the presumably-illegal typo fix could be worded as “Reject the change of ‘rebult’ into ‘rebuilt’ recently peformed using the typo correction provision of Spelling and Formatting”, and the definition would automatically take care of ensuring that the CFJ would resolve correctly despite tracker corrections and dynastic gameplay that happened while it was pending.

Comments

JonathanDark: he/him

18-01-2025 22:03:12 UTC

The tricky part is, what do you when continuing dynastic actions rely on the incorrect gamestate? What if it’s interwoven with other dynastic actions that don’t?

Unwinding a situation like this becomes untenable, to the point where the game must necessarily be frozen in order to revert completely back to the point where the mistake was made, or choose to proceed forward with the mistake baked in.

I’m not saying all situations are like this, but I am saying that it’s probably impossible to prevent all game-freezing from happening.

JonathanDark: he/him

18-01-2025 22:05:08 UTC

That said, I am supportive of making it at least a little easier to not freeze gameplay in the situations where it’s relatively simple to allow gameplay to continue when there isn’t a strong dependence on the incorrect values.

SingularByte: he/him

18-01-2025 22:09:05 UTC

I wonder if it would be possible to add an out where the person who made the incorrect gamestate can retract it if they honestly believe that the gamestate is incorrect as a result of their action? That way, a cfj to revert it could be ended early as doing nothing.

But then, I suppose that runs the risk of causing a mess in the future if someone retracts something which is later then seen as having been correct all along.

ais523:

18-01-2025 22:18:47 UTC

@JonathanDark: This probably only really helps in the simple cases, but CFJs to resolve simple cases are fairly common, so being able to prevent gameplay disruption in those cases is still a gain even if there are times that we still have to stop.

@SingularByte “I wonder if it would be possible to add an out where the person who made the incorrect gamestate can retract it if they honestly believe that the gamestate is incorrect as a result of their action?”: we have that in the rules already, the “update tracker to match gamestate” / “revert the tracker reflection of an illegal action” action.

SingularByte: he/him

19-01-2025 08:11:58 UTC

for  I don’t think this’ll fix the problem of the game having to freeze, but it’s a useful concept to have in the rules.

Josh: he/they

19-01-2025 09:54:35 UTC

for

Habanero:

19-01-2025 12:09:38 UTC

for Seems worthwhile for situations like this at the very least. I don’t know how often it’ll see any use but there’s only one way to find out

Brendan: he/him

19-01-2025 14:25:28 UTC

for