Fixed costs, low frequency services and shunting

[jamespetts]

Edit: Title change to reflect expanded discussion of shunting/orders.

No pakset, so far as I am aware, currently uses the vehicle fixed costs parameter. It has long been planned, and is still planned, to add this to Pak128.Britain-Ex as part of a general cost balancing exercise when that becomes practical. The fixed costs are an important addition to variable per kilometre costs, in that they represent the cost of labour associated with the running and some distance/use-intensity independent maintenance tasks (cleaning out a steam locomotive, for example, the frequency of which depends on time in steam rather than distance travelled).

However, two problems have recently occurred to me in relation to this: one rather niche, one of more general application. The niche problem is what to do about railway guards: I had initially thought to have a higher fixed cost in all full brake or rear brake vehicles to represent the presence of a guard, but then realised that players might want to have more than one full brake vehicle in a train, and yet  in continuously braked trains, there would not need to be (or actually be) more than one guard in a train. The full brake vehicle would be the same nonetheless. One could in theory have a different front and rear full brake using the same graphics and which can be "upgraded" to the other for free, but this seems to be rather a clunky solution. Any other ideas as to how to deal with this would be appreciated. (For passenger brakes, there is already a  front/rear distinction for most types, so this does not really matter so much).

The more significant issue is this: it might be necessary for goods or mail traffic in particular to run very low frequency trains. The famous Night Mail, for example, ran once in each direction every night. There would be many occasions on which a mail specific train (as opposed to a passenger train with some mail carriages in it) would run only once or twice a day in each direction, as mail traffic did not demand any different. The changes that I have recently made to mail generation and related matters make it far more likely that there will be incentive to replicate this sort of service pattern in Simutrans-Experimental.

The difficulty is this: a twice a day (as in, twice every 24 hours, or once every other game month at 22 bits per month and 125m/tile, which will be the settings of the next release of Pak128.Britain-Ex) train will spend most of its time doing nothing. This can be accommodated using sidings and scheduling, but players will still have to pay the full fixed cost: in other words, pay as if they are standing for four or five hours at a stretch with a fully paid driver, fireman (if applicable) and guard twiddling their thumbs and/or drinking tea. In reality, of course, the crew would only be rostered when they were needed. The locomotive (but not the carriages) would additionally probably be used for other activities during the day. The inability to simulate either of these things will cause significant economic distortions once fixed costs are introduced.

Two possible solutions present themselves. The first - the simpler - is to define some new concept of a layover, in which state fixed costs do not accumulate, or accumulate at a fixed fraction of their normal wait. Precisely how this might be done is not yet clear to me - perhaps any scheduled stop of over a particular duration could be considered a layover, with full fixed costs paid only up to that limit and not beyond.

The second, which would require some very significant programming work, and thus be unlikely to be done for a very long time, would be to permit dynamic reassembly of convoys, perhaps loosely following Cities in Motion 2's practice of having vehicles regularly visiting depots and only leaving them when some or other schedule demands that some vehicle leave the depot. The system would have to be more sophisticated than that in CIM2, however, and in particular, allow more control over which convoys are assigned to which lines. Another, possibly simpler, possibility would be to allow dynamic reassembly of convoys without depot visits, which would also allow dividing and combining of trains, locomotive changes and the like, which would have other uses. This way, a locomotive could run a mix of passenger and mail trains (although this would be less useful than in reality, as we do not have peaks and troughs of passenger demand throughout the day in Simutrans, so the demand for motive power for passenger trains would remain unchanged). The latter idea could be combined with the layover idea (which might be necessary for guard's vehicles - empty rakes of carriages do not need guards sitting in them waiting for them next to be used). However, the greatest problem with this is how to conceptualise where unused vehicles are being stored and where trains have to be to couple/uncouple vehicles from any given storage point. We can easily gloss over the actual shunting, but this more general problem remains. (Conceivably, I suppose, we could store them at a station, supposing some unseen siding - but should there be a limit to the number stored? How would the GUI for this work? How would this interact with vehicles in the depot? What if a player wanted to sell vehicles currently stored in a station, or send them to a depot, or assign them to a different convoy or in a different station?).

Any thoughts on the above issues and proposed answers (and issues in the proposed answers, and proposed answers to the issues arising out of the answers to the issues- etc.) would be most welcome.


Edit

Somefresh ideas have occurred to me as to how best to deal with the "shunting" aspect of things - that is, changing the assembly of convoys dynamically. The idea is based on orders in schedules. In addition to stops in a schedule, it ought to be possible to add orders. An order would be defined as an entry with a location of koord::invalid (this part will make sense to those who know the code). There would be three types of order: (1) lay-over; (2) add vehicles; and (3) detach vehicles.

Lay over

An order for lay over would place a convoy into a state of lay over immediately after its previous stop, without moving from the position that it occupied at that stop. A state of lay over would be a dormant state: the convoy would not move, load or unload, nor accumulate fixed costs. (In fact, fixed costs are deducted as a lump sum monthly, so what would have to happen is that a record of the proportion of any given month spent laid over or in the depot would have to be kept, and the fixed costs reduced accordingly at the end of the month).

