[Csantucci]

Our www.trainsimhobby.net forum had its yearly show in an electronics fair in Forlì, near Bologna, where I could show OR.
The route developers showed a beta version of the MSTS "Nodo di Roma" route, reproducing the first section of practically all railway lines departing from Rome. It's a very heavy route in terms of memory needed. When I run a path in explore mode with OR, memory rose to more than 2,6 GB, so that I got memory overflows even with the /LARGEADDRESSAWARE version (as I can't go beyond 3 GB on my notebook).
But when I analysed the attached logfile
 OpenRailsLog_nodoRoma.zip (9.1K)
Number of downloads: 273
I had a surprise. As can be seen, among the textures that couldn't be loaded because of insufficient memory there were NIGHT textures, even if I run at daylight.
So I provisionally renamed the NIGHT folder to NIGHT1, rerun the route and the memory needed fell to 2,04 GB (more than 550 MB less!), and I did get no more memory overflow errors, as OR didn't find and therefore didn't load the night textures.
After reasoning on it I understand that the implemented way is the easiest, because so all night textures are already there when there is the day-to-night transition. However it would be nice if a smarter solution could be implemented, where night textures aren't loaded where time of day is "far" enough from sunset. Could this be possible? This would spare compute time, considerable memory and would reduce latency due to disk work.

A less important error that can be found in the logfile is that about this type of line couples:

arning: Expected end of block; got 'image' in d:\programmi\microsoft games\train simulator\routes\italia31\shapes\cartelli_attenzione_1.s:line 94

Information: Expected block image; got comment in d:\programmi\microsoft games\train simulator\routes\italia31\shapes\cartelli_attenzione_1.s:line 94

This is due to the fact that that shape is in source version. The line causing problems is a line like this one:

image ( #___Cartelli_Stazione.ace )

or like this one

image ( _AT_cart_lampioni.ace )

The OR parser considers those non-alphanumeric chars in front of the .ace file name as comment starts, instead of considering them as parts of the filename. Instead Shape Viewer, MSTS and the Route Riter .s file compiler interpret this well. Also OR interprets well the compiled file.

[Genma Saotome]

For a long time now I've been requesting that OR implement night textures to turn "on" & "off" by slipping the necessary data into the .sd file. So long as it is after the closing MSTS parenthesis MSTS doesn't mind at all. The "necessary data" could be relative to sunset / sunrise (which would make the most sense), or absolute to the clock for those situations where that might apply.

To address the memory issue you mentioned OR could check an array of data periodically (e.g., once every 10, 15, or 30 minutes) to see what will turn "on" in the next period and load those textures (and turn "off" any that can be turned off). The array gets refreshed when the loader sends new data.

Other than adding the lines to the .sd file it doesn't strike me as too difficult to add, but I suppose there is always a chance something is lurking in the idea. A good editor (e.g., emeditor pro) that can grep file sets could find all the shapes that use night textures in a flash to converting to the new way doesn't need to be complete drudgery.

[James Ross]

Not sure what sd files are doing here, they're irrelevant to the issue at hand. The loading issue certainly could be fixed and I'm sure many people would love it being fixed.

[Csantucci]

Thanks James, I'm happy you agree on it. I hope a volunteer for this improvement can be found (yourself?), as this is beyond my limited software capabilities.

[Genma Saotome]

James Ross, on 13 December 2013 - 07:20 AM, said:

Not sure what sd files are doing here, they're irrelevant to the issue at hand. The loading issue certainly could be fixed and I'm sure many people would love it being fixed.

From the basenote:

Quote

However it would be nice if a smarter solution could be implemented, where night textures aren't loaded where time of day is "far" enough from sunset. Could this be possible? This would spare compute time, considerable memory and would reduce latency due to disk work.

I should have included it in my reply.

[James Ross]

Genma Saotome, on 13 December 2013 - 09:25 AM, said:

I should have included it in my reply.

Sorry, must have skimmed over that in my haste to reply. :oldstry:

As to fixing it, yes, it's not going to be brilliantly easy, but I think the best plan is to change the current place we load day + night textures (in SceneryMaterial..ctor) to simply find those textures (if they exist, for night) and then add a separate method to actually load. This method would be called between initial loading and them being made visible (somewhere in the bottom of WorldFile..ctor probably), and then called again each time we transition from day to night or back and have that load/discard as needed (if we're feeling smart, do it a few minutes before the switch to load and then again a few minutes after to discard).

[Genma Saotome]

James Ross, on 13 December 2013 - 05:08 PM, said:

Sorry, must have skimmed over that in my haste to reply. :oldstry:

As to fixing it, yes, it's not going to be brilliantly easy, but I think the best plan is to change the current place we load day + night textures (in SceneryMaterial..ctor) to simply find those textures (if they exist, for night) and then add a separate method to actually load. This method would be called between initial loading and them being made visible (somewhere in the bottom of WorldFile..ctor probably), and then called again each time we transition from day to night or back and have that load/discard as needed (if we're feeling smart, do it a few minutes before the switch to load and then again a few minutes after to discard).

Pretty much what I was thinking too albeit w/ the.sd data, something roughly akin to: the loader checks the .sd file (I'm assuming the Loader does process the .sd file) for the ESD_Alternative_Texture() value and if night checks further to see if the .sd file has the turn-on time (may I add here that if KUJU had done this feature this time of day would probably have gone the world file where, like ESD_Detail_Level() the Route Builder could change the value on an instance by instance basis). The Loader forwards either the time it finds (or something equal to sunset) along with whatever else it gives and it gets held as some sort of list. Periodically the game loop checks the list to assess if any are due in the next period and if yes, acquires the textures. If the .sd data includes the time to turn off (which it should) this can address the discard as well. For error control, if the night texture isn't in the directory as expected, use the day texture instead.

From July, 2010: an example of the .sd

[Csantucci]

Interesting enhancement, however at the moment I'd be happy even without enhancing the .sd file, which makes things easier. By the way, does MSTS tolerate such .sd file syntax?

[copperpen]

Far as I can work out, in any txt type file, if MSTS comes across anything that does not fit the defined parameter set, it is ignored unless the parameter has no associated data.

[Genma Saotome]

Csantucci, on 14 December 2013 - 12:14 AM, said:

Interesting enhancement, however at the moment I'd be happy even without enhancing the .sd file, which makes things easier. By the way, does MSTS tolerate such .sd file syntax?

Yes (tested). I assume it works because it's after the closing parenthesis. If I knew how code C# reasonably well I'd have added this feature myself in 2010.