Topic: Balance discussion: cost (maintenance, convoy re-combination and others)

[jamespetts]

For that sort of arrangement you would need to cascade as described; but is this common? When I was designing the convoy re-combination system, I had in mind four paradigm cases that the system had to be able to deal with:

(1) a locomotive hauled train changing locomotives;
(2) a pair of multiple units dividing/combining en route (dividing in one direction and re-combining in the other);
(3) a pick-up goods train; and
(4) a locomotive hauled train dropping off carriages at a stop and those carriages then being taken on to a different destination by a different locomotive (and then re-combining again on the return journey).

I sought to design the simplest system possible that would successfully do all of those things. The case that you describe (multiple splitting at once) is not one of the paradigm cases that I had in mind because I am not aware of any significant real life examples of this. It is likely still to be possible, but, as an edge case, the interface is not likely to be optimised to make this particular case achievable in as few steps as possible, as this would in turn de-optimise the implementation for the paradigm cases.

[Ves]

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

[jamespetts]

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

The idea is not to simulate shunting directly (i.e., require the player to set up the trackwork and orders to attach and detach specific vehicles in a specific order and be able to keep track fully of the fantastically complex logistics of doing so), but to simulate the result of shunting at a more abstract level: trains join together at a station and automatically (allowing for a lapse of time) re-arrange themselves into the correct order. Thus, there is no need to simulate shunting yards, as such: there might be sidings to be simulated, but in those cases, there would be no need to keep the loads on vehicles in those cases.

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

[ACarlotti]

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

If I recall correctly (although it was some ago that I checked the data), timetabled 3-way splits/joins currently occur on the UK rail network in just two contexts:
1. The Highland Sleeper has a 3-way split/merge at Edinburgh, with smaller locomotives and additional seated carriages to the north replacing a single large electric locomotive to the south. (http://www.realtimetrains.co.uk/search/advanced/EDB/2018/02/13/1200-1159?stp=WVS&show=all&order=wtt&toc=CS and http://www.scot-rail.co.uk/page/Caledonian+Sleepers have details, although the former doesn't detail all the shunting movements. Note that platforms 1 and 2 are the opposite ends of 20 and 19, with a crossover in the middle, and the electric locomotive stays at Edinburgh during the day.)
2. Empty coaching stock movments at the beginning of the day sometimes involve multiple DMUs or EMUs running into a station, before becoming up to 4 different services. (And the reverse at night.)

Returning to Simutans, I think the best way to try implementing something like 1. in Simutrans is to allow mulitple consecutive stops at the same location. It's then just a case of working through each separate split/join event sequentially, rather than being a big mess of 4 incoming convoys all recombining to 4 outgoing convoys simultaneously. (2. is not relevant to Simutrans since we don't simulate day/night or peak/off-peak.)

Changing the way consecutive stops at the same location are handled would be useful anyway. At the moment attempting to change a schedule of the form a>A>B>C>c>C>B>A to the form a>A>B>C>D>d>D>C>B>A by deleting c first also deletes one of the Cs, which is particularly annoying if that C had settings that you wanted to retain. (In this case a,c,and d are waypoints to allow simulating a bus stand.)


I've been thinking about how you could set up running freight trains that pick up and drop wagons enroute, and have two ideas here:
Idea 1:
Allow attaching tags to vehicles, which can be set and read in consist orders. So you when you pick up vehicles from an industry and ship them to the mainline, you can set a tag to indicate where they should go, which can be read by subsequent consist orders to ensure the correct routing later on. In its most basic form, such tagging would be invisible to the path explorer, but would be used to ensure that the correct amount of vehicles go to each downstream destination, and perhaps also to minimise the amount of cross-loading of goods when coupling/uncoupling (which might be able to reduce the loading time at that location). However, this idea struggles with multiple flows originating a the same station, and I'm not sure how you'd fix that.

Idea 2:
Add the option to specify that particular vehicles should only load goods for one destination (which maybe could be a building/industry, a destination station, or transfer station), and then allow a consist order to specify which wagons to include according to which of the two schedules is next on the intended journey of the first item of freight in the vehicle.

