[pschlik]

ErickC, on 21 February 2021 - 05:27 PM, said:

This makes absolutely no sense whatsoever. The procedure outlined here says to multiply the car weight by the braking ratio by the friction coefficient at zero and then the friction curve reduces the output force - but that makes no sense. Does the sim simply treat the highest value in the brake friction table as a coefficient of 1.0 and then divide the values at higher speeds by that?

I did a quick little test with this, and it just gets weirder and weirder. It seems to me that the sim is using the brake shoe friction at zero speed as the "maximum" brake shoe friction (even if that is not actually the maximum value of brake shoe friction!), and thus the friction that leads to the value of MaxBrakeForce. Any brake shoe friction lower than the level at 0 mph will lead to correspondingly lower brake force, but any brake shoe friction higher than the value at 0 mph this will just be ignored.

For example, a hypothetical (and completely unrealistic) situation where the max brake force is 50,000 pounds with 50% brake shoe friction at 0 mph, 25% brake shoe friction at 50 mph, then 100% brake shoe friction at 100 mph...would lead to a brake force of 50,000 pounds at 0 mph, 25,000 pounds at 50 mph, and 50,000 pounds again at 100 mph. Even though 100 mph is set to have twice the brake shoe friction as 0 mph, the sim truncates the brake shoe friction to the value at 0 mph.

A better solution would be for the MaxBrakeForce to correspond to the brake force at 100% brake shoe friction, such that at 0 mph the brake force would be 25,000 pounds, then 12,500 pounds at 50 mph, and the full 50,000 pounds at 100 mph.


Yet I don't anticipate that will be changed as changing it would break the brakes on a lot of content that's already released. I've already set up my spreadsheet for braking performance to account for the (questionable) assumptions OR is making, and "fixing" this would require a recalculation of everything I've done so far, or accepting that the brakes would become twice as strong as I intend them to be. Of course, there's always the option to add an "ORTSMaxBrakeShoeForce" option that works the expected way, but we really need to stop adding ORTS___ stuff to .eng and .wag files, and instead just make new Open Rails specific file formats.

[R H Steele]

Bumping Back to the poster original point -- 2021 Wish List -- How about OR provide a method/option to load "user selected" route specific options when starting to explore or run activities/timetables. The variability in routes is such that the OR options: viewing distance, super elevation, dynamic shadows, shadow all shapes, distant mountains, & others are dependent upon the route and also the hp of the user's machine.

[Genma Saotome]

R H Steele, on 23 February 2021 - 02:14 PM, said:

Bumping Back to the poster original point -- 2021 Wish List -- How about OR provide a method/option to load "user selected" route specific options when starting to explore or run activities/timetables. The variability in routes is such that the OR options: viewing distance, super elevation, dynamic shadows, shadow all shapes, distant mountains, & others are dependent upon the route and also the hp of the user's machine.

All of that and more belongs in the *.trk file but IMO don't count on that ever happening.

[Guille592]

This has been asked many times but I think I have to ask again for a file that couldn't be reversed engineered, improving ground textures and having dynamic lights would be great too.

[cjakeman]

Guille592, on 28 February 2021 - 02:40 PM, said:

This has been asked many times but I think I have to ask again for a file that couldn't be reversed engineered

Sorry, but I don't understand. What is this all about, please?

[ATW]

I like this topic on wishes an agree with majority especially engine performance an RPM playing a role. Majority of engines I worked on I always when I got the opportunity on runs is write down TE Curves an convert them to ORTS but if newer options come I am for it especially adhesion/slip control.

But I like to put few wishes from my sleeve based on experience an learning curves I like to see in ORTS.

1. More driver (You run them) test scenarios an disciplines for improper handling or improper train makeup. I made a topic last year an its my biggest wish is for optional stocks to have its own set limits planted in WAG an ENG files regarding curve negotiations an forces since we already have curve speeds. http://www.elvastowe...297#entry263297

To cut it simple short what is a given stocks minimum curvature requirement an how much TE/Force within coupler forces run-in/run-out can it handle before it pops off rail without visuals but turning the derailed car into a red line in track monitor that acts like a buffer.... you know the red line dead-end won't let you go through or derail. Running a red line running through a switch should be a discipline added to evaluation as not all switches are spring.

2. Advanced Engine an Brake setups for cold starts vs hot starts everything up an running with cut in breakers, hoses, light setup etc.

3. Another thing I like to see in braking is the Suppression state to be tweaked to real standards as I know some co workers got in trouble for not putting train in Suppression at West Colton setting out cars in recieving yard that needed to be humped an already bled enough. Since 6 handbrakes will hold the train while Brake Cylinders are bled enough after the train pops in emergency from its remaining BP there is not enough air to apply Cylinders unless you charge it up. Good for humping long cuts without enough air or suppressed to 0. Know some dangerous engineers in history that had a penalty application but wanted to keep going without stopping train so they put the train in suppression to bleed the cylinders because reseting the alerter didn't have to be at 0 speed.

1 Final braking concerns RPM levels helping charge up the air quick enough. When in the release position BP does everything it can to charge enough pressure even with a hole (open angle cock) or in emergency while if there is a set the BP remains the decrease to 0 PSi. There also needs to be features for users to give position increments opening an closing angle cocks to reduce train from going in emergency as well as increments for applying handbrakes.

[Guille592]

cjakeman, on 01 March 2021 - 07:09 AM, said:

Sorry, but I don't understand. What is this all about, please?

By reverse engineering I mean converting an .S file into an .3ds file, it's sad but I know some cases that people put their time into creating something and then comes another person, converts the model into .3ds without asking any questions or having the "ok" from the original author, I know many cases, it has happened in Trainz and it happens in MSTS/OR, it's sad but true. That's one of the main reasons of why we(at least some part of the Spanish community)have been asking for another file format.

[YoRyan]

In principle, it's not possible to prevent somebody else from copying or converting your content. You can obfuscate your data (to some extent), or use one of the encryption methods used in commercial games (mind you, even Dovetail Games didn't think this was worth it for Train Sim World) -- but at the end of the day, if it's decoded for display on the screen, it can be ripped. Sucks, but it's a problem inherent to digital art.

Guille592, on 01 March 2021 - 02:58 PM, said:

That's one of the main reasons of why we(at least some part of the Spanish community)have been asking for another file format.

Experience has taught me that "let's support other formats besides .S" is quite a controversial idea around here. :sweatingbullets:

[Traindude]

As far as this "Wish List" goes, something I'd like to see is curve speed limits being displayed in track monitor--perhaps a curved arrow with the recommended speed rounded down to the lowest integer. I'm getting sick and tired of having to guess the speed limits and then receive the message "Your passengers are feeling uncomfortable" or "Your freight cars may be damaged" just because I overestimated the speed limit, and then having to memorize the recommended speed for every single curve along the route.

[copperpen]

I never have curve speed limits turned on. To me it is a somewhat useless bit of code if it is applied to every curve the train runs through. Curves where speed limits apply should be clearly marked as part of the route, not arbitrarily applied by a bit of code.