[rfranzosa]

mestevet, on 14 December 2011 - 08:41 AM, said:

Symptom in OR: There's an odd effect in OR, that I think might be a "shadow", that is not seen in MSTS (see images). This black patch seems to change depending on the viewing angle I choose with the camera rotation keys - in some angles the entire side of the car is black, in others not at all. I'm seeing this with every piece of rolling stock that I created so far, but not with other rolling stock. Perhaps it's a result of the items being created in TSM, or maybe some choice I made in modeling or creating the textures? Don't know, but I'd like to resolve this, it doesn't look good:

Steve and OR Team,

The BLW/ZT models exhibit the exact same behavior in MSTS on the Monon Route. Rick Berg and I finally determined that it was the use of 'static' track sections. Most yard and terminal areas on the Monon route make extensive use of static track (especially Chicago). Rick temporarily removed the sections as a test and the problem went away.

I wonder if what you're seeing relates to the same effect on a different route in OR?

Rick

[BillC]

Steve,
If this route is public domain or you are willing zip up the route, I would be interesting to take a "programmers view" of it. What is absolutely need are .cvf file and .eng files. I am assuming that you are modeling this as an
electrical unit. Tracks should not affect the operations.

Post here if you want to pursue this.

Bill

[longiron]

You might give these suggestions a try.

mestevet, on 14 December 2011 - 08:41 AM, said:

Since recently taking the plunge into OR, I wanted to see how my Silverliner II cars performed. Maybe some of these things already have solutions.

1) Controller
Symptom in OR: The controller doesn't seem to really work right, not just the control animation in the cab view, but the basic function from the .ENG file. So what doesn't it do? First of all, it requires me to use the "W" key "reverser" to put the car into forward - there is no such control on the Silverliner. And it doesn't notch properly, meaning, it doesn't use the correct number of notches as they're defined for MSTS (it only has 3 instead of the correct 5) and it doesn't have the notches at the correct "power setting".

first thing to check is ensuring the eng and cvf files have the same notches. As you know, BillC, our resident cab controls, expert is on the case :>)

mestevet, on 14 December 2011 - 08:41 AM, said:

It also seems to accelerate slowly compared to the MSTS model and real life. Mind you, Joe Realmuto and I ran timed tests over known distances to get the acceleration performance correct in MSTS, since real life TE curves have never been found for these cars, but we did know speeds/distances/times from me actually riding the cars. I have not duplicated those tests in OR, but I'll probably need to.

Give it a try with both front & rear pantos in the up position.

mestevet, on 14 December 2011 - 08:41 AM, said:

2) Brake
Symptom in OR: Currently, the brakes are very slow in OR and react like the brake on a freight train, cylinder pressure is slow to build (accurate for a string of hopper cars, not so much for a 4 car MU train). This may be because of the way we had to choose brake parameters in MSTS to get the system to mimic the graduated release type brake or it may be the "more accurate physics" in OR. Since we tuned the brakes to work as close as possible to the real ones in MSTS, they might not function as well with that setup in OR. Whatever the cause, the brakes don't have the right reaction time and response, so something needs to be done. (just a note, this isn’t an “unrealistic expectations” thing, I think I can produce video that shows how quickly the brakes in the real cars respond)

Don't worry too much. In the near future, Open Rails will have its own version of MSTS .eng files that will have a independent set of braking parameters for higher realism. That way you can have optimized set-ups for MSTS and OR. For the short term please read the following on how you can adjust the behavior of the braking system in the Options menu.

Open Rails software has implemented its own braking physics in the current release. It is based on the Westinghouse 26C and 26F air brake and controller system. Open Rails braking will “read” the type of braking from the ENG file to determine if the braking physics uses passenger or freight standards, self-lapping or not. This is controlled within the Option menu.

Selecting Graduated Release Air Brakes in the Options menu allows a partial release of the brakes. Some 26C brake valves have a cut-off valve that has three positions: passenger, freight and cut-out. Checked is equivalent to passenger standard and unchecked is equivalent to freight standard.

The Graduated Release Air Brakes option controls two different features. If the train brake controller has a self-lapping notch and the Graduated Release Air Brakes box is checked, then the amount of brake pressure can be adjusted up or down by changing the control in this notch. If the Graduated Release Air Brakes option is not checked, then the brakes can only be increased in this notch and one of the release positions is required to release the brakes. Another capability controlled by the Graduated Release Air Brakes checkbox is the behavior of the brakes on each car in train. If the Graduated Release Air Brakes box is checked, then the brake cylinder pressure is regulated to keep it proportional to the difference between the emergency reservoir pressure and the brake pipe pressure. If the Graduated Release Air Brakes box is not checked and the brake pipe pressure rises above the auxiliary reservoir pressure, then the brake cylinder pressure is released completely at a rate determined by the retainer setting.

