[systema]

I think there may also be a new problem with waiting points and or reverse points. I got a freeze and crash while testing an activity.

Log attached.  OpenRailsLogfreeze.txt (83.67K)
Number of downloads: 168

Mick Clarke
MEC

[Eldorado.Railroad]

1. Have you rebooted your O/S (cold)? Win10, forced update break things?

2. Failing hardware, RAM, GPU/RAM?

3. To narrow down what caused this you might have to do a bit of a binary search through the various testing releases, to see where it fails.

4. I, have looked at your log file, there is a lot of stuff being loaded at start up. Any bug(s) in the timetable data?

5. I keep my viewing distance way down, ViewingDistance, to about 2500 meters, this might help.

6. Things should not be broken like this, without an explanation. Sometimes we have to dig deeper to find what developer pulled what source and mangled things. That kind of inquisition could/may get sticky. Be prepared for some friction.

7. Maybe the answer is simple. Too many render primitives, etc? Some OR registry setting got flipped?

8. It is too bad that "upgrades" break things, and keep on breaking things. I do not like that. Often I just stick with some version and do my testing/experiments from there. But you have been with this project for many years, so I think you would know that.

Steve

[cjakeman]

cesarbl, on 02 August 2023 - 10:35 AM, said:

I always spend some time ensuring that my changes don't have a big impact, but sometimes I fail to do so. I apologize for that. I really appreciate when people report bugs in the forums, because I cannot test a feature in all existing rolling stock.

You're right, Cesar. Content is outside our control, so not everything can be tested before it's published. Inevitably our Open Rails project relies on prompt and specific feedback from our users.

cesarbl, on 02 August 2023 - 10:35 AM, said:

However, I feel sad if instead of just reporting it, people write rage messages saying that we don't care about bugs.

Please don't stop contributing improvements; our project is benefiting from your expertise.

[cjakeman]

Eldorado.Railroad, on 02 August 2023 - 02:29 PM, said:

3. To narrow down what caused this you might have to do a bit of a binary search through the various testing releases, to see where it fails.

Good advice, Steve, but we don't keep all the Testing Versions (although this is changing). However we do keep all the Unstable Versions, so the first step would be to find the last Unstable Version which doesn't have the problem and the first one that does.

If you can do that, Rob, then we can work through the PRs to see which one made the difference.

[Csantucci]

systema, on 02 August 2023 - 01:09 PM, said:

I think there may also be a new problem with waiting points and or reverse points. I got a freeze and crash while testing an activity.

Log attached. OpenRailsLogfreeze.txt

Mick Clarke
MEC

The thread hang doesn't seem to be related to waiting points and reverse points. Looking at the log there are two hypotheses:
1) an unwanted loop in handling an animation of a steam locomotive
2) simply a temporary overload of the CPU.

[cesarbl]

Quote

an unwanted loop in handling an animation of a steam locomotive

This is suspicious. I must have introduced a really naughty bug, but I'm yet unable to find it. I'm now inclined to think that NaN propagation is involved in the problem.

[roeter]

Eldorado.Railroad, on 02 August 2023 - 02:29 PM, said:

1. Have you rebooted your O/S (cold)? Win10, forced update break things?

2. Failing hardware, RAM, GPU/RAM?

3. To narrow down what caused this you might have to do a bit of a binary search through the various testing releases, to see where it fails.

4. I, have looked at your log file, there is a lot of stuff being loaded at start up. Any bug(s) in the timetable data?

5. I keep my viewing distance way down, ViewingDistance, to about 2500 meters, this might help.

6. Things should not be broken like this, without an explanation. Sometimes we have to dig deeper to find what developer pulled what source and mangled things. That kind of inquisition could/may get sticky. Be prepared for some friction.

7. Maybe the answer is simple. Too many render primitives, etc? Some OR registry setting got flipped?

8. It is too bad that "upgrades" break things, and keep on breaking things. I do not like that. Often I just stick with some version and do my testing/experiments from there. But you have been with this project for many years, so I think you would know that.

