Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: All routes and trains lost after update?

  1. #1
    Join Date
    Jun 2022
    Posts
    1

    Default All routes and trains lost after update?

    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.

  2. #2
    Join Date
    Dec 2006
    Location
    Brockville, ON, CA
    Posts
    2,990

    Default

    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 :-)

  3. #3

    Default

    >>>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.
    ............Vince ..............
    ...... Author NECv4 .......
    .... LIRR BUILD PHOTOS ....
    ...... Eschew Obsfucation ......

    On the The Statue of Liberty in New York Harbor there is a Tablet. On it is written:
    "Give me your tired, your poor, your huddled masses yearning to breathe free,
    the wretched refuse of your teeming shore, send these, the homeless, tempest-tossed to me,
    I lift my lamp beside the golden door!"

  4. #4

    Default

    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.

  5. #5
    Join Date
    Sep 2006
    Location
    .
    Posts
    2,867

    Default

    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.

  6. #6
    Join Date
    Jun 2004
    Location
    Perth, WA, Australia.
    Posts
    591

    Default

    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.

  7. #7
    Join Date
    Nov 1999
    Location
    Eltham, Victoria, Australia.
    Posts
    7,202

    Default

    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.
    Cheers
    Derek

  8. #8
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    2,789

    Default

    Quote Originally Posted by superheatedsteam View Post
    ....
    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.
    Cheers, Gerry
    It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
    Forever, ridin' drag in railroad knowledge.


  9. #9
    Join Date
    Jun 2004
    Location
    Perth, WA, Australia.
    Posts
    591

    Default

    Hi Derek,

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

    Quote Originally Posted by derekmorton View Post
    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

  10. #10
    Join Date
    Sep 2006
    Location
    .
    Posts
    2,867

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •