You reversed your second and third steps; I carried out the Growth Tick before I marked the form for enactment.

no this is spatricus

@Bucky Oh, thank you; thanks to Red’s vote I can’t edit but it doesn’t affect the argument, it just has to have been between red’s marking the form enacted and making the roll.

My interpretation of “When a Proposal is Enacted, its stated effects are immediately applied in full” is that any of the proposed changes carried out during the enactment sequence are considered to have happened at the time the proposal was marked enacted and in the stated order, even if the back end shows the changes to their respective tracking documents happening before or after the enactment mark.

@Bucky What’s the basis for that interpretation? The ruleset doesn’t appear to make any statements about timing; in fact it goes to great pains to separate the enacting clauses, making it relatively clear that they are distinct.

The proposal in question doesn’t have anything that can be magically applied to a platomic ruleset; it contains a sequence of instructions that must occur, physically, as carried out by a person. Is your argument that these actions occurred magically before they actually took place?

I will also remind of the clause in Representations of the Gamestate:

“If authorised by the rules as a result of a City Architect’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change.”

The place where this particular change is tracked is the post to the blog, although the dice roller timestamps do also have some heft.

What is “When a Proposal is Enacted” if not a statement about timing?

Proximate at best; “when it is sunny, clothes get dry” does not imply that the clothes become dry the instant the sun rises.

I feel like I have to with Josh on this one. However much we’d like “immediately” to be without interruption, unless the rules make it atomic, it’s interruptible.

It definitely introduces the possibility of changing the course of enactment, but that’s been possible from other means: the Proposal altering rules that no longer exist due to another Proposal enacted first, or referencing invalid gamestate variables, for some examples.

It also shows the potential abuse vector from admins who are rightfully clearing the Proposal queue by processing multiple Proposals at once, but without an atomic action binding the order of admin’ing the Proposal and the order of enactment, could in theory enact them out-of-order, especially if doing so would be advantageous.

I definitely think we should do a pass on the language around enactment early in the next dynasty as it is full of holes.

To illustrate further, suppose I’m an admin that just edited a Proposal as admin’ed passing, and then I get an urgent message from my day job and have to spend the next 30 minutes doing that job before being able to get back to actually implementing the Proposal changes.

Is the gamestate and ruleset truly frozen in those 30 minutes? On what basis?

It’s not frozen, but the stuff you did 30 minutes later is considered to have happened when you edited the proposal.

@Bucky How do you square that with the above-mentioned

“If authorised by the rules as a result of a City Architect’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change.”

?

That doesn’t apply to the critical “make a list” step.

Yes, the real question is whether the *list* was made before or after Bucky’s growth tick. In fact, it was made immediately upon marking the proposal enacted (I already knew what it would be, since I had checked the figures immediately prior). So even if Bucky’s growth tick occurred, it didn’t matter since the list was already made.

And no I can’t prove it, but you can take my word for it!

revote green tick; frick EE

frick EE, and cc discussion