Re: [Rails-devel] Bug reports

[Jim B. <jim...@ya...>]

Erik,

Here's the 1830 FAQ I was referring to below, by Steve Thomas- http://www.18xx.net/1830/1830f.htm

Here's the relevant paragraph on privates' auctions and dropouts-

<snip>
If two or more players have placed bids on a Private Company, rule 7.2  
states that "an auction is held in which all bidders (but no one else)  
take part. The starting price for the auction is the highest sum bid,  
and the minimum raise is $5." When the number of interested players is  
only two, the simple and obvious style of auction is that the players  
raise their bids alternately until one decides to pass. Doing it this  
way seems universal. When there are three or more bidding players,  
some groups hold an organised auction, where players bid or pass in  
player order; in some groups a player passing may not rejoin the  
auction. Others (including my own group) have a free-for-all, where  
any eligible player may make a bid at any time, and the auction ends  
when all players agree to stop.
<snip>

I felt the example text (quoted in the bug) was clear on this, but I  
understand it's ambiguous.

That notwithstanding- if all other things are equal- it's certainly  
easier for online/pbem play, to /not/ require extra passes in these  
situations.

Thanks all for the thoughts and feedback on the issue, anyway- and  
erik and brett for all the hard work on these rails issues, it's great.

best,
  - jim


On Nov 19, 2009, at 12:18 PM, Jim Black wrote:

>
> In terms of your first question (bid again or drop out), I've verified
> this with a number of players, but also- there's a popular FAQ for
> 1830, that acknowledges that this is played differently across
> different groups, and that this is a popular 'house rule' (an odd way
> of putting it, that just increases the ambiguity).
>
> I think, the moral is- that there is no definite answer agreed among
> experts.
>
> The one deciding factor for me in filing this bug for rails is this:
> whenever this comes up in pbem play- players always WANT to keep
> passing, and it typically up slowing everything down significantly
> that rails keeps returning to that player.
>
> Other than that, I have no opinion or real preference, and I'd just
> try to make sure players in any game I hosted understood how Rails
> plays this, ahead of time, so that there's no unfortunate surprises.
>
>  - jim
>
>
>
>
>
> On Nov 19, 2009, at 12:00 PM, Erik Vos wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: John David Galt [mailto:jd...@di...]
>>> Sent: Thursday 19 November 2009 19:31
>>> To: Development list for Rails: an 18xx game
>>> Subject: Re: [Rails-devel] Bug reports
>>>
>>> Erik Vos wrote:
>>>> #2898839 - 1830:  dropouts remain, in privates-auction.
>>>> - "When a private has 3-or-more bidders, the auction will continue,
>>>> even after one bidder passes and drops out.
>>>> However, rails also continues to allow that player(s) to bid  
>>>> again."
>>>> - Confirmed and fixed.
>>>
>>> I believe these players are supposed to be allowed to bid again.
>>
>> Hmm, you may be right on this one. The rules don't say anything
>> explicitly
>> about passing players dropping out of the auction. The rules book
>> quote
>> give by Jim in the bug report ('There's a specific example of this
>> in the 1830 rulebook, in italics on page 5, rhs: "Player #2 must
>> raise the bid.. or drop out".') is not conclusive, as in the case
>> described only two players are bidding; thenm if one passes,
>> bidding ends regardless whether the pass-then-drop-out rule
>> applies or not.
>>
>> Perhaps I have to revert this fix.
>> Any other opinions?
>>
>>>> #2898830 - priority incorrectly affected by privates auctions.
>>>> - "Rails doesn't handle priority correctly across a typical
>>> 1830-style
>>>> privates auction. Note that the auction itself, does not count as a
>>>> player action- for the bidders, winner, etc. In rails, it
>>> appears to."
>>>> - Confirmed and fixed. The fix is generic: auctioning will
>>> now never
>>>> change the PD after bidding in any game. Not sure of this rule  
>>>> holds
>>>> for all games, but I'm currently not aware of any exceptions.
>>>
>>> I believe this purchase, like any other, does determine the Priority
>>> Deal if it is followed by everyone passing (even though it does not
>>> change who is next in the stock round that was interrupted by the
>>> auction).  I would handle this by making the auction its own "round"
>>> (which implies that one "round" can interrupt another - a capability
>>> that would also apply to the minor-exchange rounds in 1835/37/2038,
>>> CGR formation in 1856, and mergers and the IRSFF split in 1841).
>>
>> I don't think so.
>> On what written 1830 rule would you base your statement: 'I believe
>> this purchase, like any other, does determine the Priority Deal
>> if it is followed by everyone passing'?
>>
>> The round-within-a-round approach is indeed what Rails does (or will
>> do
>> when the time comes) in the other cases that you mention.
>> But not (yet) in the 1830-style auction-within-the-initial-round.
>> Thinking about it, that might indeed have simplified the code.
>>
>> Regards,
>> Erik.
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel