Why derailments may be necessary [No Flame Wars]

[digitrax83]

So I have discovered a reason for including derailments in the OR in the future other than for testing purposes.

I have a little procedure I want all of you to try in order to understand my reasoning.

1. Download the "A Swiss Fantasy Mountain Railway" route (freeware) from Trainsim.com https://www.trainsim.com/vbts/tslib....right&fid=8291

2. Select either a heavy freight train or fast electric train as your consist (these are just recommendations, but the consists you choose must NOT be a consist with just the engine itself. You must have cars on the consist)

3. Start from the Matterhorn_Halt start point. This is the downhill start point.

4. Run down the hill with the throttle at maximum.

5. As you near the bottom of the hill (about a 1/2 mile away from the end of the line) uncouple from the consist you were towing

6. When you hit the end of the line, you will stop instantly as per OR's programming.

But remember.....your consist is still racing towards you. When your consist collides with you, Open Rails panics and crashes. This is because it doesn't know how to use the MSTS derailments code and so it throws up a "Stopped Working" error message since it can't recover.

Open Rails knows that the consist behind you cannot couple to your engine at such a high speed, so it attempts to make the derailment sequence happen. Unfortunately it's been programmed to ignore MSTS's derail code and as such creates the crash above.

This will happen every single time you try this.

Now you may be thinking "It's just one route, this doesn't mean that derailments should be included."

But here's the thing: Would you rather have derailments stay the way they are and risk program instability, or would you rather have derailments as an option (similar to what MSTS did) and have a very stable source port?


Remember, derailments don't always have to be on, they could be an option in the launcher.
Not everyone wants them, but it would be nice to have them as a little extra much much later in development.
(I mostly derailed trains to test if they had the bounding-box floating/twitching problem that some new content has)

So that's my reasoning. Feel free to give feedback. But let's keep this civil.

See you on the main-line!
Digitrax84

[OTTODAD]

After uncoupling wagons and disconnection their brakes hoses are they not supposed to apply their brakes to stop them moving ?

[digitrax83]

After uncoupling wagons and disconnection their brakes hoses are they not supposed to apply their brakes to stop them moving ?

I do know that. But I'm explaining the mechanics of the game engine for the newbies who may want to jump into OR right away.

[UP_4848_Thunder]

I agree about the option as I go to MSTS when I want to test and see COG, bounding boxing, derail forces.

My concern is what happens if a train in ORTS slams into a cut of cars too fast then a wag/eng is built for, runs head on with another train due to running a light, hard heavy head end braking of say too many units occurs causing jacknife in connection of also hard heavy power pushing on cars/locos light enough with too much brake force/friction or string lining of too much force at curves?

Since MSTS at times tended to derail in heavy dynamic bunch braking due to weak couplers on a end, why not make either the front/back couplers have the values of derailing in connection with Mass, Height, Force, Buffer values after breaking bunched?

Example 1 bellow.

