(Serious) What is the official reason behind removing derailment physics from Trainz?

Disclaimer: Before you start typing your reply, I'd kindly like to let you know that I'm not here to discuss whether or not derailments should remain removed, or be restored. From what I have researched, that has been debated ever since T:ANE came out, so I'm not here to start another discussion of that type. I just want to know what is the official reason for their removal. Thank you.

With that out of the way, here we go.

So as we all know, Derailments have been part of Trainz since the first edition came out in 2001. They have been changed in ways as newer versions of Trainz came out. Finally TS12 was the last version of Trainz to feature derailments. Once T:ANE came along, the derailment physics were removed. Now I've tried researching in the past as to the reason for their removal, but that led to conflicting answers. Here are a few theories I've found through past research:

Theory 1: They were removed because multiplayer server owners were experiencing younger drivers (kids) intentionally crashing their trains on their servers.

This would actually make sense to a degree. Although one could simply add a driver command (or if it's not available have one created) to where derailment physics were turned off to discourage players from intentionally derailing trainz on their multiplayer server.

Theory 2: They were removed because of legal concerns with brands, railroads, etc...

This would seem very unlikely for the simple reason that Trainz is just a Computer game. And other train simulators past and present have their own derailment physics. I've even seen a YouTube video of another Train Simulator gameplay, where the train hit a automobile and the train had to make an emergency stop and emergency services arrived to the accident site, as well as other similar videos. Besides, Trainz had derailment physics for years until 2015, for a total of 14 years. I could go into more details about the legal aspect but I think that sums it up fine.

Theory 3: They were removed because it was decided to focus on other more important features such as graphics.

This one also seems likely as it was supposed to be T:ANE (Not TRS19) that was gonna have major graphical improvements. Don't get me wrong, T:ANE did make a number of good advances, but TRS19 ultimately got the job done well. So if your choice is between improving derailment physics or improving graphics, compatibility, surveyor tools, etc... I guess one would naturally think that the later would be better. But that leaves just one problem with this theory: If that were the case, then one would think that derailments would simply go unchanged with no updates, not necessarily removed.

---

But that's just 3 of the common theories I've read over time. So now I look to you guys, is there an official reason why derailments were removed? Remember, I'm not here to debate if they should stay removed or be reintroduced. That's a topic for another day perhaps. Oh and pretty please, don't just say: "Your not supposed to leave the rails!" or "This is a Train Simulator, not a Derailment Simulator" as that does not really add to the topic and is not exactly relevant. Plus it's a bit silly. Thank you.

N3V said the code used in TS12 did NOT work in TANE due to changing the physics system and it was not a priority to create new code for the new graphic engine and physics system. But it is on the to do list.

William

so basically an upcoming service pack?

Maybe, but those of us that have been here a while know that time doesn't work the same in N3V land as it does in the rest of the world. The to do list is very long. It might make it in TRS2030.

William

wreeder said:

Maybe, but those of us that have been here a while know that time doesn't work the same in N3V land as it does in the rest of the world. The to do list is very long. It might make it in TRS2030.

William

Click to expand...

Indeed lol.:hehe: It's been 5 years since T:ANE came out and derailments still have not been reintroduced. So it would seem they do intend to re-add them in the future, but that could be years from now. As a former staff member for War Thunder, I remember the Devs would claim to have plans to add or change certain features and then totally forget about them for a long time. I remember one example of a player reporting a bug regarding inaccurate performance stats that was considerably a big deal (it made Dev Q&A) and it took them two years to fix it even though it was a simple issue that just required 5 minutes of typing in new stats. But I digress. I guess we shall wait and see what they will do.

N3V just too lazy to implement it to the new E2 game engine as well as much of other things working fine in previous Auran Jet engine.

Post Deleted

The other issue not mentioned is that train crashes are horrific disasters & N3V and the general community here doesn't want to glorify them. By keeping derailments simple like they are, you keep that from happening. Train crashes kill people, which is not something we should be praising.

peter

JAGG said:

N3V just too lazy to implement it to the new E2 game engine as well as much of other things working fine in previous Auran Jet engine.

Click to expand...

As usual the "armchair experts" are able to tell us all exactly how they would do it if they were in charge of things, had an unlimited budget, plenty of staff and did not need to worry about paying the rent. Fortunately, for those of us who want N3V to survive so that we can continue enjoying this great simulation, N3V do not follow such advice.

PerRock said:

The other issue not mentioned is that train crashes are horrific disasters & N3V and the general community here doesn't want to glorify them. By keeping derailments simple like they are, you keep that from happening. Train crashes kill people, which is not something we should be praising.

peter

Click to expand...

First, Thank you for taking care of... The off topic comments from earlier.

Back on topic, it makes sense that they were removed simply because the physics engine was becoming out of date. And it was even mentioned that they were under consideration to be reintroduced. But that's my 2 cents.

SAUBER_KH7 said:

Back on topic, it makes sense that they were removed simply because the physics engine was becoming out of date. And it was even mentioned that they were under consideration to be reintroduced. But that's my 2 cents.

Click to expand...

Pretty much correct. The link provided by MP242 is reprinted below:-

Unfortunately with the introduction of particle effect collisions in TANE, we were unable to carry over our previous 'derailment physics' system, as you cannot have two 'physics' systems side by side (note, this is physics as in object physics, not in terms of driving physics which are separate).

We may look into derailment physics again in future, however we cannot say when this may be. As a few have mentioned, derailments are generally avoided as much as possible in railways, and as such we do feel that there are higher priority tasks for us to focus on before derailment physics. Unfortunately as we are a small team, there are limitations on how much we can do at any one time.

Click to expand...

I am all in favour of realism but not at any price. Other issues generate far more posts and "bring back" requests than derailment realism or crashes in general.

I didn't suppose too much of people to agree with me here, where a lot of blindly loyal or somehow involved ones appear. But it still doesn't make me change my opinion about N3V, I'd read too much empty promises, awkward excuses and obvious bugs ignorations. I just expressed my thought about it based on my personal experiencies of CUSTOMER. Maybe I may add another one yet. N3V is possibly pushing unsolved issues in front of them to have always some potentional reserve for next version/SP improvements. Thats maybe part of their bussiness strategy. Anyway, not any servility would make N3V better ;-)

JAGG said:

I'd read too much empty promises, awkward excuses and obvious bugs ignorations. I just expressed my thought about it based on my personal experiencies of CUSTOMER. Maybe I may add another one yet. N3V is possibly pushing unsolved issues in front of them to have always some potentional reserve for next version/SP improvements. Thats maybe part of their bussiness strategy. Anyway, not any servility would make N3V better ;-)

Click to expand...

While I don't agree entirely with your choice of words, I can understand the frustrations. One persons "empty promises" can be anothers "features we would still like to add but can't at the moment", one persons belief that bugs are being ignored can be anothers realisation that some problems are too complex to solve in the expected time with the resources available.

We all have our pet priorities of what is missing from Trainz and what needs to be "fixed first", but those priorities are as diverse as the interests of Trainz users themselves and will rarely be in agreement. To me it is a good sign that users are able to put forward their criticisms (constructive criticisms one would hope but unfortunately far too many are just negative) in a forum funded by the company they are criticising.

A common complaint is that N3V always comes out with a new version of Trainz before all the bugs and other "important" issues are fixed in the current version, but that is the nature of software development. If N3V stood still to make TRS12 "bug free" and perfect before TANE was released then we would still be waiting for the final version of TRS12 to be released with its outdated graphics engine and outdated graphics, assuming N3V somehow survived the loss of income.

Too often "blind loyalty" or "fan boy" are labels thrown at those who offer any opinion that does not agree with a negative post offered by a frustrated or angry user. That, I suspect, is part of human nature. When you run out of arguments, throw insults.

JAGG I have no ill will towards you but I do get frustrated with the constant claims that N3V are "too lazy" or "too incompetent" or "not interested" in fixing this or that issue first before they do anything else. If developing a better railroad simulation was simple then why don't the critics do it and do it better? I will always remember one poster in these forums who claimed that he was going to develop a better train simulator than N3V ever could. He even posted a few snippets of C++ code he had written to prove his worth. But that was his last post that I recall seeing.

My thoughts.

What is the cost and the the ROI? A low cost change in a low interest category might be approved. But the cost of this one may exceed the established metrics and will not happen. When you have a business to run you cannot accede to emotion or low return adventures.

pware said:

.... I do get frustrated with the constant claims that N3V are "too lazy" or "too incompetent" or "not interested" in fixing this or that issue first before they do anything else.....

Click to expand...

Well at least I do thank You for confirmation, that those claims as signs of dissatisfaction of customers are so often, that it become "constant" ;-) Such excuses like "nature of SW development" does not prove as valid. You are not going to buy a car with fender not painted just because it is nature of automotive, right? You would be forced to, if all manufacturers would offer such a car, but this is not the case. I consider the adequate pressure of the customers base on the SW developer as a must. I don't take such russian style like argumentation: "You don't like it? We don't care, go away and make it better yourselve" into the consideration. I like Trainz. I am loyal to Trainz, I was often involved in excited discussions on trainsim forums and social media groups highlighting Trainz pros and other sims cons. I am not either blind or servile just because posting on the forum run by the developer, but quite the contrary, I do consider mentioning of weaknesses here as most direct way how to let the developer know, or remind him, sorry.

