Menu
▾
▴
rails-devel
|
From: Stefan F. <ste...@we...> - 2010-07-11 17:21:22
|
Erik: two quick fixes of reported bugs and a few comments/questions related to this: 3010534: 1856 1/2 share from limit can't buy 5% share of CGR - The reason was that the call to the certification limit test did not consider the certificate count (1/2 here), assuming that each certificate counts full. - From the code it seems that defining certificate types might help. Then it would be easier to group the certificates available in the pool or the player's portfolios. Other games might even have more variation. - The Buy action (still) do not store the certificate ids, if more than one certificate is sold. The sell action does not store the ids at all. The same is true for the Exchange for Share action. This poses the risk of reload errors especially after undos. 3025465: 1856. THB token spot blocked inappropriately - Here the case of a non-blocking home base on OO-Tiles was not accounted for. Fixed that now by changing the home city to null as long as the home city is not selected. Adjusted the paint method in GUIHex to find a free slot to paint the home company name on. - I always wonder, if the token methods and the token variables in city are restricted to BaseTokens only or if they can hold any type of Tokens (as the TokenI signature suggests). If the latter is the case some methods might not work as intended, for example hasTokenSlotsLeft(). Sometimes it seems that the common interface TokenI creates more confusion than it saves code, as most of the time Base and BonusTokens are handled in separate methods anyhow. - Going forward thinking about 1870 which has DestinationTokens, which behave in some respect like BaseTokens and in other like BonusTokens, things do not get easier in the near future. A general token class, which allows to configure the behavior of tokens and define TokenTypes might be an alternative, but requires lot of refactoring. But then the TokenI interface is helpful for a start with. Stefan Curiuos, who wins the worldcup tonight ;-) Good luck for the Dutch team. |
|
From: Erik V. <eri...@xs...> - 2010-07-11 18:25:39
|
Stefan, Some responses below. Erik. -----Original Message----- From: Stefan Frey [mailto:ste...@we...] Sent: Sunday 11 July 2010 19:21 To: Development list for Rails: an 18xx game Subject: [Rails-devel] Two bug fixes - questions to Erik Erik: two quick fixes of reported bugs and a few comments/questions related to this: 3010534: 1856 1/2 share from limit can't buy 5% share of CGR - The reason was that the call to the certification limit test did not consider the certificate count (1/2 here), assuming that each certificate counts full. [EV] The easy fix would be to use the cert.count. Any problems with that? - From the code it seems that defining certificate types might help. Then it would be easier to group the certificates available in the pool or the player's portfolios. Other games might even have more variation. [EV] You mean different types for 5% and 10% shares? Or what else? On first sight I don't see much value in that. - The Buy action (still) do not store the certificate ids, if more than one certificate is sold. The sell action does not store the ids at all. The same is true for the Exchange for Share action. This poses the risk of reload errors especially after undos. [EV] I remember you have discussed this before, but I haven't yet managed to understand what exact problem storing certificate IDs would fix. Does this relate to the known problem that items in lists are generally moved to a different position after an undo? That shouldn't be difficult to fix, but I haven't yet got to it. Pending that generic solution, I have fixed a few apparent cases; there may be others, but I haven't any good examples. 3025465: 1856. THB token spot blocked inappropriately - Here the case of a non-blocking home base on OO-Tiles was not accounted for. Fixed that now by changing the home city to null as long as the home city is not selected. Adjusted the paint method in GUIHex to find a free slot to paint the home company name on. [EV] Hmm, I have always thought that the same token laying rules would apply to the THB home hex (Hamilton) as to the Erie home hex in 1830, and so I have implemented it identically. But I see that the 1856 rules are silent on this point, and can't find any clarifications either. Is it indeed generally agreed that another company may lay a token in Hamilton before the THB does? - I always wonder, if the token methods and the token variables in city are restricted to BaseTokens only or if they can hold any type of Tokens (as the TokenI signature suggests). If the latter is the case some methods might not work as intended, for example hasTokenSlotsLeft(). Sometimes it seems that the common interface TokenI creates more confusion than it saves code, as most of the time Base and BonusTokens are handled in separate methods anyhow. [EV] There already is the concept of "off-station" tokens, which e.g. applies to the 18AL coalfield token. Please note, that the code carefully distinguishes between "base tokens" and "bonus tokens". Not sure how much value the existing TokenI interface really has, but there many other useless interfaces that I would rather ditch than this one. - Going forward thinking about 1870 which has DestinationTokens, which behave in some respect like BaseTokens and in other like BonusTokens, things do not get easier in the near future. A general token class, which allows to configure the behavior of tokens and define TokenTypes might be an alternative, but requires lot of refactoring. But then the TokenI interface is helpful for a start with. [EV] I would consider destination tokens as base tokens which (temporarily) can be placed in an off-station location, but that would IMO not change their base token character. Nevertheless I totally agree that this is a hard one, which may require some rethinking on how tokens will be handled, in particular in the UI. It's one reason that 1870 is not that high on my wish list (another one being that I have never played 1870). Curiuos, who wins the worldcup tonight ;-) Good luck for the Dutch team. [EV] Thanks - we'll need it. High time to turn on the TV. |
|
From: Stefan F. <ste...@we...> - 2010-07-12 21:54:38
|
Erik, seems that the amount of luck was not sufficient to beat the best team of tne WorldCup. But coming home as second is not too bad. Answers to the non-THB issues below. Stefan Quick answers see below: > 3010534: 1856 1/2 share from limit can't buy 5% share of CGR > - The reason was that the call to the certification limit test did not > consider the certificate count (1/2 here), assuming that each certificate > counts full. > > [EV] The easy fix would be to use the cert.count. Any problems with that? Did that, no problem. > > - From the code it seems that defining certificate types might help. > [EV] You mean different types for 5% and 10% shares? Or what else? On first > sight I don't see much value in that. In the code you twice (once for buying and selling) extract those shares that have common properties. Certificates currently differ only for percentages (or number shares), certificate counts and president property. It would be easier to refactor that into if there would be a certificateTypes. Or one could proxy that by a getCertificateTypes(), which returns a list of certificates, which represent the different classes. But the main value lies in the for Rails typical two-tier structure, where a type of something is configured first and then instances are created derived from the type (like TrainType, CompanyType) etc. I am much in favor of that approach as it allows a lot of flexibility going foward. > > - The Buy action (still) do not store the certificate ids, if more than one > certificate is sold. The sell action does not store the ids at all. The > same > > is true for the Exchange for Share action. This poses the risk of reload > errors especially after undos. > > [EV] I remember you have discussed this before, but I haven't yet managed > to understand what exact problem storing certificate IDs would fix. Does > this relate to the known problem that items in lists are generally moved to > a different position after an undo? That shouldn't be difficult to fix, but > I haven't yet got to it. Pending that generic solution, I have fixed a few > apparent cases; there may be others, but I haven't any good examples. Sorry I thought you had mentioned that you already implemented that (but this referred to the brown stock spaces). Yes it is an alternative solution for the reload problems after undo. Advantages: A) It does not require the protection of order of the interchangable objects, which is somehow counterintuitive. B) It allows the use of HashMaps/HashSets to store the interchangable objects. But implementing both is the best protection, especially for future extensions, as - if I remember correctly - you need the order protection for the portfolio certificates already to keep the certificate ordering of the IPO stack in 1835 I could give it a try, but it might break the savefile compatability. If that is the case it should be moved to a later release. > [EV] There already is the concept of "off-station" tokens, which e.g. > applies to the 18AL coalfield token. Please note, that the code carefully > distinguishes between "base tokens" and "bonus tokens". Not sure how much > value the existing TokenI interface really has, but there many other > useless interfaces that I would rather ditch than this one. That is exactly the problem TokenI: It is not totally useless (like some others. :-)), but still most of the time baseTokens and bonusTokens are treated separately. I was wondering for example, if I could replace the TokenI variables/methods for cities with a BaseToken signature and Rails would work identical: Or same question reverse: Is there a use case that requires a storage a BonusToken in a city object using the city's tokens variable? > > [EV] I would consider destination tokens as base tokens which (temporarily) > can be placed in an off-station location, but that would IMO not change > their base token character. Nevertheless I totally agree that this is a > hard one, which may require some rethinking on how tokens will be handled, > in particular in the UI. It's one reason that 1870 is not that high on my > wish list (another one being that I have never played 1870). 1870 is a good next target, as it requires some interesting concepts, but is still not too far away from 1830. |
|
From: Stefan F. <ste...@we...> - 2010-07-12 21:03:50
|
> 3025465: 1856. THB token spot blocked inappropriately > [EV] Hmm, I have always thought that the same token laying rules would > apply to the THB home hex (Hamilton) as to the Erie home hex in 1830, and > so I have implemented it identically. But I see that the 1856 rules are > silent on this point, and can't find any clarifications either. Is it > indeed generally agreed that another company may lay a token in Hamilton > before the THB does? Erik, thanks for catching this ambiguity. I thought you intended that behavior as for the Erie compatability an unlaidHomeBlocksTokens="yes" for Hamilton was missing. I checked the rules before the fix and it seemed that the indicate that a token can be laid. As there is no special rule for THB as for the Erie in 1830, it falls back to the standard spec: "In the starting city for a company that has not yet started, a company cannot place a station marker on the last available space (if an extra space becomes available later, the station marker may then be placed)." Seems the question is if the two cities on the OO tile are considered as one entity. The 1856 FAQ of Steve Thomas is also quiet on this topic. At least the group, which filed the bug, considers the Hamilton hex not completely blocked. Does anyone of the 1856 experts (I am not) have a definite answer or should we escalate the question to the 18xx yahoo list? Stefan |
|
From: Stefan F. <ste...@we...> - 2010-08-12 21:14:21
|
Some time ago I forwarded the question to the yahoo group. There were two possible interpretations suggested: A) THB home hex is blocked like Erie until brown, except that on the gray 3 slots tile, two companies can token before THB. B) As long as the other slot stays open, tokening of one company is allowed. There is a new game option that allows to select A) or B). Default is B) as it allows play of A) if players decide to interpret the rule differently. For this I rewrote the token blocking procedure: Companies with undecided tokens can have two different blocking behaviors: i) Block a slot in all cities of that hex (allCitiesBlocked = yes in XML for the company) ii) Block a slot in any city of that hex (allCitiesBlocked = no in XML for the company) i) is the behavior of Erie and THB in variant A) ii) is the behavior of THB in variant B) The blocking procedure potentially works for multiple home bases in a single hex now. I kept the blockedForTokenLays attribute of the MapHex for 1835 compatibilty (Preussen does not block an additional slot of Berlin) and other future use. Stefan On Monday, July 12, 2010 11:03:45 pm Stefan Frey wrote: > > 3025465: 1856. THB token spot blocked inappropriately > > > > [EV] Hmm, I have always thought that the same token laying rules would > > apply to the THB home hex (Hamilton) as to the Erie home hex in 1830, and > > so I have implemented it identically. But I see that the 1856 rules are > > silent on this point, and can't find any clarifications either. Is it > > indeed generally agreed that another company may lay a token in Hamilton > > before the THB does? > > Erik, > thanks for catching this ambiguity. I thought you intended that behavior as > for the Erie compatability an unlaidHomeBlocksTokens="yes" for Hamilton was > missing. > > I checked the rules before the fix and it seemed that the indicate that a > token can be laid. As there is no special rule for THB as for the Erie in > 1830, it falls back to the standard spec: > "In the starting city for a company that has not yet started, a company > cannot place a station marker on the last available space (if an extra > space becomes available later, the station marker may then be placed)." > Seems the question is if the two cities on the OO tile are considered as > one entity. > The 1856 FAQ of Steve Thomas is also quiet on this topic. > > At least the group, which filed the bug, considers the Hamilton hex not > completely blocked. Does anyone of the 1856 experts (I am not) have a > definite answer or should we escalate the question to the 18xx yahoo list? > > Stefan > > --------------------------------------------------------------------------- > --- This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2010-07-13 18:54:14
|
See below [EV2] > - From the code it seems that defining certificate types might help. > [EV] You mean different types for 5% and 10% shares? Or what else? On first > sight I don't see much value in that. In the code you twice (once for buying and selling) extract those shares that have common properties. Certificates currently differ only for percentages (or number shares), certificate counts and president property. It would be easier to refactor that into if there would be a certificateTypes. Or one could proxy that by a getCertificateTypes(), which returns a list of certificates, which represent the different classes. But the main value lies in the for Rails typical two-tier structure, where a type of something is configured first and then instances are created derived from the type (like TrainType, CompanyType) etc. I am much in favor of that approach as it allows a lot of flexibility going foward. [EV2] My thinking was, that certificates of *one* company only differ in share percentage and presidency, and these differences can easily be represented by just two attributes. In several games, train types and company types have many more and more profound differences. That's why I don't see that much added value in certificate types. But I'm not at all opposed to such refactoring. > > - The Buy action (still) do not store the certificate ids, if more than one > certificate is sold. The sell action does not store the ids at all. The > same > > is true for the Exchange for Share action. This poses the risk of reload > errors especially after undos. > > [EV] I remember you have discussed this before, but I haven't yet managed > to understand what exact problem storing certificate IDs would fix. Does > this relate to the known problem that items in lists are generally moved to > a different position after an undo? That shouldn't be difficult to fix, but > I haven't yet got to it. Pending that generic solution, I have fixed a few > apparent cases; there may be others, but I haven't any good examples. Sorry I thought you had mentioned that you already implemented that (but this referred to the brown stock spaces). Yes it is an alternative solution for the reload problems after undo. Advantages: A) It does not require the protection of order of the interchangable objects, which is somehow counterintuitive. B) It allows the use of HashMaps/HashSets to store the interchangable objects. But implementing both is the best protection, especially for future extensions, as - if I remember correctly - you need the order protection for the portfolio certificates already to keep the certificate ordering of the IPO stack in 1835 I could give it a try, but it might break the savefile compatability. If that is the case it should be moved to a later release. [EV2] In any case, sequence preservation is high on my next-to-do list (the main obstacle being a lack of test cases). > [EV] There already is the concept of "off-station" tokens, which e.g. > applies to the 18AL coalfield token. Please note, that the code carefully > distinguishes between "base tokens" and "bonus tokens". Not sure how much > value the existing TokenI interface really has, but there many other > useless interfaces that I would rather ditch than this one. That is exactly the problem TokenI: It is not totally useless (like some others. :-)), but still most of the time baseTokens and bonusTokens are treated separately. I was wondering for example, if I could replace the TokenI variables/methods for cities with a BaseToken signature and Rails would work identical: Or same question reverse: Is there a use case that requires a storage a BonusToken in a city object using the city's tokens variable? [EV2] Don't think so (though you can never know what creative 18xx designers will invent next year), but the reverse does occur. In 1870, base tokens can appear (without functional change) in off-station locations, so for that purpose alone I think we would need something like TokenI to specify the contents of off-station spots on tiles, because in other games BonusTokens may appear on such tiles. 18FL is a bit different in that base tokens may metamorphose into BonusTokens (hotels) - or one could say: that game's tokens have a dual nature: another case for TokenI? In general I would have no problem to change TokenI into BaseToken or BonusToken wherever appropriate - I'm just not so sure if we can rely upon our current understanding of appropriateness. Erik. |
|
From: Stefan F. <ste...@we...> - 2010-07-13 21:34:39
|
Erik: there was a test case for the sequence problem attached some time ago. I have forwarded that e-mail to you directly. Stefan Just some (random) thoughts on Tokens: Going forward I think we can leverage on the TokenHolder interface. A helpful thing would be to register all TokenHolders to a TokenManager. This would for example allow to find all BaseTokens for RevenueCalculation. Maybe we could add for each Token a kind of workflow definition in XML, which defines possible TokenHolder locations and possible transitions between them: For example: * In standard games BaseTokens start in PublicCompanies portfolios and move to City locations. * Some BonusTokens start with PrivateCompanies move to PublicCompanies and then to MapHex locatons. On Tuesday 13 July 2010 20:54:05 Erik Vos wrote: > See below [EV2] > > > - From the code it seems that defining certificate types might help. > > > > [EV] You mean different types for 5% and 10% shares? Or what else? On > > first > > > sight I don't see much value in that. > > In the code you twice (once for buying and selling) extract those shares > that > have common properties. Certificates currently differ only for percentages > (or > number shares), certificate counts and president property. > > It would be easier to refactor that into if there would be a > certificateTypes. > Or one could proxy that by a getCertificateTypes(), which returns a list of > certificates, which represent the different classes. > > But the main value lies in the for Rails typical two-tier structure, where > a > > type of something is configured first and then instances are created > derived > > from the type (like TrainType, CompanyType) etc. I am much in favor of that > approach as it allows a lot of flexibility going foward. > > [EV2] My thinking was, that certificates of *one* company only differ in > share percentage and presidency, and these differences can easily be > represented by just two attributes. In several games, train types and > company types have many more and more profound differences. That's why I > don't see that much added value in certificate types. But I'm not at all > opposed to such refactoring. > > > - The Buy action (still) do not store the certificate ids, if more than > > one > > > certificate is sold. The sell action does not store the ids at all. The > > same > > > > is true for the Exchange for Share action. This poses the risk of reload > > errors especially after undos. > > > > [EV] I remember you have discussed this before, but I haven't yet managed > > to understand what exact problem storing certificate IDs would fix. Does > > this relate to the known problem that items in lists are generally moved > > to > > > a different position after an undo? That shouldn't be difficult to fix, > > but > > > I haven't yet got to it. Pending that generic solution, I have fixed a > > few apparent cases; there may be others, but I haven't any good examples. > > Sorry I thought you had mentioned that you already implemented that (but > this > referred to the brown stock spaces). > Yes it is an alternative solution for the reload problems after undo. > > Advantages: > A) It does not require the protection of order of the interchangable > objects, > which is somehow counterintuitive. > B) It allows the use of HashMaps/HashSets to store the interchangable > objects. > > But implementing both is the best protection, especially for future > extensions, as - if I remember correctly - you need the order protection > for > > the portfolio certificates already to keep the certificate ordering of the > IPO stack in 1835 > > I could give it a try, but it might break the savefile compatability. If > that > is the case it should be moved to a later release. > > [EV2] In any case, sequence preservation is high on my next-to-do list (the > main obstacle being a lack of test cases). > > > [EV] There already is the concept of "off-station" tokens, which e.g. > > applies to the 18AL coalfield token. Please note, that the code carefully > > distinguishes between "base tokens" and "bonus tokens". Not sure how much > > value the existing TokenI interface really has, but there many other > > useless interfaces that I would rather ditch than this one. > > That is exactly the problem TokenI: It is not totally useless (like some > others. :-)), but still most of the time baseTokens and bonusTokens are > treated separately. I was wondering for example, if I could replace the > TokenI variables/methods for cities with a BaseToken signature and Rails > would work identical: Or same question reverse: Is there a use case that > requires a storage a BonusToken in a city object using the city's tokens > variable? > > [EV2] Don't think so (though you can never know what creative 18xx > designers will invent next year), but the reverse does occur. In 1870, base > tokens can appear (without functional change) in off-station locations, so > for that purpose alone I think we would need something like TokenI to > specify the contents of off-station spots on tiles, because in other games > BonusTokens may appear on such tiles. 18FL is a bit different in that base > tokens may metamorphose into BonusTokens (hotels) - or one could say: that > game's tokens have a dual nature: another case for TokenI? > In general I would have no problem to change TokenI into BaseToken or > BonusToken wherever appropriate - I'm just not so sure if we can rely upon > our current understanding of appropriateness. > > Erik. > > > --------------------------------------------------------------------------- >--- This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > 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