All routes and trains lost after update?

[Peoro902]

Hello,

Unfortunately, I lost all of the game's files (all trains and routes, mostly MSTS-based stuff) irrevocably after "trying to" update ORTS.
Immediately after the update (1.4), I couldn't access to the resource folder anymore, noticing that all of the files were gone, whereupon I concluded that this was most likely caused by the update (?).
I didn't thought of creating a back-up of the folder, since I didn't see that coming after all. Now there seems to be no way to restore the files (most of them were / are not downloadable anymore), which is just a shame.

Does someone know how and / or why this happened? I couldn't find anything on the internet that even remotely matches my problem.

[charland]

Little surprised to hear this. Two weeks ago I downloaded and installed v1.4 with no trouble. The download is named differently then v1.3 so is have one of both. They both point to the same Train Simulator folder that is separate from the two program folders.

Was your Train Simulator folder inside your Open Rails folder?

Paul :-)

[Vince]

>>>Peoro902

If you had any train sim content installed in the Open Rails folder they are gone.
OR folder contents get erased on an update.

[rt35ge]

Making backup folders is a MUST! Poor guy learned his lesson the hard way. I got 3 sets of backups on most everything I consider important on my computer.

[geepster775]

With MSTS, your routes and rolling stock were a subfolder underneath your main MSTS executables. No problem since your MSTS executables never upgraded or changed.

With Open Rails you cannot nest your routes and rolling stock inside the Open Rails executables folder. The executables (which change quite often) folder and content folders both have to sit side by side.

New applications often need more attention than the usual MSTS-think.

Its not really a loss when you now have the opportunity to start fresh with Open Rails exclusive content anyway. Just because Open Rails could run older MSTS content didn't mean it was the best approach or was preferred by any means.

[superheatedsteam]

To be fair, the behaviour of the OR updater where it deletes all files and folders within the application folder and more importantly potentially all of a users data is not the norm or ordinary expected behaviour in 2022.

Most installation software for Windows operating systems use MSI. The advantage of MSI, beyond system file version control it that when uninstalling or upgrading an application, MSI will only remove or update the files that were part of the initial install. Sometimes operators do things that programmers don't expect. In the case of OR, I could find to explicit information warning that your data must not be stored under the OR application folder.

If the OR updater has the potential to delete the users 3rd party data then the least it can do is challenge the operator with a warning that this is a possibility, then give the the operator the option to not proceed with the update and/or click on OK I understand this in order to proceed.

[derekmorton]

At the moment we are stuck to windows.
MSI is an installer systems that ties us to Microsoft, this is NOT a good thing.

We need to be cross platform, therefore MSI is not a choice.

The OR updater may not be the best option today, but going forward it will be.

Routes built with OR in mind do not install in the OR folder structure.

[R. Steele]

....
If the OR updater has the potential to delete the users 3rd party data then the least it can do is challenge the operator with a warning that this is a possibility, then give the the operator the option to not proceed with the update and/or click on OK I understand this in order to proceed.

I've looked and cannot find a warning in the manual, common sense, and good practice dictate there should be one, as you suggest.

[superheatedsteam]

Hi Derek,

I fear you may have miss-understood my post so I will address your posts on a paragraph by paragraph basis.

At the moment we are stuck to windows.
MSI is an installer systems that ties us to Microsoft, this is NOT a good thing.

I concur. However, currently OR is only being released as a Microsoft Windows application. I too would prefer that Linux and Apple operating systems versions of OR were also available but currently they are not. So my focus/discussion/comparison of the common use of MSI as a benchmark of operator experience and expectations in relation to the upgrading of currently installed software in a Windows operating system environment are valid and relevant.

We need to be cross platform, therefore MSI is not a choice.

I am not suggesting that MSI be used as the installation platform of choice for OR. In fact MSI is not used for the installation of OR itself or by Updater.exe. What I am saying is that MSI is the predominant installer of choice for most applications developed for the Windows operating system and in general there is a very good reason for employing that delivery method. When it comes to end user experience, when installing or upgrading a software application on a Windows operating system, MSI is predominantly used. This sets a bar, an expectation, of what the user experiences each time they perform an upgrade of an application on their computer. With that in mind, from a non computer savy end users perspective, the running of an update/upgrade of an application should not result in the loss of a users data or customisation settings for that application, unless they are informed prior/during the upgrade process that this is going to occur.

The OR updater may not be the best option today, but going forward it will be.

There is nothing wrong with the current updater, with the exception that it does not warn the operator that running the update, via the convenient, built in update process within the OR application itself, that the update is going to delete all their 3rd party data, if that data is located within the OR application folder.

Routes built with OR in mind do not install in the OR folder structure.

I concur, but if I decide as an end user to install or post install, move the route/rail vehicle/cabview etc, data to a sub folder within the OR installation folder on my computer, which to be frank is not without precident in the real world, then I should be warned that running an upgrade of my application has the potential to also delete all my content data.

