The International Simutrans Forum

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?

Sounds good. The pop-up schedule window is still needed for schedule editing  at depots. Maybe this can be changed as well?

I like suggested changes, specially:

Quote from: prissi on October 21, 2020, 01:44:06 PMSchedules are now accessed under a "schedule" tab in the convoi window. No extra window popping off. Make editing schedule much easier.

Having to move/resize all those extra windows to edit a schedule is annoying, so this change is appreciated.

Quote from: prissi on October 21, 2020, 01:44:06 PMSchedules are now accessed under a "schedule" tab in the convoi window. No extra window popping off.

I like the tabs generally, but I am unsure about one point. When will changes made to the schedule list be applied?
It feels a little unfamiliar to apply these when selecting a different tab. Requiring to close the window doesn't feel like a good option as well.
An explicit apply (and discard/reset) button might be an option and it would solve an isue I face frequently. When I make some changes to a line, I then notice I do not want to apply these changes, as I messed it up. As soon as I close the window, these changes will be applied. The only way to discard these is killing simutrans or  the network connection, which usually is not a good option as well.

Quote from: prissi on October 21, 2020, 01:44:06 PMThe line management window will become just a list of lines.

To me, this is fine, but bear in mind some players use rather unpreciese line names and might use the list to identify their lines.
Not sure if that's a reason to keep the stop list or some basic informations in that window. In any case, the vehicle list can be kicked out.

Anyways, this change is appreciated.

I support the apply/discard schedule idea. Another nice-to-have might be to support drag&drop for schedule entries to re-arrange them. Also, IMO the Minimum load and month wait time can be duplicated for each schedule entry so you can see and set them all at once. See my masterpiece of art in the attachment. ;)

Since I wanted to add departure times too, I highly doubt this will work out with the available space.

Departure times?
You mean finally schedules arriving in standard?
That's one of only 3 features I really miss in standard!

SInce many people play Simutrans like a railwys, I finally think this should be there. It is useless for profit maximisation though.

Here is a patch with the requested apply and reverts buttons too. But this gives too many buttons ... alternatively the schedule woudl be updated when leaving the tab or closing the window.

I wonder it there shoudl be a seperator below the four top buttons. Or if these four "dangerous" buttons should go rather to the bottom below the schedule.

I think one could remove the follow button, since there is a follow button in the title bar. Also one could remove the servers line since the same information is in the schedule tab.

Any comment appreciated.

What if we replace [remove] with an "X" at each of the waypoints? , same as seen in the save games list.

===============================

Another idea is you can add a filter that replaces the 3 buttons (add, insert, remove), and combines them in a drop-down list.

Quote from: prissi on November 02, 2020, 02:45:17 PMI think one could remove the follow button, since there is a follow button in the title bar. Also one could remove the servers line since the same information is in the schedule tab.

I agree; this would also free up space for the schedule tab. Maybe do it like this: Single click centers the main view on the current position of the vehicle, and double click additionally follows the vehicle?

Quote from: prissi on November 02, 2020, 02:45:17 PMBut this gives too many buttons

What about just having "add stop" and "apply/revert schedule"? The latter two can be disabled until the schedule is actually changed. Schedule entries can be added as normal, then drag&dropped to the right position, and removed via an "X" button for each schedule entry like Yona-TYT suggested.
Personally, I do not like that schedule entry conditions are (still) separate from the actual schedule entry, since one has to click on each entry to see its wait time. What about something similar to this Factorio blog post (https://factorio.com/blog/post/fff-279), i.e. multi-line schedule entries? However, I do not know how feasible this is with the current UI code.

Drag and drop is a little tough to handle, at least with the GUI code as it is. But I thought too that adding and inserting should go away, probablz just inserting after current mark and up and down arrows next to delete to move entries around.

Easier is a combobox or a button that changes text. I think I will go for that right now

I think the [remove now] button should not be there, it makes more sense to me than this in the details tab.

But withdraw and and remove buttons should be close together. And withdraw sets no loading, which is a schedule action ....

My intention is to prevent the player from mistakenly pressing the remove now button, however I'm not sure what would happen if this happens in the new interface.

I suggest that when you click the button it is held down (similar to the "go to depot" button) and the changes are applied when changing tabs or closing the vehicle window.

Another interesting idea (I think) is to keep the button pressed for a few seconds until the vehicle is removed.

The same happens as when you press this before.

r9355 has the current state, so you can test it. It worked for me for many situations, but it may be still very buggy.

Next is a proper line window with schedule, charts, convoilist and haltlist ...

mmh

gui/schedule_list.cc line 84

Quotesort_type_c.new_component<gui_scrolled_list_t::const_text_scrollitem_t>( translator::translate("Free capacity"), SYSCOL_TEXT) ;

Can the existing text Free Capacity be used?

r9381

probably a typo

(https://forum.simutrans.com/index.php?action=dlattach;topic=20444.0;attach=29386;image)

After accepting the stop, the list is reduced very much.

Thanks, I still need to add the texts to the translator.

We have a few concerns about this feature.
- Forced departure of vehicles on standby or stopping a vehicle once it is no longer able to organize its operation.
- The "Removed now!" Button is placed in a place where you are likely to accidentally press it.
- The operation of the route editing screen is complicated and may be confusing to beginners.
We are concerned about these three points.

Forced departure (no load) should work as before. Maybe "Forced departure" and "Stop" should get their own buttons. Before stopping was a left over side effect of the ancient system, and was not needed since the schedule windows operated on a copy of the actual schedule since ever.

Yes, the remove now button. I was thinking of leaving it with the convoi, but the withdraw button (which is the remove now on empty vehicles) should be rather with the schedule, because "no load" is a schedule operation and will cancel withdraw.

The line list is like the convoy list. You click on an entry and the detail opens. It is different from before, but it is now consistent to all other list windows in Simutrans, where a click opens the respective detail window.
I will try to improve usability by trying to open the new line window next to the line list windows.

I saw the nightly r9382. When the traffic arrangement is needed, such as the case that vehicles are deadlocked, how can I change the stop_index of the vehicles? Even though I selected a specific schedule entry in the schedule editing window called from a depot window, I could not change the next stop of the convoy.

As of schedule editing, the entries of "add", "insert", and "remove" are switched by pressing the single button. However, I think this is not user friendly, since it is quite doubtful that players can immediately recognize that they should press the "Add" button to switch to "insert" or "remove" mode. IMO, "Add", "Insert", "Remove" buttons should be shown separately as they are in 122.0 stable.

For the line list window, I think that at least the stops of the line should be shown in the line list window. Players often omit the naming of lines, thus showing only line names may cause confusion. In 122.0 stable, the stops of the selected line are shown below the line list. So players can understand the route only with moving the cursor. However, with the current design, players have to click the line, and select the stops tab with a mouse, just to grasp the route of the line. I think this can be pretty annoying.

To be honest, I think there is no need to change the design of line list window. Although your changes increase the consistency in window design across the other windows, making the line list window too simple can cause the problem as I described above.

r9381

If you open a line in the line list and close the window, you cannot open the same line again.

Another Problem

The halt cursor remains after a line is created. If you then click, Simutrans closes without comment.

First, the old window had to go, since it does not scale with the theme.

@THLeaderH
Interesting, the stop display was for me the most useless ever.

About the mode, probably a combo box is better.

The rest are bugs, which I will address.

Schedule editing in the convoi-window does not work (apply / insert stop does not set the tool).

The crash should be fixed in r9392.

Should work better with r9397.

Also the line from line list will open right to the line window. Changing next destination worksa now again for convois too.

The only thing missing is the stop function and maybe a drive on button, which just skips the current waiting and advances the schedule to the next entry. Maybe this should get a "Cruise contro" tab, with the other four buttons from the schedule tab?

In line list: with r9400 one can reopen line window after closing it

Hello, I have tried stndard after long playing extended, and found out that setting the convoy schedule is quite buggy (in nightly). Is there some bigger change just in progresss? Or should I test and report specific problems? Also, previously the retire "button" meant  "unload and go to depot"; while now it is "unload and sell on spot" which was "withdraw" button. Or at least it is so in extended... Some consistency would be nice.

Retire is unload and sell when empty. So if you retire an empty convoy, it is sold on the spot. Maybe extended changed that, but there is the button "Go to depot" which does what you want.

And please report problems, since my quick test had everything working for me.

Quote from: prissi on November 19, 2020, 12:27:19 PM
Retire is unload and sell when empty. So if you retire an empty convoy, it is sold on the spot. Maybe extended changed that, but there is the button "Go to depot" which does what you want.

But "go to depot" does not unload before...

Quote
And please report problems, since my quick test had everything working for me.

I'll check with latest nightly

But you will still get reimbursed for delivery to the depot ...

Quote from: prissi on November 20, 2020, 01:02:34 AM
But you will still get reimbursed for delivery to the depot ...

:o :thumbsup:

Quote from: prissi on November 19, 2020, 12:27:19 PMAnd please report problems, since my quick test had everything working for me.

In the schedule list - the new line button is grayed out. It does not matter if I select "All" tab, or some specific transport mode tab. Also there is no way to delete unused schedule. When changing schedule, one has to "apply" schedule, which was not needed before.

Also having the appy/insert/delet switch as a button is counter intuitive (at least for me). A combo box is IMHO more suitable. Clicking a button I would expect to do something (eg. it is fine for copy backwards to be a button), but not just switch mode of what is happening. But this may be just because I'm used to the way this is done in extended.

I'm used to create schedule when buying the first convoy for it. So, go to depot, buy a new vehicle, click on schedule, click on stops, adjust loading times, and in the combo box on top promote to line. Hmmm, line dialog opens with everything as I want. Fine, close it. Close the vehicle's schedule. Still "not assigned to line". Check the combo box, select the new line, but some other schedule appears. Close. In the depot the new line cannot be chosen from the combo box.

I admit, some of the issues may be connected with the fact that I'm not used to click "apply" after each schedule modification. Is that something new?

The apply button was requested to allow to revert a schedule. However, it is entirely possible to apply the schedule upon closing/changing the tab.

The combobox is indeed better. In the new lien window, I used combobxes as well.

deleting line is in the line window under the convoi tab.

The rest works, if one presses apply.

Quote from: prissi on November 21, 2020, 12:12:19 PM
The apply button was requested to allow to revert a schedule. However, it is entirely possible to apply the schedule upon closing/changing the tab.

Wouldn't it be sufficient then to have only the revert button, and auto-apply when closing the window as before? I don't know how long is this change there, whether "standard" players are already used to the apply button or not. For me it is one more click that I'm not used to...

Quote
deleting line is in the line window under the convoi tab.

Found it... I did not expect it there. I did not even notice the tabs before. I was quite fine with the old line dialog as it was....

This means to move the convoi deletion buttons back to the details tab. Maybe no the worst place. Please try r9430, which is liek the old, i.e. actumatically applies schedule and stops convoi while applying.

That is better. The flow for depot - buy vehicle, set schedule, promote to line is smooth now. The only problem is, that after closing the line and schedule windows, the depot still says "no schedule". But if I reopen the schedule, it is there, even with the new line mentioned. But the depot does not recognize the schedule until the depot window is closed and opened again. Even then it says the vehicle has "individual schedule", and not the newly created line. But sending the vehicle out of depot works and it goes on the intended line.

Is it possible to not stop the convoy when I switch to the schedule tab? That is not very nice (and especially if ported to extended - it will switch vehicles to drive by sight). I admit that in this case the apply button would make sense. Or an edit button, that would stop the vehicle, enable editing, and change itself to apply/revert button. Or better if editing the schedule would be possible without stopping the vehicle. And it will stop only after leaving the dialog/tab.

Switching between tabs should not affect the convoy in any way. Also there used to be information about the line a vehicle is running, with a link (triangle) to the line management, where one could examine the line.  Now there is only a link to Edit the line, but not to view it. Would it be appropriate to show the line (or info that the vehicle has individual schedule) in the common part, below the destination line?

And one more thing - I tried editing the schedule. Added one more stop and reverted. At that moment the invisible window containing the list of stops shrunk to minimum, so only two stops were visible, an scrollbar (that was not shown before) appeared. See scrreenshot

 ??? in the past ist was possible to stop a vehicle, just open the schedule windows

it is no way to stop a vehicle now  :-[

Quote from: makie on November 23, 2020, 08:47:23 PM
??? in the past ist was possible to stop a vehicle, just open the schedule windows

it is no way to stop a vehicle now  :-[

It is - just open the schedule tab of the convoy. It just is imho not intuitive. I'd not expect switching tabs to do anything. The previous way of clicking on button that opened the schedule was imho more inutitive (or maybe I just got used to it)

*Hm* now it works. (with Rev 9433)

but it has not yesterday

Maybe a special constellation. If it works this way, it is ok. 

Somehow my answer was not registered.

Your workflow is somewhat broken. If you want to create a new line, then there is the new line entry in the line selector. That the promote to line button works for the convoi is rather luck ...

Changing the schedule while driving is difficult, because this is also the place to change the next stop in the schedule. However, for inserting operation the current entry must be changed. Or when the window is open for some time, the current entry is advanced. (Ok, as long as there are zero edits, the current entry could advance in the schedule tab too.) But if there was any edit, then there is no chance of updating it, because the intention is lost.

One way out could be that the current stop cannot be set from the schedule, rather there would be a "advance current destination" button.

Also there was complaints about not being able to stop convois, so I introduced it again. If not stopping, we may need again a convoi stopping button.

Perhaps just a description on the tab would be enough - "edit schedule (stop convoy)"  but it is quite long...

Before you had to click the schedule button to see the schedule, and that dialog usually popped up just where you wanted to add the stops. Hence the change.

But you are right, the line could be shown again.

EDIT: I forgot, the small area show be also fixed by now.

I partially reverted the r9462, which moved the call to set_tool. At that new place, the call is ignored (as settool does nothing during loading).  I also noticed that the schedule tool is always active when convoi window is open. Imho it would be more intuitve to activate the tool only if the schedule tab is open.

If one opens convoy window and schedule tab, then the convoys seem to be stuck in 'schedule changed' state and do not move.

Edit: schedule_t::start_editing is not called when opening convoy info

Edit2: applied some fixes, but do not know whether these are correct. At least, the nightly gets closer to playable.

If you send a vehicle to the depot and close the vehicle window, the vehicle forgot the depot and continue in the scheduled plan.

If you open a vehicle window, the mouse cursor turn to add stops to the plan. This should be only if the scheduled plan tab is open.

I did a brief test on r9482, and faced the following problems.

• As makie reported, the mouse cursor is the "add stop" mode when you just open the convoy window. "Add stop" cursor is on even after the convoy window is closed.
• When you applied a line to a convoy in the depot window and make the convoy start from a depot, the convoy seems to be stuck in 'schedule changed' state.
• The game sometime crashes when I closed the convoy window.
• When you change the tab in the convoy window or close the convoy window, the schedule proceeds or goes back.

Apart from these issues, I think some considerations are needed for UI design.

• You can only "add" a schedule entry at as the last entry. Inserting a stop entry in a specific location is an operation that is often done, but doing the operation is not so convenient with the current UI.
• The "delete line" button is in "vehicle list" tab of a line info window. Deleting the line is not a vehicle related operation, so I think the button should be in the line list window.

Send to depot should not be overwritten anymore. However, sending a convoy to depot and then change into the schedule tab still leads to problems.

@THLeaderH: I thought I had fixed the crash in 9479 :/ Can you post how to reproduce it? "add stop" should not be on after closing window. It sounds like your test was with some older revision?

Did some more fixes: schedule tool no longer active when convoy-window is opened. Also the vehicles will not wait a long time before doing route search and proceed when convoy window was open. (r 9488, 9489).

Please test with r9489 again

Quote"add stop" should not be on after closing window.

You are right. It was my misunderstanding.

QuoteI thought I had fixed the crash in 9479 :/ Can you post how to reproduce it?

In my environment with r9482, I created a line with the line list window, set stop entries, then close the line info window. When I close the window, the game crashes. I got the following backtrace at that time.

sim(44422,0x700000888000) malloc: Incorrect checksum for freed object 0x100f0e088: probably modified after being freed.
Corrupt value: 0xd0000000100f1801
sim(44422,0x700000888000) malloc: *** set a breakpoint in malloc_error_break to debug
Process 44422 stopped
* thread #11, name = 'com.apple.NSEventThread', stop reason = signal SIGABRT
    frame #0: 0x00007fff6b12f33a libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff6b12f33a <+10>: jae    0x7fff6b12f344            ; <+20>
    0x7fff6b12f33c <+12>: movq   %rax, %rdi
    0x7fff6b12f33f <+15>: jmp    0x7fff6b129629            ; cerror_nocancel
    0x7fff6b12f344 <+20>: retq
Target 0: (sim) stopped.
(lldb) bt
* thread #11, name = 'com.apple.NSEventThread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff6b12f33a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff6b1ebe60 libsystem_pthread.dylib`pthread_kill + 430
    frame #2: 0x00007fff6b0b6808 libsystem_c.dylib`abort + 120
    frame #3: 0x00007fff6b1ac50b libsystem_malloc.dylib`malloc_vreport + 548
    frame #4: 0x00007fff6b1bdd27 libsystem_malloc.dylib`malloc_zone_error + 183
    frame #5: 0x00007fff6b1a0f1b libsystem_malloc.dylib`tiny_malloc_from_free_list + 1801
    frame #6: 0x00007fff6b1a0297 libsystem_malloc.dylib`tiny_malloc_should_clear + 288
    frame #7: 0x00007fff6b19f0c6 libsystem_malloc.dylib`szone_malloc_should_clear + 66
    frame #8: 0x00007fff6b19dd7a libsystem_malloc.dylib`malloc_zone_malloc + 104
    frame #9: 0x00007fff6b19dcf5 libsystem_malloc.dylib`malloc + 21
    frame #10: 0x00007fff30f15a35 CoreFoundation`CFRunLoopPerformBlock + 617
    frame #11: 0x00007fff2fb68ed4 HIToolbox`PullEventsFromWindowServerOnConnection(unsigned int, unsigned char, __CFMachPortBoost*) + 570
    frame #12: 0x00007fff2fb68c72 HIToolbox`MessageHandler(__CFMachPort*, void*, long, void*) + 48
    frame #13: 0x00007fff30f5fb05 CoreFoundation`__CFMachPortPerform + 250
    frame #14: 0x00007fff30f31304 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
    frame #15: 0x00007fff30f31250 CoreFoundation`__CFRunLoopDoSource1 + 541
    frame #16: 0x00007fff30f2fd79 CoreFoundation`__CFRunLoopRun + 2270
    frame #17: 0x00007fff30f2ee3e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #18: 0x00007fff2e342954 AppKit`_NSEventThread + 132
    frame #19: 0x00007fff6b1ec109 libsystem_pthread.dylib`_pthread_start + 148
    frame #20: 0x00007fff6b1e7b8b libsystem_pthread.dylib`thread_start + 15


It seems to be a runtime error issued by macOS because of modification of freed objects.

I think old_schedule might be no longer valid after changing a line.So the call to finish editing should not happen in gui_schedule. This needs to done via a tool or will lead to immediate desync.

r9491 should fix this.

Yes, you are correct. In order to do this, call_convoi_tool('g'... ) needs to be called.

A crash report with r9493. To reproduce this,

• Open a existing line info window and the schedule tab.
• Add a new schedule entry.
• Move to the chart tab.
• Go back to the schedule tab.
• Press the "Revert" button. Then the game crashes.

backtrace:

Process 62273 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x28)
    frame #0: 0x00000001000c0cd5 sim`gui_schedule_t::action_triggered(this=0x00000001290413b8, comp=<unavailable>, p=<unavailable>) at gui_schedule.cc:583:34 [opt]
   580 delete schedule;
   581 schedule = NULL;
   582 }
-> 583 schedule = get_old_schedule()->copy();
   584 stats->schedule = schedule;
   585 stats->update_schedule(true);
   586 update_selection();
Target 0: (sim) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x28)
  * frame #0: 0x00000001000c0cd5 sim`gui_schedule_t::action_triggered(this=0x00000001290413b8, comp=<unavailable>, p=<unavailable>) at gui_schedule.cc:583:34 [opt]
    frame #1: 0x00000001000c0e0d sim`non-virtual thunk to gui_schedule_t::action_triggered(gui_action_creator_t*, value_t) at gui_schedule.cc:0 [opt]
    frame #2: 0x00000001000b2053 sim`button_t::infowin_event(event_t const*) at gui_action_creator.h:32:11 [opt]
    frame #3: 0x00000001000b2037 sim`button_t::infowin_event(this=<unavailable>, ev=0x00007ffeefbfdc10) at gui_button.cc:276 [opt]
    frame #4: 0x00000001000b5b5b sim`gui_container_t::infowin_event(this=0x000000010cf34ba0, ev=0x00007ffeefbfdcb0) at gui_container.cc:201:23 [opt]
    frame #5: 0x00000001000b5b5b sim`gui_container_t::infowin_event(this=0x00000001290413b8, ev=0x00007ffeefbfdd50) at gui_container.cc:201:23 [opt]
    frame #6: 0x00000001000b5b5b sim`gui_container_t::infowin_event(this=0x0000000129042aa0, ev=0x00007ffeefbfddd0) at gui_container.cc:201:23 [opt]
    frame #7: 0x00000001000c7e3b sim`gui_tab_panel_t::infowin_event(this=0x0000000129041270, ev=<unavailable>) at gui_tab_panel.cc:162:29 [opt]
    frame #8: 0x00000001000b5b5b sim`gui_container_t::infowin_event(this=0x0000000129041000, ev=0x00007ffeefbfded0) at gui_container.cc:201:23 [opt]
    frame #9: 0x000000010010317a sim`gui_frame_t::infowin_event(this=<unavailable>, ev=<unavailable>) at gui_frame.cc:132:34 [opt]
    frame #10: 0x0000000100179d53 sim`check_pos_win(ev=0x00007ffeefbfe178) at simwin.cc:1556:20 [opt]
    frame #11: 0x00000001002b625f sim`interaction_t::process_event(this=0x000000010b16be80, ev=0x00007ffeefbfe178) at siminteraction.cc:366:5 [opt]
    frame #12: 0x00000001002b676b sim`interaction_t::check_events(this=0x000000010b16be80) at siminteraction.cc:439:7 [opt]
    frame #13: 0x000000010031f81c sim`karte_t::interactive(this=0x00000001247afe00, quit_month=2147483647) at simworld.cc:7238:17 [opt]
    frame #14: 0x00000001002c4424 sim`simu_main(argc=4522360, argv=0x0000000100450174) at simmain.cc:1520:9 [opt]
    frame #15: 0x000000010035dc3e sim`sysmain(argc=6, argv=0x00007ffeefbff680) at simsys.cc:1124:9 [opt]
    frame #16: 0x00007fff6afe7cc9 libdyld.dylib`start + 1


Good catch. Yes the schedule has to be properly initialised again upon clicking on the tab. However, in networkgames there might be still a short moment, when this is the old schedule. Hopefully fixed in r9495

if i "remove now!" a train that is running, then the game crash

Program terminated with signal SIGSEGV, Segmentation fault.
#0  schedule_t::get_current_entry (this=0x0) at gui/../dataobj/schedule.h:98
98              schedule_entry_t const& get_current_entry() const { return current_stop >= entries.get_count() ? dummy_entry : entries[current_stop]; }

Indeed, since the schedule editing state is only with active schedule tab, applying the schedule must be only then when this is open. There were some more issues, when changing player while editing. I hope, I caught most of them in r9497

I get this compiler warning:

gui/convoi_info_t.cc:264:28: warning: logical not is only applied to the left hand side of this comparison
      [-Wlogical-not-parentheses]
        if(  !cnv.is_bound()  ||  !cnv->get_state()==convoi_t::EDIT_SCHEDULE  ) {

I do not know which expression would be correct: state == EDIT_SCHEDULE or != EDIT_SCHEDULE

Ups, it can only reach this state (not EDIT_SCHEDULE) if the player was chenged with the dialog open. So it should about, if the state is not EDIT_SCHEDULE

I get this message: "The vehicle's schedule must not be changed during route-finding", but the vehicle is still in the depot.
(https://www.mediafire.com/convkey/ec8c/5o9sy1op61dr7kg6g.jpg)
To recreate:

   
• Select a vehicle in the depot. Press "start" without assigning routing / schedule.
  
• Now press the "schedule" button, this should open the convoy window (I think this should not happen), close the window.
  
• Finally press the "schedule" button again, the message will appear: "The vehicle's schedule must not be changed during route-finding".
  

I am using the script scenario tutorial, but this was working without issue prior to this patch. I attach the script and savegame:
Script: http://www.mediafire.com/file/zr4u1vu1qew4jie/tutorial_pak128-beta-v1.5.20.zip/file
Savegame: https://www.mediafire.com/file/53vfnoy7kbjbeod/tutorial_pak128-beta-5-test.sve/file

Another strange problem:
The truck starts by itself (without pressing the "Start" button).
To recreate:

   
• Follow the tutorial instructions, assemble a PMNV 1950 Mack truck with a carbon trairler.
  
• Configure schedule as instructed in the tutorial and close the convoy window.
  
• Finally save the game and load the game again, there you will see the truck starting without authorization from the depot.

Script: http://www.mediafire.com/file/zr4u1vu1qew4jie/tutorial_pak128-beta-v1.5.20.zip/file (http://www.mediafire.com/file/zr4u1vu1qew4jie/tutorial_pak128-beta-v1.5.20.zip/file)
Savegame: https://www.mediafire.com/file/53vfnoy7kbjbeod/tutorial_pak128-beta-5-test.sve/file (https://www.mediafire.com/file/53vfnoy7kbjbeod/tutorial_pak128-beta-5-test.sve/file)

I think those two bugs were related. The convoi state was accidently set to EDIT_SCHEDULE, even if the convoi was in the state INITIAL, i.e. was in the depot. r9581 should fix this.

Quote from: prissi on January 23, 2021, 01:35:43 PM
I think those two bugs were related. The convoi state was accidently set to EDIT_SCHEDULE, even if the convoi was in the state INITIAL, i.e. was in the depot. r9581 should fix this.

I keep having problems with the schedule.


This time it happens if you select the 2 merchandise stations and then close the window without complying with the minimum load value (100%) proposed by the tutorial (this cleans up the schedule list), Edit. (you need to repeat the process several times until you get the message: "The vehicle's schedule must not be changed during route-finding") then save and load the game, you will see vehicle leave the depot without any routing.

Script: http://www.mediafire.com/file/zr4u1vu1qew4jie/tutorial_pak128-beta-v1.5.20.zip/file (http://www.mediafire.com/file/zr4u1vu1qew4jie/tutorial_pak128-beta-v1.5.20.zip/file)
Savegame: https://www.mediafire.com/file/53vfnoy7kbjbeod/tutorial_pak128-beta-5-test.sve/file (https://www.mediafire.com/file/53vfnoy7kbjbeod/tutorial_pak128-beta-5-test.sve/file)

As soon as you managed to get the convois state from inital to edit_schedule, it will leave the depot upon reloading. But I could not get the convoi into this state any more.

Quote from: prissi on January 24, 2021, 02:24:45 PM
As soon as you managed to get the convois state from inital to edit_schedule, it will leave the depot upon reloading. But I could not get the convoi into this state any more.

Are you using the savegame together with the script?
Edit.
Try this other savegame:  https://www.mediafire.com/file/lmctprlsrs6mbch/tutorial_pak128-beta-5-test-new.sve/file

   
• Assemble the truck, select the 2 merchandise stops and close the convoy window. (https://www.mediafire.com/convkey/075b/van0dfxhxaym2cn6g.jpg)
• Press the schedule button again (Sometimes you have to repeat the previous step) to display the routing change message. (https://www.mediafire.com/convkey/ba2e/99dmd1vemkk38tq6g.jpg)

I could click many times. tried also combinations without script and with: All fine in r9588.

Quote from: prissi on January 25, 2021, 12:08:46 PMI could click many times. tried also combinations without script and with: All fine in r9588.

I cleaned up the directory where I compiled and have recompiled with the latest update available on github, but the problem is still there I'm afraid. :-[ 
My concern is that this completely breaks the logic that the script uses to maintain control over the number of vehicles in circulation and the regressions in case the player removes a vehicle.

I wonder if someone else can confirm that? ..... I'm also using a linux district, so I have to see if this happens under windows too. I am going to do some tests on another pc.

QuoteI could click many times.

You mean clicking the stops multiple times while using the script? ... if this is affirmative, I must mention that this only occurs if there is inconsistency with the number of vehicles in circulation, this type of inconsistency should only occur if the player removes a vehicle, but in this case it seems that a vehicle is detected additional.
I am going to leave you a test script that shows the vehicles in circulation in the scenario window (it should replace the script "tutorial_pak128-beta") .https://www.mediafire.com/file/vwnb1ffs8mxk7cv/tutorial_pak128-beta-debug.zip/file (https://www.mediafire.com/file/vwnb1ffs8mxk7cv/tutorial_pak128-beta-debug.zip/file)

If the number of vehicles is consistent, you should see the values as seen in this image:(https://www.mediafire.com/convkey/7722/871uw6565qu44l46g.jpg)

When the number of vehicles is inconsistent (current problem appears), the values look like this:(https://www.mediafire.com/convkey/0b63/rhalkwb0ghg7pdf6g.jpg)

The script does not work for me. The number in circulation never increased. I could copy 10 convois, start 2, then the error message was "You must copy nine convoys." If there was eleven convois when hitting start, it was also not working.

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

Quote from: prissi on January 26, 2021, 01:01:57 AMThe 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.

Quote from: prissi on January 26, 2021, 01:01:57 AMI 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.

Quote from: prissi on January 26, 2021, 01:01:57 AMHowever, 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.

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).

Quote from: prissi on January 29, 2021, 02:45:12 PM(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.) 8)

Quote from: prissi on January 29, 2021, 02:45:12 PMHow 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:(https://www.mediafire.com/convkey/5a08/kexjoy5i3xm8ley6g.jpg)

I have made a video capture, look here:
https://www.mediafire.com/file/2x3wcquf5y5cjwb/Capture-schedule-problem.webm/file (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.

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.

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

Quote from: prissi on January 31, 2021, 11:15:35 AM
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.

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.

Line button does not have auto alignment. :o

(https://www.mediafire.com/convkey/d265/8dd8cfv5tu17bnl6g.jpg)

@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.

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.

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.

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.

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.

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.

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

Quote from: wolfgang on February 05, 2021, 04:08:43 PM- 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.

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.

Quote from: wolfgang on February 05, 2021, 04:08:43 PM
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 (https://forum.simutrans.com/index.php/topic,20715.0.html) from multi-player games shows that malicious behaviour of this kind almost never happens.

Quote from: Ranran on February 05, 2021, 04:27:46 PMExpress 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......

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....

Quote from: prissi on October 21, 2020, 01:44:06 PM
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?

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

Quote from: prissi on March 03, 2021, 02:35:22 PMThere 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.

8) 8) 8)

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.

@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.

The double convoi window bug is fixed in r9776

Quote from: prissi on May 17, 2021, 02:20:25 AMThe double convoi window bug is fixed in r9776

Thanks, now it works fine  8) .

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.

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.

Quote from: prissi on August 03, 2021, 03:41:58 AMPlease 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.

Quote from: prissi on August 03, 2021, 03:41:58 AM
...
Please give an example when you would need an absolute departure time and minimum load.
...

time
(https://forum.simutrans.com/index.php?action=dlattach;topic=20444.0;attach=29720;image)

minimum load and time
(https://forum.simutrans.com/index.php?action=dlattach;topic=20444.0;attach=29722;image)

no set load and time
(https://forum.simutrans.com/index.php?action=dlattach;topic=20444.0;attach=29724;image)

Quote from: Freahk on August 03, 2021, 09:03:24 AM
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.

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.

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.

It should use the same format since it calls the same routine. I will check.

And yes, I though once allowing the same stop more than once to have a multiple of times. But the logic and error checking (one would for instance have to enforce all stops are either schedule or minimum loading type. (Actually most tedious would have been the GUI, which why I did not finish this.)

In extended, we have a fixed frequency defined as "run n-times per month", so a Line set to depart twice per month without an offset (in standard 1th 0:00), will define two slots per month: One at the beginning of the month, one in the middle of the month.
Surely, allowing explicit schedule slots has some merit, but I suspect especially in standard that might be overcomplicated.

The schedules were a longstanding request of the people using Simutrans as model railway, as they have been mentioned many times over the years. Also there were complains about the waiting time not being in "normal" units. Thus I sought to solve these two in one go.

Slots with offset would be possible as well, but would require some more additional logic in the convoy and additional structures to the schedules. Also the departure would be again acryptic 1/n th of the month plus offset.

From my understanding, the departure time already is an offset relative to the bginning of a month. That's just the same as in extended but encoded in a more user friendly way (day, hour, minute instead of an admittedly rather artificial 1/1440 of a month unit...)
What's misssing is a way to allow multiple departures per month. Extended makes use of a frequency here, which might indeed be an issue in the UI.
What does "at 1st 0:00, 2-times per month" mean?
Maybe a timetable view might help showing this months exact departure times?

The departure time is absolute, at a certain time of the month, noy an offset. If departure is set to 8th 8h45, then the train will depart on the 8th at 8:45 (or slightly later on a month with 30 days, since the internal ticks are the same for each month). The waiting time with minimum load is indeed an offset relative to the arrival time.

What's the difference between an "absolute departure time, at a certain time of the month" and an "offset by an absolute amount of time relative to the beginning of a month" ? Which is what the offset in extended actually is: It shifts all slots (in case of standard there is only exactly one slot) by a fixed amount of time relative to the beginning of each month.

Ok, I misunderstood what you meant with offset.

Follwing the suggestion, r9994 allows now also for multiple departure per month (like every two days). The absolute dparture time is then the time of the first departure which is repaeted n times per month.

Very very welcome changes, Mr. Prissi. Good job!

A minor annoyance is that after changing to Fixed Monthly Departures from Minimum Load, the text on the combobox is cropped - but if you resize the windows, it instantly adjusts the size of the combobox to fit it. The other way around (changing from Fixed Monthly Departures to Minimum Load), the combobox is always resized. Weird.
Also I think it is more correct to say "n times starting on the [day]" than "n times on the [day]".
(https://i.imgur.com/8bIe2RG.png)

Otherwise I have been testing it a bit and it seems to work as intended. Thank you.

That seems very useful :)
But now "wait for load, then wait for the next scheduled slot" would make sense  :-X

I tried a different (albeit longe) test in the translator. The raw text is not good, I agree.

@Freahk That is not possible as it is implemented right now. But just make a one tile stop afterward to wait for the next slot would do the same.