In both cases, there could be a difference in the coupling time depending on whether any goods need to be moved to another vehicle (or the platform if there is insufficient capacity, or everything can just be left where it is.

[jamespetts]

Thank you for your thoughts on this: that is much appreciated.

I agree regarding the multiple consecutive stops: I will have to modify the code to allow for this without deleting (I think that this should be fairly straightforward, as I think that there is code somewhere that specifically exists to perform this deletion).

As to the vehicle tagging: how had you thought of setting these in consist orders? Since consist orders are to consist of the state of the consist after any re-combination operations, this would not easily allow for tagging of vehicles already in a convoy (especially in respect of those vehicles that form part of a convoy when initially assembled in the depot). Had you imagined that the vehicles would be tagged by portion of the train, or separately for each individual destination that might be served?

[ACarlotti]

What I had been imagining with tags is a way of being able to define a consist by both the vehicles in it and by what tags those vehicles should already have. The idea occurred to me while I was thinking about the possibility of getting specific vehicles to go to specific places by choosing different types of vehicles to go on different routes.
As an analogy, you could consider it as allowing vehicles to be painted different colours, and rather than a consist order saying for a particular vehicle "I want a bulk goods hopper", it could say "I want a blue bulk goods hopper", or event "I want a blue bulk goods hopper, which I'm then going to repaint in pink in the new convoy".

The idea of tags would be that you could, in a somewhat clumsy fashion, say that "these vehicles ought to be carrying goods to go onto these routes when the convoy divides". A more intelligent, but I think still feasible approach, is to actually allow the consist to be determined based upon where the goods in each vehicle want to go to. This would require either a per-convoy or per-vehicle setting to say "only load stuff for the same destination within each vehicle".

So in terms of code (loosely), I think this (by which I mean the non-tags idea) would require:
1. A change to the vehicle loading code to enable restricting goods to have matching transfer points if the vehicle. Whether to apply this restriction could be determined by a boolean stored in the vehicle (or possibly in the convoy). (This could be implemented separately before any of the following, and could also be useful in combination with conditional skips.)
2. The ability to specify in a consist order that certain extra types vehicles will be taken if the first good they are carrying has a next transfer point that is best reached via the associated schedule.
3. An addition to the decoupling code to be able to determine which portion of the convoy provides the best (or at leat some) route to a particular transfer point.
4. (Optionally) The ability to automatically set a vehicles boolean flag for loading only to a single destination. The most sensible place to do this would appear to be in a consist order.

[jamespetts]

This is certainly an interesting idea - but, to take your colour metaphor - how would players say "I want this open wagon to be blue" when "this open wagon" is part of the convoy as as originally assembled at a depot? Would you imagine a second interface for this beyond the consist orders?

[ACarlotti]

There could be a second interface, although that probably isn't strictly needed (at least if otherwise redundant consist orders are allowed).

[jamespetts]

There could be a second interface, although that probably isn't strictly needed (at least if otherwise redundant consist orders are allowed).

Thank you for the clarification, and apologies for not having reverted earlier on this, as I wanted to think about this carefully.

I can see that there might be some benefit to this idea. Had you imagined this as a bitfield of flags that could be set to change in consist orders or set initially in the depot/convoy details window? This is how I am currently imagining that such a feature might work: there would be the aforementioned 16-bit bitfield per vehicle. By default, these bitfields would be set to 0. The consist orders would also have an additional 16-bit variable for each vehicle consisting of that vehicle's bitfield. This would also be zero by default. If all bits set in the consist order's vehicle slot are also set in the vehicle's bitfield, then the vehicle would be considered suitable to be used, otherwise it would not.

I am not quite sure how to represent this in the UI to the player (16 checkboxes seems as though it would be very awkward design) - Ves, have you any thoughts about this? Does anyone have any thoughts on how this suggested implementation would affect usability for the player?

[Ves]

I’m trying to wrap my head around the new additions by ACarlotti:
Is the idea to add some kind of filters for the player to set when they create the consist order?
Would it for instance work like if you have a huge network, and then a region further away, you could mark each vehicle with, say color blue, and do that for all vehicles going to this region, and then the lines actually traveling to the region would in their consist order have just something like “all blue cars” without the need to go too much into detail?

In other word, a “vehicle grouping”?

Would a vehicle be able to hold more than one “color”?

[jamespetts]

From what I understand, ACarlotti's suggestion is for the tags to be an additional restriction on which vehicles may be coupled to a convoy as a result of a consist order. It would not be possible for the tags alone to define this, as, for the reasons given above, it is necessary for the type of goods carried to be deterministically set for each vehicle in each set of consist orders.

[jamespetts]

I should note that I have begun to implement the data structures for consist orders, and I should be grateful for feedback before proceeding further on that specific part of the code.

This is discussed more fully in the technical discussion thread.

[Ves]

I have begun the work on doing the vehicle management window, as that seemed more straight forward, both conceptually and technically, than the consist order window. Hopefully I will also learn some new GUI techniques that I can use in the consist order window later. The "vehicle manager" window does now exist on a local branch and it currently only do two things: lists the vehicles you own, and lists all vehicles available to you (I know, i promised to code that YEARS ago  https://forum.simutrans.com/index.php/topic,13654.msg135690.html#msg135690. Well here it is.... ) in two separate lists, and all sorted with tabs by waytype, like in the "schedule manager".
The plan with the window is to make it easier for the player to "manage" the vehicles, to get an overview of what vehicles the player owns and perform actions across multiple vehicles by tabs benieth the lists, featuring stuff like "information", "payload", "maintenance/upgrade" or whatever names for the tabs is suitable. Also, I would like to be able to sort, especially the left hand list, by different parameters etc.
Im still in the proces of making the two lists "speak" with the window (it is apperently not as straight forward as one might think) so when a vehicle is selected, the window knows what vehicle is in fact selected, and wether it should unselect the previously selected vehicle etc.

I have some questions:
1 - 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?
2 - I am puzzled as to what to do with multiple unit vehicles, that is vehicles that will never decouple outside a depot. Preferably I would list them together as a entry in the left list, however, I dont know currently a solid way to distinguish between a multiple unit vehicle that never decouples, and a vehicle with constraints, but which do decouple. I imagine that you anyway need to adress this, so the player cannot unrealistically couple and decouple vehicles that ought not to be, for instance via some datfile parameters? something like:
fixed_coupling_outside_depot_next=1
fixed_coupling_outside_depot_prev=1
3 - Are there any specific features that you (as in both James and anyone else) would like to see in this window (if possible), or any suggestions to improvements I could do in the window?
4 (new) - Will there be any way to identify specific vehicles, like a unique number or desc-name combined with a number or similar?

Lastly some screenshoots of the work in progress window: Note that the entries on the left list autoresize according to the picture, so they dont overlap, which Im quite proud to have achieved. I consider removing the pictures on the right hand side, to allow for some text instead, and because the picture will be visible on the left hand side (and also elsewhere I plan to) anyway. Also, you are supposed to click on a vehicle in the left hand list, to make it show up in the right and list, but currently it shows all vehicles you own for that waytype (remember the "speaking to window" issue I wroter earlier?).




On a side note: Scrolling through the lists really makes one appreciate the fantastic quality on all of the vehicles in Pak.Britain, and in such quantities! 1659 rail vehicles, to name a few 
Well done Pak.Britain(-ex) creators and maintainers! 

edit:
Added question nr 4

[DrSuperGood]

A thought occurred to me the other day. When this feature is added one should probably give some vehicles an absolute maximum end of life date, after which the vehicles are automatically sold or confined to depot forever. This is to represent that some vehicles are no longer legally allowed to be operated for safety or other reasons.

For example the boy riding a pony delivering mail eventually has to stop due to child labour laws preventing one from exploiting child labour in later years. Another example is in the distant future, eg 2040, all fossil fuel powered vehicles can no longer operate due to strict emission laws. A final example would be that all steam trains have to be pulled from lines and replaced with either electric or diesel by a certain date, as happened with British Railways.

[ACarlotti]

1 - 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?

I'd say the most important consideration when writing code for the gui (apart from correctness) is that it be as readable as possible. Players will only have a small number of gui windows open at one time, so it seems unlikely that generating gui elements such as this will take up a significant proportion of the overall processor time. Of course, if it does turn out that the current implementation significantly slows the game (though only for the player using that gui), then it would be time to look at optimising for speed or memory at the expense of a little readability.

It would probably be sensible to place a method to list all vehicles used by a player in a sensible place (player_t seems appropriate), where it will be easier to reuse the functionality elsewhere or modify the algorithm used.

4 (new) - Will there be any way to identify specific vehicles, like a unique number or desc-name combined with a number or similar?

Are you looking for something similar to the internal ids used for convoys?

[Ves]

DrSupergood, that looks interesting,  but I highly doubt James will do that, since he probably will want it to not be economical feasible instead, forcing the player to change the old vehicles.

However a variant of your suggestion: the player could determine that at a specific year/month in the future that (s)he wants a replacement, or retirement, of a particular vehicle should start.
James?


ACarlotti, thanks!
You probably have a point that no more windows usually would be open if this window is open, I just was wishing for a more “obvious” solution than how I have done it. Also currently, I realize, I have missed the vehicles you own, but which has not become part of any convoys, but only lives as single vehicles in the depot vehicle selector. Putting it at vehicle_t is probably a good thing, it is, however, nothing I dare do.

Yes, I had envisioned In my head that the individual vehicles would get some kind of ID number to help tell them apart.
If the ID starts at 0 (or some other player set value) for each vehicle type, it would perhaps be easier to memorize the vehicles, as it would come somewhat close to how the real life litera numbers where composed.

[jamespetts]

Ves - thank you very much for your work on this: it is most appreciated.

My apologies that I have not had more time to work on the vehicle management features of late: my Simutrans time has been taken by a large number of bug reports from the online game relating to time interval signalling. In short, the reason that there have been so many issues is that there were a few specific use cases that had not been tested that unexpectedly did not work with the current code and required significant additional logic to make work, but, because of the enormous complexity of the signalling system, that extra logic now requires extensive and intensive debugging. When most of the bug reports use the server game as a reproduction case, the size of that game makes running it in the debugger so slow that it takes 5-20 times longer to diagnose each bug than would be the case with a reproduction case in a smaller map. I have also recently taken up railway modelling, which is taking some of the time that I might otherwise spend on Simutrans-Extended.

Turning to your questions, I will answer them in sequence.

1. There is no better way of doing this so far as I can make out. Indeed, this is the way in which things are done in convoi_frame.cc (although the convoys owned by a particular player are cached there so that the world's list of convoys only needs to be read once for every time that the window is opened). As A. Carlotti states, however, this aspect of things is not performance critical.

2. I do not think that this distinction is entirely practical, as there is no fixed concept of such convoys in the game. In reality, multiple units on railways were sometimes uncoupled and coupled outside depots in ways that are not now considered normal. There were some trains that were semi-permanently coupled together with bar couplers or the like (and still are: think of modern multi-vehicle trams, for instance), but there are no data for distinguishing these from vehicles that have normal couplings but are rarely uncoupled from anything else. One distinction that you might consider is a vehicle that has exactly one constraint requiring coupling to another vehicle which also has exactly one constraint requiring coupling to the first vehicle: such pairs of vehicles would thus only ever be coupled to each other. However, this will produce many false negatives: even many steam locomotives share tenders with other locomotives, for example. Adding extra data just for UI handling in this way would be a huge task for Pak128.Britain-Ex given the number of rail vehicles. If anyone can think of anything ingenious for this, however, this might well be worth considering.

3. It would be very useful to have cost statistics (including for cost based features planned but not yet added, as discussed in this thread) and some way of comparing different vehicles in different ways. One might have, perhaps, a system for predicting future upkeep cost if present trends continue (taking into account future wear, etc.), although I appreciate  that this will be difficult to code for without the code for the underlying feature being written, so it may be better simply to prepare for this feature being added in the future.

4. Vehicles do not have the same handle system that convoys and stops have. Thus, whilst it would be easy to add a system for stops that works in the same way as it does for convoys because the basic code for this is already present, just missing in the UI (presumably, because it was not thought useful), there is no code anywhere dealing with automatic numbering of vehicles, and adding this would be quite an undertaking. Internally, they are distinguished simply by pointer addresses, which are non-stable in that they vary between load/save cycles and between different computers in a network game (although remain consistent outside a load/save cycle on any given computer). In reality, vehicles did have numbers: road vehicles and aircraft have registration numbers and rail vehicles have rail company internal numbers. In theory, it would be possible to provide for automatic numbering on creation based on a numbering scheme predefined in the .dat files (which would have to allow for letters as well as numbers to permit, e.g., registration numbers); but this would get very complex and require a huge amount of work. Much easier would be to identify vehicles of the same type by date of purchase and convoy membership. Vehicles that are identical in both of those respects may not need much distinguishing.

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

[Ves]

Thanks for your response, and no worries, Simutrans doesnt run anywhere Best luck in your model railroading, I used to do that but have no space for it currently 

1) Ok, I will keep this for the moment then!

2) I was thinking about if there where some clever way to find it by looking at the constriants, but as you write there will be false positives and negatives everywhere. I was also thinking if there where any way to identify a "tender", so they could be displayed in a clever way.
I do think that this is something that really is worth considering. You have many vehicles, which in real life would be considered one vehicle, but the technical limitations in Simutrans makes it into two vehicles. For instance you have multiled busses, or trains running on "jacobs"-type boogies (two cars share one boogie), and also the additional cargo- and passenger holds for many of the vehicles in pak.britain. I dont think you want the player to be able to rearrange that on the fly?
On the question to where to draw the line, I would think that it is the pakset maintainer that decides what is considered "easy" separations to do at a platform and what is not. You could combine it with a "separation_time", where the pakset creator can estimate how long time it takes to separate a vehicle from the next and previous.
The subject of constraint groups has been brought up many times before, and that could be a quite elegant solution.
However, getting around without having to edit all those vehicle datfiles I also struggle to figure out...

3) Indeed! A tab with charts could be very usefull! I would like to be able to do predict future costs and dates, that is a good idea!

