News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Little Suggestion for spacing

Started by mopoona, April 17, 2011, 09:53:57 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mopoona

I've did some experiments with spacing and did achieve rather good results. I managed to operate on long a dual-track high speed rail line (approx. 1000 fields long) with different train speeds ranging from 140 to 330 km/h. I was able to create a timetable that allowed almost every train to drive without any complications. Overtaken trains usually didn't have to wait (they were overtaken in the time they stoppet at a station).
Six times a month two highspeed trains in each direction use the track. They start at the same station and use a different approach to the high-speed track so they run closely after the other. The time between these trains is used to allow other trains to use the track (like cargo trains).

I think the spacing feature is very important if you have both low passenger and freight levels and cannot afford to build multi-track routes for every form of transit. I have a little suggestion to make the feature more accessible : It would be very nice, if you could set some kind of offset to the waiting times
For example: You are using a train station to connect to train lines. Both trains will try to leave the station at the same time. If you could set a offset for one of the trains you could make them leave in the order you want.

What do you think?
 
Greetings from Düsseldorf

Carl

This is a great idea. There should be two parameters: (a) convoy spacing/month and (b) offset from the standard time. The latter could also be measured as a fraction of the month. So you could have two lines leaving from the same station, both with the same cnv/month parameter, but timed to leave (say) half an hour apart.

mopoona

Greetings from Düsseldorf

Carl

I notice that the devs haven't picked up on this, so I thought I'd see if I can motivate it a bit more.

At the moment our convoy spacing system works as follows. Say I set a line to have a spacing of 12 convoys/month, and to wait for 100% load at station A. Under these settings, a train will only be allowed to leave station A at certain times: specifically, on increments of 1/12 of a month. For instance, on my game this means that a train will be released at 00:00, 02:00, 04:00, 06:00... etc, because a month lasts for 24 hours. So if a train arrives at 00:01, it will wait until 02:00 to leave -- and the same is true if it arrives at 01:50.

This works very well -- it's a hugely powerful feature -- but it has some limitations. Some large stations are the base for many different lines which run on a similar frequency. But if I have five lines with frequency 12 convoys/month based at the same station, this means that at 00:00, 02:00, and 04:00 (etc) five trains will all try to leave at once -- which can cause serious network issues.

Obviously there are ways around this within the current system. But what would be great is if we could have a feature like mopoona proposed -- an 'offset' feature. On this behaviour, I could have two lines with the same frequency based at the same station, but programmed to leave at different times. Say that both have a spacing of 12 cnv/month. One could have an offset value of 1/24 month. This would mean that it leaves at increments of 1/12 month -- offset by plus 1/24. In practice this means that a train on this line would be released at 01:00, 03:00, 05:00, 07:00, etc, keeping it separate from the other line which has an offset of zero.

Given that the game already has to calculate when to release trains, I doubt it would add very much complexity to simply ask it to add a simple extra element to the calculation.

Here ends the simple proposal: below I'll consider a more radical idea in this vein.


---

Having thought about the above quite a lot, it's clear that Convoy Spacing gives us a good basis for a timetabling feature in Experimental. In fact, I'd go so far as to say that it already gives us a timetabling feature -- although to make it work as such currently requires some work. It seems to me that we should embrace this, and see how far the spacing feature can get us on the road to timetabling. Here are some initial thoughts about how it might work.

Given the information the game already has, it's already capable of working out basic timetables for routes. Consider: the game knows when it will allow trains to depart from stations where convoy spacing is in effect. It knows how long trains take to get from station to station (and once the point-to-point average speed feature is added, it will know this in even greater detail). This is all the information required to make and display a basic timetable for a route. Given that Route 1 is scheduled to leave station A at 00:00, 02:00, 04:00, etc, and that it takes 30 mins to get from station A to station B, the game can work out that Route 1 should (if all goes well) serve station B at 00:30, 02:30, 04:30, etc. Even without any additions to the game, it could presumably generate and display this information in-game.

Once all this existing data is farmed and displayed, I can't imagine it would be too difficult to allow players to alter the figures and thus tweak timetables (to allow for better connections, etc, etc.)



So, in summary -- I think the simple proposal could be fairly easy to implement in the short term, but future development of the Spacing feature should aim in the direction of timetabling. Given that we already have so much of the required structure in place, and given how powerful such a feature would be, it seems worth the effort!

I'd be interested to hear your thoughts on this.

jamespetts

