Learning more about OR and I like it.

[MsSheare]

Learned today that OR doesn't use AI or sd files glad to have learned that. I stopped using MSTS when it just refused to keep running, but loving the fact I can do so more with OR.

[GokuMK]

Sd files are still used if exist. You can put there some useful parameters.
But yes, if you feel good with default values, you don't need a .sd file.

[Ray Beale]

Also I made a change to the Notch settings in an engine file and OR took no notice of it.
So I assume OR just uses default Notch settings and dosn't read that part of the engine file.
The Notch changes do work in MSTS.
I was wondering what other parts of the engine file that are just default settings and OR ignores.
Not what I would think of as a realistic way of doing things.
RB

[qballbandit]

What do you mean, exactly, by doesn't use AI? I still have "AI" engines coded for specific lighting as trailing units. "AI" trains still exist.
Did you mean, you don't need AI engines and can use player engines?

[ossie]

I think "need" is probably the right word Neil. I deleted all my AI locos ages ago. All my AI trains have player engines on them now, but given your attention to detail with lighting, AI might still be the better option for you? I'm guessing the way you'd light trailing units would be different to the way you'd want a lead loco lit, so short of creating two player driveable locos with lead & then trailing lighting, AI is still probably the best way to go if you want to do lights properly?

[geepster775]

Aside from stepwell or walkway lights, I'm curious to know just how trailing units would need specific lighting?

I'm sure it can all be accommodated with a proper lights section on the one remaining player eng file, although it may approach 60 to 80 light definitions to cover all the potential use situations, and thus restricted to OR-only user environments, as it would completely consume available MSTS light totals right quick. AI and Trail were initially created as a workaround for pre-Bin lighting total limitations of MSTS.

And I will be the first one to admit when player-only became a thing, the payware guys were way behind in making sure the one file remaining could address proper lighting in all situations. Hell, their factory eng files couldn't even do DPU lighting correctly. But then again, they were building models for dual environment use, still.

[qballbandit]

Honestly, it is more about educating myself on eliminating the AI versions, and using the player .eng file intelligently based on what OR can now handle. Indeed, my trailing units just have stepway/walkway/truck/DPU lights. I also still have static locos with the same (minus DPU lights), plus dim front & rear lights, and no sound. (used for sitting in yards and sidings as stand alone units, or with cuts of cars attached)
This is all carryover from the many years of MSTS, and the bazillion locos I have in my trainset folder.

[Erick_Cantu]

It might be helpful to configure player lights and AI lights in separate include files - both loaded in one ENG - to keep things looking a little more tidy. This is probably the approach that I will use, but it depends on how you build your physics. I prefer to keep a directory of my own include files that are called up by very short ENG files only containing what needs to change on a per-unit basis (sounds, model, operating weight, things like that).