Re: [s-d] RFC: Devices

["Mike McGann" <mike.mcgann@xxxxxxxxx>]

I put it on the shelf because I only got one comment on it. I was
thinking that it was too much of a change to get passed through.

- Hose

On Nov 26, 2007 11:23 PM, Jamie Dallaire <bad.leprechaun@xxxxxxxxx> wrote:
> Hose...
>
> Whether you prefer to do it during or after the refresh, but think it might
> be time to dust off the framework?
>
> Billy Pilgrim
>
>
> On Nov 8, 2007 10:59 PM, Jamie Dallaire <bad.leprechaun@xxxxxxxxx> wrote:
>
> >
> >
> > On Nov 8, 2007 8:17 PM, Mike McGann <mike.mcgann@xxxxxxxxx> wrote:
> >
> > > On Nov 8, 2007 7:19 PM, Jamie Dallaire <bad.leprechaun@xxxxxxxxx> wrote:
> > >
> > > While the rules, as they stand, would prohibit that action, the rule
> > > could
> > > be changed to allow that action by a device. Since Blueprints basically
> > > have
> > > to be created by proposal, you could roll it up into the same proposal.
> > > I
> > > think it would be better if the rules explicitly give permission when
> > > needed
> > > than to allow devices to change things at will.
> > >
> >
> > I was going to say that it would be tedious to change all the rules for
> > that, but actually I think you're right. It requires the same amount of
> > effort to include a provision in a blueprint for overriding a certain rule
> > as to modify that rule to allow for the blueprint's action to disregard it,
> > since devices would be created via proposal anyway.
> >
> >
> > > Some rules probably have good reasons for it. Requiring only one
> > > supporter
> > > for an usurp is probably a good idea if the active number of players is
> > > low.
> > > You wouldn't want the Chariman and MoM to go AWOL holding this device
> > > and
> > > not being able to muster enough support to wrest control and turn the
> > > clock
> > > on.
> >
> >
> > The 3 person usurp device was just an example, which I also think is a
> > little high.
> >
> >
> > > If Blueprint "xyz" is destroyed, it ceases to exist, is no longer a
> > > Blueprint, and cannot conflict with a future Blueprint that may be
> > > called
> > > "xyz"
> >
> >
> > Good. That's what sounds most reasonable to me. But as for several of the
> > other questions in my previous email, I was not only asking because I
> > wondered about the answer, but also just to indicate that said answer should
> > be made a bit more explicit in the (future) proposal.
> >
> >
> > > Using the general term works--I'll put those changes in. Also, I don't
> > > think
> > > it would be necessary to say in the same type of currency. The rules of
> > > the
> > > currency can decide that out when a new currency is introduced. You may
> > > want
> > > to have a currency that is not compatible with mackerel, but you may
> > > want to
> > > have one that is compatible or equivalent to mackerel (for example, 1
> > > trout
> > > = 1000 mackerel)
> >
> >
> > You're right about that, except I think it could sometimes be a little
> > tricky to decide whether two currencies are compatible or not, and could
> > lead to judgment calls having to be made. To pick up on your trout example,
> > suppose trout were convertible to mackerel (as points are now) but mackerel
> > was not convertible to trout (as is the case with points right now). I know
> > points are not a currency, but a weird analogous situation, with regards to
> > currency exchange, could potentially develop between two currencies. This
> > is, after all, a nomic. In this situation, it might be ok for player A to
> > top a price of 800 mackerel by bidding 1 trout, since one trout can easily
> > be converted to 1000 mackerel. But whoever tried to top 1 trout with 1100
> > mackerel could arguably be out of luck. Since trout aren't convertible back,
> > are they really worth more? Conversion conflicts could come up if we have
> > floating exchange rates at some point, too. What's the top bid today might
> > not be tomorrow. Just hypotheticals, but I think that the simplest way would
> > be to impose a particular currency for the pricing or bidding on any device,
> > specified by the proposal that created the blueprint. That way, people who
> > hold reserves of other currencies are welcome to bid (in the particular
> > currency for that blueprint) as long as they think they can come up with the
> > cash in the proper currency.
> >
> >
> > > How about bidding starts on Breakday, ends at the end of Tango, you have
> > > until the end of Ballotday to come up with the macks?
> > >
> >
> > How about Breakday --> Halfday (6) --> Ballotday (9). That way, we can
> > keep the extended bidding period. And 3 ndays should be enough to come up
> > with the cash, especially considering that you probably had some sort of
> > plan worked out by halfday if you were willing to bid a particular amount.
> >
> >
> > > The Production Count does not decrement, it is still Biddable, so it
> > > opens
> > > up again for bidding on Breakday. Might need to put in someway to
> > > prevent
> > > someone who has no mackerel and no points to keep putting in a bid of a
> > > zillion to prevent it from ever being bought.
> >
> >
> > About the prod count not decrementing, I guess a fine reading would show
> > that this is what happens, but it might be best to spell it out plain and
> > clear. Good point, I had not thought of that strategy (no mack no points).
> > Not really sure what would be appropriate so I'll just throw out some
> > punishments that might deter this from happening. I know some of them are
> > inappropriate but I'm brainstorming. Reduced voting power for next nweek?
> > Just can't vote next nweek? Can't hold a ministry? Cannot take any game
> > actions other than voting for an nweek? Bids will not be taken from player
> > for the next *x* biddable blueprints? Future cash/points earned will be
> > deducted as long as it takes to make up the original bid? Automatically
> > assigned MiniMinister of Duncery?
> >
> > Billy Pilgrim
> >
> _______________________________________________
> spoon-discuss mailing list
> spoon-discuss@xxxxxxxxx
> http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss
>
_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss