[Bnomic-private] Proposal: Bandwidth

[Wonko]

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.

>> 
>> 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.

>> 
>> 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.

-- 
Wonko