Schedule windows improvements

[Yona-TYT]

The script does not work for me.

The previous script did not work for you? Strange, I only made minimal modifications, I will leave attached only the file that I have modified for you to replace it.

I could copy 10 convois, start 2, then the error message was "You must copy nine convoys."

When only the first 2 vehicles start it is due to inconsistency with the number of vehicles in circulation and the vehicle counter of the script.

However, I could open the schedule windo as many times as I like and nothing happened. It opened each time anew.

Are you setting the minimum load to 100% ?, you must leave it at zero for the routing list to be cleared.

[prissi]

How do I load the scenario afterwards? It just says now "scenario loading failed". (I have honestly no ideas on using scripts with simutrans, sorry).

[Yona-TYT]

(I have honestly no ideas on using scripts with simutrans, sorry).

Don't worry about it, I'm going to do my best to explain this well. (don't impart if that means having to use teamviewer.)

How do I load the scenario afterwards? It just says now "scenario loading failed".

The file "scenario.nut" is for you to replace the existing one in the directory "/simutrans/pak128/scenario/tutorial_pak128-beta".
The error loading is due to missing files. The scenario directory should look like the following image:

[Yona-TYT]

I have made a video capture, look here:
https://www.mediafire.com/file/2x3wcquf5y5cjwb/Capture-schedule-problem.webm/file

Edit.You can see in the scenario window the moment when the "all convoys" counter reaches 22.

Edit.I think I have a clue.
It seems to happen only when the map is clicked while editing the schedule and the function "is_work_allowed_here (pl, tool_id, pos)" is called, just at that moment the number of convoys increases.
I guess it should be checked in /dataobj/scenario.cc

Edit.--------------------------------------------------------------------------------------------------------------------------------------
I suspect this is not caused by the new schedule window, I am going to open a new thread in the scripts section.

[Dwachs]

This has nothing to do with scripting: Create convoy in depot, click schedule, now click on a wrong tile to get error message 'stop has to be on a way', close schedule window. Now the message appears 'convoy does not find route'. The convoy is not listed as being in depot in the vehicle list despite being there. It can also be selected in the depot. The step to click on a wrong tile is important, without it everything is as expected.

[prissi]

EDIT:
Ok, the window top event set the convoi state. However, this is not allowed in depots. Should be fixed in r9593

[Yona-TYT]

EDIT:
Ok, the window top event set the convoi state. However, this is not allowed in depots. Should be fixed in r9593

Mr. Prissi thank you very much for your patience with this on this!.
Vehicles are working very well now.

[wolfgang]

I tried the latest nightly (9795) and I like the new schedule windows. Just my two cents in this:

When changing a schedule, the vehicle should not stop like dead, causing a traffic jam behind it. Therefore I suggest two additional buttons: apply and cancel. So the player can change the schedule as needed, and the vehicle will follow its old schedule, until the "apply" button is pressed. Pressing "cancel" would reverse the changes.

[Yona-TYT]

Line button does not have auto alignment.

[prissi]

@Wolfgang
An earlier version of the patch was exactly like this, but received strong critics from the players. The stopping of the vehicles was a desired feature.

[Mariculous]

I'm still with that idea. The only thing that was missing is a simple "stop vehicle" button, as that is needed in some cases.
If I remember correctly, not being able to stop vehicles was the main objection.

[prissi]

Also when the vehicle drives on, the current items will change. However, this cannot be updated without changing the waiting time etc. in the top. So after the next waypoint/stop, the scheduel state will go to apply, even though nothing changed and would just try to send the vehicle back. There is no easy way around this.

[Yona-TYT]

There is strange behavior with timeout when saving and loading the game.

Process:

   
• Configure individual routing and set load to 100% and timeout a value of 16, and close the window.
• Save and load the game again and you will see that the value of the waiting time changes, in my case to 31.

[wolfgang]

I understand that some players prefer changing a schedule while the vehicle is on halt, for example if you don't want the current load to reach the next station. But the traffic jam caused by this stop can lead to more trouble then one more load of goods at the wrong place, if making the changes takes you too long, especially when trains are involved: one train stopping in the middle of a track can cause a whole cascade of none moving trains because of signals that make the following trains stop.

I see several possible solutions to this problem:

1. Player must create a complete new schedule first, and then assign that new schedule to the appropriate vehicle, instead of changing the current one.

2. Put the whole game on pause automatically, whenever the schedule of a vehicle is changed, so there won't be any blocked roads and tracks. That function should be optional, of cause.

3. On roads, make the halting vehicle stop a bit to the street's edge and let the following cars overtake it. That won't work for trains, though, unless you send the train onto some virtual holding track.

I agree that this is not easy to solve. But at least, don't stop the vehicle as soon as the player opens its schedule tab. Some times you just want to take a look at it. If a stop is unavoidable, do it as soon as the first change is made.

[prissi]

Most of the heavy users use lines, and just occasionally schedules. So the pressure is not as big for many users.

Stopping everything is not possible in network games (or will be very disruptive). As single player press p before editing ...

You can look at the schedule as another user (apart from public player). Then the vehicle in question should not stop. The logic around this is hopefully working, but additional testing is welcome.

Editing the schedule while the vehicle is driving has two problems. When the vehicle advances, the current entry in the list cannot advance. Or one would not be able to send vehicles to another destination, because the program cannot guess if the difference is intentionally or just due to driving on.

[wolfgang]

I can see your points for stopping a vehicle while editing its schedule there, Prissi, and I agree it wouldn't be easy otherwise.

On the other hand: you mentioned network games, which I haven't played yet. What happens, if one player parks a vehicle next to another player's loading station, opens the schedule and leave it open? That vehicle would stop, blocking the opponent's loading station as long as the schedule is opened. So editing a schedule could be used to harm another player. Wright?

What about these suggestions:

- vehicles stopping on roads while the schedule is edited should be overtaken by other vehicles, just like a bus at a station

- trains could virtually be sent onto a holding track, eg, by making them semitransparent while editing, making block signals ignore that train, thus enabling other trains to "overtake" the edited train

And just for the funny side: as a matter of fact, I never use planes in my games. What happens when you edit a plane's schedule? Does it stop in mid air? :-D

[Ranran(retired)]

- trains could virtually be sent onto a holding track, eg, by making them semitransparent while editing, making block signals ignore that train, thus enabling other trains to "overtake" the edited train

I think it is easy to abuse. Express trains can overtake slow freight trains on a single track by abusing schedule changes.

[michelstadt]

For me as a single player stopping is not a problem. Sometimes it might be good if vehicles could advance while editing, but as they don't behave like this, I decide if I stop the game meanwhile or not. Just my two cents.

[Matthew]

On the other hand: you mentioned network games, which I haven't played yet. What happens, if one player parks a vehicle next to another player's loading station, opens the schedule and leave it open? That vehicle would stop, blocking the opponent's loading station as long as the schedule is opened. So editing a schedule could be used to harm another player. Wright?

The evidence from multi-player games shows that malicious behaviour of this kind almost never happens.

[Isaac Eiland-Hall]

Express trains can overtake slow freight trains on a single track by abusing schedule changes.

I would almost say that if someone wanted to work that hard to abuse the system - as it would be rather extreme micromanagement - I'd almost say let them because if they're willing to work that hard to "cheat", that's a lot of work. Sure, not in one specific case, but constantly monitoring your entire network......

[Matthew]

Another thought. Opening the schedule is the only way to stop vehicles. This is especially important in multi-player games, which cannot be paused. I use this all the time, for example, to recover from jams. If opening schedules did not stop vehicles, there should be a 'Stop' button in the Vehicle Window.

Actually there should probably be a Stop button in the Vehicle Window anyway....

[Manche]

The schedule windows seems totally different from the other dialogues. Also the line management window is a monster. Hence I propose the following:

Schedules are now accessed under a "schedule" tab in the convoi window. No extra window popping off. Make editing schedule much easier.

Lines get their own window, with schedule/statistics/stations/convoi tabs. So one can easily compare lines next to each other.

The line management window will become just a list of lines.

The will reduce the clutter of windows on the screen and remove the annoying extra scrolling when editing a schedule, because this window unfailingly pops up on the stop one wants to add ...

Any comments?

I agree.

But we need to consider to those two points.
- Sometimes, insert some stations between in existing that.
- Each buttons need to show what it does. e.g. Close button has a mark 'X'. Referenced Yona-TYTs post, but I can't find where is the close button.

I thought this is the one of the most biggest change in simutrans history. Change is simple, but explain is not.
Vehicle window has so heavy amount of information. One question, can player adapt to modified gui, w/ short period?

[prissi]

There will be a delete button with window closing cross in r9669.

[Yona-TYT]

There will be a delete button with window closing cross in r9669.

Wow nice!.

Edit.
I would like to suggest that the new button take the appearance from the theme file, I explain:
-- If the theme includes an "X" button, it will overwrite the "closing cross". 
-- If the theme does not include an "X" button then we use the "closing cross" instead.

[prissi]

From r9771 schedule have now absolute departure times, when the minimum load is set to zero but a waiting time is given.

Since the waiting time is relative, 14 days 14h 11min will actually depart on the 15th at 14h and 11min in a month with 31 days. If the month is shprter, departure is slightly off.

If the convoi arrives at such a scheduled stop within half a month after \the scheduled departure time, it is assumed that the convoi is late. Otherwise it will wait for departure. Thus means that the maximum waiting time for such a scheduled departure is half a month.

Also in order to save departure times properly, I had to increase the savegame version.

[Yona-TYT]

@Prissi, a little remark, if the convoy window is open but positioned in a different tab like "Chart", it should go back to the "Schedule" tab if the player presses the [Schedule] button in the depot window.

[prissi]

The double convoi window bug is fixed in r9776

[Yona-TYT]

The double convoi window bug is fixed in r9776

Thanks, now it works fine  .

[Roboron]

A couple of thoughts on this:

1 - A little explanatory text to explain the format of the date to be introduced would be welcome (specially for new users). For example "(days - hours : minutes)", or if you want it even more concise "(dd-hh:mm)".
3 - Having "Depart on" on a different line from "Minimum load" would also add some clarity.
2 - I don't like the "Depart on" option changing suddenly to "Depart after" when certain conditions are met ("Minimum load" is not set to "0"). This is uterly confusing (and I have been myself confused by this). Furthermore, I don't understand why we can't choose between both of them, no matter what the value of "Minimum load" is. Imagine a scenario where:

- I want a vehicle to leave the station if:
a) Minimum load is 50%.
b) An absolute departure time.

Currently this is only possible if the minimum load is 0%, otherwise you can only specify relative departure time. Why? That doesn't make sense to me. If we are truly going to have both options, I suggest making a radio button to select between absolute/relative departure time, independently from minimum load.

[prissi]

An absolute departure time makes sense with schedules. Then a random departure on reaching the laoding level will ruin your balanced schedule.

If you optimise for money, minimum load with a relative waiting intervall (to avoid blocking) is the best option. Then an absolute departure time would not make sense. Otherwise it may wait for an entire month or two seconds, depending on arrival.

Please give an example when you would need an absolute departure time and minimum load.

Instead of minimum load zero using a combobo was also considered. That may reduce your confusion, I think.

[Mariculous]

Please give an example when you would need an absolute departure time and minimum load.

Whenever you want to combine the best out of these two worlds:
Think of absolute departure times as potential time slots that can be used without slowing down faster vehicles.

In paksets that make use of monthly maintenance or use high purchase costs, mixing different types of transport on the same tracks can even be more economically than "wait for load" as schedules can ensure that expensive fast trains won't be slowed down by a slow train in front, which means more kilometers per month, thus less trains are needed to carry the same amount of goods, pax or mail, thus less monthy costs and less purchase costs.

But then there is a conflict with freight trains as it's often still more economic to run these on load rather than running on a schedule.
This conflict can be solved by using "wait for load" and scheduled time slots, which means "Wait for at least x%, then pick the next assigned slot"
Surely there's no mechanism to ensure that such a slot is taken by only one vehicle, but usually there are many free slots just behind a fast train before the next fast train catches up, so this isn't a big issue and in any case, it's still better than running entirely randomly into a scheduled network.

The same way adding a "maximum wait time" to the above might make sense:
Wait for x% load.
Whenever the load is reached or the maximum wait time exceeded, depart at the next scheduled time slot.

[Andarix]

...
Please give an example when you would need an absolute departure time and minimum load.
...

time


minimum load and time


no set load and time

[prissi]

Whenever you want to combine the best out of these two worlds:
Think of absolute departure times as potential time slots that can be used without slowing down faster vehicles.

In paksets that make use of monthly maintenance or use high purchase costs, mixing different types of transport on the same tracks can even be more economically than "wait for load" as schedules can ensure that expensive fast trains won't be slowed down by a slow train in front, which means more kilometers per month, thus less trains are needed to carry the same amount of goods, pax or mail, thus less monthy costs and less purchase costs.

But then there is a conflict with freight trains as it's often still more economic to run these on load rather than running on a schedule.
This conflict can be solved by using "wait for load" and scheduled time slots, which means "Wait for at least x%, then pick the next assigned slot"
Surely there's no mechanism to ensure that such a slot is taken by only one vehicle, but usually there are many free slots just behind a fast train before the next fast train catches up, so this isn't a big issue and in any case, it's still better than running entirely randomly into a scheduled network.

The same way adding a "maximum wait time" to the above might make sense:
Wait for x% load.
Whenever the load is reached or the maximum wait time exceeded, depart at the next scheduled time slot.

This waiting while not filled and then depart one the next slot does not work well with Simutrans. The extra waiting time will let extra goods pile up and reduce production a lot. Due to further production while waiting to reach the slot, all convoys of that line in that station will load and depart at the same time, leading very much to bunching of goods. Furthermore, if that combination is really desired, there could be a one tile "waiting halt" after the main station before joining the passenger rail line to wait for the next slot.

To be useful, one would need more than a single departure time, i.e. allow many slots at one stop. I originally planned for this, but in the end did not add it.

[Mariculous]

Tbh, I have no idea of how schedules work in standard.
I assumed there is a frequency and an offset to define the schedule slots as in extended, just encoded differently.
Further I assumed that the same schedule slots cannot be used by multiple vehicles of the same line.
That assumption might have been wrong. If the schedules are always running one departure per month, then it won't work well in simutrans standard.
Restricting schedules to one departure per month seems much to unflexible to setup anything economically useful, especially when playing in a world with large bpm values.

[Andarix]

For me at the moment it looks like there is only one time for the whole month.

Would mean that I would need 4 lines for 4 departure times.
Because a departure time for the whole month should often not be enough.

To make matters worse, I have different advertisements in German. The times after the stops are in English in 12 hour format. But above I set the 24 hour format.