Started by jamespetts, April 11, 2017, 02:03:56 AM
0 Members and 1 Guest are viewing this topic.
Quote from: Ves on February 03, 2018, 02:26:52 PMI cant say for sure that "this is common practice" etc, but I am very sure that if such a case is needed in the real world, that is what they do. Trains in the real world are so extremely modular, so multiple splitting at once is really not an issue in the real world.Thinking about it, my example was just a small example to illustrate the point, but the scaled up version is a big shunting yard, with lots of cars changing train, and those cannot be that uncommon in the world.If the player get the possibility to assemble/disassemble convoys outside the depot, they are most probably going to expect to be able to do this.
Quote from: jamespetts on February 03, 2018, 04:04:34 PMAs I note above, the edge case that you describe of a triple split should in principle be possible (although I might need to adjust how schedules cope with consecutive stops in the same location), but the interface will not be optimised for such cases as doing so would de-optimise the code for the commoner cases.
Quote from: ACarlotti on February 04, 2018, 04:51:33 PMThere could be a second interface, although that probably isn't strictly needed (at least if otherwise redundant consist orders are allowed).
Quote from: Ves on April 30, 2018, 07:56:02 PM1 - Curently i am finding all individual vehicles the player owns by looking through all convoys on the map, however, I suppose that is quite inefficient, but I dont know of another way. Will there be another way to gather all vehicles owned by the player eventually?
Quote4 (new) - Will there be any way to identify specific vehicles, like a unique number or desc-name combined with a number or similar?
QuoteAs to Dr. Supergood's idea, it is rare for any vehicle type to have stopped being useable entirely - even with modifications - at an exact date. Post boys could easily be replaced with slightly older boys over the legal working age (at slightly higher cost); railway carriages with manual doors could have automatic central locks fitted to the doors (at cost), and so forth. Note that the expiration date for steam locomotives on British Railways was driven by economics not any extrinsic rules forbidding the use of steam. Steam continued to be used (and is still used) on the Welshpool and Llanfair light railway, which was owned by British Rail until the late 1980s when it was privatised, and steam trains regularly ran (and still do) on the main line for enthusiasts' special trains. Also, steam locomotives were used on the outer reaches of the London Underground (not in the tunnels, I hasten to add) for three years after steam was abolished on the main lines. Thus, it would be far more realistic (and easier for players to understand) for the incentive to cease to use vehicles to be economic and to accumulate gradually rather than be an arbitrary cut-off at an exact date.
Quote from: jamespetts on May 02, 2018, 09:29:11 PMVes - can you clarify whether you intend the constraint to which you refer to be limited to describing just what can and cannot ever be coupled/uncoupled outside a depot?
Quote from: Ves on May 02, 2018, 10:59:53 PMYes, in its basic form, yes.
Quote from: jamespetts on May 03, 2018, 09:29:19 AMThank you both for your thoughts.What I was trying to establish is how the game should behave when vehicle A, which couples only to vehicle B, has "fixed_coupling_outside_depot_next=1", but vehicle B, which couples to vehicle A, does not have "fixed_coupling_outside_depot_prev=1". Have you any thoughts on that question?
Quote from: jamespetts on December 24, 2020, 11:36:22 AMMay I ask specifically why you think that triggers, broadcasters and receivers give unnecessary precision and complexity; unnecessary for precisely what? The explanation for the features is discussed in this thread (the current thread being deliberately confined to a detailed technical discussion of the implementation). As explained there, triggers are necessary to work with the layover function, which is in turn necessary to achieve balance of a realistic implementation of running costs per unit of time, which is an essential part of the ultimate goal of reality based cost and revenue balancing.
Quote from: freddyhayward on December 24, 2020, 11:46:56 AMQuoting from a more recent post, but I think it's more appropriately discussed here. I've read as much of this thread as I can in a short amount of time. I still can't find an answer to the following questions:1. Why is the layover feature necessary for balance? (this is the clearest of them all)2. What parts of layovers are most important for balance and most appropriately developed and simulated in game?3. Why are triggers necessary to simulate those parts?
Quote from: jamespetts on December 24, 2020, 11:57:45 AMThe need for the layover feature was first discussed a long time ago - one of the earlier (but not necessarily the first) discussion of it was in this thread (see the first post in particular). You will see how the ideas have evolved over time to their present form.
Quote from: freddyhayward on December 24, 2020, 12:13:19 PMThank you. It is still unclear to my why layovers in that form are necessary. I note that there were many suggestions to use a simpler form of layover, in which staff costs are decreased or suspended after a set time threshold. Again, I cannot see how a layover flag or triggers are necessary for layovers. I could see how triggers could potentially be necessary for convoy recombination, but I don't see why layovers ought to be tied to recombination.