Steve

Re. points 1, 2, 4 and 5 : these can be discarded as both versions, old and new, are running now, in the same environment, using the same settings and data etc. So if any of these issues were the cause, both versions should be affected in the same manner.
Re. point 3 : see below
Re. points 6 and 8 : yes, I know - been there before.
Re. point 7 : it looks like that, but what has been changed to cause this?

cjakeman, on 02 August 2023 - 11:32 PM, said:

Good advice, Steve, but we don't keep all the Testing Versions (although this is changing). However we do keep all the Unstable Versions, so the first step would be to find the last Unstable Version which doesn't have the problem and the first one that does.

If you can do that, Rob, then we can work through the PRs to see which one made the difference.

Sadly, that's not possible. I have worked on the new update for months, it comprises over 2000 lines of code changes. Also, the full timetable has been adapted to the new version, adding new commands to a very large number of trains, which took me weeks to complete.
To insert all those patches in previous unstable versions would be an immense task. Given the time required to set up the test for a specific unstable version, start the timetable and run to the required time which properly shows the problem, it would take at least a day for each unstable version to test.
To revert the timetable changes so it could work with the unaltered code would also take quite some time.
Due to the problems I had with GIT (as I explained elsewhere), I have allready spend months on this update, not making any progress, but simply to get things sorted out so the changes could be committed and made available to others. I am not going to spend some more months on this to sort out problems which are not of my making.
I can commit the changes to the latest version and leave it at that. I have a proper working version with which I am happy. We can then forget about this whole issue and pretent it does not exist.
Sorry if this sounds a bit harsh, but it's not the first time I am making efforts to share my progress by committing my latest changes, only to run into all kinds of issues which I have nothing to do with, but which take up a lot of my time to sort out. I do find this all rather frustrating.

Regards,
Rob Roeterdink

[James Ross]

cjakeman, on 02 August 2023 - 11:32 PM, said:

Good advice, Steve, but we don't keep all the Testing Versions (although this is changing). However we do keep all the Unstable Versions, so the first step would be to find the last Unstable Version which doesn't have the problem and the first one that does.

If you can do that, Rob, then we can work through the PRs to see which one made the difference.

Although not announced yet, we have the last two years of Testing Versions available already. This was built for the new website. (We have the same setup for Unstable Versions going back to March, possibly further in the future.)

The Testing Version is by far the best option to find when a regression happened, since it can only move forward with new code merging, unlike the Unstable Version.

roeter, on 03 August 2023 - 01:09 AM, said:

Sadly, that's not possible. I have worked on the new update for months, it comprises over 2000 lines of code changes. Also, the full timetable has been adapted to the new version, adding new commands to a very large number of trains, which took me weeks to complete.
To insert all those patches in previous unstable versions would be an immense task. Given the time required to set up the test for a specific unstable version, start the timetable and run to the required time which properly shows the problem, it would take at least a day for each unstable version to test.

You do not need to do anything with your code yet.

You (and anyone else experiencing an issue) should download and run the latest Testing Version, and then older Testing Versions, to see which ones have the issue.

No code changes, no development environment needed.

If you find the first Testing Version to have the issue, we'll have a much easier time of figure out the source and fix.

If you don't find any Testing Versions with the issue (especially if you wait a week), it is likely that your code and the rest of the code are interacting badly somewhere, which you'll have to figure out.

Note: Always start development from the "master" branch.

[roeter]

James Ross, on 03 August 2023 - 01:36 AM, said:

You (and anyone else experiencing an issue) should download and run the latest Testing Version, and then older Testing Versions, to see which ones have the issue.

No code changes, no development environment needed.

As I explained, I adapted the timetable to run with the update. Because of this, the timetable will no longer load with the old program versions. So I cannot run these tests without a lot of extra work.

Regards,
Rob Roeterdink

[cjakeman]

Hi Rob,

roeter, on 03 August 2023 - 02:09 AM, said:

