[Request for RSDL] Changes to derailment handling.

General discussion about Rail Simulator that doesn't really fit in to any specific category. A good place to start if you're not sure what category it should fit in to as well.

Moderator: Moderators

Locked
User avatar
jivebunny
Very Active Forum Member
Posts: 2015
Joined: Mon Jun 26, 2006 9:49 pm
Location: Brittany, France

[Request for RSDL] Changes to derailment handling.

Post by jivebunny »

Last night I encountered two derailments whilst driving a HST to test some signalling on my "sandbox" route. The first occured at low speed but was otherwise a complete mystery; I have the feeling I was either rear-ended or side-swiped by an AI service. The second was due to a signal reverting to danger as I approached at around 90mph, leading to a collision with a locomotive stopped on a crossover in the middle of nowhere. My guess here is it had tried to switch tracks and "got lost". Admittedly, both of these accidents were probably down to my signalling, but I was unable to establish why the collisions had occured in either of these two cases because the frustrating "derailment" camera hovered around in circles above my train (WHY????) as soon as contact was made with the other service, preventing me from seeing a) the location of all the other consists, b) the state of the surrounding signals and c) the state of the points on the paths of the AI services.

I realise derailments are not what this sim is about, but they do happen and it's frustrating (particularly when testing scenarios) that they often remain a complete mystery due to the camera view switching and locking itself to the "derailment" view. This was one of the many frustrating features of MSTS and the last activity I ever bother making was dogged by the player service repeatedly derailing in the same place, the reason for which I was never able to establish because I was forced into the "derailment" view each time. Personally I do not see the need to glorify train accidents with their own camera view, but that's a matter of opinion... The following two minor changes would IMO make a world of difference, although admittedly there are much more important things that need fixing at this moment in time:

1) If a derailment occurs, the camera should change to (or stay in) "free" mode - view 8 - so that the user can explore the surrounding area as normal. The only modes which really need "blocking off" following a derailment are the "cab" and "passenger" views, purely in the name of good taste.

2) It should be up to the user when to exit the scenario. By all means the sim should produce a popup, but it should a) have a "jump to location" button next to the derailment coordinates - for use when an AI service derails miles away for example - and b) have "quit" and "continue" options, the latter simply making the message disappear and allowing you to continue as normal. If you're quick you can sometimes click the globe and go back into the editor following a derailment, but most of the time you are simply forced back to the main menu and have to wait for the route to load up again, which is user-friendliness on par with MSTS.

I have attempted to edit DerailmentCamera001.bin by copying bits from the other camera .bin files, but it seems the view is fixed and hard-coded into the sim. (I deleted blueprints.pak from RailSimulatorCore before launching). I would be grateful if RSDL could take a look into this and potentially add it to their (presumably long!) list of feature requests.

JB
"Moving half of West London would be a ridiculous amount of work."
User avatar
RSderek
Very Active Forum Member
Posts: 4760
Joined: Mon Sep 10, 2007 12:19 pm
Location: London
Contact:

Re: [Request for RSDL] Changes to derailment handling.

Post by RSderek »

The bug list is tiny compared to the wish list...

The derailment camera has been discussed at great length, on what people want to happen and what should happen regarding train operators.

But I have taken note of your wish.
regards

Derek
To contact me email support@railsimulator.com, not here.
So long, and thanks for all the fish.
http://dereksiddle.blogspot.com/
User avatar
AndiS
Very Active Forum Member
Posts: 6207
Joined: Fri Sep 23, 2005 4:43 pm
Location: Jester's cell in ivory tower
Contact:

Post by AndiS »

In the light of people being worried about crash movies made in KRS, the best solution would be to freeze the picture at the time of the derail and mark the spot of the derailment by a red circle (5 or 10 metres large, painted on the ground), or alternatively by some red stick (10 m high), placed vertically at the point of derailment.

Of course, you need some explanatory alert box telling the user why the picture froze.

For AI derailments or collisions a similar marker should be placed and the camera should jump to there.

In both cases, the driver's evaluation which is printed at the end should include the exact coordinates of the location of accident. Then, you can save them and fly there in the editor.