4) Ok, I do get the point that one could question the need for a separate vehiclename, as it would mostly only be for the GUI anyway. I will then not plan for it in the lists.

[jamespetts]

In relation to no. 2: one of the issues is that there are not really hard boundaries. Vehicles (in the Simutrans sense) that would be treated as separate vehicles for accounting purposes, for instance, might not be uncoupleable at stations (consider as in the example of a train made up of quite separate carriages coupled with bar couplings). However, a vehicle such as an articulated 'bus would be treated for all purposes as a single vehicle in reality, whereas in Simutrans, it is treated as two vehicles. Thus, there is no universal way of defining multiple vehicles as an inseparable unit that makes sense for all purposes.

Had you imagined a need for a way of distinguishing which vehicles can and cannot be uncoupled out of depots for the purposes of the convoy re-combination? This might possibly be necessary, but this would not be quite the same thing as you had in mind.

[DrSuperGood]

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

One cannot really bring in "enthusiasts' special trains" into the argument as they are a special case where the attraction is the vehicle/train itself rather than where it is going. People come from all over the world to have a ride on the GWR 4900 Class 5972 Olton Hall aka "Hogwarts Express" due to its  appearance in the Harry Potter film series.

These are unique pieces, something currently not simulated in Simutrans Extended and unlikely to be so for a long time for complexity. Further more many of them have had extensive modification to comply with modern safety requirements. Often the combined cost of restoration and modification far exceeds the cost of a brand new and better equivalent. As such technically there is a hard cut off date because beyond that the cost of keeping a fleet of them serviceable exceeds the cost of buying a fleet of replacements and hence they might as well be automatically replaced.