Lay over would be a state that it would take time to enter and leave (which time ought to be set in simuconf.tab). There ought to be an option for a lay over to be timed or indefinite. In a timed lay over is one where the convoy would remain in its laid over state for a fixed time or until a scheduling interval, and then exit that state (perhaps beginning to exit the state sufficient time in advance taking account of the time taken to come out of lay over for it to start moving towards its next schedule item at the appointed time). It ought to be possible to assign the vehicle to a new line on exiting a lay over, and then specify which entry in that line's schedule that it should execute first.

It also ought to be possible to specify whether a convoy in a laid over state makes its vehicles available to other convoys, for the purpose of them adding vehicles, as outlined below.

Lay over ought only to be possible at stations (not waypoints). All passengers/mail/goods ought to have to disembark/be unloaded before the convoy enters lay over, and passengers/mail/goods ought not to be able to route past a lay over. Players would of course be able to schedule lay-overs in sidings which are part of stations.

Add vehicles

The add vehicles order ought to allow a convoy to add vehicles according to rules specified in the schedule entry to the convoy. The vehicles to be added must be in laid over convoys that allow their vehicles to be taken by other convoys at the same station as the convoy at the time when the add vehicles order is to be executed. The addition of vehicles would be simplified: there would be no actual shunting: the vehicles would simply be removed from the origin convoy and added to the destination convoy. There should be a particular time that adding vehicles ought to take, which ought to be able to be set in simuconf.tab. Multiple add vehicles order ought to be able to be stacked consecutively: when this is done, the time for adding vehicles ought to be counted only once.

Each add vehicles order ought to allow the player to specify whether the vehicle(s) are to be added to the front or the back, the minimum and maximum number of vehicles matching the rules to be added, and criteria for what sorts of vehicles can be added (for example: whether powered or unpowered, what traction types are permissible (steam, diesel, electric, etc.), a maximum axle load, a maximum weight, a minimum and maximum power, whether the vehicle needs to carry a particular type of load, the minimum and maximum capacity, a minimum comfort, a minimum and maximum catering level, whether the vehicle can be at the front or rear of a convoy, whether it has a rear driving cab, etc.). The schedule ought not to move beyond the add vehicles command if the minimum number of vehicles specified in the add vehicles order are not available at the station: the convoy ought to wait until such vehicles are available. Further, it ought automatically to prevent combinations of vehicles which are not permissible. If a number greater than the minimum number of vehicles for the order is available, then the greatest number of vehicles available ought to be added up to the maximum. The convoy ought not to wait for there to be enough vehicles for the maximum number specified.

The laid over convoy from which the vehicles are taken might be rendered in an undriveable state (for example, by the removal of a locomotive). This will not be a problem provided that the remaining vehicles are used for something else (in which case, the empty convoy will be deleted), or vehicles are added to the convoy by an add vehicle order immediately after a timed lay over order.

Detach vehicles

The detach vehicles command ought to allow a convoy to detach some of its vehicles and leave them at the station. As with the add vehicles command, this ought to take a certain amount of time and only be possible at stations. The detached vehicles ought remain where they were left by the convoy. It ought to be possible to specify which vehicles are detached by specifying a certain number from the front or the back of the convoy. If vehicles are detached from the front, then those vehicles ought to have to be moved (or move on their own accord, as discussed below) before the convoy left at the rear is able to move - the convoy ought to check whether all tiles to the next signal are clear of vehicles before moving if the last order is a detach vehicles order or the convoy is a newly formed one from detached vehicles (see below).

Detached vehicles ought to form a new convoy generated at the time of detachment. There ought to be two options as to what to do with this convoy: either have it immediately laid over indefinitely (the suitable option for loose vehicles), or have it assigned to a line straight away, and, in the latter case, to determine which schedule entry in the line from which it is to start. The latter will only be possible if the remaining vehicles can form a driveable convoy as in a detached multiple unit section, or the first entry in the line is an add vehicles command such that it will get into a driveable state by the use of that command. If the convoy is assigned to a line but is not driveable, an error message ought to be given.

General

This system ought to allow for considerable flexibility of operations (mainly with rail based vehicles), such as dividing and combining trains, changing locomotives, a pick-up goods service, banking, or even, if used in a sophisticated way, a completely dynamic allocation of stock to a whole set of lines. It would take some time to program, but could conceivably be implemented alongside long planned changes to the replacer so as to prevent the need for convoys to go to a depot to need to be replaced: the current plan is to allow convoys to be replaced at any time, but it might well be worthwhile allowing such replacement only at a lay over. Indeed, further thought about the interaction between this system and replacements generally might need to be considered - is the current concept of replacement necessary at all if we have this system of dynamic changes of vehicles in convoys?

Any thoughts on this proposed system and its interaction with other aspects of the game would be very much appreciated.

[rsdworker]

sounds good - its very ideal for my map

[jamespetts]

Interesting - how would it help your map?

[ӔO]

Average speed of freight trains was pretty slow when they required multiple break ups and assemblies. Block trains were created to avoid this slow down, at the cost of flexibility. The proposed changes look like they would simulate this adequately.

I don't recall where, but I think the average speed for freight was around 10km/h

Would this proposed system allow long trains to be assembled and disassembled at stations shorter than the train with an additional time penalty?

[Junna]

I don't recall where, but I think the average speed for freight was around 10km/h

Depends on the era... but by the 1900's they weren't quite that slow. The limited braking provided would limit them to 40 km/h or so at maximum, but over-speeding was quite common still. I'm guessing the 56km/h limit of most early stock is to reflect this low speed- the problem is of course them holding up all passenger trains due to the  game's scale.

[Carl]

I think many of these features sound desirable for all sorts of reasons. But I'm a little unsure about the premise. Do lots of players typically run services whose frequency is as low as once every 24 in-game hours? For passengers, at least, I do not think this is feasible at even the lowest passenger_factors. I can't speak for freight, since I don't typically use that.

[ӔO]

Depends on the era... but by the 1900's they weren't quite that slow. The limited braking provided would limit them to 40 km/h or so at maximum, but over-speeding was quite common still. I'm guessing the 56km/h limit of most early stock is to reflect this low speed- the problem is of course them holding up all passenger trains due to the  game's scale.

I meant average speed for freight, from start to destination. Due to the way freight was handled, with mutiple stops for assemble/disassemble, it resulted in a very slow average speed. This is why many freight trains were switched over to block trains, with trucks doing the collection and distribution work.

[jamespetts]

This discussion raises a number of complexities. First, some complexities arising from the original suggestions that have since struck me. Firstly, there is the issue of what happens if different players' vehicles are available and laid over at a station when a convoy executes a join command - ought a convoy be allowed to be made up of different players' vehicles? If so, who should pay the running costs while they are running as a convoy? What should happen if that convoy is put into a depot?

I think that the correct answers to those questions are these: firstly, it ought to be possible to pick up another player's vehicles, but only if that other player has specifically allowed her/his vehicles to join a convoy of a different player: this will need to be an explicit option in the layover settings. Secondly, there ought to be no objection in principle to a convoy running with multiple players' vehicles: this was and is a frequent occurrence on the railways, particularly in inter-regional workings: I am put in mind of a lovely colour photograph circa 1939 of a train made up of a mixture of Southern Railway and Great Western Railway carriages hauled by a Southern locomotive at Oxford station on the Great Western, which was running an inter-regional train. In those circumstances, the running costs ought to be borne entirely by the player who owns the convoy as a whole (in other words, the player who set the schedule, whose convoy executed the join vehicles command, rather than the player whose laid over vehicles were picked up by the convoy - this ought to apply even if the laid over vehicles picked up were locomotives).

Secondly, if another player's vehicle enters a depot, there should be no change from normal behaviour until the convoy is disassembled, whereupon the detached vehicle belonging to another player ought to be registered as belonging to the first player's store (I plan to change the way in which depots work such that all vehicles that are in a depot are accessible from all depots belonging to the same player, centralising the concept of a depot, and making using existing stored vehicles with the replacer much easier). This implies that these changes will need to wait until the long planned changes to the replacer and vehicle economics are coded.

The second and more difficult issue is what happens about routing and loading. The simple solution, which does not interfere with existing routing, is as implied in the original post, which is to offload all passengers/mail/cargo whenever a vehicle goes into layover. However, this causes problems. Imagine two particular scenarios, both based on real railway practice: (1) two passenger trains arrive at a station, join, and leave as a single train; and (2) goods are loaded onto empty wagons at a station, which are then picked up by a passing train. In the first case, all the passengers on the passive train, the one that has to go into lay-over to allow its vehicles to be joined to the first, would have to leave the train and re-join it again: this would entail the train waiting for all these passengers to load, which would potentially lose the time advantage of coupling the two. More seriously, it would artificially lower the waiting time for passengers at that station because a high proportion of passengers who were boarding the new combined train had only just got off the previous train, and would therefore have a near zero waiting time.

In the goods example, as goods take a lot longer to load than passengers, in reality it made sense in years gone by to load wagons before being picked up by a passing freight train. However, this could not be done in the system that I originally outlined, as the goods would have no way of knowing that the wagons would in due course be picked up by a train that is the best option for getting them to their destination. The train would pick up empty wagons, which would then load: the wagons might as well have been on the train to start with. The same applies for unloading in the other direction.

I am not sure that I have thought of a satisfactory solution to the second problem yet, but one thing that I wonder is whether the best solution might be somehow to work out which goods/passengers would have been pre-loaded, and discount the loading time accordingly, although I am not quite sure of how this might work. Any thoughts as to how to deal with this are welcome.

As to the issues raised by other posters in this thread, it was precisely because I have been making changes that will make low frequency services (mail in particular; furhter changes to passenger generation which might have a similar effect for passengers on longer journeys are to come) more likely to be desirable in the future then they are in 10.27 and Pak128.Britian-Ex 0.8.4. I want to create the incentives for players to have realistic service frequencies, which will include very low frequencies in some case, which is why I have to consider the economic consequences of these low frequencies and how to accommodate those consequences.

As to allowing trains to be assembled at shorter stations with a time penalty, this is an interesting idea. Was there any real life practice that you had in mind, AEO, in this connexion?

[ӔO]

In NA, it's common practice to assemble/disassemble freight trains that are longer than railyards.

In the UK, at least according to train simulator 2013, it was not all that uncommon to have very small railyards with very short sidings.
In one scenario, it was quite a hassle assembling a freight train that had about 20 cars with an LMS black 5.

[jamespetts]

Hmm, I that is probably worth inclusion, in that case. Any thoughts on the trickier issues outlined above?

[neroden]

"There would be many occasions on which a mail specific train (as opposed to a passenger train with some mail carriages in it) would run only once or twice a day in each direction, as mail traffic did not demand any different. The changes that I have recently made to mail generation and related matters make it far more likely that there will be incentive to replicate this sort of service pattern in Simutrans-Experimental."

FWIW, I've tried this in the stagecoach era with the current version of experimental... and it doesn't work.  The problem is one of two things, I'm not sure which.
(1) mail generation may simply be way too low.
(2) the time tolerance for the mail may not allow for it to wait to be picked up overnight.

[neroden]

I think many of these features sound desirable for all sorts of reasons. But I'm a little unsure about the premise. Do lots of players typically run services whose frequency is as low as once every 24 in-game hours? For passengers, at least, I do not think this is feasible at even the lowest passenger_factors. I can't speak for freight, since I don't typically use that.

It's not viable for passengers and mail.  It's viable for freight.  Probably time tolerances.

I've found that I have to have a ship running at least once a game-month to get any passengers on it.  This is for very long ship runs, sometimes 6 months at a go.  Even that isn't reliable: twice a game-month is necessary to get reliable patronage.

This gets back to the issue that time and distance handling is a mess.  I may try to clean that up more...

[Junna]

(1) mail generation may simply be way too low.

I believe this is the reason. My dedicated mail company went from 5-6 million a year (which indeed was excessive) to 50,000, which rose to 70,000 but stayed there.

[jamespetts]

Passengers have a journey time tolerance: mail and freight does not. Low frequency services ought to be serviceable for mail and freight in a way that they are not for passengers (allowing supplies to build up slowly at the origin or a transfer stop for a long time before emptying them all into an occasional large convoy). Passengers, of course, need a more frequent service, as they are time sensitive in a way that other things are not.

As to the ratio of mail to passengers in the latest RC, this is based on really quite precise real life figures: see here for a full discussion.

As to time and distance handling being a mess - do you mean that the behaviour is wrong, or that the code is not cleanly written? If the former, can you let me know what the wrong behaviour is?

[ӔO]

some ideas

Layover
Automatic idle off/layover convoys that have long waiting times.
If a convoy has a very long waiting time for its departure, say longer than 20mins, it will turn itself off. It should wake up itself before departing. I don't know how many minutes it normally takes to warm up certain vehicles, but this should either be done automatically by looking at vehicle and power type or through the dat file.
If vehicles are turned off and unloaded, there should be a waiting time penalty added to the unloaded goods.
Laid over vehicles should sit where they were and occupy space, but if the station has a layover waiting area, it can be shunted there to keep platforms free.


join/disassemble
Vehicles ought to be awake or on to be added together.
Is there anything wrong with the idea of "packaging" convoys in another thread? I think it was in a standard extension thread.
Each convoy has its own schedule, however they do not have to have their own power and can be picked up by free locomotives that serve their own line. So instead of joining/splitting individual wagons, these wagons are already assembled into fixed packages.
For experimental, specifying the lines to be picked up or dropped off could be added.
Usually, train wagons are in fixed formations (groups) and are never disassembled individually. They, typically, will remain with their group of wagons until they are no longer needed for the job and are reassigned.

[jamespetts]

Interesting thoughts - can you find me the link to the "packaging" thread?

One additional matter for consideration in matters relating to this topic is the concept of availability: the proportion of time that a given vehicle is able to spend earning money as opposed to being in the depot. Quite apart from the direct cost of maintaining the vehicle (the cost of labour and spare parts of what is actually done with it in the depot), there is the opportunity cost of the time that it is spending in the depot and not earning revenue. When diesel locomotives replaced steam locomotives on the East Coast Mainline, half the number of diesel locomotives were required than steam because of the higher availability of diesel locomotives. Implementing this in a user friendly way, however, is not easy. One might perhaps look to what they do in Cities in Motion 2, requiring vehicles to visit a depot periodically, but we have to think of what should happen if a vehicle fails to visit a depot regularly enough, and how to deal with a situation where a convoy such as a train contains vehicles with widely disparate maintenance requirements. Also difficult is how to link this system to the layover/shunting/dividing/joining things discussed above (which, as ever, is more complicated for rail type vehicles) - if locomotives need more regular maintenance than carriages, players will want to be able to remove a locomotive from a train, send it to a depot, and have another locomotive that is just out of the depot attach to the train to take it on its next working: but how to code to allow this to happen easily is another matter entirely.

[ӔO]

http://forum.simutrans.com/index.php?topic=10802.25

my idea is on #43

I'm not too sure about the 'zones' idea, although it would be good for freight branch services.

[jamespetts]

That's an interesting set of ideas, although I am not sure that I quite understand how these "zones" would actually work. We need to work out quite basic things such as how to deal with block reservations on dividing/combining (to ensure that when a train divides, it does not clear the block reservation of the remaining part, allowing something else to crash into it; and also to ensure that when a train joins, the joining part is able to enter a section reserved by another train), how the UI for this would work (this is a vast subject by itself), how vehicles waiting for something to happen are handled by the game and (perhaps most importantly) how to avoid deadlocks (carriages waiting for a locomotive which never turns up, perhaps because the carriages are blocking the line causing other trains to become stuck on the route that the locomotive needs to use to get to the carriages, etc.). Any higher level concept, such as "zones" needs to be thought of in terms of interfacing with all these lower level details of the game.

[Jando]

... But I'm a little unsure about the premise. Do lots of players typically run services whose frequency is as low as once every 24 in-game hours? For passengers, at least, I do not think this is feasible at even the lowest passenger_factors. I can't speak for freight, since I don't typically use that.

