Introduction and MSTS scripting quirks

[Airborne]

Hi there, I want to start off with a short introduction of myself before getting into the matter at hand.

I am a middle-aged man (oh god, how does it sound, certainly not feeling like it from Germany, drawn to simulators since an early age. Starting off with the likes of Silent Service, F/A 18 Interceptor, F19 Stealth Fighter, over to some MSFS iterations up to FS02, I always had a knack for technical simulations - maybe attributed to the generation of games back then, more on the air/combat side. Up until that point, time was an abundant resource.
Beginning with FS04, some sidetracking to the Silent Hunter franchise, and also MSTS, my occupation with simulators left a lot to be desired, from my perspective at least. Fast forward to now, still being somewhat of a railway enthusiast, but remembering the technical problems I always struggled with in MSTS, I became aware of Open Rails, hallelujah! But enough of that, on to my questions.

Upon installation of Open Rails and getting it to run smoothly and beautifully with MSTS content (still impressed), I started some route explorations and activities, just for testing purposes. (but i really want to start with those default MSTS routes and activities, if only for nostalgic reasions)


Understandably, the logging file gives me an abundance of script errors, possibly most, if not all, attributed to malformed original scripts, as Open Rails inspects them a bit closer. I already looked around, but understandably, people posted many logs with similar messages but their problems are differing.

Among others, the following messages I would argue could be ignored with the default routes:
Warning: Expected string block; got empty block in [...]
Warning: Replaced existing TrackSection 360 in [...]
Warning: Ignored invalid track node 243 pin [1,0] link to track node 196; already linked to track node 243
Warning: Skipped unknown world block 309 (0x00000135) first seen in [...]
Information: Cannot locate TCSection for platform 399
Information: Platform split by junction at Red Eagle
Information: Skipped unknown lighting model index -1 first seen in [...]
Information: Ignored missing animations data in shape [...]
Information: Ignored missing overheadwire.ace, using default. You can copy the overheadwire.ace from OR's AddOns folder to D:\Programme\MSTS\ROUTES\USA1\Textures

However, just from the sound of it, these sound like they need some attention:
Warning: 1 missing SignalType(s) in D:\Programme\MSTS\ROUTES\USA1\sigcfg.dat:line 132
Warning: Ignored unknown SignalType script TESTSEM_BNSF2LIGHT in D:\Programme\MSTS\ROUTES\USA2\sigscr.dat:line 281

Can all of the messages be ignored, or do some of those hint to problems in the route, e.g. the ones concerning signals? For instance, in the sigcfg.dat Kuju seems to announce that it will define 2 SignalTypes, but merely continues with the defintion of AM14Light. This alone is fine by me, but Open Rails somehow expects a speedpost in there, if I read the log right, stating SPEEDPOST just above the error line.

Similarly, the SignalType TESTSEM_BNSF2LIGHT is nowhere to be found in the corresponding sigcfg.dat, granted. There are other TESTSEM... scripts in sigscr.dat, which did not raise an error. After further musings, I guess these are really not needed after all.


On another note, with evaluation logging, despite ticking appropriate logging options on the evaluation tab and activation of the data logger (at start or via F12), I do not get any evaluation records in the dump, merely those from the data logger tab. Is the evaluation logging not functional as of yet, or am I doing something wrong..

Also, the bad quality of the needles in the Acela default cab: is this a cab image or rendering problem?


Thank you and regards.

[conductorchris]

Hello Airborne.

Lots of questions, many to which I can't help. But I can say welcome!

The general rule about errors in Open Rails is that they can be ignored if not causing problems. Open Rails is better at not crashing when errors exist and also better at reporting what errors exist in order to be useful for diagnoses if something isn't functioning right.

I think what you are seeing is that the original default MSTS routes are not perfect. But they have all been replaced by better routes anyway.

Christopher

[ebnertra000]

First things first, welcome!

On to the errors:
Is the folder 'Programme' the German equivalent of 'Program Files'? If so, the OS's security system will cause problems.
Most of the first batch of errors are pretty harmless. I've made shape that for some reason have animation data (they're mileposts) and give that error. The platform in Red Eagle could be fixed relatively easily, just by moving the platform off the switch.
The signal files on the Marias Pass route have a couple extra signal types that aren't used in the route. I wouldn't worry about them.

In fact, I wouldn't worry about any of these, as long as OR works as intended

[R. Steele]

Airborne, Welcome. I can only echo Christopher's remarks.
Adding:
1. if you like to run electrified routes, you'll need the overheadwire.ace texture file -- if you cannot locate one (there may be a copy in the TS library, just ask - like Christopher said, it's among the items that are not show stoppers.
2. Most importantly - you are actually looking at the OR log...WOW - many users don't realize there is logging, nor how valuable it can be in troubleshooting. Congrats.

Cab needles problem are an artifact left over from MSTS, trying to correct them is probably a waste of time.

[Airborne]

Thank you for the welcome! I'll ignore those messages - until I divert to custom routes, at which point I will cherish the OR log once again.

Now I understand the overhead wire message - OR allows for route specific wires, to be put in the corresponding route folders, while MSTS uses a default one for all routes. Although OR doesn't seem to come with an addon folder anymore. But as you said, can ignore this one too.

Regarding the "Programme" folder, you're correct, thats the Program Files equivalent. Was not aware of the problem. However, my manual file operations in this folder structure went fine so far.

[ebnertra000]

The Program Files issue is present on OSs from Vista and newer (Win 7, 10, etc.) Mine is installed in C: drive (C:/MSTS, C:/Open Rails). That's fine. See here for further detail: http:\\msts.steam4me.net/tutorials/installing_msts.html

[derekmorton]

Regarding the "Programme" folder, you're correct, thats the Program Files equivalent. Was not aware of the problem. However, my manual file operations in this folder structure went fine so far.

Its not YOUR file operations that matter, its the file operations behind the scenes that silently fail.
First step is to reinstall away from programme, as per steam4me above.

[mikeebb]

Wonder if we're mixing something up here? Open Rails, technically, runs OK in Program Files (x86) or Program Files (depending on 64- or 32-bit Windows version). It's a modern program in that respect. It's best to place the data (routes, trains, etc.) outside of Program Files, though, since that make edits and route/train installs easier. OR requires you to specify where the routes and trainsets are if MSTS isn't installed (can use the MSTS registry keys to find the basic folders otherwise), but once done it works fine wherever they are relative to the program. The downside to having it in Program Files (which the installer will do if you don't change the default) is difficulty with updates if you go to the weekly releases or even daily - updates to the program may require administrator permission, and certainly will if you download the zip files from Jim Ross' web site and install by copying the files to the program directory. My experience is that it's less annoying to install OR outside of Program Files, like with MSTS, but technically it's not required.