Line management overhaul

[peehaa]

I have a couple of ideas about developing linemanagement, but before I start I'd like to get your permission. Especially because you have said to want to work on that in a short while as well.

I would like to see lines made up of other lines. This way you can have one line description but have vehicles move on this line with several start and stop places, or have a main line and a loop at one or both ends. With buses in the Nederlands the latter happens quite a lot.
After this is developed I would add a possibility to make certain stops have a different priority from other stops. This way you can add local, interlocal and international trains to the same line, but have only the local line stop at all stops, while the others stop at their own stops. Also I want to propose a level 0 (zero) where vehicles do not stop except when there are passengers/goods at or for the stop (like with most stops in the bus).
Come at this point I have a couple more ideas, but they are not really developed yet, and it might be necessary to ask permission again. Of course if anyone has ideas that fit in with this, like shunt orders/shunting e.g., I am happy to give it a try.

Main reason I post on this board is that if you do not want it in your game, I for me wil develop it anyway (possibly as a plugin, or for personal use only), but I don't want to do the same work you do, nor will I stand in your way if you want to do it yourself for whatever reason.

[Ves]

There are several threads scattered around with discussions on certain things, which might be worthwile and interresting to read (or skim through, as some are quite massive).

As some of the threads are burried quite deep, I have listed the ones I remember from on top of my head:

Most worthwhile would be the top 3-4 as they all appear to contain aspects of what you want to do.

Request for two new timetable features
-> http://forum.simutrans.com/index.php?topic=14000.0
Convoy re-combination
-> http://forum.simutrans.com/index.php?topic=14301.0
Fixed costs, low frequency services and shunting
-> http://forum.simutrans.com/index.php?topic=11751.0
Overhauls and renewals
-> http://forum.simutrans.com/index.php?topic=14134.0
Outline of proposed and work in progress changes to passenger transport
-> http://forum.simutrans.com/index.php?topic=11476.0


Here are some discussions on some other topics, in case you want to read more:
Overview of Simutrans-Experimental features
-> http://forum.simutrans.com/index.php?topic=1959.0
Potential feature discusion: economic integration
-> http://forum.simutrans.com/index.php?topic=15095.0
City growth - techincal discussion
-> http://forum.simutrans.com/index.php?topic=13498.0
Discussion of new signalling system
-> http://forum.simutrans.com/index.php?topic=14888.0

[jamespetts]

Peehaa - thank you for the interesting ideas, and thank you to Ves for very usefully cataloguing the relevant threads: that is most helpful.

What I am planning to do is largely set out in the threads to which Ves referred. One of the things that this will involve is adding greater sophistication to lines and schedules. In particular, one thing that will need to be done is to add extra parameters to each schedule entry to allow for more customisation: this would include everything from ignoring the choose operation of choose signals (i.e. treating them as normal signals when the destination in question is the convoy's next destination) to commands for coupling/uncoupling (more detailed consideration will need to be given to how this might work in light of the issues discussed in the relevant threads especially in relation to branching schedules, which is a particularly complex issue) and special commands for when vehicles are sent to the depot for maintenance and overhaul (e.g., having a depot visit permanently in the schedule, which a convoy will skip unless it has travelled a certain distance since its last maintenance, etc.).

I was not planning to implement the exact feature that you suggest: I had not specifically considered it. Doing so in the terms that you suggest in this post is likely to be problematic because there are lots of important parts of the code that assume that all convoys on any given line will have an identical stopping pattern, so that, for example, passengers/mail/goods will board any convoy belonging to a particular line because the (necessarily singular) schedule assigned to that line includes their destination or next transfer stop, and the path explorer (the highly optimised code for routing passengers/mail/goods written by a talented coder who no longer works on Simutrans) produces only one set of timings for each line on the assumption that a single line has a single set of timings (and not some convoys that have different timings because they skip stops or terminate short). This is why branching schedules (necessary for dividing/combining trains) is so complex and as discussed at some length, I think, in one of the threads to which Ves refers: accommodating stop skipping and short terminating, too, would make this even harder.

I suggest that you achieve what you are looking to achieve in a slightly different way, either by creating some sort of superset of lines from which actual lines can easily be created (and perhaps changes to one might then replicate accross to the others automatically save where they are different, and perhaps sharing line statistics), or (more simply but perhaps less usefully) by having an easy way to copy lines. This is a potentially easier way of doing things that is not possible for schedule branching. Note that it is very important for the game to work in the multi-player mode for any player commands relating to these lines to be propagated using the special system for propagating commands in simtool.cc (you will see how it works by looking at the code: essentially, a string is sent over the network by one function and then parsed by another: usually, a single character determines which of a list of commands is to be processed, and a further string adds further parameters if necessary).

Of course, if you have a good idea as to how to make non-singular and/or non-linear schedules work properly with all of the game's innards efficiently, then I should be interested to know what it is, as that may well help me considerably with the branching schedules that I may well have to provide for in due course.

If you are able to code this in a way that fits in with what I plan to do and that works properly in multi-player online mode (and generally), then I should seriously consider including such a feature, as it could well make managing linked groups of lines (some short terminating, some stop skipping, etc.) much easier. Indeed, for 'bus, tram and urban rail lines where short terminating is common, this would potentially be very useful.

Incidentally, the next major project that I am planning to undertake after I finish fixing a few bugs in signalling and producing some more signalling tutorial videos is precisely this work on schedules and lines (which is important for balance as discussed in some of the threads to which Ves linked). This is a particularly challenging project, especially for me, as I work full time and am entirely self-taught in C++ (which I learnt in order to modify Simutrans starting in 2008). If you are able to assist with this process and contribute some of the coding (and perhaps your own ideas as to how best to implement some of this), that would be fantastically helpful and could potentially make a huge difference to the next major release date: we do very much need people who are able to assist with coding.

Do not feel obliged, of course: any assistance that you are able to give, whether large or small, or whether simply by reporting bugs and/or adding features of particular interest to you that also are potentially useful to others and do not conflict with what is planned is more than welcome, but if you are able to contribute to one of the planned major projects, you would have the chance to have your own ideas as to design and implementation in the project.

In the meantime, do let me know if you have any queries about how the code works, and I shall try to assist as best as I can (bearing in mind that I cannot always remember how things work, and I often do not know myself how some of the code from Standard works).

[peehaa]

@Ves:
Thank you for taking the time to make a list of topics that can be helpfull. Altough I appear to be new on this forum, I have read a lot already, but some of the older threads I did not seem to have read before.

Doing so in the terms that you suggest in this post is likely to be problematic because there are lots of important parts of the code that assume that all convoys on any given line will have an identical stopping pattern, so that, for example, passengers/mail/goods will board any convoy belonging to a particular line because the (necessarily singular) schedule assigned to that line includes their destination or next transfer stop, and the path explorer (the highly optimised code for routing passengers/mail/goods written by a talented coder who no longer works on Simutrans) produces only one set of timings for each line on the assumption that a single line has a single set of timings (and not some convoys that have different timings because they skip stops or terminate short).

That will make step two (giving a priority to stops) of my plans very hard.

This is why branching schedules (necessary for dividing/combining trains) is so complex and as discussed at some length, I think, in one of the threads to which Ves refers: accommodating stop skipping and short terminating, too, would make this even harder.

I suggest that you achieve what you are looking to achieve in a slightly different way, either by creating some sort of superset of lines from which actual lines can easily be created (and perhaps changes to one might then replicate accross to the others automatically save where they are different, and perhaps sharing line statistics)[...]

This was exactly what I was thinking about, only to this superset of lines it would likely be possible to add vehicles as well. That way you have line A > Z is made up of the sections

Code Select Expand

A > B > (C .. E) > F > (G .. K) > (L) > M > (N .. Z)
where:
'x' is a normal stop,
'(x .. y)' is an existing line which can hold vehicles (preferably)
'(x)' is a line in a station where special orders like shunting can be given
(I hope this way the characters used are clear).

Note that it is very important for the game to work in the multi-player mode for any player commands relating to these lines to be propagated using the special system for propagating commands in simtool.cc (you will see how it works by looking at the code: essentially, a string is sent over the network by one function and then parsed by another: usually, a single character determines which of a list of commands is to be processed, and a further string adds further parameters if necessary).

I do not think that this is different from current practice, given that I only change the way a schedule is built, the schedules will still not be shared between players, but I will look in to that (I am a solo player).

[...]Incidentally, the next major project that I am planning to undertake after I finish fixing a few bugs in signalling and producing some more signalling tutorial videos is precisely this work on schedules and lines (which is important for balance as discussed in some of the threads to which Ves linked). This is a particularly challenging project, especially for me, as I work full time and am entirely self-taught in C++ (which I learnt in order to modify Simutrans starting in 2008).[...]

In the meantime, do let me know if you have any queries about how the code works, and I shall try to assist as best as I can (bearing in mind that I cannot always remember how things work, and I often do not know myself how some of the code from Standard works).

I will do that given that I am not only new to Simutrans development but also to C++, learning this was on my to-do list for a long time, but only now I feel confident I can be of some service for this project. Right now you are my master by far.

I do not consider your proposal for a simple line-copy for now, maybe if I really do not find a different way, but given the other proposals I really think this has to be worked out one way or another and a simple line-copy is not going to solve any other problems.

[jamespetts]

That will make step two (giving a priority to stops) of my plans very hard. ... This was exactly what I was thinking about, only to this superset of lines it would likely be possible to add vehicles as well. That way you have line A > Z is made up of the sections

Code Select Expand

A > B > (C .. E) > F > (G .. K) > (L) > M > (N .. Z)
where:
'x' is a normal stop,
'(x .. y)' is an existing line which can hold vehicles (preferably)
'(x)' is a line in a station where special orders like shunting can be given
(I hope this way the characters used are clear).

I am not sure that I fully understand this suggestion. How would you imagine that adding a vehicle to a group of lines would work? Imagine that one has lines A, B and C in group 1. Each of lines A, B and C have a different (but related) schedule. If one adds a convoy to group 1 without also adding it to exactly one specific line, how does it know which of the three schedules to follow, and how will passengers/mail/goods know whether to board this convoy or not if some but not all of the lines in group 1 stop at their intended destination?

I think that I might have understood your diagram (which might be a partial answer to the question); did you imagine groupings which concatenate lines, so that one would have a line (for example) from stop X to stop Z stopping at intermediate stop Y, and then another line from stop Z to stop Q, calling at N, O and P as intermediate stops, and a superset would be a line from X to Q, calling at X, Y, Z, N, O, P, Q? That conceivably could work for short terminating (although it is then hard to see how this would be any advantage over the current arrangement, as in the current system, one would need two lines for that arrangement (one line from X to Z and another from X to Q, and in your system, if I have understood it correctly, one would need two lines (X to Z and Z to Q) and a superset of both of those), but I am not sure how this would work for stop skipping.

I see that a simple copy system may well not achieve the more sophisticated objectives; but a superset system in which changes to one line's schedule could optionally be propagated to all lines in the superset, all lines in the superset that have a matching schedule entry, or be unique only to that particular line, and where line supersets ("diagrams", perhaps) could share statistics on revenue, etc. could well work to achieve what you are interested in achieving, could it not? This would then equally accommodate stop skipping: one would create a line, e.g. A>B>C>D>E; one would then add it to a superset, create another line from that superset, and then modify its schedule (with the option not to propagate the modification) so that it now stops only A>C>E. Both of the lines would then have joint profit, revenue, cost statistics in the superset, and (optionally) modifications to, for example, the departure frequency from A made to one of the two lines would be propagated to the other without the need to modify both. This could all be accomplished without any modifications to the system for checking which convoy to board or the path explorer.

I do not think that this is different from current practice, given that I only change the way a schedule is built, the schedules will still not be shared between players, but I will look in to that (I am a solo player).

Any time there is a new type of command that can be sent by a player, this needs to be sent to the server as described. If, for example, there is a new type of parameter for a schedule, any command to set that parameter in any given line or convoy's schedule will need to be sent to the server.

I will do that given that I am not only new to Simutrans development but also to C++, learning this was on my to-do list for a long time, but only now I feel confident I can be of some service for this project. Right now you are my master by far.

I shall endeavour to assist as much as I am able to do so.

[peehaa]

I think we mostly have the same idea, only the approach differs. I think it is a good idea to implement both on top of each other, and with a little bit of hiding for your idea.

Your idea I think is the best approach for the stop skipping. The way I understand your idea is that the player makes a line, than upgrades it to a superline and uses this as a (coupled) template for other lines. The coupling comes in effect for the statistics and the route updates (both, one or none). The downside is that you can also add a roundtrip or a new strech of line, so the statistics are not necessarily correct.
To tackle that we can add hiding: Hiding makes only limited redirections possible, since it is not explicitly visible that the above created lines are in fact different lines. I was thinking to give stops priorities, starting at 1 (one) this time where the game automatically makes a new line when two or more stops have a different priority from all other stops. Then you give convois a stop-priority (seperate from a still to add drive priority to let two convois pass each other), so as to make them stop only at the necessary stations. The max. number of stop priorities is pak-dependant/user selectable).

My original idea was more along the lines of having several lines that can hold both: convois and lines. E.g.:

Code Select Expand

line 1: F > G > H
line 2: N > O > P
line 3: A > B > C > l1 > Q > R > S
line 4:     D > E > l1 > I > J > K
line 5:             l1 > L > M > l2
line 6: C > l5 > K > J
As to the in-game handling: Lines are added like any other waypoint; for this we need the line management window I think, so perhaps it would be usefull to have the option to display only part of that window.
In the Add line window, only the line number/name is visible. In the line management window -> station section are all stations visible but stations coming from other lines (1, 2 and 5) are visible with some kind of accent, to separate both types easily. Also in line 1, 2 and 5 one can see what other lines use these lines, perhaps in the vehicle section of line management.

I will make sure it works in multiplayer too.

I propose I make a proof of concept of my original idea as soon as possible, possibly this week, if not: next week. This does not mean it is ready on all aspects, but that way you can see how I thought it could work (single player, no changes to conf/gui etc.; of course they will come soon after.)

[jamespetts]

That is very interesting - yes, I see that that could work. If I understand correctly, you want to make the user interface similar to your original idea such that it enforces subsets/supersets of lines rather than any splitting/joining, which seems feasible and may well make the statistics more meaningful as you state.

In terms of adding lines like any other waypoint, I wonder whether there might be something to be said for having an "advanced..." (or similar) tab in the schedule window (which is the window opened when "new line" is selected), and having all of the minimum load, wait for time, departures/month, etc. as well as the interface to concatenate lines as you suggest (and, in future, some further schedule tools for future features) hidden unless this button is selected, such that users by default see a very simple interface for the schedule?

Edit: One other thing of which you will need to be careful to make sure still works after you implement this is the network diagram in the minimap, which is based on schedules. I shall look forward to seeing your implementation, however!