Hehe, sometimes I get the feeling that I'm the only one running freight routes in 1800.

Low frequency? I have routes that carry meaningful amounts of cargo for a few months and then do nothing for multiple years. Many industries (worst offender: bakeries) order crazy amounts of supplies, i.e. a route is heavily overcrowded for a few months and then does nothing for the next few years. Of course during these years nothing has to be transported thus the ships and carts just do nothing and wait at their respective stations.

In my current map I have a bakery that has ordered enough flour to last the bakery for the next 5 years.

[jamespetts]

Jando - the issue with bakeries "ordering", as you put it, large amounts of flour is probably a badly calibrated input storage setting (the bakeries can seemingly keep flour for a very long time). Can you make a list of the industries that store too much input cargo so that I can look into recalibrating them? I should be very grateful.

[Jando]

Hello James!

I'm not really sure what an input storage setting is. But here's a screenshot of the bakery I mentioned in my earlier post: http://i.imgur.com/eWPdHxt.jpg. You see that the monthly demand of the bakery is 16 crates of flour. 968 crates of flour have been in transit (roughly the demand for 5 years), what I tend to call what the bakery "ordered" from the grain mill. Of those 968 the first 300 crates have been delivered.

Under consumption it says: flour 283/707/16 crates. I always wondered what the 3rd number tells me, it seems to have no effect, is that the input storage?

Here's a screenshot of another, less dramatic, example of a hardware shop that shows the effect: http://i.imgur.com/MEzBbG3.jpg. The shop had "ordered" large amounts about a year ago, those got delivered, the storage graph goes up. For the next 8 months the shop has no demand for goods cause he has built up storage. 2 months ago now the shop has ordered another 216 crates that prolly will last him for the next year.

In the context of this thread here, i.e. low frequency service, I don't really mind that the industries behave as they do - however it should be clear that there are a lot of very low frequency services in these maps.

[jamespetts]

The input storage is the amount of storage space that an industry has for input goods. In the bakery example, this is how much flour that it can store internally. It will keep demanding more flour until its internal storage is full, and will then use up its internal storage at a pre-set rate. Both the rate and the storage can be set individually in .dat files.

If industries have very large storage capacities in relation to their size, then this might well produce unrealistic behaviour, especially for industries with perishable inputs, such as bakeries, which will need to be kept in a constant supply of fresh flour. For other industries, such as hardware shops, having a larger input storage is more realistic, but only within reasonable limits.

[Jando]

The input storage is the amount of storage space that an industry has for input goods. In the bakery example, this is how much flour that it can store internally. It will keep demanding more flour until its internal storage is full ...

Is this literally how the algorithm works? Demanding more supplies until enough goods have been delivered to fill the internal storage? If so we have a design that relates demand to speed of delivery. The slower the delivery process is (ships, canals, ocean routes, long (!!!) loading times) the more goods are demanded by the industry.

[jamespetts]

Ahh, but then we add to that the concept of goods in transit, which was designed specifically to address this problem: the number of goods in transit to the industry is monitored, and, if it exceeds a set amount in combination with that currently stored in the industry, the industry ceases to demand further goods until the amount in storage or the amount in transit reduces.

[jamespetts]

It is time for some reconsideration of these ideas, not because implementing them is imminent, but because it is necessary to know what is planned in respect of these ideas to know how to deal with vehicle overhauls, which are on the horizon as part of the balancing exercise.

My current thinking on the matter is that dynamic reassembly of convoys/consists/trains is an important aspect of real life railway working. Although its importance has declined considerably of late, it is still relevant to some extent to freight trains (which sometimes are loaded without a locomotive attached) and multiple unit passenger trains (which are sometimes divided and combined during a journey), and was of very great importance historically, with locomotive changes, slip working, dividing and combining of passenger and goods trains and pick-up goods services being the norm for over a century. Although this set of concepts relates only to rail type transport, it is an important enough aspect of that type of transport to be worth giving some consideration to simulating.

However, for reasons that I think that I discuss above, it is very difficult to do this with things that carry cargoes, as the idea of vehicles from one convoy changing the convoy to which they belong mid-journey an extremely difficult thing to accommodate in the passenger/goods routing algorithm. Something that simply allowed for changing locomotives would be a little easier as it would not involve the issues with the routing of passengers/goods, but there still would be difficulties to overcome. Something allowing only for the changing of locomotives would have a considerable benefit (allowing a changeover between steam/diesel and electric traction for partly electrified routes, for instance), although would not fully simulate the variety of railway operations. This might (or might not) transpire to be a necessary compromise.

Something allowing for a change of locomotives only would do a great deal to assist with the low frequency problem described above, which would in any event not just apply to rail services, but also to, e.g., road services, where mail lorries might spend much of the time waiting for an assignment. The simple layover option suggested above could be used there.

A locomotive change system would also allow some revision of the current reversing system to allow special provision for turning steam locomotives, as has been requested in the past. Instead of tender engines turning automatically (but taking more time to do so), they might require a depot (which would be assumed to contain a turntable) to turn them, but be allowed to run in reverse, but at a lower speed (perhaps 45km/h). Then, players wishing to have a turned locomotive taking the train from a terminus station would have to arrange a locomotive change at each end, with a fresh locomotive coming from the depot and the old locomotive returning to the depot to be turned. The fresh locomotive from the depot arrangement might even be configured to allow a faster turnaround than the existing locomotive running around the train as is (vaguely and implicitly simulated at present), giving an additional (and realistic) economic reason to have depots at major termini. However, I do wonder whether such an arrangement would confuse or irritate players and make setting up railway routes too awkward: feedback on that aspect of things would be much appreciated.

The reason that this needs consideration now is the interaction between it and the way in which vehicle overhauls need to work.  At present, the replacer sends vehicles to the depot to be replaced as soon as the convoys are empty. This is known to cause serious congestion that can take a long time to fix, and also wreak havoc on carefully planned timetabling. A possible solution that has been under consideration for a number of years is to abolish depot visits for replacement entirely and overhaul and replace vehicles on the fly in much the same way as livery changes are done now. This does have potential problems, however, for replacement if, for example, vehicles are of different lengths or a convoy is to be replaced with a different number of vehicles: the depot code has robust ways of handling these changes that cannot be implemented for on the fly replacements.

If, however, we have the idea of layovers and locomotive changes and so on, this idea makes rather less sense: if vehicles are going to the depot for a layover, or to await the next train to haul, it makes little sense for them not also to go to the depot for the purposes of a major overhaul or being replaced with something else. Also, if convoys are less fixed in their contents, it becomes much harder to know what to replace: if, for example, a line of railway convoys operated a schedule involving a locomotive change, when a player upgrades that line, how would Simutrans know which locomotives in the depot to upgrade or even whether to upgrade locomotives in the depot?

If convoys are to return to the depot to be replaced or even overhauled, there needs to be a more orderly way of doing it: perhaps the ability for players to specify a certain point or points in the timetable after which an automatic return to the depot is permitted. Quite how this would fit in with layovers and locomotive changes would require furhter consideration; borrowing Cities in Motion's idea of regular scheduled depot visits might be one idea, but the question then is how these are to be organised and what is to happen if players refuse to schedule such visits (and what happens on loading a game where no such things are stipulated) It is also open to question whether such a system would be excessively annoying for players who tend to prefer to make higher level decisions rather than have to tinker with each line's maintenance schedule.

I should be grateful for any views on what are admittedly quite complex and far reaching issues, especially those that involve ingenious (but practical) solutions (but any general feedback would be appreciated).

[Ves]

Merry christmas!

I was incidentally thinking about reassembling convoys, shunting and stuff about a month ago.  I worked out a system in my head. It works a little bit different than your way James, but I think the principles of overlay and other things you talked about could easily be included. I have just thought on what I would think is the easiest way to configure and keep track of everything, GUI wise and logical. Although I struggle to code a simple thing as a vehiclelist, I believe the similarities to the goods route finding system could make things easier.
Anyway, my thoughts about the "Magnetic Car":

My idea is that in real life, each car get a ticket which says a lot of stuff, mainly it's destination(s). Then you have the driving part (loco), which needs a schedule in order to go anywhere. The first mentioned are passive, second are active.

In simutrans, I create a shedule which only includes eg a forest and a sawmill and assign that to four lumber cars. I order it to wait for full load at the forest. These cars are passive, just like the goods they carry, and cannot do anything other than load (because of their schedule, goods have now found a route) and wait for a hike.

Then I create a new schedule between the forest and a transport hub and assign that to a small loco. It can only haul the weight of two cars, and I order it to space every hour, waiting at the hub. This loco will start drive its schedule because it's an active vehicle (it has an engine). It will not carry any cars, since the cars route finding system still cannot find a valid route to its destination.

Lastly I create another loco and a schedule between the hub and the sawmill and order that to wait for four cars (X tones of good, X tones of cars, X meter of cars, X number of X good cars etcetera) at the hub. I also mark that it may not decouple anything (X tones of good, X number of X goods cars and so on) at the sawmill, forcing the loco to not just leave directly, remaining a single "convoy"

Now the four "passive" cars have found a route through the two "active" schedules we created, just like goods are handled today. Initially they don't care if it's a direct route, how fast it is, if it's steam or diesel etc, but this could be specified in their schedule.
When the small loco arrives, two cars (since the loco can only carry X of tones) like a magnet get coupled to the loco creating a convoy leaving the forest and other cars.

When they arrive at the hub, the passive cars get attracted to the other loco waiting there, adding up behind. Still the other locos schedule is not fulfilled since it needs four cars to leave the station. After next round with the little loco, the now five vehicle long convoy can leave, and will act as a single convoy we all are used to see in simutrans until it arrives back to the hub with the empty cars. The cars will now automatically use the small loco back to the forest when that leaves. The small loco only carries two cars at a time, and it will leave them at the forest since the cars loading time is longer than the couple time. In the second round from the hub with the rest of the cars, the small loco will automatically uncouple the unloaded cars and couple the two loaded cars (they have finished loading while the loco was away) and everything restarts over again.

Passenger services would naturally be a little different. Either I could just create an active convoy (with an engine) and go as we are used to in simutrans, or I could first create a number of passive passenger cars, and do like the good example above, making sure the passive cars and the loco have all stations I want them to visit in their schedules.


This logic could then be used to street vehicles where lorries have trailers and there are trailer parks and so on.