Like yourself I have many years of experience in the IT industry and I have a reasonable understanding of how computers work at the hardware, operating system and application levels. Personally, I have appropriate backups so that in the event of a complete disaster, I still have the ability to restore my data on another computer, short of a global EMP event. That's great for me but of no good to an end user, who may not have my years of IT experience. Most operators expect an upgrade of an application on their PC or phone to occur without a catistrophic loss of their personal data.

Any software developer with an iota of empathy for the 'users' of their software would, dare I say should, understand that not everybody that uses that software, has the same deep and though understanding of the finer points of software engineering or best practice at the time of release.

I have had the unfortunate experience of discussing replicatable faults in software with the 'engineers' that programmed those faults, and they in turn expressed the opinion that the software they had written was working “by design” and end users should not make mistakes. In my opinion this is the pinnacle of bastardry and not something that should be encouraged or supported for an open source project. We should ideally all work together towards a common goal of a superior software application to fullfill the wants and desires of as large and diverse a community of train simulation operators as possible. Assuming that 'all' users of OpenRails have the same collective memory and/or experience of long term experienced users of MSTS/OR as well as the developers of the OpenRails application itself is an exercise in hubris.

I'm observing something in the OR software I believe needs to be improved for the needs of the many and I'm calling it out. If it is fixed or not will not impact on me, but it may help some other unfortunate operartor in the future.

Open Rails Update problem OR update problem. // for google bots attention

Standing off soap box now.

Cheers,

Marek

[geepster775]

95% of the user base is coming from the world of MSTS, which already had established all the routes and rolling stock assets in your 1MSTS directory, which does sit parallel to your Open Rails executables. The initial OR installer makes no overt effort to relocated them, it just worked with wherever the files were put during MSTS installation. It takes active user relocation effort to place them in jeopardy inside the OR executables folder. In the same way it takes active user oversight to never generate adequate backups. Should there be a mention in the manual deterring user efforts to relocate files in certain unstable locations, sure, I can agree with that. But no software driven repetitive warnings with every update. Thats alarming too many people needlessly. I understand the zapping of old may not be typical, but if it is done to eliminate murky support headaches given the frequency of updates that some users, but not all, may make, then I have no problem with breaking standards. Everything here was user activated double mis-step combined with too much historical MSTS-think which we need to break out of.

[rdayt]

Here, try this. https://www.ccleaner.com/recuva/download The free one is good enough for what you want.
It'll find your files unless you've wiped them with a file wiper. You haven't.

Randy

[derekmorton]

>I have had the unfortunate experience of discussing replicatable faults in software with the 'engineers' that programmed those faults, and they in turn expressed the opinion that the software they had written was working “by design

Hi Marek,

I have been in this place like you.
I have to say that if I was to write a long version, it would certainly look like yours.

I think that Gerry has hit the nail on the head with the idea of a warning from the updater, and a note in the manual.
New users will not see the warning in the manual, but they will see the warning from the updater.

I am sure that we do not see any where near all of the deletes that happen, only the few that post about it.

So yes, we are all going the same direction.

I will post a link of this thread over at Elvas to bring it to the attention of the OR management team.

[geepster775]

Oh stop it, Derek.

This is not a software design problem. Neither the OR installer or updater actively places your route and rolling stock files in jeopardy. It is a MORON USER problem. Moron users with too much 'MSTS on the brain' who take active steps on their own behalf to relocate content files around on their hard drives so that their OR installation looks like their MSTS installation (why on earth?) that results in said content ending up in jeopardy. If anyone is out there moving files around on their hard drives, they are not 'green, innocent, newbies'.

It is an absurd proposal to throw chronic alerts in the face of those who update frequently, making the updater look nefarious or rogue or something to be feared in the eyes of regular folk, just because there are a handful of MORONS out there who rarely update and that have taken active steps on their hard drives to place their content in jeopardy.

There may be a few more out there that we don't hear about, but then again they are probably quietly embarrassed they did something really dumb that jettisoned their content by accident and they don't want to bring their blunder to anyone's attention. Usually, they just learned the hard way that, gosh, OR really is not MSTS. Imagine that.

Put a warning in the manual. If they don't read the manual, then that's a moron user problem that the rest of us shouldn't have to underwrite by tolerating excessive nag alerts. It is not our job to baby-proof the software for those who don't read the instructions.

[ftldave]

What you are seeing here happens a lot in the open source software world. Common sense gets ignored because of ideology, good ideas like sensible warnings and suggestions for helpful software improvements too often get dismissed out of hand.

That said, not backing up before any major software upgrade is, indeed, asking for disaster, learning a bitter lesson the hard way. Backups are our friends. Backup. Backup the backup and put that one someplace else 'cause it will be needed, sooner or later.

But sad to see, but not so unexpected, the lousy open-source world style "you are a moron because you don't think just like I do" response. Sheesh.

[R. Steele]

...the lousy open-source world style "you are a moron because you don't think just like I do" response. Sheesh.

Dave, I am just not sure how to interpret this sentence...is the open source style "lousy" ( dubious ) or is the open source style somehow related to everyone thinking the same and when you don't you're a moron...(also dubious ). Maybe I'm a little too obtuse this morning, could you offer clarification?