When British Rail anti-steam policy was in full effect they did not allow any steam engines on most of the main lines. This was a huge problem for some of the enthusiasts who brought up their favourite trains from being scrapped as they could not run them in the UK as there were no suitable track stretches to run them properly. This is why many trains ended up being sent to countries like the United States of America where they were still allowed on the tracks. This has obviously changed, with Network Rail permitting steam trains on tracks as long as they fit all their requirements which many can do.

Anyway another idea to tie in with wear and other mechanics for vehicles. Some vehicles should also be given a finite life expectancy before they cannot be used and must be replaced. This is because maintenance and overhauls are not sufficient to prolong the safe use of the vehicle. Generally the vehicle would be renewed with itself, but if not available one would have to renew it with a like equivalent.

This is realistic and would apply for the following.

• Horses: Horses have a finite life expectency. They eventually die of old age, and often start to under perform long before then. One cannot fix such a horse, and rather has to out right replace them. Horses are technically an asset of the company.
• Boats: Boat hulls have a finite life expectency. After this is exceeded the hull runs a risk of catostrophic failure so the ship is no longer safe to use. Although less common with todays hull designs, this was especially the case for Clipper type ships which had under a 30 year working life before hull fatigue became a problem. Since most of a boat is the hull it effectivly means ordering a new boat for a replacement. Old wood ships had near no scrappage value due to how common and degraded the wood was, but metal hulled ships retain a significant scrap metal value.
• Winged aircraft: The airframes have a finite life expectancy due to fatigue. Once the airframe is at end of life it is not safe to fly the aircraft anymore and a completly new airframe is needed. Airframes are so complex and precise that only aviation manufacturers can make replacements, which effectivly means buying a new plane. Planes are unique in that scraped aircraft retain comparitivly a lot of value since changeable components like engines might still have considerable working life remaining so can be resold at high value as spare parts.

