[pschlik]

With Unstable builds returned, and my modding efforts returning to lighting (which is a pain to adjust without reloading the entire game!) after weeks of working on physics, I figured now is a good time to get going on this.

After an afternoon of experimenting, I have the sim scanning for updates of any files in the GLOBAL, ROUTES, SOUND, and TRAINS folders (these are handled separately for organization reasons, a locomotive doesn't need to know if anything changed in the ROUTES folder) and a tickbox in the options to turn this on or off. The only actual behavior I have implemented so far is that any file update anywhere in the TRAINS folder will cause every locomotive and train car to reload the .eng/.wag file, then unload and reload the model in the 3D world. For the actual version of the feature, locomotives and train cars should only be reloaded when a file change might actually affect that specific locomotive or train car, but I first want to get reloading working at all.

Unsurprisingly, at first the one locomotive I was working with was quite unhappy to be reloaded. Things seem to get upset when you change data while the data is being used... But by moving the reload to the update thread (unfortunately, this causes a small lag spike when reloading files, which might be the price to pay for real-time updates. Still vastly faster than closing and reopening the game!) and fixing a couple of behaviors that could be considered bugs (for some reason, reloading a diesel locomotive would cause additional nonexistant diesel engines to be added to the list???), I can force a lot of the parameters of the locomotive to change in real time!

Right now it causes some undesired effects, like resetting the controls to their default state, and it's a bit too easy to find ways to cause a crash, but with how unexpectedly easy it was to get to this point I think this feature has a future. Chasing down the few specific edge cases that don't seem to work (for example, reloading the .eng file doesn't seem to respect any changes made to the cab view) and adding some extra behaviors to initialization so that some things (like the controls) are not reset when 'hot reloading' (I'm going to be referring to this feature as "hot reloading" as this is the terminology used in the coding world when processing file changes in real time) should make this very usable.

I cannot say how things will work beyond reloading locomotives and train cars, obviously it would be great to reload scenery, but even trains only is a good feature to have. I can already guess that there will be some files that would be especially unhappy to be hot reloaded, like the track database, but so far, I see no catastrophic limitations.

[Weter]

Hello.
Would ask to clarify some unclear moments.

Quote

The only actual behavior is that any file update anywhere in the TRAINS folder will cause every locomotive and train car to reload the .eng/.wag file, then unload and reload the model in the 3D world. For the actual version of the feature, locomotives and train cars should only be reloaded when a file change might actually affect that specific locomotive or train car, but I first want to get reloading working at all.

So, not each and every piece of stock in simulation session, but only related to changed files?

[pschlik]

There's no reason to reload the GP38-2 and 30 different freight cars if you only changed the Dash 9, that would be far too slow, so yes only the things that are changed should be reloaded. I think I will add a keybind to force reload the entire scene, just in case the system fails to detect a change or you forgot to enable the option in the settings, but for the automatic reloading that will be set up to do the minimum number of file reading operations as those are much slower than most other calculations.

[ExRail]

This is brilliant, and are exactly how Modloader for GTA-SA works. Texture and geometry and more gets reloaded if a change is detected.
It makes every other method feels archaic.

Regarding reloading the hole game to see a change:
Thanks to the people that made the Open Rails Save Game function work so well, by going back to the exactly same camera and position after a reload.
That has been a time saver instead of having to navigate to the same place 5 miles away from the train, to see a change.

[Weter]

Thanks for tip, Jan.
It's especially useful for timetable mode debugging, spanning 24-h period of simulation.

Thanks Phillip.
So, target reload of affected stock piece is now the future functioning?

[Guille592]

This (if I understood correctly) could be a workaround to change for example destination boards, simply swap textures or make a .bat to load a new texture and let the sim reload it... Would love to see this inn action, yup.

[pschlik]

That is not the intended use at all. Reloading the whole thing just to change a texture or freight animation is inefficient overkill. Reloading overwrites everything, even stuff that hasn't been changed, since there's no way to know what has or hasn't changed (at least, not without doing a lot of extra work that is not worth it), which has a lot of side effects beyond changing your texture that you probably don't want. While I can set things up so that a few common things aren't reset, like the position of the main controls, I have no clue how more complicated systems will react and some things will not cleanly reset. Hot reloading is for development only, the endless possibilities for it to cause strange things are not appropriate for regular operations.

[Guille592]

We will be still scratching our heads on how to make "dynamic destinations" then. 😅 Anyways, it will come in handy like you said for development.

[pschlik]

Bit of a status update... I have started chasing down specific things that weren't working or were being re-initialized to an undesired state. Controls are no longer reset to the default position on reloading (still set to the default position when you first load in though), the brake system is force-initialized on anything that is updated (technically, this is not remembering the previous state of the brake system, but the alternative is the brake system being completely broken on reload so...), edits to .sms files are properly captured (unless include files are used, I will need to determine how to handle include files), particle emitters and cab views are actually reset on reloading instead of perpetually adding more and more instances of each (locomotive with 100 cabs? yes, OR allows it), and most importantly, updates to shapes and textures are captured in real time.

Getting shapes and textures to work was a bit more interesting, and a good starting point for figuring out how more systems will be handled. (It also helps that I should only need to set up shapes and textures once, then it can be used for both trains and scenery, in theory.) Shapes and textures rely on a lot of caching, OR specifically avoids reloading a file that's already loaded which is the opposite of what we want this time. So with a bunch of extra behavior, a change in a texture file will force that texture to be reloaded from scratch next time it is used, then will also force any shapes using that texture to be reloaded from scratch. (Similarly, updating a shape file will force the shape file to be reloaded from scratch too.) For testing, I still have trains being reloaded upon any file change, but the shapes and textures only reload when needed. It won't be as easy to make trains only reload when needed.

As a practical example, I have Paint.net open with the main texture file of the SD70M #7006 shape and an unsaved edit to add red "HELLO" text to the right side of the locomotive (you can tell the changes have not been saved as the file thumbnail has the golden * in the top left corner, and the file name in the title bar is preceded by a *). The locomotive in the 3D world doesn't have this edit.
https://i.ibb.co/kVtZHg4f/before-edit.jpg

But when I save the file (note that the golden * has disappeared, and the file name in the title bar doesn't have a * anymore), the locomotive in the 3D world now has the "HELLO" text present. These two screenshots are just seconds apart.
https://i.ibb.co/pBnhPJ2h/after-edit.jpg

Hopefully it is very obvious how this makes texturing much easier, as the wait to observe updates to textures can be reduced from a minute to a second.

What makes this situation even more devious is that the locomotive pictured here is not EMDX #7006. I took a different locomotive and edited the .eng file in real time to point at the shape file for EMDX #7006. At first, the model appeared grey as none of the texture files were in the correct spot, but each time I copied a texture file over it immediately appeared on the model. The system kinda deals with it. Unless you cause a more major error than just a missing shape or missing texture.


Next I'm going to chase down sounds and cabviews more. Figuring out how to handle sounds with include files will be important to figuring out how to handle trains with include files, shape files, cab view files, sound files...lots of files to keep track of! As for cab views, despite all the texture work, cab views don't seem to reflect changes made to texture files in real time. Probably something different about texture handling that needs to be told manually to reload textures, but I will be quite happy when I don't need to restart the whole program to move things around in cab views by a few pixels!

I don't think I'm going to toss this into unstable until I have trains reloading only when needed, unless that step takes too long. It is already useable even when reloading files unnecessarily, but I haven't tried using the feature in an activity with more than one train as I fear the potential for lag (and the potential for AI trains to get confused).

[Weter]

Hello.
It's now more obvious, why tickbox is needed:

Quote

Shapes and textures rely on a lot of caching, OR specifically avoids reloading a file that's already loaded which is the opposite of what we want this time. So with a bunch of extra behavior, a change in a texture file will force that texture to be reloaded from scratch next time it is used, then will also force any shapes using that texture to be reloaded from scratch.

Please, shrink Your screenshots - while they being 6+MB, browser can't wait them to be streamed fully and sets @posted image@ placeholders instead into text.

[pschlik]

Hot reloading for trains only (scenery coming eventually? shouldn't be too difficult...) is now on unstable. Automatic hot reloading is disabled by default but can be enabled in the experimental tab of the options.

Hot reloading will reload the visual model of an engine or wagon whenever...

• a shape used by the engine or wagon is updated (I made sure to check for updates to freight animations and coupler shapes as well)
• a texture used by the engine or wagon is updated (including textures used by shapes, which triggers an update for the shape as well, light textures, particle emitter textures, and cabview textures)
• a .cvf file used by the engine is updated (changes to the cabview will be re-read, but the visual model has to be reloaded for those changes to appear)
• an .sms file used by the engine or wagon is updated (sounds will be re-read, and then the visual model reload also reloads audio)
• an .inc file used by any .cvf or .sms the engine or wagon uses is updated (will also re-read the affected files)
• a .wav file used by the sounds of the engine or wagon is updated (will also re-read any affected .sms files)

Reloading the visual model is not very disruptive, the model will disappear from view for a split second then reappear with everything visual/sound related reset. It is functionally equivalent to moving the camera far away and then returning, which is something that is supposed to happen normally so it's pretty smooth and fast.


What is more disruptive is reloading both the simulated and visual model of the engine or wagon whenever...

• the main .eng/.wag file used by the engine or wagon is updated (also checks for updates to the OR-specific .eng/.wag in the "OpenRails" folder)
• an .inc file used by the .eng/.wag of the engine or wagon is updated

While this does allow for things like moving around lights and particle emitters, it also lets you do things that might not work so well like changing the brake system used. And just reloading the simulated model, even when nothing has changed, can cause funny business, so don't expect flawless results when attempting changes like that. I especially don't know what will happen if a power supply or train control script is reloaded, but I suspect external scripts will not know what to do when a hot reload of the simulation happens.

Part of the 'things that might not work' includes introducing errors. If you save a file update with a mistake in it, Open Rails will happily reload that file and crash. Be careful when making updates, and don't try to use hot reloading on trains with errors like missing files as that can interfere with hot reloading. Similarly, hot reloading will try to handle renamed files, moved files, and copied/new files, but these kinds of changes can cause OR to consider the files missing, and missing files do not trigger hot reloads. Hot reloading will work most reliably when an existing file is changed by saving it or overwriting it in place.


I can't guarantee that every change will trigger a hot reload automatically when expected. For the sake of efficiency most of the 'thinking' for hot reloading only happens when a file is changed and then hot reload will only actually happen if I have manually set it up so that a detected change actually causes something to happen. While making everything reload with every file change no matter what would be very reliable at getting changes to show up, like I said that is dumb for performance reasons. More things can be added to the list of hot reload triggers, and more testing is needed to see what needs to be added.

Also, I suspect some changes, even if detected, may not show up correctly. While I have focused on shapes, textures, cabs, and sounds, at multiple steps in the process I encountered issues caused by reloaded data merely adding on to existing data instead of overwriting it. These kinds of things normally don't cause trouble as normally you only load a wagon once, so nobody ever considered that maybe the list of cabviews should be reset before attempting to add any cabviews. It is not hard to make such things work, but it is hard to find all the cases where that might happen without just trying more things.

And while reloading the simulation for a train can cause issues, I do want it to be mostly seamless for regular content. So far, I have made sure that a train should still be able to move after hot reloading it, but a lot more experimenting is needed to make reloading as smooth as possible.

[jonas]

I'm impressed. I replaced and renamed some ace texture files on a locomotive and it was immediately visible on the locomotive.
As a route builder, I'm looking forward to the simultaneous display of changed scenery objects. Thank you, Phillip, for the undoubtedly time-consuming work you've done so far, and thank you also for the prompt manual update.
Greetings
Jonas

[Weter]

Hello.
Happy Holidays.
Some questions, if You don't mind:

Quote

a .cvf file, used by the engine is updated (changes to the cabview will be re-read, but the visual model has to be reloaded for those changes to appear)

Re-load of game session is still needed here?

Quote

an .sms file used by the engine or wagon is updated (sounds will be re-read, and then the visual model reload also reloads audio)

So, as above, any changes in shape or texture are still needed to re-load the vehicle with updated sounds?

[albertosaurio65]

Hi,
I was testing this functionality, and first of all, it was giving me an error because I didn't have a SOUND folder along with the global, routes... folder. Creating it, even though it was empty, solved this.

Then I tried changes on a locomotive by overwriting the .ace file, but the following error appeared.

Error: System.ArgumentException: The path is not of a legal form.
   at System.IO.Path.NewNormalizePath(String path, Int32 maxPathLength, Boolean expandShortPaths)
   at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
   at System.IO.Path.GetFullPathInternal(String path)
   at System.IO.Path.GetFullPath(String path)
   at Orts.Viewer3D.RollingStock.CABTextureManager.GetStale(String texPath) in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\RollingStock\MSTSLocomotiveViewer.cs:line 1190
   at Orts.Viewer3D.RollingStock.CabRenderer.CheckStale() in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\RollingStock\MSTSLocomotiveViewer.cs:line 1659
   at Orts.Viewer3D.RollingStock.MSTSLocomotiveViewer.CheckStaleTextures() in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\RollingStock\MSTSLocomotiveViewer.cs:line 426
   at Orts.Viewer3D.Viewer.ProcessGraphicsFileUpdates() in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Viewer.cs:line 1084
   at Orts.Viewer3D.Viewer.Update(RenderFrame frame, Single elapsedRealTime) in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Viewer.cs:line 832
   at Orts.Viewer3D.Processes.GameStateViewer3D.Update(RenderFrame frame, Double totalRealSeconds) in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\GameStateViewer3D.cs:line 117
   at Orts.Viewer3D.Processes.UpdaterProcess.Update() in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:line 131
   at Orts.Viewer3D.Processes.UpdaterProcess.DoUpdate() in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:line 108
   at Orts.Viewer3D.Processes.UpdaterProcess.UpdaterThread() in P:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\UpdaterProcess.cs:line 74
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

I wanted to make sure it wasn't the case you explained about a corrupted file causing it to close, so I restarted it with the changes, but everything was fine. The locomotive includes multiple inc in the ENG, as well as different routes for the sounds it uses and the cab.

[pschlik]

Weter, on 31 December 2025 - 05:09 AM, said:

Re-load of game session is still needed here?

No, that is done automatically. Even though the cabview is not part of the 3D model of a train, the 3D model needs to be reloaded to reload the cab view, which is exactly what is done already.

Weter, on 31 December 2025 - 05:09 AM, said:

So, as above, any changes in shape or texture are still needed to re-load the vehicle with updated sounds?

Not sure what you mean. Changing anything related to sounds will cause the whole model to be reloaded, even if nothing changed about the shape or textures.

Albertosaurio65, on 31 December 2025 - 06:05 AM, said:

I was testing this functionality, and first of all, it was giving me an error because I didn't have a SOUND folder along with the global, routes... folder. Creating it, even though it was empty, solved this.

I did not know OR would start without a SOUND folder, I can make it so that missing folders are ignored.

Albertosaurio65, on 31 December 2025 - 06:05 AM, said:

Then I tried changes on a locomotive by overwriting the .ace file, but the following error appeared.

I think that means there's a cab view control with no texture attached. I have avoided setting up any of my cabs like that but it's definitely possible. I can check for those and skip them.