At the moment only single pipe air brakes are modeled. So the auxiliary reservoir needs to be charged by the brake pipe and depending on the WAG file parameters setting this can delay the brake release. When the Graduated Release Air Brakes box is not checked, the auxiliary reservoir is also charged by the emergency reservoir (until both are equal and then both are charged from the pipe). When the Graduated Release Air Brakes box is checked, the auxiliary reservoir is only charged from the brake pipe. The Open Rails software implements it this way because the emergency reservoir is used as the reference pressure for regulating the brake cylinder pressure. The end result is that you will get a slower release when the Graduated Release Air Brakes box is checked. This shouldn't be an issue with two pipe air brakes because the second pipe can be the source of air for charging the auxiliary reservoirs.

Open Rails software modeled most of this graduated release car brake behavior based on the 26F control valve, but this valve is designed for use on locomotives. That valve uses a control 44 reservoir to maintain the reference pressure and Open Rails software simply replaced the control reservoir with the emergency reservoir.

Increasing the Brake Pipe Charging Rate (PSI/Second) value controls the charging rate.

Increasing the value will reduce the time required to recharge the train; while decreasing the value will slow the charging rate. However, this might be limited by the train brake controller parameter settings in the ENG file. The brake pipe pressure can't go up faster than the equalization reservoir.

The default value, 21, should cause the recharge time from a full set to be about 1 minute for every 12 cars. If Brake Pipe Charging Rate (PSI/Second) value is set to 1000, the pipe pressure gradient features will be disabled and will disable some of the other new brake features, but not all of them. Brake system charging time depends on the train length as it should, but at the moment there is no modeling of main reservoirs and compressors.

mestevet, on 14 December 2011 - 08:41 AM, said:

3) External Model
Symptom in OR: There's an odd effect in OR, that I think might be a "shadow", that is not seen in MSTS (see images). This black patch seems to change depending on the viewing angle I choose with the camera rotation keys - in some angles the entire side of the car is black, in others not at all. I'm seeing this with every piece of rolling stock that I created so far, but not with other rolling stock. Perhaps it's a result of the items being created in TSM, or maybe some choice I made in modeling or creating the textures? Don't know, but I'd like to resolve this, it doesn't look good:

Need to test on our machines. If we cannot reproduce the "effect" it may be something as simple as you updating your video card drivers

mestevet, on 14 December 2011 - 08:41 AM, said:

4) Sounds
Symptom in OR: Currently not all sounds for the Silverliner function as they do in MSTS, for instance the external horn does not function (the horn does function on other locomotives I've tested in OR, and the Silverliner's "cab view" horn, which is based on the same .wav recording, does function). Things like the "power" sounds, the "random radio chatter" and some of the control sounds also seem not to function.

Other community members noted this issue, too. It was resolved by check that no sound volume setting is higher than 1.0. Open Rails does not handle sounds properly if the volume setting is 1.2, for example. Setting those sound streams to 1.0 immediately allowed the sound to be played. We are working on a fix as we speak.

[longiron]

mestevet, on 14 December 2011 - 06:08 PM, said:

As is typical practice with EMUs, there is only one pantograph on these cars.

I'm asking to see if the OR code is correctly handling electric MU'd cars. If you get much more acceleration with two panto up, then there's some work to be done on the coding side. If not, then we should help you to better understand the OR electric physics engine.

mestevet, on 14 December 2011 - 06:08 PM, said:

I'm not entirely sure my ancient, albeit capable, card is even having software updates anymore! I'm hoping, if it is the card, that it may be as simple as some of the graphics settings on the card)

If you don't mind, what's the make and model + VRAM

mestevet, on 14 December 2011 - 06:08 PM, said:

Having said that, is there a list of the sound triggers that are currently enabled in OR? is there any guide as to how they work

Developers are not the ideal ones to ask to write something down, so "no". Essentially, the team looked at a huge volume of sms files to figure out the MSTS/BIN triggers and duplicate their behavior. We're still catching some we missed. We probably could go back to the code to figure it all out, but most it's tough to find someone for the job ... and do it for free.

mestevet, on 14 December 2011 - 06:08 PM, said:

I was always particularly disappointed in the way MSTS triggers operated with the action of brakes, and wish that OR could "get it right". One of my peeves was having MSTS play a brake sound repeatedly (at least for certain brake setups) for an "air discharge" instead of just allowing the stream to loop until the discharge finished. It just sounds wrong (in MSTS) to have "hiss" pause "hiss" pause "hiss"... instead of just "hissssssssssssssssss" done.

Steve

Unfortunately, Open Rails doesn't change the full play length of wav files. If the sms file says play "one shot" or repeat wav for x times, then that's what gets played. The only real fix is to record a longer hiss wav.

[dantheman]

The black textures happen on my PC regardless of stock/route. It only happened after the new lighting was introduced (I forget which version).