Errors Reported In ORTS Logs

[OTTODAD]

How is it possible that despite ORTS finding all sorts of errors when loading a MSTS route's scenario all these errors do not prevent it running in MSTS and in most cases not in ORTS either ?

Why have the program code waste time checking for them in the first place if they are not interfering with the running of whatever ?

What will happen when there is a specific for ORTS Route Editor which can create routes the code of ORTS will be happy with, not finding any more errors to slow down what it does ?

O t t o

[twpol]

How is it possible that despite ORTS finding all sorts of errors when loading a MSTS route's scenario all these errors do not prevent it running in MSTS and in most cases not in ORTS either ?

Why have the program code waste time checking for them in the first place if they are not interfering with the running of whatever ?

It depends a lot on the problem found; in a lot of cases, the issue can be ignored in some way - if a shape file cannot be loaded, for example, you'll just be missing that item of scenery. Other errors, such as duplicate items in the sigcfg.dat file, probably will prevent OR for completely correctly working because there is something inconsistent with the file - MSTS might have silently ignored the error or it may have not checked for the particular consistency OR is.

Generally speaking, the code attempts to be defensive - reporting everything that we think is wrong or inconsistent even if it's easy to "cope" - so that everyone (including us) get a better idea of what weirdness exists in MSTS content and what we might not be supporting correctly yet.

Don't forget that MSTS checks things too and has that continue/cancel dialog when something's wrong. I'm not sure we're actually doing more checks or less than MSTS, but many checks need to be there to prevent the program crashing later - OR just likes to tell you when it's done this.

What will happen when there is a specific for ORTS Route Editor which can create routes the code of ORTS will be happy with, not finding any more errors to slow down what it does ?

Hopefully, fewer or no errors will be reported. As I say, most of the checks are required for the program to not just crash so we'll probably keep all the warnings in place. If a check is required, removing the warning will only speed up the case that has the warning anyway.

[OTTODAD]

Thanks, James !

Like with all backward compatible updates it would be easier to start from scratch and am not sure which would be less work for coders, doing that or trying to make the old code work in the new program ?

Take care, O t t o.

[longiron]

How is it possible that despite ORTS finding all sorts of errors when loading a MSTS route's scenario all these errors do not prevent it running in MSTS and in most cases not in ORTS either ?
O t t o

I will give a couple of concrete examples where the "errors" reported by Open Rails has improved the gaming experience for both OR and MSTS that I have personally experienced.

First, sms errors. Many times fixing the sms errors OR reports have brought to life sound EFX that the author intended for OR and MSTS. With MSTS, players just didn't know any better because there was no error, so they accepted what they heard.

Second, inconsistencies between .eng and .cvf for engine controls. Fixing them changes the behavior of the controls for both OR and MSTS.

Lastly, once we get the OR signaling complete, I guarantee fixing errors the OR finds will let signals operate properly and potentially eliminate activity standoffs or other inconsistencies because the underlying signal logic flaw was only occasionally exposed. Even with the current state of the signaling, it's identified issues that route builders have used to update signal logic.