[Ves]

Yes indeed I had imagined that it would not, for instance, be possible to swap the backend of an articulated bus with another! Imagine an articulated bus drives to a stop, decouples the backend, connect another and then continue. Altough it might look funny with lots of backends waiting around, it illustrates something that should not be possible. People would be reporting that as a bug.

Also in this multiple unit era, which for some part is heavily built around hard constrained consists, but whith easy coupling between consists. It would only add to the immersion and gameplay depth if the player has to take into account that (s)he cannot separate the units outside the depot.

No, you are right that there is no universal way to define what vehicles are considered inseparatable, that is why I believe it is best if the designer of the pakset steps in and define what vehicles can separate, and what not.

[jamespetts]

There is a fundamental difference between the lifetime of a specific vehicle and the lifetime of a type of vehicle. As discussed here and elsewhere, it is certainly intended to simulate the lifetime of particular vehicles by making the cost of an overhaul the cost of replacing the vehicle entirely (especially in the case of horses). In some cases, this may require a variable overhaul cost where subsequent overhauls cost more than earlier overhauls. However, the lifetime of particular vehicles (aside from biological vehicles, for which a special case will have to be made in the code because of the inherent nature of biological organisms being different from mechanical vehicles), the lifetime of vehicles will be based on usage, not time elapsed (and lifetime being based on time elapsed since purchase is in any event different from lifetime being determined at a specific date not related to the date of purchase).