The marker and precise coordinates are important because there can be cases where a long train runs across a whole series of switches and maybe someone changes a switch as the train passes over it. Therefore, it need not be the switch near the front which caused the derailment.
User avatar
jivebunny
Very Active Forum Member
Posts: 2015
Joined: Mon Jun 26, 2006 9:49 pm
Location: Brittany, France

Re:

Post by jivebunny »

Thanks Derek :)
AndiS wrote:In the light of people being worried about crash movies made in KRS, the best solution would be to freeze the picture at the time of the derail and mark the spot of the derailment by a red circle (5 or 10 metres large, painted on the ground), or alternatively by some red stick (10 m high), placed vertically at the point of derailment.
The aim of my post was to request more freedom, not less. A red circle and an alert box will not show us why Service A tried to drive through Service B, or how Service C ended up crashing off siding X and into river Y. To use the potential for "crash movies" as an excuse is about as credible as Auran's "blood and gore" excuse for refusing to model bounding boxes so that trains collide at diamond crossings rather than ghosting through eachother..

JB
"Moving half of West London would be a ridiculous amount of work."
User avatar
jamespetts
Well Established Forum Member
Posts: 857
Joined: Thu May 20, 2004 1:07 pm
Location: UK
Contact:

Re: [Request for RSDL] Changes to derailment handling.

Post by jamespetts »

"Good taste" is always a wholly illegitimate reason to restrict anybody's liberty. If people want to act in a taste that we consider bad, that is entirely a matter for them: we do not have to watch. It is irrational and oppressive for some people to force other people to comply with their tastes.

The current handling of derailments is indeed highly problematic for scenario creators and players alike: it would be useful if the game could pause on a derailment, with all camera options available, and give players the chance (after they have had a chance to look around to see what caused the derailment) of (1) quitting the game; (2) reverting to edit mode to fix the problem; (3) removing all the trains involved in the derailment and continuing with the scenario (unless it is a standard scenario and the player train is one of those that has derailed). Since the current derailment physics are not particularly realistic in any event, and take up a great deal of processing power, a more useful representation of derailment might simply be to shade all derailed trains red (in a similar way to the way in which stock in the scenario editing mode is shaded red when it is placed somewhere other than a track) as soon as they come into contact, etc. There should also be the option to turn on direction arrows to show the directions in which the trains were travelling when the derailment occurred, and a cross (or other suhch symbol) to show the point of the derailment.

Derek, what do you mean exactly by, "what should happen regarding train operators" here - who are the "train operators" in this context?
James E. Petts
CaptScarlet
Very Active Forum Member
Posts: 3673
Joined: Fri Nov 17, 2006 11:29 am
Location: The Netherlands

Re: [Request for RSDL] Changes to derailment handling.

Post by CaptScarlet »

jamespetts wrote: Derek, what do you mean exactly by, "what should happen regarding train operators" here - who are the "train operators" in this context?
I would have thought that was obvious, its the rail companies who are associated with the game.

John
User avatar
jivebunny
Very Active Forum Member
Posts: 2015
Joined: Mon Jun 26, 2006 9:49 pm
Location: Brittany, France

Re: [Request for RSDL] Changes to derailment handling.

Post by jivebunny »

jamespetts wrote:"Good taste" is always a wholly illegitimate reason to restrict anybody's liberty. If people want to act in a taste that we consider bad, that is entirely a matter for them: we do not have to watch. It is irrational and oppressive for some people to force other people to comply with their tastes.

The current handling of derailments is indeed highly problematic for scenario creators and players alike: it would be useful if the game could pause on a derailment, with all camera options available, and give players the chance (after they have had a chance to look around to see what caused the derailment) of (1) quitting the game; (2) reverting to edit mode to fix the problem; (3) removing all the trains involved in the derailment and continuing with the scenario (unless it is a standard scenario and the player train is one of those that has derailed). Since the current derailment physics are not particularly realistic in any event, and take up a great deal of processing power, a more useful representation of derailment might simply be to shade all derailed trains red (in a similar way to the way in which stock in the scenario editing mode is shaded red when it is placed somewhere other than a track) as soon as they come into contact, etc. There should also be the option to turn on direction arrows to show the directions in which the trains were travelling when the derailment occurred, and a cross (or other suhch symbol) to show the point of the derailment.

