AI diesel makes steam noise

[moelarrycurly4]

For some reason in OR the AI BNSF engines make chuffing sounds instead of diesel sounds.
I guess there sis the wrong sound file in the engine file somewhere.
Anyone else noticed this?

[qballbandit]

Which engines? Did they sound good in MSTS? How are the sounds aliased/coded in the .eng files?
Doesn't sound like on OR issue, it sounds like a user issue - sounds not configured properly?

[moelarrycurly4]

sounds fine in MSTS
it is the dash 9
with driveable version of dash9 all sounds are fine
when AI train passes it hisses in OR instead of diesel sound.
When i can find the correct SMS file I will look at coding.
It is like OR is subbing a wav file for the correct one.
No sound error in log.
i am going to try diff route and see what it does
So far same thing on two routes.

[R. Steele]

Are there any sound warnings in the OR log file? Whenever you encounter what might be a problem be sure to zip up a copy of the logfile and attach it to your post. The people that can help...will need to see the log. There is a lot of good information in there, you'll have to teach yourself how to read it.

OR does not sub files...it only uses the data you provide...through sms, eng, wag and other files. Junk in - Junk out!
The AI "hissing" in OR might just be "air" release sounds not steam from the AI.

[moelarrycurly4]

No sound warnings in log file. already check there just a skipped unknown world block
now that you mention air release that could be the sound. Wonder if OR not picking up other stream for engine sounds external
This is original SMS file from MSTS that has not been edited so the Junk in comes from MSTS.

[moelarrycurly4]

It appears to be using x_d9_airb_auto1.wav looped , now If i can just find that trigger.

[geepster775]

Anytime you are dealing with AI or TRAIL engine varieties in your consists, you are dealing with deliberately COMPROMISED sounds, lights, and cab/control features needed to get past previous MSTS and Win 95-era PC technology limitations.


In the MSTS days,

PLAYER = Used on the point of player trains only
- - Full sound features, Full control features, Full user-controlled light features

AI = Used on the point of AI trains only
- - Compromised sounds, limited control features, Lights appropriate for lead unit status on AI (headlights, ditch lights)

TRAIL = Used as buried trailing units on Player or AI consists
- - Compromised sounds, limited control features, limited lights



If you are using Open Rails, there is no fundamental reason on the planet to be using any kind of compromised AI or TRAIL versions of engine files. If you insist on sticking with the past, and you still encounter problems, then the fix is squarely on your plate. The helpful way out is to fire up your consist editor and only apply full feature engine files in place of the compromised versions.

[qballbandit]

In OR, I still make regular use of all my old AI engines. In MSTS, as well as OR, my AI engines were created and named as such because I stripped the lighting down to have just the step/walkway/truck lights on vs. all the lights of a lead/player engine. Other then that, whatever Route Riter stripped out of .eng file when it created the AI engine.
Makes it easy for me to create consists for player and AI trains, and pick through both sets: player/lead engines, and trailing unit/AI engines.

Also, I still use all of my "static" engines created by Route Riter. These are a third category classified as "static", and used as leads on static trains, or static engine consists, placed on siding and yard tracks. These have dim front & rear lights as well as all the running lights. Some have idling sound, some no sound.
So I do have a valid fundamental reason - 3 types of engines coded for 3 different functions.
All engines in my trainset folder have each of the 3, so they can be used in each of the 3 situations described above, in any activity.

[dcarleton]

In OR, when an AI train in coming downhill, it doesn't use the dynamic brakes. Instead, it repeatedly applies short bursts of air brakes. So when an AI train in coming downgrade you hear the air brake blast sound over and over again. Depending on the specific .wav files which play when the brakes are initially applied, since they are only intended to be heard intermittently, the resulting cacophony can be quite annoying or even nauseating.

A similar situation affect steam locomotives in AI mode where the injector sounds play over and over again.

One possible workaround would be to make special .sms files which do not include sound trigger 14 so that the locomotive is not capable of producing a sound when the train brakes are initially applied. But when you are running the train and you apply the brakes, they won't make a sound either, so it's not a very good workaround.

A better approach would be if the OR team could disable sound trigger 14 when a locomotive is in AI or Auto-pilot mode.

[geepster775]

Yes, Neil, if one is still using MSTS, then the lighting limitations of the past still apply and require the use of AI and TRAIL, especially if you have massive routes with lots of switchstand and wayside lighting detail, etc.

Point being, MSTS forced that definition split upon us, whereas Open Rails does not. If you are an Open Rails only user, the only thing driving the need for such continued modified definitions is user choice.

Newer features of Open Rails pretty much are centered around the full featured Player definition being applied universally. Nothing is requiring users to trim back lighting definitions anymore, everything can be accomplished with one properly coded player ENG file. The more sophisticated activities that require power swaps enroute between trains, the ability of the user to jump between consists, to commandeer and take control of just about any train out there, AI or Static, requires a full feature Player definition just about everywhere. At some point in time, we could have a new AE that allows users to specify when placing a loose consist whether the engines are running or shut down. Hell, pretty soon, we won't even need LD and MT wag definitions, either, we will end up with one WAG file per car with car weight and physics dynamically altered.

If you want to walk out on that tree branch and invest alot of blood, sweat and tears into a custom 'system' to be 'perfect' in the interim, that's fine, but when changes to the game engine result in that time investment becoming a sunk cost with limited return because the game engine advances, that's totally on the plate of the person doing the customizing. Already, we have people who won't embrace new Open Rails features because of the 15 years of sunk time they already invested into MSTS.

[qballbandit]

"Nothing is requiring users to trim back lighting definitions anymore, everything can be accomplished with one properly coded player ENG file."

Are you saying it is possible to code for the three types of lighting sections I described in my post above, into one .eng file? And, OR would know how to apply each of the three correctly based on how one of the three (or all three) engines are used in an activity? (Lead/Trailing Unit/Static)
I admit honestly, I am not deeply in tune with the more advanced and sophisticated things OR allows us to accomplish, but if this can be done, that is a great thing.

[baldwin]

..............Hell, pretty soon, we won't even need LD and MT wag definitions, either, we will end up with one WAG file per car with car weight and physics dynamically altered.

The beginnings of that are already in place. Provided you have a loading and/or an unloading facility you can start with an empty consist, go to the loader and fill the cars, run to the unloader and empty the cars. Car weight will change as load/unload happens. Just needs a mod to the wag files, all documented in the manual.

[moelarrycurly4]

Skipping trigger 14 in the SMS file killed the chuff. Now sounds like an engine when it passes.

Now I have to figure out crazy signal script ( a custom one some one wrote)

[moelarrycurly4]

Ha found bad argument in signal script