Carl,

thank you for your thoughts. The reason that I hadn't picked up on this previously is because there is a rather long list of other things needing to be done! I shall deal with the offsets suggestion first then move to the timetabling discussion.

There are two subtly different versions of offsetting being proposed here (I think): convoy offsetting and line offsetting. The former (which is what I understood Mopoona to be suggesting) is much trickier to implement and use than the latter. The latter, however, might be a serviceable feature, as it would require only one additional parameter and one additional UI control in the existing line detail window. It would also require far less micromanagement for players than a convoy based system, since there would be far fewer parameters for players to have to tweak. I might well consider this, but it will have to wait for a version increment, since it requires an extra parameter to be saved.

As to timetabling, I have always consciously resisted the idea of having full timetabling. The reason for that is that it both enables and incentivises micromanagement, which can substantially detract from the enjoyment of playing. If players can only get the best out of their network by tinkering with a large number of highly detailed settings requiring careful piecing together of large quantities of mathematical information to get right, then players either have to do the difficult work or put up with a suboptimal network (and, in multiplayer games, be out-competed by players who are prepared to undertake the difficult work). I take the view that playing a game should not be about doing difficult work, and that the monotonous and the routine should either be automated or simplified away to reduce the game to genuinely interesting abstract choices that require creativity and intelligence but not arduous computation. The current convoy spacing works well because it is very simple to set up and use and does not require any tedious calculation by the player to use to maximum effect. Full timetabling would require that kind of arduous work, and would likely be highly daunting for new players as a result. For that reason, I do not intend to add full timetabling features to Simutrans-Experimental.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

Hi jamespetts,

Thanks for the response! Some thoughts on your thoughts:

I'm pleased to hear that you think the offset idea is serviceable.

On timetables, then. I'm certainly sympathetic to many of your worries about full timetabling. However, I think that we might be able to find a middle ground which doesn't have all of the flaws you describe above. The reason I thought it appropriate to suggest timetabling at this juncture is because the Convoy Spacing feature gets us at least partway along the road to timetables. It doesn't seem like a huge step from Spacing to Timetabling, so partly I'm just suggesting that we call a spade a spade and admit that the Spacing feature is already a kind of Timetabling feature! :-)

What's more, Spacing -- especially if Offsetting is implemented -- is already subject to many of the same complexity concerns that you express above, especially in terms of advantaging players who are willing to put in lots of effort. It's already true that those willing to optimise their networks with Spacing will do better than those who don't. In response to those worries, I'd say the following. Any Timetabling feature worth its salt would, like the Spacing feature currently, be fully optional. In the current version of the game it's perfectly possible to build an excellent network without spacing -- and if the Timetabling feature were to resemble the current features in important ways, there's no reason why that shouldn't continue to be the case. Furthermore, I certainly agree that timetabling should only be done in ways which don't require "arduous computation". But I can't see any reason to think that *every* way of implementing Timetabling would require this.


jamespetts

Carl,

thank you for your thoughts. As to timetabling, being optional does not really assist the complexity issue: in a multiplayer game, a player who used timetabling would, in some cases at least, have an advantage over a player who did not, which would mean that the other player would either do badly in the game or have to use timetabling; if implementing timetables was hard work rather than fun, then the player would be faced with two non-fun options (doing badly or undertaking hard work), and enjoyment of the game would cease.

The spacing as it currently stands is not really a timetable: it does not require players to think about precisely how one set of services will interact with another (which consideration becomes exponentially more complicated with the number of added services). Indeed, in light of that, I do worry that an offset would introduce precisely such a consideration and would itself amount to excessive micromanagement. I do wonder about the offset - could the same result not be achieved by setting slightly different spacing parameters for each line (one at 19, one at 20, one at 21, etc.)?

As to there being a timetable implementation that does not potentially require arduous hard work for the player - I can't think of one; can you?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

Quote from: jamespetts on June 06, 2011, 02:52:12 PM
The spacing as it currently stands is not really a timetable: it does not require players to think about precisely how one set of services will interact with another (which consideration becomes exponentially more complicated with the number of added services). Indeed, in light of that, I do worry that an offset would introduce precisely such a consideration and would itself amount to excessive micromanagement.

This is true, although I maintain that the differences between the present system and a bona fide timetabling system would be differences in degree rather than kind. There is already motive to think about interaction between services to a certain extent. Currently they are just less explicit and more difficult to engineer.

