The International Simutrans Forum

 

Author Topic: Train gets ordered randomly (after reversing?)  (Read 844 times)

0 Members and 1 Guest are viewing this topic.

Offline CK

  • *
  • Posts: 36
  • Languages: NL, EN, FR
Train gets ordered randomly (after reversing?)
« on: March 10, 2020, 07:21:23 PM »


I have seen this occur a few times now with convoys like this (around 1950-52), and I'm not sure how to reproduce this (other than maybe building a consist like this and having it reverse several times). I have also seen variants in which the locomotive remains up front but the tender becomes the penultimate carriage.

Offline Matthew

  • Devotee
  • *
  • Posts: 560
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Train gets ordered randomly (after reversing?)
« Reply #1 on: March 10, 2020, 08:15:04 PM »
This happens on most trains for me. I think it is a consequence of the patches discussed in this thread.

By the way, does anyone find that tank engines also turn around more slowly now? Like 2m15s instead of 30s? Maybe it's coincidence, but it seemed to happen around the same time.

Offline Ranran

  • Devotee
  • *
  • Posts: 1510
  • Languages: ja
Re: Train gets ordered randomly (after reversing?)
« Reply #2 on: March 11, 2020, 12:30:06 AM »
I'm sorry for the inconvenience. (´・ω・`)

I think this is the same as the pakset mismatch issue because vehicles with bidirectional = 0 may randomly show unexpected forms.
So the second locomotive shows a different form from the setting.
As a result, an unexpected reverse order is performed.
This is still random and can only be seen in network server mode in my environment.

I've fixed the issue cause and it would be helpful to test it again.

Offline Ranran

  • Devotee
  • *
  • Posts: 1510
  • Languages: ja
Re: Train gets ordered randomly (after reversing?)
« Reply #3 on: March 12, 2020, 10:31:40 AM »
Unfortunately, today's update didn't work either. I apologize for any inconvenience this has caused for a long time. As determined by the nightly build symptoms, bidirectional does not initialize properly and appears to have indeterminate values when bidirectional = 1 is not declared in the dat file. However, if it has constraints, it is initialized in another way. Therefore, many inconsistencies occur in vehicles such like ships, planes, buses and trucks. That is, it is not intended that ships, planes, buses and trucks have sharp-headed bars in most cases. Since this cannot be reproduced with the one built with MSVC, I have a hard time investigating and solving the problem.

Previously, vehicle_desc.h used the following initialization method.
Code: [Select]
is_tilting = bidirectional = can_lead_from_rear = available_only_as_upgrade = false; Some documentation stated that this initialization method is an error. Is this correct? Did my patch manifest the problem by adding more variables here? (Or could unintended values be passed?)

I pulled up a request that modified this method and rewrote it to do the initialization separately. Also, since extended conforms to c++ 11, initialization is performed at the time of declaration with care. It would be helpful if you could test it. Also, since Ranran is a programming noob, advice on whether this fix would be correct is also helpful. (´・ω・`)

Offline Freahk

  • Devotee
  • *
  • Posts: 1504
  • Languages: DE, EN
Re: Train gets ordered randomly (after reversing?)
« Reply #4 on: March 12, 2020, 11:04:57 AM »
I was searching for that line of code and guess I found it.
Quote
mixed_load_prohibition = is_tilting = bidirectional = can_lead_from_rear = available_only_as_upgrade = false;
Technically it's not an initialisation but a chain of assignments.
"=" is resolved right-to-left and "returns" the assigned value. So let's reduce this tep by step to see what actually happens!

Quote
mixed_load_prohibition = (is_tilting = (bidirectional = (can_lead_from_rear = (available_only_as_upgrade = false))));
Quote
mixed_load_prohibition = (is_tilting = (bidirectional = (can_lead_from_rear = false))); //available_only_as_upgrade  is false now
Quote
mixed_load_prohibition = (is_tilting = (bidirectional = false)); //can_lead_from_rear is false now either
And so on.
The assignment is perfectly fine and does what you would expect.

Offline Phystam

  • Devotee
  • *
  • Posts: 510
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Train gets ordered randomly (after reversing?)
« Reply #5 on: March 12, 2020, 12:49:53 PM »
Each variable should be initialized explicitly. That would be safe...
like this:
Code: [Select]
mixed_load_prohibition = false;
is_tilting = false;
bidirectional = false;
...
But your  =-chained statement should work correctly as you expected. (I think there is another error at some point.

Offline Freahk

  • Devotee
  • *
  • Posts: 1504
  • Languages: DE, EN
Re: Train gets ordered randomly (after reversing?)
« Reply #6 on: March 12, 2020, 04:40:48 PM »
Neither of these are initialisations. Both are assignments!

Best practice would actually be using initialiser lists but that's not related to the bug. Assignments will work just as good as the chained assignment statements.

If you were ever wondering what that crazy stuff just before the function body is, e.g. this one:
Code: [Select]
vehicle_desc_t() : geared_power(0), geared_force(0) { }
That's an initialiser list.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2836
  • Languages: EN
Re: Train gets ordered randomly (after reversing?)
« Reply #7 on: March 13, 2020, 10:30:16 AM »
If variables appear to change randomly then it could be caused by out of bound array access or dangling pointers. A crash will only happen if the access occurs in an area of invalid virtual memory, and not when it happens where other data happens to be placed. This sort of error is the hardest to find the cause of, especially if it happens infrequently.

Offline Ranran

  • Devotee
  • *
  • Posts: 1510
  • Languages: ja
Re: Train gets ordered randomly (after reversing?)
« Reply #8 on: March 17, 2020, 11:39:32 AM »
Thank you for the advice. Fortunately the cause is clear.
This problem seems to be due to incorrect initialization of can_lead_from_rear instead of bidirecional.
I have removed can_lead_from_rear in that patch. This is because can_lead_from_rear can be replaced with has_rear_cab = 1 and bidirectional = 1.
New makeobj no longer record can_lead_from_rear, but old paks have can_lead_from_rear.
Old paks with can_lead_from_rear assign a value to can_lead_from_rear and translate this as above. So there is a can_lead_from_rear in the code for compatibility.
On the other hand, the new pak does not have can_lead_from_rear, so this assignment does not occur, so initialization is not performed, which may cause the above translation to be performed unintentionally, so bidirectioal could be rewritten to 1. This made bidirectional seem indefinite.

With today's update, the mismatch issue appears to be gone. Please check just in case.

However, the client triggers desync immediately. (´・ω・`)
Is this related to the network server going down recently? Did people have any desync issues while people were forcibly connecting?

Offline Freahk

  • Devotee
  • *
  • Posts: 1504
  • Languages: DE, EN
Re: Train gets ordered randomly (after reversing?)
« Reply #9 on: March 17, 2020, 11:50:09 AM »
Is this related to the network server going down recently?
No. The listserver really only matters for server announce. (guess that's what you meant)
Maybe something strange is going on if the server attemts to announce but the listserver is down, so make sure it doesn't.

Did people have any desync issues while people were forcibly connecting?
It would be a lie to say "no, not at all" but there were only a few desyncs. Some days many per hour, some days none at all but it never desynched immediately after connecting.