JAGG said:

Well at least I do thank You for confirmation, that those claims as signs of dissatisfaction of customers are so often, that it become "constant" ;-) Such excuses like "nature of SW development" does not prove as valid. You are not going to buy a car with fender not painted just because it is nature of automotive, right? You would be forced to, if all manufacturers would offer such a car, but this is not the case. I consider the adequate pressure of the customers base on the SW developer as a must. I don't take such russian style like argumentation: "You don't like it? We don't care, go away and make it better yourselve" into the consideration. I like Trainz. I am loyal to Trainz, I was often involved in excited discussions on trainsim forums and social media groups highlighting Trainz pros and other sims cons. I am not either blind or servile just because posting on the forum run by the developer, but quite the contrary, I do consider mentioning of weaknesses here as most direct way how to let the developer know, or remind him, sorry.

Click to expand...

The auto analogy would only apply to hardware, meaning CPUs, disk drives, and the rest of the lot.

The software industry works this way, and a lot is dependent upon the size of the company, and resources meaning money.

1) A product is conceived.
2) The product is developed.
3) The is alpha tested.

This could take many months, or longer.

4) The product is put into early beta testing - a bit better than alpha testing, but not by much.

This process can last months, or even longer.

During this time no product is sold so the company is surviving on other products, hopefully there are some, support contracts if they're big enough, and their initial venture capital investment. These resources have to be managed carefully, and it's at this critical point where the company and software can become vaporware as almost happened with N3V's previous company, Auran.

