[Bnomic-private] Proposal: Bandwidth

[Glotmorf]

On 9/14/02 at 12:20 AM Wonko wrote:

>Quoth Glotmorf,
>
>> On 9/13/02 at 11:40 PM Wonko wrote:
>> 
>>> {{
>>> __Fixing the Bandwidth__
>>> 
>>> [[
>>> I was looking through the ruleset, searching for an open hole,
>>> When I stumbled 'cross a rule that was intriguing to behold...
>>> This rule was numbered two-one-two, it tried to regulate
>>> The number of proposals which each player could create.
>>> 
>>> But alas, for our dear admin, this rule's purpose was defeated,
>>> By another of the rules, which had poor two-twelve superceded!
>>> This rule, which we call rule nineteen, doomed two-twelve to disposal,
>>> By stating that all Players have the right to make proposals!
>>> 
>>> So rule two-twelve was contradicted, and was overruled,
>>> By rule ninteen! (which was enforced by rule three-three slash two!)
>>> And so while we have tried proposals many to prohibit,
>>> It turns out the sad truth is that there is no Bandwidth Limit!
>>> 
>>> This hole I had discover'd, I found to be quite scary -
>>> To think that our poor admin in proposals might be buried!
>>> And so I now have written a proposal most preventive,
>>> I hope when voting comes around you all will be assentive!
>> 
>> Tsk.  There is no hole.  Rule 19 may well say all players can make
>proposals,
>> but it doesn't say they can make an infinite number.  Rule 212 doesn't
>> conflict with this; it only modulates it.  What would conflict with this
>is a
>> rule that says under certain circumstances a player can't make
>proposals.  No
>> such thing exists.
>
>Imagine this: I make five proposals (hard to imagine, isn't it? :) Now,
>according to rule 212, I can't make any more. According to rule 19, I may
>submit proposals. That is a conflict.

No, because Rule 19 is a general case: it supplies permission.  As for the=
 actual method of doing so, that's where Rule 212 comes in.  The rules that=
 talk about bandwidth, the rules that talk about public fora, the rules=
 that talk about Admin recognition of submitted proposals, all together=
 dictate the method and window of opportunity for submitting proposals.=
  Any player can submit proposals.  E just has to do it the right way.  No=
 conflict.

>>> This is how it goes:
>>> ]]
>>> Amend rule 212 to be:
>>> {{
>>> __Bandwidth__
>>> 
>>> Each player has an attribute called Bandwidth. No player's Bandwidth=
 may
>>> never exceed 10.
>> 
>> So...every player's bandwidth must exceed 10 at some time or other?
>
>Um... I change that to 'ever'.
>
>>> At the beginning of each nweek, each player's bandwidth becomes 5.
>>> When a player makes a proposasl, eir bandwidth decreases by one.
>>> When a player makes a 1/2 proposasl, eir bandwidth decreases by 1/2
>>> instead.
>> 
>> Then something should be done about Rule 704, Judgment Props.  Judgment
>props
>> are defined in that rule as being proposals.  The rule says they don't
>count
>> against bandwidth, but this new version of Rule 212 would take priority
>over
>> that.
>
>On the other hand, under the current ruleset, 'Bandwidth' isn't defined.
>Judgment Props do count towards the 5-prop limit, though. That's one of=
 the
>problems I'm attempting to address here.
>
>> Also, why specifically have whole and half proposals?  Club props can
>take any
>> fraction out of the club's members' bandwidth.
>
>Half proposals were somebody else's idea. They're already in the ruleset.
>If
>you don't like 'em, propose to remove 'em yourself.
>
>>> If a player attempts to make a proposal, but the making of such a
>proposal
>>> would decrease eir bandwdith to less than zero, the proposal is not
>made.
>> 
>> So...proposals that create rules that have the possibility of reducing
>some
>> player's bandwidth to less than zero automatically don't get made?
>
>The making of the proposal wouldn't be doing the massive reducing, the
>passage/failure of the proposal would be. The making of the proposal only
>drops bandwidth by a point.
>
>>> 
>>> This rule supercedes rule 19.
>>> }}
>>> Amend rule 256, Section B.3, by replacing the text
>>> 
>>> "The player who holds the Token of Proposals may make one more proposal
>>> than
>>> is allowed under the current ruleset. Immediately after eir extra
>proposal
>>> is recognized by the Administrator, the Token of Proposals is
>automatically
>>> returned to the Bandwidth Gremlin."
>>> 
>>> with
>>> 
>>> "The bandwidth of a player holding the Token of Proposals is treated as
>if
>>> it were one greater than it would be if e did not have the Token of
>>> Proposals. At the end of each nweek, the Token of Proposals is
>transferred
>>> to the Bandwidth Gremlin's possession."
>> 
>> I'm uncomfortable with "what it would be" rules.  Judging by the votes
>on my
>> rollback proposal, so is everyone else.
>
>This isn't a 'what it would be' refferring to the past. That's the thing
>people don't like. This is a 'what it would be' refferring to a present
>condition. It's easy to calculate - ignore the effects of the Token to=
 find
>out what eir bandwidth 'would be', then add one to find out what it IS.
>It's
>the same way Radar Towers work.

Uh-huh.  And suppose a later rule does something to modify bandwidth, but=
 is in conflict with the Token of Proposals rule, so the Token takes=
 priority...except that what the player's bandwidth "would be" without the=
 Token is what it "would be" with the other rule in effect.  This is a time=
 bomb.

>>> Amend section B.10 of the same rule by replacing the text
>>> 
>>> "When a player is Burnt, e may make one fewer proposal then e would
>>> normally
>>> be able to."
>>> 
>>> with
>>> 
>>> "The bandwidth of a Burnt player is treated as if it were one less than
>it
>>> would be if e were not Burnt."
>>> 
>>> }}
>> 
>> I honestly don't think Rules 19 and 212 conflict.  I'd be perfectly
>happy to
>> submit a judgment prop to that effect...
>
>Even if they aren't in conflict, this proposal is still a good idea=
 because
>it defines "bandwidth". I could make a case for why M-Tek doesn't work at
>all, based on the way it refers to some strange object called 'Bandwidth'
>which, under the current ruleset, does not exist.
>
>But they are clearly in conflict - once I've submitted 5 proposals, one
>says
>I may submit more, the other says I can't. If that's not conflict I don't
>know what is.
>
>Incidentally, if they aren't in conflict, then we have a SOE - r212 says
>that it doesn't apply during nweek 23, but the sentence that says that,
>according to itself, doesn't apply right now. It's the classic "This
>statement is False" paradox, and the only way we can know whether or not
>there's a bandwidth limit is if another rule supercedes poor broken r212
>and
>sets the limit. 
>
>Fortunately, r19 does this for us.

Also fortunately, we're almost at the end of nweek 23, so the end-of-r212=
 problem will go away.  Did anyone actually exceed their erstwhile=
 bandwidth this nweek?

						Glotmorf