Going one step further, this could be used to cross connect vehicles of different types, eg a ferry carrying cars or trains. Then all vehicles routed over that leg would automatically detect the ferry as part of the route, and automatically act as passive vehicles for that particular leg. Also proper use of containers, trailers and trucks on trains and boats could be possible.

Some possible problems/dilemmas:

• if you have a convoy that for one or several legs needs an additional loco, how to "join" two active vehicles? Mark one as to wait for engine (X KW, X minimum speed etc) and the other as passive in the schedule?

• how to make a passive consist get out from the depot? A phantom loco? Teleportation? A loco you are forced to by with the sole purpose as to bring consists out?

• if the diamond edition is implemented, how to handle such things as containers? As a new vehicle group?

• and also massive dat changes to specify what can carry what.

• in the case with passenger transport mentioned in above example, it might be too tedious to create two very similar schedules, yet different (one passive, one active). solution could be to simplify the passive schedule and add a checkbox that allows loading and unloading whenever the cars happens to stop at any station. Then the loco holds responsibility to stop at the right places (which it anyways holds)

[jamespetts]

Thank you for your thoughts, and merry Christmas to you, too. One of the difficulties that I have in working on Simutrans-Experimental is that I have to do the best that I can with the existing code base. In many ways, this is a good thing, as I do not have to start from scratch (myriad are the joys of open source software), and I doubt that it would ever be finished if I did, but it does have downsides, one of those being that I am constrained in my alterations such that they must fit the existing system. To some extent, of course, I can change the existing systems, but the more significant the change, the longer that it takes to do it (and exponentially so, since more significant changes affect a larger number of other parts of the code, each of which need more work to change them than each of the fewer numbers of areas of code required by a smaller change), and the more bugs that my changes are likely to introduce. For this reason, I am careful not to make fundamental changes unless they are absolutely unavoidable.

In this case, what you propose would involve a fundamental change, being assigning schedules to individual vehicles rather than entire convoys. That change would permeate vast swathes of how the game operates and require a lot of things that work perfectly well at present to be re-designed from the ground up. I do not have the resources to allow me to do this (and it is not clear to me precisely how this would actually work for every mechanic in the game that interacts with schedules, either). For this reason, the ideas that I have contemplated above are focussed on adapting the existing model of schedules being attached to convoys. Even then, it is difficult to imagine how the somewhat intractable problems described above could actually be fixed.

Incidentally, I am also not clear on how what you suggest would work with vehicles that are both powered and carry a payload, such as multiple unit trains, railcars, 'buses, unarticulated lorries, aircraft, boats or ships, as the idea seems to require a fundamental distinction between a locomotive and a hauled vehicle which does not exist either in reality or Simutrans.

[Ves]

I didn't make any distinction between a vehicle carrying good and vehicle not cary any. only between vehicle as active or passive. A motor vehicle carrying good would be considered "active" and act just as they do in today simutrans, you make a schedule and it will run. According to multiple unit passenger trains, each set would be made out of multiple active units, constrained together (May not separate), supposedly making the nonleading parts passive. If you want to join two motorcars set, one set should be made passive as described above.

You could simplify and say that my idea, is to add a "passive" status to the schedule, that needs an active scheduled unit to move.

[jamespetts]

Ahh, I see; but I still do not fully understand how what you propose would actually work. Imagine a train which splits en route into two separate trains to various destinations. The train starts at A, calls at B and splits at C: the front half goes to D and the back half to E.

Passengers boarding at C bound for E would need to know to board the back half of the train, rather than boarding the front half or continuing to wait. The way that the routing is done at present does not allow for this: routes are pre-calculated between all origins and destinations. Packets of passengers (or mail or goods) wait at a stop knowing only their ultimate destination and next transfer. They wait until a convoy comes along that takes them to their next transfer. They calculate that by looking at the convoy's schedule to see whether it goes to the next transfer (there is also code to see whether another convoy, arriving later, will get to the destination sooner). Each convoy has a single schedule, which is just a list of stops. This does not readily accommodate, and cannot, so far as I can make out, readily be modified to accommodate, either branching or designation of specific portions of the convoy for specific destinations.

The (relatively) easy part is actually having convoys recombining on the fly: the hard part is to make the routing system work around this.

[Ves]

The Two trains will have their unique schedule, all the time.

Train 1 is going from A-B-C-D

Train 2 is coming from X and are supposed to join 1 at B and split again at C continuing by itself to Z

There are several ways this could look like, an example:

Train 1 schedule would be:
A -

B -

C -

D -

----

Train 2 schedule:

X-

B - status set to: PASSIVE

C- status set to: ACTIVE

Y -

----
Train 1 schedule doesn't have to include more than that (looking like the simutrans schedules we know today)

The passive status of train 2 that is set at B will force it to wait for "whatever picks it up". It will automatically magnetize to whatever matches it's constraints, taking it to its next stop. At C it gets the command to get active, which is what makes it split from train 1 and make it able to drive in to Y. Some GUI could also make the player add constraints to what may pick it up at B.

To make sure a train is picking another one up, some more GUI could be added:

---
In train 1 schedule:

A-

B - wait for (a nice GUI to be able to specify what to wait for) the extra set, possibly combined with a Max time waiting.

C - force decoupling (again a nice GUI)

D-
---

Either way, passengers going from B to Y will board the correct train, since it still has its personal schedule (from X-Y)