Quote
I do wonder about the offset - could the same result not be achieved by setting slightly different spacing parameters for each line (one at 19, one at 20, one at 21, etc.)?

This goes some way to solving the issue. But note that most combinations will still result in several occasions each month where more than one convoy tries to leave at the same time. This will always happen at least once per month -- that is, precisely at the start of the month, when all will try to leave. That could be avoided with offsetting.

Also, this strategy is less available when you get to larger divisions. There might be a big difference between running 2 convoys per month and running 3 convoys per month, for instance.

Quote
As to there being a timetable implementation that does not potentially require arduous hard work for the player - I can't think of one; can you?

Not yet. I'll give this some more thought and get back to you.



jamespetts

The differences may be of degree rather than of kind, but, if the degree is enough (and, really, I think that it is), does it matter? One possible solution to the "everything leaving at once" issue without micromanagement might be some sort of automatic offsetting, but I am not sure how that would work and worry that it might be fiddly to implement.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

inkelyad

Quote from: jamespetts on June 06, 2011, 01:12:20 PM
There are two subtly different versions of offsetting being proposed here (I think): convoy offsetting and line offsetting.

Spacing: per line parameter.
Offset: per stop parameter.

If you implement this, you will have (almost) full timetable. To make it full you need to calculate 'preferred' speed for convoy and use it.

But all this is too complex.
Quote from: carlbaker on June 06, 2011, 03:19:23 PM
But note that most combinations will still result in several occasions each month where more than one convoy tries to leave at the same time.
It is not a problem. You can build 'out of band' stations and use signals. (see my demo when i posted spacing patch)

Problem is undefined leaving order. Hm..
We can add 'line level' (local/intercity/etc) parameter and use it as priority?

jamespetts

#10
Inkelyad,

welcome back! You make good points - but may I ask: what is an "out of band" station?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

Quote from: inkelyad on June 06, 2011, 05:17:08 PM
We can add 'line level' (local/intercity/etc) parameter and use it as priority?

That's something else I was thinking about suggesting.

jamespetts

I should be interested to know exactly how the proposed priority system would work, and, in particular, how it would interact with the block reserver.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

inkelyad

Quote from: jamespetts on June 06, 2011, 08:15:03 PM
what is an "out of band" station?
See attached image.

Quote from: jamespetts on June 06, 2011, 10:05:16 PM
I should be interested to know exactly how the proposed priority system would work, and, in particular, how it would interact with the block reserver.

As usual.
Relevant code:

            sint64 wait_from_ticks = (welt->get_zeit_ms()/spacing) * spacing; // remember, it is integer division
            int queue_pos = halt.is_bound()?halt->get_queue_pos(self):1;
            go_on_ticks_spacing = wait_from_ticks + spacing * queue_pos;

and

    // Nun wurde ein/ausgeladen werden
    if(loading_level>=loading_limit  ||  no_load  ||  welt->get_zeit_ms()>go_on_ticks)  {
        [SKIP]
        advance_schedule();
        state = ROUTING_1;
    }

Convoys try to leave at same time means they have same go_on_ticks (start of the month). We need to use queue/priority here.

In other hand, adding spacing_shift to schedule_t more or less trivial.

wlindley

Would it be possible to make it so a bus or truck at such an "out of band" station would Unload at the "entry" side, then wait there *inside* the station before turning around and waiting to Load to the "exit" half? 

inkelyad

Well, you asked for it. (github branch).

New simuconf.tab parameters:

spacing_shift_mode
0 - shifting feature disabled.
1 - enabled per line
2 - enabled per stop

2 is default value.

spacing_shift_divisor
ticks_per_world_month/spacing_shift_divisor will be used as step for shift change.
24*60 is default value

jamespetts

Inkelyad,

thank you for that. Can I check - have you tested to ensure that this is network compatible (i.e., that when the client changes the spacing shift, this is transmitted to the server)?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

inkelyad

It seems to work with localhost server.

jamespetts

Thank you for checking that - much appreciated. I have fixed the save game versions as you suggested in the other thread - thank you for spotting that.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

This is now incorporated in the released 9.9.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

mopoona

I had a simple idea how to improve the spacing feature. Would it be possible to allow setting the load-percentage to 101 % when using spacing? If you use timetables (with spacing) all the time you get a little annoyed by initially full-loaded vehicles that started their trip too early.
Greetings from Düsseldorf

Carl