5)The product is released to beta and an outside group is testing.

This process can last many, many months.

This too can take many months, and let's hope the venture capital money is still around and other products are selling. This is also why many companies don't announce new products too soon. They don't want to lose their sales of previous products when developing the new ones due to customers waiting until the new product comes out.

6) Version 1.0 is finally released barring no show stoppers.

No show stoppers means if it doesn't CTD, it's good to go. Being version 1.0 the product is going to have bugs. Bugs that were not caught in the alpha and beta testing for reasons unknown, but the usual case is there is now a larger sized group of people with more system variations to test on.

7) Version 1.0 enters into maintenance mode while a new program is developed.
8) Hot fixes are created.
9) Further beta testing, which can last many months is done.
10) HF 1.0 is released.
11) Feature requests are made by customer.
12) Feature requests are ignored.
13) SP 1 comes out after many months of beta testing.
14) New product comes out.
15) New product contains a roll-up of some of the fixes for bugs found in the previous product, and some of the new features are introduced.
16) Process repeats.

In general, and this applies to most software developers, new features are not applied to hot fixes or service packs. These are meant to repair bugs discovered by customers and the QA team. These bug-lists are an ongoing thing, which are done as new products are developed to keep new product in the pipeline. It's usually not a single person doing both jobs, but instead multiple employees are assigned to tackle new product development and others for product support.

Software development is done in what is called man-hours. Allocating man-hours to a software budget is an expensive process and resources are planned and allocated carefully. Long term bugs, those that aren't critical for operation but are annoying, are moved to the bottom of the list until there's time to fix them. It's not that they're pushed off, it's there's not enough time or resources to tackle those. As we've seen, bug fixes do happen to these annoyances, but they are usually far in the future on a new product, or sometimes not at all.

The somewhat generalized process shown above applies to all software products no matter what company is developing it. The biggest determining factor is company size, and budgets.