As I explained, I adapted the timetable to run with the update. Because of this, the timetable will no longer load with the old program versions. So I cannot run these tests without a lot of extra work.

Does this graphic anomaly only appear then when you run the timetable to a certain point?




I wonder what you see if you place the train at that location and run an un-adapted Testing Version in Explore mode.

[joe_star]

cesarbl, on 02 August 2023 - 10:35 AM, said:

I'm so sorry for the wheel problem. It didn't appear in any of the steam locomotives that I tested, and I couldn't notice it when I introduced a new feature. If anyone is willing to help me, I will try to solve it. I would need a locomotive showing no drive wheels for testing.

Unfortunately, due to conflicts with other PRs, the changes were in the Unstable release only for a week, and the bug stayed unnoticed, and entered the Testing version.

I read in the past days some comments which weren't very nice towards developers, particularly for those of us who do physics. I'm a Physicist, and I'm not a competent developer in other areas, so if physics improvements are constantly disregarded, it's better to not introduce anything new. No improvements means no new bugs!

I always spend some time ensuring that my changes don't have a big impact, but sometimes I fail to do so. I apologize for that. I really appreciate when people report bugs in the forums, because I cannot test a feature in all existing rolling stock. However, I feel sad if instead of just reporting it, people write rage messages saying that we don't care about bugs.

Hi Cesar,

Below are some steps to reproduce the issues that I have observed (U 2023-7-21 - 1922) :-
a. Download the harzquerbahn route, stock and activities set https://the-train.de...6-harzquerbahn/
b. Select Activity "HBE01 Passengers for Brockenbahn"

Bug 1 - wheels on steam locomotives not rotating in autopilot mode
c. Once activity is laoded, immediately hit Alt+A for autopilot mode
d. Locomotive 99 will start moving without its wheels rotating
e. Switch back to player mode, the wheels will start rolling
f. Switch back to auto pilot and wheels will continue rolling
g. When the train automatically stops at a station via autopilot, the same situation is repeated

Bug 2 - Missing driving wheels on AI steam locomotives
a. In the same activity as above - switch view via Alt+F9 to any of the other trains in the activity
b. The driven wheels will be observed missing

Notes
- Both issues only happen when advanced adhesion model is turned ON
- I have not yet observed Bug 2 on a player locomotive, only other AI locomotives in the activity

Additionally, I also reported a separate physics issue here http://www.elvastowe...post__p__299306

This issue can also be reproduced on said route with Locomotive 99

[cesarbl]

Thanks! So the key is that the problem only affects AI trains (and autopiloted). Yesterday I uploaded a fix, which is present in the unstable version. If the problem is not fixed with that, I'll try to reproduce it following your instructions.

[James Ross]

roeter, on 03 August 2023 - 02:09 AM, said:

As I explained, I adapted the timetable to run with the update. Because of this, the timetable will no longer load with the old program versions. So I cannot run these tests without a lot of extra work.

Make a new timetable with only a couple of trains to demonstrate?

Did you share which consists these are and where to get them? I might have missed it, sorry.

[joe_star]

cesarbl, on 03 August 2023 - 09:05 AM, said:

Thanks! So the key is that the problem only affects AI trains (and autopiloted). Yesterday I uploaded a fix, which is present in the unstable version. If the problem is not fixed with that, I'll try to reproduce it following your instructions.

Hello Cesar,

I am glad to report that both visual bugs I mentioned above are resolved.

Would you have any insights also into the 3rd issue regarding the net positive wheel and crankshaft inertial forces at high speeds?

Thanks

[cesarbl]

I'm glad to hear that it was solved with such a simple fix.

Quote

Would you have any insights also into the 3rd issue regarding the net positive wheel and crankshaft inertial forces at high speeds?

Peter said he had an idea about the origin of the bug, and he's more familiar with that part of the code, so in principle he was going to fix it. Otherwise, I don't mind looking at it, but it will probably take me more time. Nevertheless I'll have a quick look at it to see if I see an obvious problem with easy solution.