Even 101% may not be enough if you have vehicles with overcrowded capacity.

mopoona

Greetings from Düsseldorf

jamespetts

Do people think that this would be better to be 100% of normal capacity, or 100% of total capacity (both seated and standing)?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


mopoona

Since Simutrans Experimental should stay compatible to its own save games and the save games from Simutrans (Standard) I would vote for 100 % = normal capacity. Imagine loading an older save game and having to change all your loading times to get the behavior how it was before.
Greetings from Düsseldorf

sdog

100% of normal capacity. If i use 100% is want the convoy to leave before overcrowding. Guessing at what percentage the normal capacity would be reached would be not to usefull.

using a percentage exceeding the vehicles percentage to prevent it leaving before schedule is very confusing! At least use a descriptive entry. OR assume not setting a value if spacing is activated as waiting there regardless of fill state.

Sadly since schedules are independent of vehicles, calculating the 100+x percentage for overcrowding isn't an option. Is the load until overcrowd capacity is reached actually required, or could anyone live with load until 100% of regular capacity?

Carl

"Load until overcrowded capacity reached" is only really required in order to avoid vehicles leaving "early".

Sdog is right that the linking of spacing and wait-for-load is somewhat counterintuitive. A "spacing without load restrictions" option would be beneficial (and would solve the topic of this discussion).

mopoona

It seemed to me that 101%-load would be the easiest to implement since there are no UI changes to come with it... But I guess its the best thing to allow the usage of spacing when no loading-parameter is set.
Greetings from Düsseldorf

inkelyad

#29
This is done intentionally (well, almost). Fully loaded bus should not wait another 2-3 hours due to spacing settings. I suppose I can change this, but it can create strange results in loading code. We do have 'first come, first served' loading queue on multi-platform stations. While head of queue is here, there will be no loading for other buses. In worst case we will be forced to add another state (WAITING_FOR_SCHEDULE).

Carl

The easy fix would, as mopoona says, to allow for max-load values which exceed 100% -- if the limit was set far above what overcrowded capacity could ever reach (say 1000%) then this would have the same effect as programming a new state. This leaves it open to the player how the feature is used: it can either be used as intended (by inkelyad's description) or in the alternative way that mopoona describes.

Carl

#31
In relation to the above discussion, I've committed some changes to git which I think meet everyone's desires.
https://github.com/jha4ceb/simutrans-experimental/commits/learning-curve2
(Edit: attached (I think) is a git-generated patch.)


The effect of the changes is as follows:

-- The "minimum load" value in the convoy schedule window allows for values of up to 150% of normal capacity.

-- This allows players who use "convoy spacing" to be sure a vehicle will not leave before its spacing slot, and thus allows for greater flexibility in network management.

-- The change still allows one to set the value as "100" and thereby retain the old behaviour.



The following applies to vehicles with overcrowded capacity:

-- If a vehicle is loaded to 100% of normal capacity and other vehicles of the same line are loading in the same station, then no more passengers will board the full vehicle. Instead, they will board a vehicle with spare capacity.

-- If a vehicle is loaded to 100% of normal capacity and NO other vehicles of the same line are boarding in the same station, then passengers will continue to board the full vehicle up to its overcrowded capacity limit.

dannyman

As I am not a heartless cheapskate, I say if the bus is full, I'm not having the driver wait around to fill it more with standees.  Let them get started ahead of "schedule" because hey all that weight in the vehicle is going to slow them down anyway.

But for those who really want to pack their passengers in like cattle . . . well, get them patches rolling . . .

jamespetts

Carl,

thank you very much for doing this, and apologies that I have not had chance to look at it yet: I have been rather preoccupied with the network desync bug, I am afraid. I shall hopefully have time to look into this whenever I manage to fix that issue. Thank you again for your work on this!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

James: no problem! Just to say that I'm not certain that the second of those two commits -- which changes the %-step values -- is necessary. I guess you can see what you think. Really all that's required is a change in the one line which limits "minimum load" to 100.

And just to address Dannyman's objection that using this would be a strange way to run a network: there are some uses for which this feature is important. For instance, if you're using spacing to manage fast and slow trains on the same track (as I described in the tutorial topic) then it's crucial that the slow train not leave before its designated slot, even if it is full. If it were to leave before, it would cause havoc with the network.

Importantly, the patch still allows you to set "minimum load" to 100% and thus retain the old behaviour. All it does is give extra flexibility for those who build networks which require it.