Note also that what I'm proposing is that every single peace of car-units/vehicles will have their own personal schedule, as every vehicle is it's own convoy. You could say its more like multiple convoys are able/forced to drive together.


Ok, I understand from what you are saying that a vehicle (or convoy) needs to have a fixed list of stops that the passengers (or goods) may navigate through. As i see it, it's only my idea in my first post about a player setting, letting a car just follow and pickup wherever it is stopping, which is conflicting that.
First of all, it was only a secondary idea spawning of the initial idea. But just to talk about it, it maybe could be possible if the cars, when they are coupled to the active vehicle, get a copy of the schedule (which contain all travel information) that the loco is having. It should then copy the schedule from the entry of joining to the entry of splitting (the cars will have the first and last stop in its schedule in order to join in the first place). Problem here though could be if you use this method and make a train that only exists once every month and are split in between. Then there would not exist any "convoy" with the right loading properties (assuming the loco containing the initial schedule is not carrying any good). One solution could be to save the schedule with goods information  *somewhere* for the longest time or twice or trice the time a schedule can span, but I admit that's far from perfect.

Anyway, that's a secondary feature that could be incorporated on top of the initial one.

[jamespetts]

The Two trains will have their unique schedule, all the time.

Train 1 is going from A-B-C-D

Train 2 is coming from X and are supposed to join 1 at B and split again at C continuing by itself to Z

Ahh, your idea is that it would not be a single convoy at all, but two convoys? That, too, would be difficult in all sorts of other ways, especially with movement code and signalling, and would require some quite drastic re-writing of code accross very numerous areas, some of which I do not even fully understand.

...Ok, I understand from what you are saying that a vehicle (or convoy) needs to have a fixed list of stops that the passengers (or goods) may navigate through. As i see it, it's only my idea in my first post about a player setting, letting a car just follow and pickup wherever it is stopping, which is conflicting that.
First of all, it was only a secondary idea spawning of the initial idea. But just to talk about it, it maybe could be possible if the cars, when they are coupled to the active vehicle, get a copy of the schedule (which contain all travel information) that the loco is having....

Again, this seems to envisage vehicles, rather than convoys, having schedules, which would require some fundamental changes the ramifications of which I am not in a position fully to comprehend. Such large changes generally take many months of intense work doing little else than integrating the new system to the existing system, exhaustive testing, tracking down and fixing the numerous bugs, then doing the same for the bugs caused by the fixing of the previous bugs. I do not think that this feature is likely to be worth the sort of extreme amount of work necessary for any such drastic or fundamental changes in the code any time soon; it is only likely to be viable in the short or medium term if it can be done with much more modest and isolated changes to the code.

Edit: In the abstract, the only way that I can see of doing this sort of thing is having special entries in a schedule with instructions for convoy re-assembly, but I cannot work out any specific system of doing this that is actually workable.

[Ves]

Yes, two convoys!

Ok, I'm not a coder so i obviously don't know what is specific difficult to code and what's not. :-)

But obviously, you need to be able to manage vehicles much more if you want to separate them. I can imagine there are two ways (again, I'm no coder):

Split convoys into new convoys, (need a way of handling schedules)

Or

Making all vehicles it's own convoy (private schedule for all vehicles)

My initial suggestion leans towards the second option, and for me as a player schedule operator, this would feel most natural I suppose.

Isn't it possible to use the already existing structures in the code, just level it up? There is a clear definition of a convoy in the code, I suppose, isn't it possible to basically copy that code and call it something like "consist" and instead of single vehicles, it uses "convoys" as parameter? It would then refresh every time new vehicles are added or removed. Then adjust the convoy-code to accept only one vehicle and point all such stuff as drawing, signaling etcetera to the new "consist"?

There already exists a way for goods to jump on the next suitable vehicle, it must be possible to copy that in some way so passive convoys can jump on the next suitable "consist"..?

Edit: typo

[jamespetts]

I am not quite sure how you envisage a "consist" here: the current concept of a "convoy" seems to cover what you mean by "consist", yet you envisage them being different; I am somewhat unclear on what you envisage those differences to be. I also do not know what you mean by "level it up" here.

As to goods boarding the next suitable vehicle, I think that you are referring to the boarding algorithm in which goods take the next free vehicle in a convoy; this decision is made after the decision to board that convoy is taken and as part of the function for boarding that specific convoy.

[Ves]

Ok, sorry if I'm messing up some stuff here :-P
What I meant:
In today simutrans there is some code that assembles convoys out of vehicles, which you could say work as an umbrella for the vehicles (getting length, information, pictures, positions on maps, holds the schedule etc).
My idea is that every vehicle act as it's own convoy, so a convoy = 1 vehicle.
Then you said that it's problematic to organize multiple convoys together.
Then I came up with the idea that you create a new thing called the "consist" in the code, which basically is a copy of the convoy-code, just everywhere the original convoy code points to single vehicles, you make it point to convoy code. Even though the word convoy and consist could mean the same thing, in this context, a "consist" is an umbrella over multiple "convoys".

As stated, I don't know how it actually works in the code. I'm just guessing...

Level it up was just a bad wording :-)

[jamespetts]

That's not quite how the code works, I'm afraid: one could not just point to a different bit of code. One would need to change a large number of areas quite fundamentally. Simutrans's code is not as modular as might be ideal (and, even if it were, it is not clear precisely how the "consist" abstraction would actually work and interact with actual convoys).