Coupling (
Type ( Automatic )
Spring (
Stiffness( 5e4N/m 5e6N/m )
Damping( 3e6N/m/s 3e6N/m/s )
Break( 5.1e7N 5.1e7N )
r0( 0cm 2cm )
)
Comment (
Velocity ( 0.2m/s )
)
Coupling (
Type ( Bar )
Spring (
Stiffness ( 5e6N/m 5e6N/m )
Damping ( 1e6N/m/s 4e6N/m/s )
Break ( 2.33e6N<----Stretch force 2.81e6N<------- Bunch/Buffer force )
r0 ( 0cm 1cm )
)
Velocity ( -0.2m/s )
)

[OTTODAD]

The Route Riter supplies a number of coupler options created by experts on the subject and have no problems running trains anywhere, using my own preferred UNIVERSAL-RIGID-COUPLERS version.


.

[seagoon]

I don't understand why you state that "derailments may be necessary".

Necessary?

Maybe a diversion for those who like that type of thing in a rail sim but hardly "necessary".

[rdamurphy]

Just to clarify: OR uses absolutely no MSTS code in any way...

Nor is the MSTS executable necessary for OR to function.

Leaving out derailments was a conscious decision by the development team.

Robert

[James Collins]

You guys have to remember that OR is a train physics simulator. Things like trees, cars and the like were added in by accident as they have no bearing on the drivability of a locomotive. This game is nothing more than a calculator with visuals. Am I being sarcastic? Yes. but it shows my bigger point of whats really important versus whats not? Who sets that standard really? This is how it is and how dare you ask questions. My point gets proven again and again.

[OTTODAD]

Leaving out derailments was a conscious decision by the development team.

Phew, just as well, testing the tracks of large routes with my high-speed Santa-Fe-Explorer, ORTS itself being capable of Ctrl-Alt-PageUp time acceleration when running activities !

[digitrax83]

I agree about the option as I go to MSTS when I want to test and see COG, bounding boxing, derail forces.

My concern is what happens if a train in ORTS slams into a cut of cars too fast then a wag/eng is built for, runs head on with another train due to running a light, hard heavy head end braking of say too many units occurs causing jacknife in connection of also hard heavy power pushing on cars/locos light enough with too much brake force/friction or string lining of too much force at curves?

Since MSTS at times tended to derail in heavy dynamic bunch braking due to weak couplers on a end, why not make either the front/back couplers have the values of derailing in connection with Mass, Height, Force, Buffer values after breaking bunched?

Example 1 bellow.

Coupling (
Type ( Automatic )
Spring (
Stiffness( 5e4N/m 5e6N/m )
Damping( 3e6N/m/s 3e6N/m/s )
Break( 5.1e7N 5.1e7N )
r0( 0cm 2cm )
)
Comment (
Velocity ( 0.2m/s )
)
Coupling (
Type ( Bar )
Spring (
Stiffness ( 5e6N/m 5e6N/m )
Damping ( 1e6N/m/s 4e6N/m/s )
Break ( 2.33e6N<----Stretch force 2.81e6N<------- Bunch/Buffer force )
r0 ( 0cm 1cm )
)
Velocity ( -0.2m/s )
)

Cool find Thunder! That's pretty interesting. I'll have to fool around with that this weekend on Marias Pass.

I don't understand why you state that "derailments may be necessary".

Necessary?

Maybe a diversion for those who like that type of thing in a rail sim but hardly "necessary".

I said "may be necessary" not "absoulutely necessary." I think they might be necessary in order to fix this bug or at least be used as a workaround. If not then they could always be added as a tickbox option in the far future.

Leaving out derailments was a conscious decision by the development team.

I'm well aware of that. I'm just stating facts about a certain bug I encountered that seems to be linked to thelack of derailments. And just because something was left out doesn't mean it can't be brought back in the future.

For example: When Croteam scrapped several alpha levels for Serious Sam 1 (an older FPS game), they reused said maps in Serious Sam 3 many years later. Don't get me wrong though, I still like Open Rails, there are just certain little things I'd like to see (whether they are included or not).


Thanks a lot for your feedback guys!
~Digi

[seagoon]

I wasnt talking to you. I was actually taking your side. .....

In that case, Jim, you really need to couch your comments in unambiguous terms so as to avoid confusion amongst the rank and file.

[tscraftsman]

Open Rails without derailments is like running a train in "Sandbox mode" Much like a flight simulator with no ground to collide with or a first person shooter game with infinite armor.

I could see some of the reasoning behind not implementing visual derailments due to the immature crowd that all they want to do is make the biggest wreck and post screenshots of it. For myself and possibly others I'd be pleased with just having a pop up window as a consequence for saying I bushed my train by over exceeding the speed limit, or that I had a collision with another object side swiped some equipment that wasn't in the clear or I derailed from running throw a switch.

Would be nice to meet in the middle on this issue basically no visual derailment needed at all. Just consequences in the form of a popup for poor train handling or failure to follow signal indication etc. Much like what flight simulator has for when you exceed the air frame design and your plane breaks up due to pilot incompetence.

[eric]

Am I being sarcastic? Yes. but it shows my bigger point of whats really important versus whats not? Who sets that standard really? This is how it is and how dare you ask questions. My point gets proven again and again.

This is the last time I'll warn you and the rest of the group on this...

Asking questions or even criticising isn't the problem here. What gets posts deleted and threads locked is the manner in which someone choses to go about making their point.

Let me be clear: anything approaching flamebait is subject to action...

[digitrax83]

This is the last time I'll warn you and the rest of the group on this...

Asking questions or even criticising isn't the problem here. What gets posts deleted and threads locked is the manner in which someone choses to go about making their point.

Let me be clear: anything approaching flamebait is subject to action...

Understood.

[baldwin]

Open Rails without derailments is like running a train in "Sandbox mode" Much like a flight simulator with no ground to collide with or a first person shooter game with infinite armor.

I could see some of the reasoning behind not implementing visual derailments due to the immature crowd that all they want to do is make the biggest wreck and post screenshots of it. For myself and possibly others I'd be pleased with just having a pop up window as a consequence for saying I bushed my train by over exceeding the speed limit, or that I had a collision with another object side swiped some equipment that wasn't in the clear or I derailed from running throw a switch.

Would be nice to meet in the middle on this issue basically no visual derailment needed at all. Just consequences in the form of a popup for poor train handling or failure to follow signal indication etc. Much like what flight simulator has for when you exceed the air frame design and your plane breaks up due to pilot incompetence.

In complete agreement with the thoughts and ideas presented here. I think the problem lies in the fact that the ORTS roadmap whilst looking to arrive at version 1 release with MSTS compatibility, in fact is only going to have the ability to run stock and routes, but zero derail capability. What it can do now is allow you to run a route with sensible real world coupler strengths and not run into the MSTS node problem. No more kryptonite couplers required.

To have the "consequences" of inappropriate action displayed as a pop-up and have the resulting delay added to the activity duration is, I think, outside the scope of the first full release. This does not preclude it from being added in a later version.