Menu
▾
▴
rails-devel
|
From: Dr. M. B. <dr....@t-...> - 2015-08-28 06:11:53
Attachments:
1830_20150828_0610_Erik.rails
|
Good morning, the current StartRound Code for 1830 with the price reducing contains a slight flaw. If all participants pass enough times that the price of the object in question drops to zero the object will be assigned to the last person that passed and not to the first person that faces the object with price 0 in the new round. Apparently rails doesnt handle the setcurrenttonextplayer-part in that context correctly. See the attached save game. Player Erik was the last one to pass the price dropped to zero, he got the private, but still has to pass anew for the next item in the StartRound ?... Regards, Martin |
|
From: Stefan F. <ste...@we...> - 2015-08-28 10:49:44
|
Martin: good catch! Yes, this does not work correctly. Interestingly this bug is also in Rails 1.x, thus most likely it never worked. :-( A fix is in that does the following: * The last player passed, first stock round finished * The first player has to purchase the first private for free, however this counts as a purchase (see 1830 rules), thus the next player to act is the second player. The next bug to fix is that the priority deal is not updated during the StartRound. This was also true in Rails 1.x. Stefan PS: I always assume now that bug reports etc. refer to rails_2_develop, unless you specify a different branch. On 08/28/2015 08:11 AM, Dr. Martin Brumm wrote: > Good morning, > the current StartRound Code for 1830 with the price reducing contains a > slight flaw. > > If all participants pass enough times that the price of the object in > question drops to zero the object will be assigned to the last person > that passed and not to the first person that faces the object with price > 0 in the new round. Apparently rails doesnt handle the > setcurrenttonextplayer-part in that context correctly. See the attached > save game. > > Player Erik was the last one to pass the price dropped to zero, he got > the private, but still has to pass anew for the next item in the > StartRound ?... > > Regards, > Martin > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Dr. M. B. <dr....@t-...> - 2015-08-28 11:20:37
|
Hi Stefan, regarding the priority not working i think thats a bug of the "static" StartRoundWIndow internally rails keeps track of the priority and everything is ok. Regards, Martin Am 28.08.15 um 12:49 schrieb Stefan Frey: > Martin: > good catch! > > Yes, this does not work correctly. Interestingly this bug is also in > Rails 1.x, thus most likely it never worked. :-( > > A fix is in that does the following: > > * The last player passed, first stock round finished > > * The first player has to purchase the first private for free, however > this counts as a purchase (see 1830 rules), thus the next player to act > is the second player. > > The next bug to fix is that the priority deal is not updated during the > StartRound. This was also true in Rails 1.x. > > > Stefan > > PS: I always assume now that bug reports etc. refer to rails_2_develop, > unless you specify a different branch. > > > On 08/28/2015 08:11 AM, Dr. Martin Brumm wrote: >> Good morning, >> the current StartRound Code for 1830 with the price reducing contains a >> slight flaw. >> >> If all participants pass enough times that the price of the object in >> question drops to zero the object will be assigned to the last person >> that passed and not to the first person that faces the object with price >> 0 in the new round. Apparently rails doesnt handle the >> setcurrenttonextplayer-part in that context correctly. See the attached >> save game. >> >> Player Erik was the last one to pass the price dropped to zero, he got >> the private, but still has to pass anew for the next item in the >> StartRound ?... >> >> Regards, >> Martin >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > ------------------------------------------------------------------------------ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Stefan F. <ste...@we...> - 2015-08-28 12:20:00
|
Yes you are correct. There is some legacy mechanism that updates the player captions in the Game Status panel. I will add a PlayerNameModel that provides automatic updates. Thanks, Stefan On 08/28/2015 01:20 PM, Dr. Martin Brumm wrote: > Hi Stefan, > > regarding the priority not working i think thats a bug of the "static" > StartRoundWIndow internally rails keeps track of the priority and > everything is ok. > > Regards, > Martin > Am 28.08.15 um 12:49 schrieb Stefan Frey: >> Martin: >> good catch! >> >> Yes, this does not work correctly. Interestingly this bug is also in >> Rails 1.x, thus most likely it never worked. :-( >> >> A fix is in that does the following: >> >> * The last player passed, first stock round finished >> >> * The first player has to purchase the first private for free, however >> this counts as a purchase (see 1830 rules), thus the next player to act >> is the second player. >> >> The next bug to fix is that the priority deal is not updated during the >> StartRound. This was also true in Rails 1.x. >> >> >> Stefan >> >> PS: I always assume now that bug reports etc. refer to rails_2_develop, >> unless you specify a different branch. >> >> >> On 08/28/2015 08:11 AM, Dr. Martin Brumm wrote: >>> Good morning, >>> the current StartRound Code for 1830 with the price reducing contains a >>> slight flaw. >>> >>> If all participants pass enough times that the price of the object in >>> question drops to zero the object will be assigned to the last person >>> that passed and not to the first person that faces the object with price >>> 0 in the new round. Apparently rails doesnt handle the >>> setcurrenttonextplayer-part in that context correctly. See the attached >>> save game. >>> >>> Player Erik was the last one to pass the price dropped to zero, he got >>> the private, but still has to pass anew for the next item in the >>> StartRound ?... >>> >>> Regards, >>> Martin >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2015-08-28 16:26:58
|
> The next bug to fix is that the priority deal is not updated during the > StartRound. This was also true in Rails 1.x. I think the historic reason was that the 1830 rules only talk about assigning the Priority Deal at each _closure_ of a stock round (including the initial one). And thinking about that, I concluded that the priority does not yet matter in the initial round. Other games may differ. As things have developed, in Rails there now indeed is a discrepancy between StartRounds and StockRounds in continuously keeping track of the (virtual) priority during a round. Erik |
|
From: Stefan F. <ste...@we...> - 2015-08-28 20:18:32
|
Erik: most likely in the beginning of Rails the PD was neither during StockRounds nor during the auction updated after each action. I added a PlayerNameModel now that is a very instructive application of the new core mechanism: Each players PlayerNameModel adds itself to the PlayerOrderModel of the PlayerManager. The PlayerOrderModel itself contains various state variables, including the PriorityPlayer state. So as soon as the PriorityPlayer variable changes this indicates that the PlayerOrderModel has changed and this implies that the PlayerNameModel could have changed. A Field in the UI observes the PlayerNameModel and gets updated accordingly. This mechanism is highly reliable and so only a few lines of code had to be added/changed to make the Player captions changing with the PriorityPlayer changing. This is now much easier in 2.0 compared to the beginning of 1.x coding. Stefan On 08/28/2015 06:26 PM, Erik Vos wrote: >> The next bug to fix is that the priority deal is not updated during the >> StartRound. This was also true in Rails 1.x. > > I think the historic reason was that the 1830 rules only talk about > assigning the Priority Deal at each _closure_ of a stock round (including > the initial one). > And thinking about that, I concluded that the priority does not yet matter > in the initial round. Other games may differ. > As things have developed, in Rails there now indeed is a discrepancy between > StartRounds and StockRounds in continuously keeping track of the (virtual) > priority during a round. > > Erik > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X