BlogNomic: The Ninth Dynasty of ais523

Do we need to consider some of the more awkward scenarios, like if you revert gamestate after someone has unidled thereby re-idling them, or reverting blog posts which could essentially delete them?

It might be worth explicitly making it clear that reverting gamestate refers to the tracked gamestate document by default, unless other items of gamestate are explicitly mentioned as being included.

I’m a bit loathe to cover edge cases in this; the Glossary isn’t intended to be rules, it’s for keywords, so that they can be called with standardised definitions, knowing that they will have to be dressed up to suit the situation they’re being used in. Something like “revert” can have hundreds of edge cases that spiral outwards based on the variables of a hundred dynasties we haven’t played yet; any attempt to make the wording completely future-proof would be longer than the existing ruleset, but we have to trust that future proposal-writers will couch their effects appropriately, and that future voters will catch issues before they occur.

I approve of the sentiment here. I’m not sure that there’s a reason to talk about conditions though; just talk about reverting the ruleset/gamestate to its state at a particular time. Reverting to a particular state is fraught with danger, as that state may never have legally existed in the first place, meaning that there is no way to determine the time at which the state occurred. It is also possible that the gamestate can be in a particular state more than once; if you attempt to revert to that state, it then becomes unclear whether you are reverting actions that occurred in between two occurrences of the state or not.

(I note in passing that “condition” is an EFF word, 16516.)

Perhaps this could be as simple as “To ‘revert’ the ruleset or gamestate to a particular time is to reject all changes to it that have been made since that time.”; that would avoid duplicating the definition of “reject”, which already covers most of what is needed.

I think JonathanDark’s concern could be mostly assuaged, in a non-combinatorial-explosion way, by stating that reverts of the gamestate in general cover only dynastic gamestate by default.

I’m avoiding the new “reject” keyword as it is important that a reverted action did not occur, rather than rejection, in which the action did occur but was retroactively considered to be unsuccessful.

If JonathanDark’s (otherwise legal) Heist Action were reverted, I would expect it not to count for his 48 hour Heist timer.

If his action were rejected, I would expect that it would count for his 48 hour Heist timer.

The distinction is meaningful and valuable.

(As an aside, woah, that reject definition is expansive - there’s no way to reject something without rejecting all play, even unrelated play, that happened after it? “All attempted game actions” includes votes and proposals… That needs an urgent rewrite)

I apparently voted for the Reject definition… That’s embarassing.

It’s currently impossible to reject anything as the act of rejecting something would invalidate the CfJ that called for its rejection!

I wouldn’t mind seeing the Reject keyword issue addressed, but I can appreciate not complicating this Proposal any further with more conceptual tweaking, so maybe another Proposal is warranted with focus on Reject.

@Josh: you misread the definition: rejecting an action recalculates all actions that occurred after it as though the rejected action were unsuccessful, but doesn’t necessarily make the subsequent actions also unsuccessful.

The “unsuccessful” is confusing under the current ruleset because “attempting to take a Heist Action” is itself an action which you can attempt to take; if you reject that, you are in effect saying that the attempt to attempt was unsuccessful, in which case it doesn’t start the timer. I don’t expect that confusion to happen under most rulesets.

That said, I can see why you might want to avoid rejecting in the definition of “revert”, if you want to remove all gameplay from the history altogether since a particular moment – we don’t currently have rules that care about players having tried to perform illegal/impossible actions, but it is possible that a future dynasty might (there are plenty of nomics with rules like that).

In any case, this wording is still unclear on what happens if you try to revert something to a state it was never legally in – I don’t massively care how that’s defined, but think that it should be defined explicitly (either as failing altogether, or as reverting it to its actual state as of the time that the specified state was present on the tracker even though the two differed).

Oh, this should probably also specify the exact location in the list to add the new item – otherwise, it gets added at the end, after “Wiki”, which would dealphabetise the list.

This almost works now, but “return that item to that state” wouldn’t have worked in the case of the recent CFJ (because it was never in that state). “return that item to the time of that state” is a bit awkward but would work – maybe there’s a better way to word it.

