News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Standard & experimental

Started by Parachute, November 29, 2014, 12:46:34 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Parachute

Since a few weeks I'm playing Simutrans again, its been a while.
One thing I don't understand about the game at the moment is the following:

There are two versions of the game now. A economically and more realistic version (Exp) and the Standard version, which hasn't been changed so much for years. Why not? Why can't the standard version be a bit more realistic? Some Exp-features can be easily implemented in Standard (I'm not a coder, but I guess that the code is not that much different).
The Standard version should not be more complicated (that would discourage new players), but it could be more realistic (which would attract and preserve some new players, I'm sure of that).

For example: (from this list),
- Journey time tolerance
- Transfer time
- Cornering
- Reversing
- Loading time
- Scheduling features (<- would make Standard so much easier + realistic to play)
- Good & passenger loading
Etc.

Ters

Many of the features in Experimental is very computationally expensive, and many Simutrans players have relatively old computers. There is also a difference of opinion as to whether the changes in Experimental are for better or worse in terms of how they want Simutrans to be.

Each player of Simutrans seems to have their own idea of what kind of game Simutrans is or should be. That has led to a multitude of options to configure some behaviour in Simutrans (both of them). But at some point, the difference becomes too big to control with options without making the code a complete mess of conditional statements and data structures that are only used when certain settings are enabled.

Personally, I'm worried that even Simutrans Standard has too many settings, making it more difficult to help other users, because the problems they are experiencing only happens with their particular setup and not on my own.

Parachute

For me its not about the settings.
F.e.: Trains in the Standard version stop for like 1 second at a station, and drive on again. Thats just not realistic. When the Exp system of loading time is implemented, Standard will not be more computationally expensive (I think), it won't have more settings or more options, it won't be more difficult, it will just be more realistic.

DrSuperGood

You are aware you are talking about realism in a game where a double track is as wide as 2 city blocks? Or where cars cannot be more than 1 in a tile per direction?

Parachute

That's also the case in Experimental.

Ters

Quote from: Parachute on November 29, 2014, 05:10:57 PM
That's also the case in Experimental.

Exactly, and as long as that is the case, I see no point in trying to impose realism in the details. Trains wait for one second you say? According to the clock below the map, it was several minutes. And it can easily take two days to reach the next town. What we see in Simutrans is an abstraction.

I would like to try out a game with real timetables, realistic speeds, loading times, rush-hour traffic and many other things. But it would require a fundamentally approach, and possibly vastly more processing power than any consumer level computer has. It's also possible that such a game would be almost unplayable, or unenjoyable due to realistic time.

Parachute

Ofcourse its an abstraction. But when in another version it is possible to make that abstraction more realistic, it should be implemented. Especially when the code & system is already there in the other version of the same game. A thing like Scheduling timetables will make the game only easier (and it would be not suddenly more heavy for a consumer level computer). Simutrans is a simulator. A simulation game attempts to copy various activities from "real life" in the form of a game. As the knowledge, the code and the system is already there in Exp, I cannot understand why some features are not implemented in the Standard version.

DrSuperGood

QuoteA thing like Scheduling timetables will make the game only easier
Not the way Experimental currently does it. Its a micro nightmare to try and schedule everything as there are no figures for slots missed etc. When running in reverse mode they share the same slot pool as well resulting in stalls.

anp

Quote from: DrSuperGood on November 30, 2014, 12:51:07 AM
Not the way Experimental currently does it. Its a micro nightmare to try and schedule everything as there are no figures for slots missed etc. When running in reverse mode they share the same slot pool as well resulting in stalls.

As far as i'm concerned, reverse mode only works with buses. With trains I find it necessary to plot the whole route as a "loop" or you will need platform choose signals and train "meeting loops" between every stop.

Ters

Quote from: Parachute on November 30, 2014, 12:36:18 AM
A thing like Scheduling timetables will make the game only easier (and it would be not suddenly more heavy for a consumer level computer).

How can you have timetables in a world where time and distance is so completely out of proportions? A slight difference in speed based on weight of the train can lead to a train arriving a day/month later on long routes. Random freight trains would also severely affect the passenger trains given how long trains are compared to map distances, making the time it takes for them to get from A to B highly unpredictable.

Parachute

Its not about time/minutes/seconds, but about a regular loop of trains. In the Standard version vehicles will approach each other after some time. In the Exp version (while that system is not perfect yet), there is a solution for that.

Another example: In Exp trains drive to the middle of the platform. In the Standard version this is still not implemented yet. But it doesn't make the game heavier, more difficult or whatever. Just a bit more realistic. Such simple changes could make the Standard version more attractive.

Ters

Quote from: Parachute on November 30, 2014, 10:20:47 AM
Another example: In Exp trains drive to the middle of the platform. In the Standard version this is still not implemented yet. But it doesn't make the game heavier, more difficult or whatever. Just a bit more realistic. Such simple changes could make the Standard version more attractive.

I don't see the purpose, nor that it is particularly realistic either, but that might depend on how railroads operate in different countries (or even from station to station, or which direction the train is traveling through a particular station). In fact, I know rather of places where trains should stop beyond the platform rather than in the middle, but on must consider platforms in Simutrans as abstractions for a larger station area (which they are, compared to the size of cities and distances in general).

prissi

Most things in experimental have been rejected because they were rather out of place or not more realistic that the current happening or too computationally demanding.

Different loading time exists also in standard. But simply no pakset supports this.

Also trains never ever stop in the middle of a platform. In almost any country there is a very strong rule where a train must stop; it is either then end of a plaform or a stop sign. However, this does not alter gameplay at all, so it is just a visual thing.

Also the "realistic acceleration code" in experimental is potentially more realistic; standard rather uses something like a tracktive effort and calls it power. But it is much less demanding and looks even more pleasing (to me) on slopes and curves than the "realistic" code. Hence this was an asthetic decision.

The most important thing in mind is that Simutrans is a transport simulator, and lot of people do not use trains much (like some US players). However, experimental is very much train focussed.

The other thing standard aims for is as little micromanagement as possible. Hence no breakdowns, no sudden loss of transport when the other convois go faster.

If you want to go on realistic, maybe the new 3D game recently released is for you. Those approaches have to get scales more correct than SImutrans, because wrong scales are much more obvious the less abstract you are.

DrSuperGood

That said I would like some form of spacing feature in standard, preferably one that is semi-automatic. A big issue with standard is that you cannot have very long passenger runs because eventually all the convoys will clump together at one side of the line while the rest does not see a train in ages. This might not seem a big deal since the passengers will still come (unlike experimental) but is a big deal because it strains the stop capacity a lot. You can reach the point where there is sufficient capacity on a line but the irregular service results in temporary overcrowding at stops. I believe this is called the bus clump problem or something like that. Basically the convoys clump together so you can go hours without seeing any and then all of them arriving at once.

I have wondered how one could implement such a thing that will adjust un-aided for varying traffic and require no human intervention once started. Experimental's manual one requires far too much micromanagement for issues mentioned earlier and such precision is unnecessary in standard as the idea is to try and space convoys to a degree to prevent stop overcrowding instead of giving "good service".

JIT2 should have solved this with industries. The continuous flow of goods will mean that full loading convoys will move in a continuous and easy to balance way. The issue with stop overcrowding due to clump is only for continuous lines (no forced waiting at stops for goods etc). Such lines are common for passenger routes where you have multiple stops on a line with varying but similar passenger production/consumption.

I tried using the "wait at most 1/X months for load" feature to achieve this but last I tried it did not appear to work. It also suffers similar granularity issues to Experimentals schedule system does for low traffic routes (no 2.5 convoys per month, only 2 or 3).

Ters

Quote from: DrSuperGood on December 01, 2014, 01:46:00 AM
A big issue with standard is that you cannot have very long passenger runs because eventually all the convoys will clump together at one side of the line while the rest does not see a train in ages.

I have never had this problem with trains, only busses. Trains can actually be somewhat spaced with signals.

DrSuperGood

QuoteTrains can actually be somewhat spaced with signals.
Yes so you spend forever designing and placing signals to try and space them out. Then you add a few more trains to cope with growing demand and need to change the signals because you run out of blocks for them. In pak64 the best solution I found was to spam the one tram engine. It is practically free to run so you can just have almost a continuous loop of them.

However that still does not mean that an automatic spacing feature would not be useful.

gauthier

I always have this problem, especially when starting new games (few convoys because few passengers). I always try to space them using min. capacity or, in rare cases since it's not accurate enough, min. loading time; but it's difficult to get the right setting, also the "right setting" changes very quickly with towns growing up and bringing up more passengers.

I thought about introducing a clock (only at terminus stop to be less computationally expensive) to space convoys, but it needs to find out (by simulating or by statistics) the complete journey time of a line.

Parachute

Quote from: DrSuperGood on December 01, 2014, 06:16:17 AM
However that still does not mean that an automatic spacing feature would not be useful.
Exactly!

wlindley

For the record: Streetcars in Phoenix have a rule that they must stop in the center of the platform.  Even the subway in Boston has signs for "2-car Stop" and 4- and 6-car stop points which more-or-less center the train on the train on the platform.

DrSuperGood

QuoteFor the record: Streetcars in Phoenix have a rule that they must stop in the center of the platform.  Even the subway in Boston has signs for "2-car Stop" and 4- and 6-car stop points which more-or-less center the train on the train on the platform.
Trains in the UK (well all the stations I have seen recently) have to stop at the end of the platform as that is the only part they can see the camera displays to check if the doors are clear as they have no conductors.

Ters

Quote from: DrSuperGood on December 01, 2014, 06:16:17 AM
Yes so you spend forever designing and placing signals to try and space them out.

Not really. I don't know why. My trains are not perfectly spaced, but they are nowhere near the big convoys my busses sometimes group into.

Quote from: wlindley on December 01, 2014, 12:05:23 PM
For the record: Streetcars in Phoenix have a rule that they must stop in the center of the platform.  Even the subway in Boston has signs for "2-car Stop" and 4- and 6-car stop points which more-or-less center the train on the train on the platform.
Quote from: DrSuperGood on December 01, 2014, 03:46:53 PM
Trains in the UK (well all the stations I have seen recently) have to stop at the end of the platform as that is the only part they can see the camera displays to check if the doors are clear as they have no conductors.

Passenger trains in Norway tend to stop at the end nearest to the waiting room or entrance.

isidoro

For bus lines, I've observed that in RL the flow control is done at certain stations of the line (normally terminus stations, but not always).  The buses proceed as fast as they can until they reach one of those control stations, then probably wait some time before continuing if they have been too fast.

For Simutrans, that could be achieved in two ways I can think of:
1) An option similar to Min. load or Max. waiting time: min. waiting time since last convoy of this line arrived.  That would require to record for each station and line that serves it the last time a convoy arrived.

2) ST could calculate that time automatically and, in this second option, it would only be a check mark in the interface: automatic spacing.  ST would record the average time t for a convoy to go round the line and make each convoy wait at least t/N, being N the number of convoys of that line.

