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