As much as I want to contradict that that by saying that an illegal state is still a state so it is possible to go to it, I am now wondering whether it’s possibly to legally go to such a state knowingly.

If you don’t know it’s illegal, it’s simple; you go to the state then someone corrects it later. If you know, then it’s implicitly legal to revert further than stated because the illegality isn’t upheld.

But it does become messy to knowingly revert to illegal gamestate and just staying there. It’s like, the cfj did say to, but to follow along is to knowingly put the game in a state that’s known to be invalid.

I don’t know how I’m going to vote just yet.

@SingularByte “an illegal state is still a state so it is possible to go to it”: I agree, but the rest of the rule talks about “the time of that state” which wouldn’t have happened in that case.

, though it would probably be more natural to talk about reverting a document/the ruleset/the gamestate to a particular time rather than a state to get around all the ‘what if that state never actually legally occured’ nonsense

*occurred

I’m not sure how to vote on this one – in particular it doesn’t fix the problem that inspired the change in the first place.

I’m with Josh that there was never actually a problem at all with the original CfJ, but regardless we can word future CfJs ‘revert the gamestate to its state at time XYZ’ which hopefully we can all agree works fine under this definition of revert

  On thinking about it, having the term defined is better than having it not defined.

No matter what rule gets implemented, cfjs turning out to be going back to an illegal gamestate is always going to cause enough complexity and messiness that there’s probably always going to be at least one follow-up cfj. Because of that, this definition of revert probably doesn’t have to actually cover that kind of situation more than it currently does.

I don’t see the “state” problem as a real problem - the historical fact of an occurrence is ganestate, so reverting into a state that is still illegal pending further reversion is possible, and the last sentence makes it clear that reverting by CfJ to an illegal state dies not imply that that state is upheld.

@Josh: although the historical fact of an occurrence is gamestate, the revert is trying to find something which is not part of the historical record, so it’s unclear what time to revert to.

I think I understand how you are intuitively expecting such a revert to work, but am having trouble phrasing it unambiguously. It’s something like “when reverting to a state that was never part of the actual gamestate, revert the tracker to match that state, and revert the actual gamestate to its actual state at the time at which that state was displayed on the tracker”. To me, that would be very unexpected behaviour to happen without explicitly stating it (in particular, it seems perverse to set the tracker and the gamestate it tracks to different values), although I do understand why it might be useful (because it guards against situations where the tracker is wrong in a way that nobody is aware of).

I do think that your version of the rule does not actually say to do that, and I wouldn’t expect it to actually happen if I hadn’t spent a couple of days trying to figure out exactly what operation is represented by your intuitive understanding of the rule.

At the risk of opening an old can of worms back up again: this is only a problem if you insist upon a strictly Platonic relationship between the ruleset and its tracking.

I do not find merit in the argument that an incorrectly or illegally applied gamestate change never existed.

I have to side with SB and Josh on this one

I believe the can of worms is mostly settled, as “it is necessary to have rules where the platonic interpretation works correctly because otherwise this creates trivial scams in which a tracking page is illegally edited – and it is necessary to have rules where the pragmatic intepretation works correctly, because otherwise the game rapidly becomes an exercise in fixing historical breakage – but fortunately, it is generally possible to write rules in such a way that the two concepts are aligned with each other”.

This only really causes problems when an action is performed under a pragmatic viewpoint that makes no sense under a platonic viewpoint.

For what it’s worth, BlogNomic’s ruleset is written in a much more platonic way than some nomics I’ve been in, despite being played in a more pragmatic way in practice. This is possibly a legacy of the Age of Scams, where a huge number of attempts were made to perform “scams” which trivially fail under a platonic viewpoint but are unclear under a pragmatic viewpoint (e.g. non-admins “enacting” their own proposals despite not having enough votes, changing the Admin field to match). It is very hard to exclude that sort of scam without using platonically-worded rules, because it is hard to prevent, say, an illegally enacted proposal creating a rule that makes its own enactment legal and prevents it being reverted; in order to prevent that scam working, you basically need a platonic “that never happened” rule you can point to.