Derek, what do you mean exactly by, "what should happen regarding train operators" here - who are the "train operators" in this context?
Whilst the red shading and direction arrows could work, I don't think removing the visual aspect of derailments is the way forward. For a start, the way in which the train as a whole has derailed usually holds a good clue as to what's happened (the problem is we usually can't see it!). And then of course there's the simulation aspect; I wouldn't be impressed if I bought a driving game which simply paused and turned my car red if I crashed. Or a footie game which did the same to the player's team when one of them was offside. If that was what happened when a derailment occured, it would instantly remove the feeling of immersion the simulator's supposed to produce, and that's never a good thing. None of us want our trains to derail, in fact I'd imagine most of us get pretty annoyed when it happens, but when it does happen it needs to be fairly convincing, as it is now ("fairly" being the key word :lol: ). And you have to consider the casual gamers and the younger simmers out there. Whilst they're not sick-minded individuals, they're going to want their train to derail if something goes wrong, and if they lose interest then it's a small part of Rail Simulator's (bright) future that leaves with them.

With regards to Derek's quote, he was simply pointing out that there's a difference between what we - the users - want to see during / following a derailment and what the TOCs involved with the sim want us to see. They want to protect their "image" (no comment..) and don't want videos / screenshots of crashes / derailments involving their liveries. Perhaps official partner content could be listed in an encrypted file and "locked" into using the current derailment view, and then everything else not on that list allowed to use whatever new system is implemented, if any. Although in reality I'm not sure how useful this would be since changing a few .bin entries would get around it...

Not an easy one this!

JB
"Moving half of West London would be a ridiculous amount of work."
User avatar
AndiS
Very Active Forum Member
Posts: 6207
Joined: Fri Sep 23, 2005 4:43 pm
Location: Jester's cell in ivory tower
Contact:

Post by AndiS »

jivebunny wrote:Not an easy one this!
That's why I rule it out before.

If everyone would be like me, we would all run stock for which the operator is no more in business (for 50+ years). However, many if not most people love contemporary stock and here you immediately run into political issues. Operators did indeed put control over virtual models on their agenda years ago, and there is nothing we can do about it. We can try to avoid royalties but we cannot revert to a time when they did not care about the genre.

In addition, it is not only the representatives of the operators who oppose crash scenes, but also people working for the railways who do not want to see the nightmare of their profession overrepresented in a game. And everyone will confirm that accidents are much more frequent in KRS than in real life, by a huge factor.

Finally, even if you would be interested in crash sequences, realistic ones are hard to implement. Jokes like mined viaducts are simply software bugs, nothing else. The physics involved in any vehicle sliding over the ground are difficult to calculate, object deformation is the frontier of game development for games which are all about destruction, it will take years until it becomes feasible in railway simulation.

Therefore, I just give up on the crash movie issue and hope for concise, more or less abstract information on the cause which I have to avoid the next time around. Red circles or red shaded vehicles does not matter. It is information that counts for me. Of course, you could get clues from a movie, but the better mode of information transfer would be an unfiltered report from the core of the game engine "vehicle X was derailed at Y because ...".
User avatar
RSderek
Very Active Forum Member
Posts: 4760
Joined: Mon Sep 10, 2007 12:19 pm
Location: London
Contact:

Re: [Request for RSDL] Changes to derailment handling.

Post by RSderek »

I think AndiS and James are correct, what we are looking into doing is giving the users more information of why the train derailed rather than the editing the derail camera movement/navigation.

regards

Derek
To contact me email support@railsimulator.com, not here.
So long, and thanks for all the fish.
http://dereksiddle.blogspot.com/
mearle73
Been on the forums for a while
Posts: 293
Joined: Fri May 12, 2006 6:52 pm
Location: Chapel St Leonards Via Ashford Kent

Re: [Request for RSDL] Changes to derailment handling.

Post by mearle73 »

Sounds good to me
User avatar
jivebunny
Very Active Forum Member
Posts: 2015
Joined: Mon Jun 26, 2006 9:49 pm
Location: Brittany, France

Re: [Request for RSDL] Changes to derailment handling.

Post by jivebunny »

RSderek wrote:I think AndiS and James are correct, what we are looking into doing is giving the users more information of why the train derailed rather than the editing the derail camera movement/navigation.

regards

Derek
In that case we're going to need A LOT more detail:

- Exact time of collision.
- Service names for all services involved.
- Player train / Player train vs AI / AI vs AI?
- Speed each service was travelling at (taken at moment of impact /derailment)
- Was / were train(s) making a heavy brake application at time of derailment / collision?
- Coordinates of initial contact (useful for example if derailment involves two long freight trains)
- Cause i.e consist tilt, excess speed, points set incorrectly, hit buffers, rear-end collision, head-on collision, collision with stationary / derailed vehicle, "side-swipe" type collision (not sure if the sim is capable of determining the last one).
- Previous and next destination / stop / instruction for all trains involved.
- Last signal passed + state + coordinates for all trains involved (How can the correct signal be identified in busy areas such as a station throat?)
- Any points set against path(s) immediately before derailment + coordinates - (Same question as above)

I'm sure I'll think of / come across more as I experiment more with the editor.

A more flexible picture speaks a thousand words :wink: :wink:

JB
"Moving half of West London would be a ridiculous amount of work."
User avatar
jamespetts
Well Established Forum Member
Posts: 857
Joined: Thu May 20, 2004 1:07 pm
Location: UK
Contact:

Re: [Request for RSDL] Changes to derailment handling.

Post by jamespetts »

RSderek wrote:I think AndiS and James are correct, what we are looking into doing is giving the users more information of why the train derailed rather than the editing the derail camera movement/navigation.
What is also needed is the option to continue the game after the derailment by excising all the derailed vehicles, or immediately move into world/scenario editor: it is extremely frustrating when a derailment means that one has to wait a very long time while the route loads all over again just to continue using it or try to fix the problem.
Jivebunny wrote:In that case we're going to need A LOT more detail:

- Exact time of collision.
- Service names for all services involved.
- Player train / Player train vs AI / AI vs AI?
- Speed each service was travelling at (taken at moment of impact /derailment)
- Was / were train(s) making a heavy brake application at time of derailment / collision?
- Coordinates of initial contact (useful for example if derailment involves two long freight trains)
- Cause i.e consist tilt, excess speed, points set incorrectly, hit buffers, rear-end collision, head-on collision, collision with stationary / derailed vehicle, "side-swipe" type collision (not sure if the sim is capable of determining the last one).
- Previous and next destination / stop / instruction for all trains involved.
- Last signal passed + state + coordinates for all trains involved (How can the correct signal be identified in busy areas such as a station throat?)
- Any points set against path(s) immediately before derailment + coordinates - (Same question as above)
Why not just equip all the trains with virtual OMTR? ;-)
James E. Petts
User avatar
jivebunny
Very Active Forum Member
Posts: 2015
Joined: Mon Jun 26, 2006 9:49 pm
Location: Brittany, France