Lifetime of types of vehicles is a different matter entirely, and is what I was addressing in the previous post. There are virtually no examples of an entire type of vehicle, even with suitable modifications, being prohibited entirely after a certain date. Even if a few such examples could be found, they would be so rare as not to justify the extra effort in coding this feature just for them.

In relation to steam locomotives, the point that I was making was simply that there was no prohibition on steam locomotives on the ground of safety: they were discontinued in service because they were found to be uneconomic as labour costs rose. That underlying incentive will be simulated. It is otiose (and unrealistic) to impose an additional artificial constraint founded, not in economics, but in the calendar date for the usability of any type of vehicle.


Ves - 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?

[Ves]

Ves - 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?

Yes, in its basic form, yes.

[jamespetts]

Yes, in its basic form, yes.

I can see that that may well have merit. One thing that should be considered, however, is what should happen when (1) one of the two vehicles has this datum specified and the other does not; and (2) both of these vehicles have this datum specified. Not being clear about this at the outset, I imagine, will lead to much confusion later.

Had you any thoughts about how this should work?

[Ves]

Well, it should, in its simplest form, be quite straight forward:

If we implement two new datfile parameters:
fixed_coupling_outside_depot_next=1
fixed_coupling_outside_depot_prev=1

... then, if a vehicle has this parameter, it can never decouple outside the depot, no matter what the other vehicle has. The existing constraint mechanics would work as usual and determine what vehicles can be around this vehicles.

