Menu
▾
▴
rails-devel
|
From: Erik V. <eri...@xs...> - 2011-06-09 14:10:39
|
As announced before, I have been thinking about how to upgrade train management to enable some new features that currently can't be implemented (notably items 2 and 5 of the below list). I'm aware of the following cases to be taken into account: 1. Normal trains. 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm aware of having such flip-side trains, and which have considered so far). 3. Initial trains (as in 18EU). 4. Fixed trains (at a cost, as some 1825 minors have). 5. Extra trains from a private special property (as in 18GA). Any others? The basic idea is to separate train certificates from actual trains. Train certificates are objects that can be traded. Each certificate represents a potential train, designated by a train type object. A dual train certificate represents one of two potential trains, and is therefore linked to two train type objects. Trains are objects owned and held by companies only. Trains are no longer created at the game start, but at the time that a company acquires a train by whatever means. The possibilities are: 1. Buy a normal train certificate: create a train object. 2. Buy a dual train certificate: ask the player what type is wanted (this can affect the price), and instantiate a train of that train type only. 3. An initial train as in 18EU is obtained by autobuying a train (certificate) at zero cost at floating time (similar to as it works now). 4. A fixed train as in 1825 is obtained by autobuying a non-tradable train (perhaps without a certificate) at nonzero cost at floating time. 5. The 18GA extra 2-train is not tradable and is not related to a train certificate. It is created when a company buys the OSRR private before phase 4. When a train is traded between companies, both the train certificate and the train object are moved. When a train is discarded to the Pool, the train certificate is moved, but the train object is destroyed. These two procedures are formulated this way to precisely implement the very explicit 18VA dual train rules: when a dual train certificate is traded between companies, the initial train choice must still be honoured, but when a train certificate enters the pool, that choice is erased. As far as I can see, the 1846 rules are somewhat less explicit but no different. The 18Scan rules seem to be silent on this matter, but I assume the 18VA rules also apply to 18Scan. If anyone is aware of different cases, please let me know. Any comments? Do other cases exist that I have overlooked but need be considered separately? Erik. |
|
From: Phil D. <de...@gm...> - 2011-06-09 14:47:19
|
They aren't considered separately but going from memory the 6/4D trains in 18Ardennes also work this way. With the further restriction that only 10 share companies can buy the 4D (presumably limit the purchase of traincerts by company should be fairly trivial) Phil On 9 June 2011 15:10, Erik Vos <eri...@xs...> wrote: > As announced before, I have been thinking about how to upgrade train > management to enable some new features that currently can't be implemented > (notably items 2 and 5 of the below list). > > I'm aware of the following cases to be taken into account: > 1. Normal trains. > 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm > aware of having such flip-side trains, and which have considered so far). > 3. Initial trains (as in 18EU). > 4. Fixed trains (at a cost, as some 1825 minors have). > 5. Extra trains from a private special property (as in 18GA). > Any others? > > The basic idea is to separate train certificates from actual trains. > > Train certificates are objects that can be traded. Each certificate > represents a potential train, designated by a train type object. A dual > train certificate represents one of two potential trains, and is therefore > linked to two train type objects. > > Trains are objects owned and held by companies only. Trains are no longer > created at the game start, but at the time that a company acquires a train > by whatever means. The possibilities are: > 1. Buy a normal train certificate: create a train object. > 2. Buy a dual train certificate: ask the player what type is wanted (this > can affect the price), and instantiate a train of that train type only. > 3. An initial train as in 18EU is obtained by autobuying a train > (certificate) at zero cost at floating time (similar to as it works now). > 4. A fixed train as in 1825 is obtained by autobuying a non-tradable train > (perhaps without a certificate) at nonzero cost at floating time. > 5. The 18GA extra 2-train is not tradable and is not related to a train > certificate. It is created when a company buys the OSRR private before phase > 4. > > When a train is traded between companies, both the train certificate and the > train object are moved. > When a train is discarded to the Pool, the train certificate is moved, but > the train object is destroyed. > These two procedures are formulated this way to precisely implement the very > explicit 18VA dual train rules: when a dual train certificate is traded > between companies, the initial train choice must still be honoured, but when > a train certificate enters the pool, that choice is erased. As far as I can > see, the 1846 rules are somewhat less explicit but no different. The 18Scan > rules seem to be silent on this matter, but I assume the 18VA rules also > apply to 18Scan. If anyone is aware of different cases, please let me know. > > Any comments? Do other cases exist that I have overlooked but need be > considered separately? > > Erik. > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Scott P. <sc...@re...> - 2011-06-09 16:00:43
|
Would this be a good time to implement the phase change effects of the nth train being purchased as in the Derrick games? 18TN: 4-trains obsolete (not rust) when the second 6-train is purchased (4-trains the the pool are removed). |
|
From: Erik V. <eri...@xs...> - 2011-06-09 18:56:10
|
Ah yes, thanks for the reminder. I believe this can be accomplished independently from the other issues. Erik. Van: Scott Petersen [mailto:sc...@re...] Verzonden: donderdag 9 juni 2011 18:00 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Train management Would this be a good time to implement the phase change effects of the nth train being purchased as in the Derrick games? 18TN: 4-trains obsolete (not rust) when the second 6-train is purchased (4-trains the the pool are removed). |
|
From: Erik V. <eri...@xs...> - 2011-06-09 18:58:31
|
Good point, I'll keep it in mind. > -----Oorspronkelijk bericht----- > Van: Phil Davies [mailto:de...@gm...] > Verzonden: donderdag 9 juni 2011 16:47 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Train management > > They aren't considered separately but going from memory the 6/4D trains in > 18Ardennes also work this way. With the further restriction that only 10 > share companies can buy the 4D (presumably limit the purchase of traincerts > by company should be fairly trivial) > > Phil > > On 9 June 2011 15:10, Erik Vos <eri...@xs...> wrote: > > As announced before, I have been thinking about how to upgrade train > > management to enable some new features that currently can't be > > implemented (notably items 2 and 5 of the below list). > > > > I'm aware of the following cases to be taken into account: > > 1. Normal trains. > > 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games > > I'm aware of having such flip-side trains, and which have considered so far). > > 3. Initial trains (as in 18EU). > > 4. Fixed trains (at a cost, as some 1825 minors have). > > 5. Extra trains from a private special property (as in 18GA). > > Any others? > > > > The basic idea is to separate train certificates from actual trains. > > > > Train certificates are objects that can be traded. Each certificate > > represents a potential train, designated by a train type object. A > > dual train certificate represents one of two potential trains, and is > > therefore linked to two train type objects. > > > > Trains are objects owned and held by companies only. Trains are no > > longer created at the game start, but at the time that a company > > acquires a train by whatever means. The possibilities are: > > 1. Buy a normal train certificate: create a train object. > > 2. Buy a dual train certificate: ask the player what type is wanted > > (this can affect the price), and instantiate a train of that train type only. > > 3. An initial train as in 18EU is obtained by autobuying a train > > (certificate) at zero cost at floating time (similar to as it works now). > > 4. A fixed train as in 1825 is obtained by autobuying a non-tradable > > train (perhaps without a certificate) at nonzero cost at floating time. > > 5. The 18GA extra 2-train is not tradable and is not related to a > > train certificate. It is created when a company buys the OSRR private > > before phase 4. > > > > When a train is traded between companies, both the train certificate > > and the train object are moved. > > When a train is discarded to the Pool, the train certificate is moved, > > but the train object is destroyed. > > These two procedures are formulated this way to precisely implement > > the very explicit 18VA dual train rules: when a dual train certificate > > is traded between companies, the initial train choice must still be > > honoured, but when a train certificate enters the pool, that choice is > > erased. As far as I can see, the 1846 rules are somewhat less > > explicit but no different. The 18Scan rules seem to be silent on this > > matter, but I assume the 18VA rules also apply to 18Scan. If anyone is > aware of different cases, please let me know. > > > > Any comments? Do other cases exist that I have overlooked but need be > > considered separately? > > > > Erik. > > > > > > ---------------------------------------------------------------------- > > -------- EditLive Enterprise is the world's most technically advanced > > content authoring tool. Experience the power of Track Changes, Inline > > Image Editing and ensure content is compliant with Accessibility > > Checking. > > http://p.sf.net/sfu/ephox-dev2dev > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ---------------------------------------------------------------------------- -- > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image Editing > and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: John A. T. <ja...@ja...> - 2011-06-09 16:19:49
|
On Thu, Jun 9, 2011 at 10:10 AM, Erik Vos <eri...@xs...> wrote: > As announced before, I have been thinking about how to upgrade train > management to enable some new features that currently can't be implemented > (notably items 2 and 5 of the below list). > > I'm aware of the following cases to be taken into account: > 1. Normal trains. > 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm > aware of having such flip-side trains, and which have considered so far). > 3. Initial trains (as in 18EU). > 4. Fixed trains (at a cost, as some 1825 minors have). > 5. Extra trains from a private special property (as in 18GA). > Any others? > In 1844, the state railroad has a pre-printed 5H on its charter that never goes away but counts towards the train limit. -- John A. Tamplin |
|
From: Erik V. <eri...@xs...> - 2011-06-09 19:14:38
|
If I’m not mistaken, the SBB fixed train behaves not any differently than the 1825 minor fixed trains, except that it is for free. Erik. Van: John A. Tamplin [mailto:ja...@ja...] Verzonden: donderdag 9 juni 2011 18:12 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Train management On Thu, Jun 9, 2011 at 10:10 AM, Erik Vos <eri...@xs...> wrote: As announced before, I have been thinking about how to upgrade train management to enable some new features that currently can't be implemented (notably items 2 and 5 of the below list). I'm aware of the following cases to be taken into account: 1. Normal trains. 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm aware of having such flip-side trains, and which have considered so far). 3. Initial trains (as in 18EU). 4. Fixed trains (at a cost, as some 1825 minors have). 5. Extra trains from a private special property (as in 18GA). Any others? In 1844, the state railroad has a pre-printed 5H on its charter that never goes away but counts towards the train limit. -- John A. Tamplin |
|
From: Schnell, V. <vol...@ar...> - 2011-06-09 21:04:53
|
Hi,
some train specials from OO-Games
1844, Switzerland, private company Nr. 7 owns a train (5h) which can
assigned to a company with a trainslot and run it in its first operating
round
1844, Regional-company can acquire only h-Trains.
1844, when the first 3-train is bought, all 2 Trains became 2h-Trains (3
to 3h with 5 train, 4 to 4h with 6-Train, 5 to 5h with 8-Train)
1853, lookout version, if opening of small companies (nr.(5),6,7,8)
occurs, all 6 2 Trains became 7 2/1M Trains, a 2M and a 3M Train are added.
if all 7 2/1M trains are bought before the first 3-Train, more 2/1M
trains are available until the first 3-Train
big company (1-4 (5)) can't buy 1M-Trains.
18C2C, Merged company have 2 Lok-Shells,
1824/1837 Austria, coal company can only own G-Trains
1880 2R (restaurated 2 Trains, which take a trainslot but are not
sufficient for the lok duty
1880, China, private has the right, to take an actual train before the
company run, or when it is closed with the first 4-Train, take the
second 4-train.
at this moment appointment to a company with no free trainslot is
possible, just throw away an older one. if no appointment is
possible, the 4-train is gone
greetings
Volker Schnell
Am 09.06.2011 21:14, schrieb Erik Vos:
>
> If I’m not mistaken, the SBB fixed train behaves not any differently
> than the 1825 minor fixed trains, except that it is for free.
>
> Erik.
>
> *Van:*John A. Tamplin [mailto:ja...@ja...]
> *Verzonden:* donderdag 9 juni 2011 18:12
> *Aan:* Development list for Rails: an 18xx game
> *Onderwerp:* Re: [Rails-devel] Train management
>
> On Thu, Jun 9, 2011 at 10:10 AM, Erik Vos <eri...@xs...
> <mailto:eri...@xs...>> wrote:
>
> As announced before, I have been thinking about how to upgrade train
> management to enable some new features that currently can't be implemented
> (notably items 2 and 5 of the below list).
>
> I'm aware of the following cases to be taken into account:
> 1. Normal trains.
> 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm
> aware of having such flip-side trains, and which have considered so far).
> 3. Initial trains (as in 18EU).
> 4. Fixed trains (at a cost, as some 1825 minors have).
> 5. Extra trains from a private special property (as in 18GA).
> Any others?
>
> In 1844, the state railroad has a pre-printed 5H on its charter that
> never goes away but counts towards the train limit.
>
>
> --
> John A. Tamplin
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: John D. G. <jd...@di...> - 2011-06-09 22:02:07
|
On 2011-06-09 07:10, Erik Vos wrote: > As announced before, I have been thinking about how to upgrade train > management to enable some new features that currently can't be implemented > (notably items 2 and 5 of the below list). > > I'm aware of the following cases to be taken into account: > 1. Normal trains. > 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm > aware of having such flip-side trains, and which have considered so far). > 3. Initial trains (as in 18EU). > 4. Fixed trains (at a cost, as some 1825 minors have). > 5. Extra trains from a private special property (as in 18GA). > Any others? > > The basic idea is to separate train certificates from actual trains. I don't see any reason to want to do this. I would handle all these cases as follows. Case 1: The train is an object as now. Case 2: There can be more than one type of new train available at a time. Create XML attributes for each type of train that allow that type to become available for purchase as a result of an event, and that allow the total number of available trains of two types to be limited to a constant. In addition to the cases you've listed, one or both of these would apply to: diesels in 1830 and 1856 (available after first 6 train); 'G' trains in 1837; meter gauge trains in 1853 (especially the 2/1G trains in the Stuart Dagger variant, though I'm not sure if those made it into 1853v2); and the two versions of types I-V in 2038. But there is no reason ever to create a "train certificate" object, because the type of a train becomes fixed in stone as soon as it is first acquired by a company. I don't know of an exception to this in any game. Cases 3, 4, 5: Simply allow a company to be hard-coded as having specified train(s) before the game starts. This includes privates (for case 5). By default a private company which owns a train can't do anything with it, not even sell it, so no new code should be needed; but of course 2038's probe would be an exception. |
|
From: Phil D. <de...@gm...> - 2011-06-09 22:06:40
|
On 9 June 2011 22:34, John David Galt <jd...@di...> wrote: > But there is no reason ever to create a "train certificate" object, > because the type of a train becomes fixed in stone as soon as it is first > acquired by a company. I don't know of an exception to this in any game. Erik already mentioned above but in 18VA, if a train gets discarded to the pool it reverts to being a certificate and the new purchaser can choose which type of train it is. Phil |
|
From: Erik V. <eri...@xs...> - 2011-06-09 22:17:32
|
OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now. The implementation is a bit provisional, as it only covers rusting yet. I think we'll have to move to a more generic approach, in which any type of action can be triggered that is normally associated with phase changes. Erik. Van: Erik Vos [mailto:eri...@xs...] Verzonden: donderdag 9 juni 2011 20:56 Aan: 'Development list for Rails: an 18xx game' Onderwerp: Re: [Rails-devel] Train management Ah yes, thanks for the reminder. I believe this can be accomplished independently from the other issues. Erik. Van: Scott Petersen [mailto:sc...@re...] Verzonden: donderdag 9 juni 2011 18:00 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Train management Would this be a good time to implement the phase change effects of the nth train being purchased as in the Derrick games? 18TN: 4-trains obsolete (not rust) when the second 6-train is purchased (4-trains the the pool are removed). |
|
From: Scott P. <sc...@re...> - 2011-06-17 21:53:01
|
On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote: > OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now. > **** > > ** ** > > The implementation is a bit provisional, as it only covers rusting yet. I > think we’ll have to move to a more generic approach, in which any type of > action can be triggered that is normally associated with phase changes. > Erik, I played through a test game and verify that the second 6-train rusts the 4-trains. It looks like you implemented this with the following as a property of the 6-train. <Sub index="2" rustedTrain="4"/> 18TN's Game.xml is currently configured to obsolete the 2/3/4-trains. All of those should not have the obsoleting property. The only trains that obsolete are the 4-trains on the second 6-train (hard rust on 8-train). As train obsoletion is currently implemented, it is just a "free pass" at another run once the train "rusts." I think there is currently no mechanism to make the train hard rust immediately, bypassing the obsolete "free pass." As you said, we will have to take a look at a more general solution for the half-phase changes. Also, it would be nice to implement the "you must buy a train unless you have no route" red text once obsolete trains are run and leave a company trainless. This must currently be triggered off something like a dividend of zero because it does not appear after a company's obsolete trains run and rust. |
|
From: Erik V. <eri...@xs...> - 2011-06-10 10:02:20
|
> -----Oorspronkelijk bericht----- > Van: Phil Davies [mailto:de...@gm...] > > On 9 June 2011 22:34, John David Galt <jd...@di...> > wrote: > > But there is no reason ever to create a "train certificate" object, > > because the type of a train becomes fixed in stone as soon as it is > > first acquired by a company. I don't know of an exception to this in any > game. > > Erik already mentioned above but in 18VA, if a train gets discarded to the > pool it reverts to being a certificate and the new purchaser can choose which > type of train it is. Indeed. In any case we need some kind of object that joins the two train types. Another approach that I'm considering is a new train subclass named DualTrain. This type would behave as a train if owned by a company, and as a dual train certificate if owned by the Bank. The upside is, that I suspect less changes are needed to the train handling code, but the downsides are (1) a higher chance to overlook certain required changes, and (2) we still don't have a solution for 18GA, for which we really need a different (or additional) way to create trains. Still this approach might turn out to be the easiest one. The jury is out. Erik. |
|
From: brett l. <bre...@gm...> - 2011-06-10 16:56:25
|
On Fri, Jun 10, 2011 at 3:02 AM, Erik Vos <eri...@xs...> wrote: >> -----Oorspronkelijk bericht----- >> Van: Phil Davies [mailto:de...@gm...] >> >> On 9 June 2011 22:34, John David Galt <jd...@di...> >> wrote: >> > But there is no reason ever to create a "train certificate" object, >> > because the type of a train becomes fixed in stone as soon as it is >> > first acquired by a company. I don't know of an exception to this in > any >> game. >> >> Erik already mentioned above but in 18VA, if a train gets discarded to the >> pool it reverts to being a certificate and the new purchaser can choose > which >> type of train it is. > > Indeed. In any case we need some kind of object that joins the two train > types. > > Another approach that I'm considering is a new train subclass named > DualTrain. This type would behave as a train if owned by a company, and as a > dual train certificate if owned by the Bank. > The upside is, that I suspect less changes are needed to the train handling > code, but the downsides are (1) a higher chance to overlook certain required > changes, and (2) we still don't have a solution for 18GA, for which we > really need a different (or additional) way to create trains. > Still this approach might turn out to be the easiest one. The jury is out. > > Erik. > I support your initial proposal. It makes sense to have a base class/interface used for creating as many sub-classes as are needed to describe all of the various variations on "Train". We already do this with just about every other concept. Hex, Certificate, StockMarket, etc. etc. etc. I'd much rather have a clear class hierarchy. The primary benefit will be readable, understandable code rather than a set of sub-classes that makes everyone ask, "Why is it done this way?" ---Brett. |
|
From: Stefan F. <ste...@we...> - 2011-06-11 05:19:23
|
On the train certificate vs. new train type: I guess that the biggest disadvantage of the train certificate solution is the problem to keep certificates and trains combined correctly. On reload and especially undo/redo situations the certificates and trains have to be the identical objects for each transfer. Otherwise it can get a mess similar to situations that haunted/haunt transfer of share certificates. A robust solution would be to id both certificate and train, but this requires changing all actions that refer to the trains. My proposal would be not to subclass the train class, but to implement the trainI interface: The FlipTrain or MultiTrain class uses a state pattern, which keeps a list of possible normal Trains it can change to and mainly forwards the calls to the current active one. In addition it has some additional methods/attributes which define the behavior of the flip/state change. From my point of view this would keep the number of changes to the overall code minimal and does not require to keep certificates and trains objects aligned all the time. But as always there are pros and cons to every solution. Stefan On Friday, June 10, 2011 06:55:58 pm brett lentz wrote: > On Fri, Jun 10, 2011 at 3:02 AM, Erik Vos <eri...@xs...> wrote: > >> -----Oorspronkelijk bericht----- > >> Van: Phil Davies [mailto:de...@gm...] > >> > >> On 9 June 2011 22:34, John David Galt <jd...@di...> > >> > >> wrote: > >> > But there is no reason ever to create a "train certificate" object, > >> > because the type of a train becomes fixed in stone as soon as it is > >> > first acquired by a company. I don't know of an exception to this in > > > > any > > > >> game. > >> > >> Erik already mentioned above but in 18VA, if a train gets discarded to > >> the pool it reverts to being a certificate and the new purchaser can > >> choose > > > > which > > > >> type of train it is. > > > > Indeed. In any case we need some kind of object that joins the two train > > types. > > > > Another approach that I'm considering is a new train subclass named > > DualTrain. This type would behave as a train if owned by a company, and > > as a dual train certificate if owned by the Bank. > > The upside is, that I suspect less changes are needed to the train > > handling code, but the downsides are (1) a higher chance to overlook > > certain required changes, and (2) we still don't have a solution for > > 18GA, for which we really need a different (or additional) way to create > > trains. > > Still this approach might turn out to be the easiest one. The jury is > > out. > > > > Erik. > > I support your initial proposal. It makes sense to have a base > class/interface used for creating as many sub-classes as are needed to > describe all of the various variations on "Train". > > We already do this with just about every other concept. Hex, > Certificate, StockMarket, etc. etc. etc. > > I'd much rather have a clear class hierarchy. The primary benefit will > be readable, understandable code rather than a set of sub-classes that > makes everyone ask, "Why is it done this way?" > > ---Brett. > > --------------------------------------------------------------------------- > --- EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2011-06-13 11:58:30
|
> -----Oorspronkelijk bericht----- > Van: Stefan Frey [mailto:ste...@we...] > My proposal would be not to subclass the train class, but to implement the > trainI interface: The FlipTrain or MultiTrain class uses a state pattern, which > keeps a list of possible normal Trains it can change to and mainly forwards the > calls to the current active one. Sounds good, except that we then still must create and somewhere hold a current active train object. Perhaps the following refinement would even further simplify matters: Currently the Train objects hold their own copy of (most of) the fixed TrainType attributes, such as the number of stops. That's actually redundant, we could as well pass on the calls for those attributes to the corresponding TrainType. The TrainI types then only need the (dynamic) state objects. For the new DualTrain class, this opens up the possibility to replace the 'current active train' by a 'current active train type', so we don't need to create any additional Train objects. I think this still can be a Train subclass. The main catch I then see is one of naming: we'll still need to distinguish a buyable certificate-style name (such as "2/1G"), to be used at initial buying time, and the actual train name, to be used everywhere else. That seems to be a much less drastic change to me than my original TrainCertificate proposal. Erik |
|
From: Stefan F. <ste...@we...> - 2011-06-13 15:35:23
|
Erik:
you are right: we already have a dual structure with train and trainType,
where train represents certificate and trainType the actual train attributes.
I agree with your proposal and would even suggest to remove the following
attributes from the train class:
protected int majorStops;
protected int minorStops;
protected int cost;
protected int cityScoreFactor;
protected int townScoreFactor;
protected int townCountIndicator;
Instead any request to train for this should be forwarded from train to the
traintype.
Then the train class would represent the standard train certificate which only
references one traintype and a flipTrain that can have several potential
trainTypes plus a current one (which could be null as long as it is not
defined).
If you have flipTrain subclassing Train or have both be implementations of the
interface trainI is up to you. However I prefer the latter and trainI is an
unnecessary, as imho there is no need for an interface with only one
implementation (unless you provide an official API).
Stefan
On Monday, June 13, 2011 01:58:18 pm Erik Vos wrote:
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
> >
> >
> > My proposal would be not to subclass the train class, but to implement
> > the trainI interface: The FlipTrain or MultiTrain class uses a state
> > pattern,
>
> which
>
> > keeps a list of possible normal Trains it can change to and mainly
>
> forwards the
>
> > calls to the current active one.
>
> Sounds good, except that we then still must create and somewhere hold a
> current active train object.
>
> Perhaps the following refinement would even further simplify matters:
>
> Currently the Train objects hold their own copy of (most of) the fixed
> TrainType attributes, such as the number of stops.
> That's actually redundant, we could as well pass on the calls for those
> attributes to the corresponding TrainType.
> The TrainI types then only need the (dynamic) state objects.
>
> For the new DualTrain class, this opens up the possibility to replace the
> 'current active train' by a 'current active train type', so we don't need
> to create any additional Train objects. I think this still can be a Train
> subclass.
>
> The main catch I then see is one of naming: we'll still need to distinguish
> a buyable certificate-style name (such as "2/1G"), to be used at initial
> buying time, and the actual train name, to be used everywhere else. That
> seems to be a much less drastic change to me than my original
> TrainCertificate proposal.
>
> Erik
>
>
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2011-06-13 16:05:12
|
> -----Oorspronkelijk bericht----- > Van: Stefan Frey [mailto:ste...@we...] > If you have flipTrain subclassing Train or have both be implementations of > the interface trainI is up to you. However I prefer the latter and trainI is an > unnecessary, as imho there is no need for an interface with only one > implementation (unless you provide an official API). We have many redundant interfaces, and I'd rather get rid of all of them, but there seems to be (or have been) a school of thought with some influence in this project that maintains that such interfaces are required about everywhere, just in case. I prefer to use interfaces only when there is a actual need to provide some common functionality to classes in completely different hierarchies (good examples we have are the CashHolder, Moveable and MoveableHolder interfaces). We'll find out whether or not we really need TrainI when developing the dual train class; I will consider both options. This could the only other train class we will ever need: even the 18EU Pullmann has (right or wrong) been implemented with the standard Train class; its peculiarities are handled by special code. Erik. |
|
From: Chris S. <chr...@gm...> - 2011-06-13 18:58:07
|
Note that, in 18EA there are triple train types - trains can be either freight or express or local. -- Chris Please consider the environment before printing this e-mail. On Mon, Jun 13, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote: > > -----Oorspronkelijk bericht----- > > Van: Stefan Frey [mailto:ste...@we...] > > > If you have flipTrain subclassing Train or have both be implementations > of > > the interface trainI is up to you. However I prefer the latter and trainI > is an > > unnecessary, as imho there is no need for an interface with only one > > implementation (unless you provide an official API). > > We have many redundant interfaces, and I'd rather get rid of all of them, > but there seems to be (or have been) a school of thought with some > influence > in this project that maintains that such interfaces are required about > everywhere, just in case. I prefer to use interfaces only when there is a > actual need to provide some common functionality to classes in completely > different hierarchies (good examples we have are the CashHolder, Moveable > and MoveableHolder interfaces). > > We'll find out whether or not we really need TrainI when developing the > dual > train class; I will consider both options. This could the only other train > class we will ever need: even the 18EU Pullmann has (right or wrong) been > implemented with the standard Train class; its peculiarities are handled by > special code. > > Erik. > > > > > > > > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2011-06-13 19:38:18
|
Thanks for the hint. Then MultiTrain or ChoiceTrain looks like a better name than DualTrain. Do such triple trains deviate in other aspects from the dual trains we know? The main point of considaration is the rule, that the choice cannot be changed when a chosen train is sold to another company, but erased when the train is discarded to the Pool? As discussed before, this rule is most explicitly stated in 18VA, but so far assumed to hold for all such choice trains. Erik. Van: Chris Shaffer [mailto:chr...@gm...] Verzonden: maandag 13 juni 2011 20:58 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Train management Note that, in 18EA there are triple train types - trains can be either freight or express or local. -- Chris Please consider the environment before printing this e-mail. On Mon, Jun 13, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote: > -----Oorspronkelijk bericht----- > Van: Stefan Frey [mailto:ste...@we...] > If you have flipTrain subclassing Train or have both be implementations of > the interface trainI is up to you. However I prefer the latter and trainI is an > unnecessary, as imho there is no need for an interface with only one > implementation (unless you provide an official API). We have many redundant interfaces, and I'd rather get rid of all of them, but there seems to be (or have been) a school of thought with some influence in this project that maintains that such interfaces are required about everywhere, just in case. I prefer to use interfaces only when there is a actual need to provide some common functionality to classes in completely different hierarchies (good examples we have are the CashHolder, Moveable and MoveableHolder interfaces). We'll find out whether or not we really need TrainI when developing the dual train class; I will consider both options. This could the only other train class we will ever need: even the 18EU Pullmann has (right or wrong) been implemented with the standard Train class; its peculiarities are handled by special code. Erik. ---------------------------------------------------------------------------- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Chris S. <chr...@gm...> - 2011-06-13 19:52:06
|
It seems to me from glancing at the rules that the 18EA trains are equivalent to the various dual trains. However, in 18EA, the train limit changing never causes trains to be discarded to the pool - if a company finds itself over limit due to phase change, it is allowed to stay over limit. Thus, the issue of train certificates in the pool is not relevant. -- Chris Please consider the environment before printing this e-mail. On Mon, Jun 13, 2011 at 12:38 PM, Erik Vos <eri...@xs...> wrote: > Thanks for the hint. Then MultiTrain or ChoiceTrain looks like a better > name than DualTrain. > > Do such triple trains deviate in other aspects from the dual trains we > know? > > The main point of considaration is the rule, that the choice cannot be > changed when a chosen train is sold to another company, but erased when the > train is discarded to the Pool? > > As discussed before, this rule is most explicitly stated in 18VA, but so > far assumed to hold for all such choice trains. > > > Erik. > > > > *Van:* Chris Shaffer [mailto:chr...@gm...] > *Verzonden:* maandag 13 juni 2011 20:58 > > *Aan:* Development list for Rails: an 18xx game > *Onderwerp:* Re: [Rails-devel] Train management > > > > Note that, in 18EA there are triple train types - trains can be either > freight or express or local. > > > > -- > Chris > > Please consider the environment before printing this e-mail. > > On Mon, Jun 13, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote: > > > -----Oorspronkelijk bericht----- > > Van: Stefan Frey [mailto:ste...@we...] > > > If you have flipTrain subclassing Train or have both be implementations > of > > the interface trainI is up to you. However I prefer the latter and trainI > is an > > unnecessary, as imho there is no need for an interface with only one > > implementation (unless you provide an official API). > > We have many redundant interfaces, and I'd rather get rid of all of them, > but there seems to be (or have been) a school of thought with some > influence > in this project that maintains that such interfaces are required about > everywhere, just in case. I prefer to use interfaces only when there is a > actual need to provide some common functionality to classes in completely > different hierarchies (good examples we have are the CashHolder, Moveable > and MoveableHolder interfaces). > > We'll find out whether or not we really need TrainI when developing the > dual > train class; I will consider both options. This could the only other train > class we will ever need: even the 18EU Pullmann has (right or wrong) been > implemented with the standard Train class; its peculiarities are handled by > special code. > > > Erik. > > > > > > > > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > 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