I am going to throw this question out there. Is MSTS's ability to work with invisible items such as the item mentioned above and the FRED and the reason to work with them considered a hack? I ask because even though OR is considered more advanced than MSTS, understanding how the above items are suppose to be processed is beneficial to the project. In short, we never found a proper way to work with them.
Edward K.
XNAMatrix.M32 returns a NaN value
#12
Posted 12 August 2015 - 01:34 PM
I don't think they are a hack in the true sense of the word. They are an anomaly like the invisible cars with no couplers that in MSTS do not couple to the train, but in OR they do. I even have a complete consist that has no couplers, but in OR the behaviour is exactly the same as one that has couplers.
#13
Posted 13 August 2015 - 04:41 AM
dennisat, on 12 August 2015 - 09:39 AM, said:
I've tested a patch to XNAMatrixFromMSTSCoordinates() that detects the zero divide condition that causes XNAMatrix to have bad values. The patch is on the bug report Bug 1484205. Since I've forgotten practically everything I learnt about matrices 45 years ago, I'm prepared for some adverse comments!
Thanks for the patch! I don't know off-hand if the code "run = 1" is right but myself or someone else should be able to confirm that by looking at some of the other code (more than is included in the patch file itself).
edwardk, on 12 August 2015 - 12:24 PM, said:
I am going to throw this question out there. Is MSTS's ability to work with invisible items such as the item mentioned above and the FRED and the reason to work with them considered a hack? I ask because even though OR is considered more advanced than MSTS, understanding how the above items are suppose to be processed is beneficial to the project. In short, we never found a proper way to work with them.
My personal feelings are that they are tricks (rather than hacks) in the MSTS world, but either way I would consider them low priority for compatibility. Even so, when we find a bug in fundamental-style code (like we did here with XNAMatrixFromMSTSCoordinates) we should definitely fix it, since this code (despite its name in this case) is very likely to live on in to the OR content world.
#14
Posted 13 August 2015 - 06:19 AM
James Ross, on 13 August 2015 - 04:41 AM, said:
Thanks for the patch! I don't know off-hand if the code "run = 1" is right but myself or someone else should be able to confirm that by looking at some of the other code (more than is included in the patch file itself)
Yes, I think it will be clear what I'm suggesting when you see the patch applied to the source.
Dennis