Nothing is perfect, of course, the problem remains when we have heterogeneous lines (made up of different types of convoys, some slower, some faster...)


Ters

If only I had some place where busses could wait without blocking traffic. I'm too modest to demolish city buildings, plus city cars tend to get into places they shouldn't and mess up even if I do get the stops away from the streets.

DrSuperGood

Quote1) An option similar to Min. load or Max. waiting time: min. waiting time since last convoy of this line arrived.  That would require to record for each station and line that serves it the last time a convoy arrived.
The last time a convoy departed should actually be recorded as part of the line schedule. That way it is directly with the relevant elements instead of needing other data structures. Also this is not automatically optimizing which adds annoying micro (but is better than nothing).

Quote2) ST could calculate that time automatically and, in this second option, it would only be a check mark in the interface: automatic spacing.  ST would record the average time t for a convoy to go round the line and make each convoy wait at least t/N, being N the number of convoys of that line.
And what when there is no timing information? Or how does it handle multi-year traffic jams that no one noticed (not spacing each convoy multiple months hopefully)? The timing measured would need to ignore the wait time added for spacing to prevent the possibility of constant incorrect feedback. The timing could be stored on the convoy itself and could be an approximation of several game ticks to trade space and range.

Another approach would be using a control algorithm on a slot based system. The idea is that the optimum rate would be one where any more causes slots to be missed. Missing a slot automatically causes the slot rate to be lowered. If all slots are filled after every convoy has gone around (a full cycle) then the slot rate can be safely raised. This might produce sub-optimal schedules (oscillation around the optimum point) but the result is probably good enough to fulfil its purpose in standard simutrans (1 missed slot is not an issue). For most purposes the rate could be "convoys per month" similar to experimental since there is seldom a case in standard where you want few convoys to be evenly spaced. Fractional amounts could possibly be allowed if the control algorithm can cope with them.

