Train gets ordered randomly (after reversing?)

[CK]

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.

[Matthew]

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.

[Ranran(retired)]

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.

[Ranran(retired)]

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 Expand

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. (´・ω・｀)

[Mariculous]

I was searching for that line of code and guess I found it.

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!

mixed_load_prohibition = (is_tilting = (bidirectional = (can_lead_from_rear = (available_only_as_upgrade = false))));

mixed_load_prohibition = (is_tilting = (bidirectional = (can_lead_from_rear = false))); //available_only_as_upgrade  is false now

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.

[Phystam]

Each variable should be initialized explicitly. That would be safe...
like this:

Code Select Expand


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.

[Mariculous]

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 Expand


vehicle_desc_t() : geared_power(0), geared_force(0) { }

That's an initialiser list.

[DrSuperGood]

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.

[Ranran(retired)]

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?

[Mariculous]

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.