Schedule windows improvements

[Vladki]

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

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

[prissi]

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.

[Vladki]

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

[makie]

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

it is no way to stop a vehicle now 

[Vladki]

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)

[makie]

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

but it has not yesterday

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

[prissi]

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.

[Vladki]

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

[prissi]

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.

[Dwachs]

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.

[Dwachs]

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.

[makie]

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.

[THLeaderH]

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.

[Dwachs]

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.

[Dwachs]

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

[Dwachs]

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

[THLeaderH]

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

You are right. It was my misunderstanding.

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

Code Select Expand


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.

[prissi]

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.

[Dwachs]

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

[THLeaderH]

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:

Code Select Expand


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


[prissi]

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

[makie]

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]; }

[prissi]

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

[Dwachs]

I get this compiler warning:

Code Select Expand


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

[prissi]

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

[Yona-TYT]

I get this message: "The vehicle's schedule must not be changed during route-finding", but the vehicle is still in the depot.

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

[Yona-TYT]

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
Savegame: https://www.mediafire.com/file/53vfnoy7kbjbeod/tutorial_pak128-beta-5-test.sve/file

[prissi]

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.

[Yona-TYT]

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
Savegame: https://www.mediafire.com/file/53vfnoy7kbjbeod/tutorial_pak128-beta-5-test.sve/file

[prissi]

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.

[Yona-TYT]

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.
• Press the schedule button again (Sometimes you have to repeat the previous step) to display the routing change message.

[prissi]

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

[Yona-TYT]

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

[Yona-TYT]

I 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

If the number of vehicles is consistent, you should see the values as seen in this image:

When the number of vehicles is inconsistent (current problem appears), the values look like this:

[prissi]

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.