You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #6, which asked for five ways of deciding who may claim a chunk. Three of them shipped in 1.1.0 as the CHUNKBLOCK_CLAIM_CHUNKS island flag (owner only / sub-owner and up / any configurable rank), and #6 is closed for those. The remaining two are a different kind of thing and are tracked here.
The shipped flag answers "does this player have the authority to spend credit, yes or no" — a single check at the moment of the click. A proposal or a vote is a workflow with state that outlives the click:
a pending proposal has to be persisted on the island (which chunk, who proposed it, when), and survive restarts
it needs an expiry, or islands accumulate stale proposals forever
somebody has to see it: a pending-claims list, a prompt on login for the approver, or a marker on /ch chunks
the level credit has to be re-checked at approval time, not proposal time — the island may have lost levels in between, and the chunk may have become unclaimable (re-locked neighbour, protection range)
#5 (branching phase paths with team voting) needs the same machinery: a proposal, a quorum, an expiry, a tiebreak, and a UI to cast a vote. If both get built, the voting mechanic should be written once and consumed by both, rather than a claim-vote and a phase-vote growing separately. Whichever is built first should carry the generic part.
Notes on scope
The wasted-credit worry that motivated Team chunk-claim governance #6 is already handled for everyone by the claim confirmation added in Confirm chunk claims before spending level credit #17 — the first hit previews and quotes the price, and only a sneaking second hit spends anything. So this is no longer about preventing accidents; it is about giving a team a say. Worth keeping in mind, because it lowers how much this needs to do.
Proposal-with-owner-approval is much the cheaper half: no quorum, no tiebreak, one approver. It could ship alone and would cover most teams.
A pending proposal drawn on the territory map would fold in nicely with the map marker follow-up mentioned at the end of Team chunk-claim governance #6.
Split out of #6, which asked for five ways of deciding who may claim a chunk. Three of them shipped in 1.1.0 as the
CHUNKBLOCK_CLAIM_CHUNKSisland flag (owner only / sub-owner and up / any configurable rank), and #6 is closed for those. The remaining two are a different kind of thing and are tracked here.Original request from @mrfloris in #6:
Why these are not just another rank
The shipped flag answers "does this player have the authority to spend credit, yes or no" — a single check at the moment of the click. A proposal or a vote is a workflow with state that outlives the click:
/ch chunksRelationship to #5
#5 (branching phase paths with team voting) needs the same machinery: a proposal, a quorum, an expiry, a tiebreak, and a UI to cast a vote. If both get built, the voting mechanic should be written once and consumed by both, rather than a claim-vote and a phase-vote growing separately. Whichever is built first should carry the generic part.
Notes on scope