Whatever calls are being made for a vehicle with this parameter, would in effect be a call for all vehicles which are currently bounded together.
So, to illustrate with an example:

Vehicle "A", "B" and "C" are being in layoff state at some station. Then comes convoy "X" and wants to connect vehicle "B". This would result in both  "A", "B" and "C" are connected, and in that specific order, if not reversed.
Where to put them in the new convoy to make sense is another question, but that is something we anyway will have to deal with in some way.

This would of corse only apply in cases where it would otherwise violate the rule never to separate them. For instance it should still be possible to change the classes of only one of the vehicles, and their info window would still be just like any other info window.

[Ranran]

I played Simutrans-Extended for a couple of days. I am having a lot of fun. I am looking forward to this feature.

BTW, "fixed_coupling_outside_depot_[hoge]" is not "constraint[hoge] do not have the parameter none or any"?

I mean, normally multiple unit's intermediate car does not have the constraint parameter "none".
It may have more than one constraint, but in such cases, they will recombine in the depot.

Only the driver's side of the lead car has "none".
There is no problem even if they separate them outside the depot.

[jamespetts]

Thank 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?

[Ves]

Thank 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?

In this case, I would think that the restriction should in fact be enforced, and it should be ignored that vehicle B doesn’t have the parameter.

The effect would be that once vehicle B gets attached to vehicle A, it can never detach again, if not done in the depot.

I would also think that if the “fixed_coupling_outside_depot_next=1” is specified, but no more vehicles are attached in the depot, this end would in effect become “un-attachable” outside the depot.

Reasoning:
The parameter should symbolize that “this vehicle wont work properly, due to realistic limitations, simutrans technical limitations, or pakset artistic, graphic or design decisions, if this end of the vehicle can be rearranged outside the depot.”

[jamespetts]

Thank you - that is very helpful. I will look into implementing this when I get a moment, although I should note that this may be a while, as bugs are still being reported at a rate faster than I can fix them.

[tubanonymous]

A few brief thoughts on the topic

1) Any sort of shunting feature would be awesome

2) I've read the thread, but having a hard time imagining what the end result looks like. Say I want to move 5 passenger carriages from one loco to another at a given station. Does the first train stop in the station, then drive to the nearest depot to reassemble; and then the second train also stops at the station before reassembling the 5 carriages inside the depot? Or do the trains pull into the station, and the carriages just pop up in the proper position after a given amount of time, like with reversing?

3) Would it be useful to create a locomotive type with the blender image of any given passenger or freight carriage, and set the power factor to 0? The cars that are shunted are in themselves their own convoy, and are assigned an order to attach to another train? The problem with this is that locomotives cannot come after carriages in simutrans. Something I always found odd...

4) Is their some aspect of the simutrans code that would require shunting to involve use of the depot?

[jamespetts]

To answer your questions: the exact mechanism of how this is to work has developed over time to an extent, which may be why you are having trouble visualising it. However, the current plan is for convoy re-combination to occur at stations rather than in depots. I am afraid that I do not really understand the third question. As to the fourth question, the current plan is for vehicles to have to visit depots periodically for maintenance and overhauls.

[freddyhayward]

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

Quoting 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?

[jamespetts]

Quoting 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?

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

[freddyhayward]

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

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

[jamespetts]

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

Were the reasons not to use those specific alternatives not discussed at the time? You will appreciate that it is difficult at some years after the implementation has been decided upon in great detail after years of extensive discussion and design work to recall why some alternative was not decided upon. Again, nothing short of a complete alternative design that fully fulfils all of the design goals of the original without causing any problems that the original does not cause and is sufficiently clearly better than the original to warrant any additional work in changing the design now is at this stage (i.e., after a very large amount of implementation work has already been done) capable of being a sufficient reason to change the design.