A minimum convoys per month number might be useful to handle situations such as multi-year long jams from causing vastly incorrect spacing and taking forever to correct.

isidoro

The idea can of course be refined.  The time interval between convoys can be estimated with the length of the route divided by an average speed to cope with the problem of initial settings or traffic jams.

Another possibility is what is done in Cities in Motion.  All lines must start in a depot (and thus we have another use for these in ST).  You buy a certain number of convoys for that line in that depot.  One convoy is issued at a certain interval of time.  When they reach the end of the line, they go back to the depot.  Thus, you have a stock of vehicles ready to be dispatched.  Of course, you can run out of them if they are not enough or there have been difficulties in the line.


DrSuperGood

Quote2) ST could calculate that time automatically and, in this second option, it would only be a check mark in the interface: automatic spacing.  ST would record the average time t for a convoy to go round the line and make each convoy wait at least t/N, being N the number of convoys of that line.
I was thinking about this earlier why I came up with my alternative idea instead of this and then I remembered. The problem with this approach is that the line can jam itself making it slower than it actually is because convoys blocked by other convoys of the same line will raise the average full trip time. An exception cannot simply be made "if stuck behind convoy of same line" because that would not factor in mixed traffic (many lines over same way) or if a jam was caused elsewhere (busy intersection that has been fixed). You will find with this approach it is easy to end up with a huge tail of convoys waiting behind the checkpoint stop with much fewer convoys than should be going around the line at any given time. Simply put, the checkpoint will because a bottleneck for convoys jamming in integer multiples.

You can only really timetable from the point of view of the stop and not the entire line. The stop only knows that a convoy from a certain line has arrived/waiting/left and not what other convoys are doing even if from the same line. If no departure slots are missed then there is a possibility that the departure frequency is too low (or it might be just right with convoys barely arriving as the slot comes). If a departure slot is being missed (convoy late) then there is a possibility the departure frequency is too high (or it might be just right but a convoy is running late due to random traffic). Based on the time a convoy spends waiting or the amount it was delayed for the next slot (even missing entire slots) you can apply a correction to the departure frequency.

The results may be imperfect and suffer from typical oscillations present in control logic (especially when exposed to a large change in trip time) but it would be better than nothing and fully automated. All computation could occur on convoy arrival/departure and all state could probably be held as part of the master schedule. Changes in convoy number or convoy type could be computed using basic approximation (double convoys double frequency, double speed double frequency) with the algorithm slowly correcting any error. Stiffness to change could be based on the number of convoys servicing the line and the frequency. A maximum delta change could be applied to prevent that "3 year jam" from causing a stupid schedule (it would limit the damage).

prissi

From the point of a transport simulator, letting full convois wait is against its purpose. Rather transport as much as possible. If the convois are not filled, you can anyway space them out using a maximum load and a waiting time. If the distance is too long to avoid bunching which leads to bad overcrowding, well cut the line into halves. Or use more and smaller convois.

Strategies to avoid overcrowding are for me one of the most interesting and motivating aspects of simutrans. Bunching or not does not matter for that.

DrSuperGood

QuoteIf the convois are not filled, you can anyway space them out using a maximum load and a waiting time.
Tried that on one of Fifty's summer servers. The result was the train never moved because for some reason the waiting time was being ignored (it just stood there waiting for 100% load even though I set it to something like max wait of 1/16 months). I need to retest in case the feature has been fixed in 120.1. If it did work it would be a valid solution.

Combuijs

It did work in the past, and I have used that strategy very often. It's a good one, the only disadvantage is that you need space for vehicles to wait in. But I feel that is part of the challenge. My favourite was 1/32, e.g. a month wait time.

I even used it a while for freight trains, but then with a longer wait time. It helps in the rare cases that a load less than 100% waits an awful long time for some reason. In the end I stopped using it, too less gain for two extra clicks for every line.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



gauthier

Quote from: prissi on December 03, 2014, 11:40:35 PM
From the point of a transport simulator, letting full convois wait is against its purpose. Rather transport as much as possible. If the convois are not filled, you can anyway space them out using a maximum load and a waiting time. If the distance is too long to avoid bunching which leads to bad overcrowding, well cut the line into halves. Or use more and smaller convois.

Strategies to avoid overcrowding are for me one of the most interesting and motivating aspects of simutrans. Bunching or not does not matter for that.
That does not work in most cases. If I want a line crossing a major city (biggest stations on the middle of the line), it is nearly impossible to space convoys using minimum load and minimum waiting time: applying these on terminus is irrelevant (and inefficient) since the main source of passengers is on the middle of the line, applying these in the middle of the line is impossible since there is usually no spare space to add platforms and it would lead to traffic jams, so it is nearly impossible to manage.

The main problem of minimum waiting time is that we can only choose values equal to month/(2^n), then if I increase loading time of one step, I divide the line's frequency by 2, if I decrease loading time of one step, I double the line's frequency ... that is obviously too unprecise. And I won't talk about interractions between minimum load/wait and multi-platform-choose-signaled stations.

Bunching on one line usually cause irregularities on networks, and one irregularity not seen by the player entails huge mess on the whole network (when I get that, I just remove all minimum wait/load from my lines and wait one year or two for the network to dispatch all the passengers in excess).

Convoy spacing is definitly what we need.

Ters

Quote from: gauthier on December 04, 2014, 07:31:09 PM
applying [minimum load and maximum waiting time] on terminus is irrelevant (and inefficient) since the main source of passengers is on the middle of the line, applying these in the middle of the line is impossible since there is usually no spare space to add platforms and it would lead to traffic jams, so it is nearly impossible to manage.

If vehicles shouldn't be allowed to drive at maximum speed, they have to wait somewhere, or cruise around the streets at slow speeds slowing down other traffic. Explicit support for convoy spacing will help on the micromanagement, but as far as I can see, the effects on other traffic can only be solved by temporarily removing vehicles that are ahead of schedule from the map (at least as far as other traffic is concerned). Sending them to the depot only makes sense when they are empty, which would normally be at the terminus.

isidoro

Quote from: prissi on December 03, 2014, 11:40:35 PM
From the point of a transport simulator, letting full convois wait is against its purpose. Rather transport as much as possible.
[...]

In RL, it isn't uncommon when convoys have a schedule.  It happened to me last week.  The city bus arrived early to one of those checkpoint stations and we had to wait five minutes, even though the bus was full, to be on schedule.  Incidentally, a passenger going to the next stop asked the driver how long will the bus wait at the stop, and knowing it, she left the bus and went on foot...

And in terminus stations passengers are obliged to leave the bus, so it is empty nonetheless.  Of course, you can ride it again, but you have to pay for another ticket then.

Ters

Quote from: isidoro on December 05, 2014, 12:35:08 AM
In RL, it isn't uncommon when convoys have a schedule.  It happened to me last week.  The city bus arrived early to one of those checkpoint stations and we had to wait five minutes, even though the bus was full, to be on schedule.

That seems a bit excessive, unless by full, you mean that all seats were taken, but that there was still room for standing passengers. Or that the bus was waiting for a connecting line, and that the bus was still full because passengers about to switch bus were reluctant to leave the bus and wait outside.

isidoro

No.  It was a regular city bus line.  It was rush hour.  It wasn't waiting for another bus, since it was an urban bus.  It was only waiting to be 14:15: time to leave that stop, incidentally in the middle of its schedule.  It was pretty full with a lot of people standing, although I wouldn't say that not a single person couldn't board.

If you think carefully, it makes sense, even if full.  Since one doesn't know where and when people will leave the bus, if the driver continues, the bus can reach the following stops (and some people leave the bus there) ahead of its normal time and other people expect the bus to arrive at those stations at a certain time...

You could argue that the bus could wait at those stations when some people leave until the scheduled time arrives, but as some people have already pointed out, not all stops in the line in a real city allows for a bus to stay there stopped.  It happens that those checking stops are real big ones with a parking place for different lines.


Ters

Quote from: isidoro on December 06, 2014, 12:05:44 AM
Since one doesn't know where and when people will leave the bus, if the driver continues, the bus can reach the following stops (and some people leave the bus there) ahead of its normal time and other people expect the bus to arrive at those stations at a certain time...

You could argue that the bus could wait at those stations when some people leave until the scheduled time arrives, but as some people have already pointed out, not all stops in the line in a real city allows for a bus to stay there stopped.  It happens that those checking stops are real big ones with a parking place for different lines.

Pre-emptive waiting makes sense if some stops are better for waiting at, and one can expect to pick up passengers afterwards. Busses I'm familiar with tend to first have a phase where they mostly pick up passengers, and later a phase where they drop them off (sometimes this is explicit in the schedule). Those that don't, rarely get particularly full and/or don't have the ability to get significantly ahead of schedule before completing the trip.

However, one of the issues brought up in other posts was that there wasn't room for the bus to wait where they needed to wait.

jamespetts

Returning to the original topic (having only just noticed this thread), as others have said, there are two versions because different people have different preferences as to the level of simplicity or complexity, and also whether particular features are desirable or not.

The timings in Experimental are actually very carefully calibrated on the basis of having two explicit timing scales: one macro scale (years and months) and one micro scale (minutes and hours). The micro scale implicitly exists in Standard, derivable from the vehicle speeds and an abstraction as to distance, but it is made explicit in Experimental. Dwell times, physics, waiting and spacing times and journey times are all calculated on the micro scale. I note the point that Dr. Supergood makes about the issues with the timing slots: those will have to be addressed in due course (and anyone who is willing to have a look at the coding and seek to improve it would be most welcome to do so).

As to trains stopping in the middle of the platform, it is fairly common in the UK for trains to do so, especially where there is a short train and a long platform with the entrance in the middle.

I don't agree with Prissi that Experimental is focussed solely or mainly on trains: a number of Experimental features are specific to aircraft, others to waterways, and still others to roads: the key differences (journey times and routing, passenger generation, comfort, range, etc.) are mode agnostic. Only a minority of features are rail specific (generally, those relating to railway signalling or certain cosmetic features such as the sequence of reversing convoys).
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.