Re: [Request for RSDL] Changes to derailment handling.

Post by jivebunny »

jamespetts wrote:
Jivebunny wrote:In that case we're going to need A LOT more detail:

- Exact time of collision.
- Service names for all services involved.
- Player train / Player train vs AI / AI vs AI?
- Speed each service was travelling at (taken at moment of impact /derailment)
- Was / were train(s) making a heavy brake application at time of derailment / collision?
- Coordinates of initial contact (useful for example if derailment involves two long freight trains)
- Cause i.e consist tilt, excess speed, points set incorrectly, hit buffers, rear-end collision, head-on collision, collision with stationary / derailed vehicle, "side-swipe" type collision (not sure if the sim is capable of determining the last one).
- Previous and next destination / stop / instruction for all trains involved.
- Last signal passed + state + coordinates for all trains involved (How can the correct signal be identified in busy areas such as a station throat?)
- Any points set against path(s) immediately before derailment + coordinates - (Same question as above)
Why not just equip all the trains with virtual OMTR? ;-)
I was going to suggest personal CCTV kits for each and every one of us to put behind our desks, and of course random D&A tests :wink:
"Moving half of West London would be a ridiculous amount of work."
User avatar
ianm42
Very Active Forum Member
Posts: 2749
Joined: Sat Oct 27, 2001 12:00 am
Location: Basingstoke, UK
Contact:

Re: [Request for RSDL] Changes to derailment handling.

Post by ianm42 »

KRS v2.0 - after a derail, you have to fetch the breakdown crane, and put everything back on the rails again :D

8)
Locked

Return to “[RS] General RS Discussion”