[Genma Saotome]

An example of the issue on car spawers: Tracks are black, roads are dark cyan. Every track located on "dirt" colored tertex is crossed by a road (excluding the yard tracks, but they have parallel roads present).. None of these tracks would be used outside of specific activities to work them and so none of these roads would need cars to be spawned on them except per an activity.

Click on image to enlarge to full size.



In this example (a different route than above),. EVERY right to left road in view will have tracks on it. Only two top to bottom roads will not have tracks. No expected activity would make use of more than three streets. I'd want car spawners activity on all streets crossed but none on any parallel streets and of course which streets those are will be different for each activity.i

Click on image to enlarge to full size.

[YoRyan]

I'd roll scenery customization into the future activity format - I don't think this is something the Kuju structure could do very elegantly.

[Genma Saotome]

YoRyan, on 04 September 2020 - 09:45 PM, said:

Still too much work. No activity designer is going to be bothered to turn off car spawners by hand. The simulator should be able to manage its resources automatically.

Oh please. Every car, locomotive, active trains, and every car in loose consists are "turned" on by activity designers -- for each activity. At any rate, it might be much more reasonable to have a list of spawners to turn off on an activities by activity basis. For most routes that would probably be an empty list. For peculiar situations, such as the examples I'm citing the "turn-off" list would be identical for most activities -- you just copy/paste/rename the one correct list for most activities and then do some editing as needed for the few where things would be "on".

YoRyan, on 04 September 2020 - 09:45 PM, said:

As for siding markers, we already have an "automatic" mode that only displays markers for sidings relevant to the current activity. Unfortunately, it's not documented... you have to press Shift+F6 until you cycle to it.

Is this a list or the proximity/brightness feature?

[Genma Saotome]

YoRyan, on 05 September 2020 - 12:34 PM, said:

I'd roll scenery customization into the future activity format - I don't think this is something the Kuju structure could do very elegantly.

Fair enough.

The KUJU straight-jacket has controlled how routes look for decades. Break free of that and open one's mind to the possibilities and suddenly things like an extended view distance can change all sorts of things. Ditto for activities -- consider Rob's timetable as one example. As doors swing open people will walk thru them and on doing so will be asking "please change X so I can do this neat idea I have".

[YoRyan]

Genma Saotome, on 05 September 2020 - 12:39 PM, said:

Oh please. Every car, locomotive, active trains, and every car in loose consists are "turned" on by activity designers -- for each activity.

The problem is that you're selling this feature as a "performance improvement," a domain that (for the most part) exists outside of the purview of activity design. So you want to turn off a few car spawners to save a few frames. What about explore the route mode, multiplayer mode, and timetable mode? What if I have a fast machine, and I'd rather render all car spawners to maximize my immersion? Why do you insist on making this choice for me?

Genma Saotome, on 05 September 2020 - 12:39 PM, said:

Is this a list or the proximity/brightness feature?

No, it's not distance-based, it uses the shunting instructions listed in the activity. (Or possibly it checks for sidings and stations along the current path - not sure which.)

[Genma Saotome]

YoRyan, on 05 September 2020 - 01:08 PM, said:

The problem is that you're selling this feature as a "performance improvement," a domain that (for the most part) exists outside of the purview of activity design. So you want to turn off a few car spawners to save a few frames. What about explore the route mode, multiplayer mode, and timetable mode? What if I have a fast machine, and I'd rather render all car spawners to maximize my immersion? Why do you insist on making this choice for me?

(1) Because I know far more about the routes I build than anyone else every will.
(2) Anybody that doesn't like spawners being tuned off can simply delete the turn-off file.
(3) Why do you insist on making this choice for me? This is a data driven application. The program properly determines how things move and display what's in the view frustum. That, plus the OR team resisting any change of the feature set outside of the limits KUJU defined. ENHANCING existing features are acceptable (e.g., better physics). ENHANCING the technology itself is acceptable (e.g., Monogame). But stepping outside of the jail KUJU built? Good Luck. This is why Rob stepped away and build his own activity methods. Go back into the beginnings of this project (private forum) and you will find many, many feature suggestions and requests from me... off hand I do not recall a single one being implemented. I finally concluded posting feature requests was equivalent to digital masturbation -- a lot of frenzy, a brief movement of feeling creative, amounting to not much else. So I stopped making suggestions some years back because it was obvious that doing so was a complete waste of time. That lasted until this summer; I see now little has changed.

[YoRyan]

It seems to me you're conflating two distinct problems: how to preserve the performance of a world tile with many car spawners, and how to allow activities to modify the route's scenery at runtime. The former is a .exe (core) problem while the latter is a .act (content) problem. But look, that's just my opinion as the new guy. If you can author the patch, great, let's review and merge; but I as a volunteer don't feel obligated to service every feature request we receive here, most especially not feature requests that seem to have but a single champion.

As to the state of the project - I cannot speak to events that transpired 10 years ago, but I suspect that our failure to develop native data formats, an acute shortage of engineering talent, and an inability to make changes to vast portions of the codebase (due to the ongoing Monogame migration) are the underlying factors here, rather than any perceived "resistance" to embracing new ideas beyond what MSTS offered. I mean, we do have timetable mode, after all.

[Genma Saotome]

No disagreement at all about the current state or why people do the things they do (there was a time when there were 20 or more programmers present, many of whom did nothing because nothing was asked of them and/or they were never told how to work with the others; those days are long gone). That's on your side of the fence. On my side, as a route and content developer, nothing much has ever happened, period. 10 years of nothing much.

[Csantucci]

YoRyan, on 05 September 2020 - 12:34 PM, said:

I'd roll scenery customization into the future activity format - I don't think this is something the Kuju structure could do very elegantly.

I've sometimes thought about that in the past. IMHO it is not a complicated issue introducing this in OR. An additional line could be introduced in the .act file

ORTSSceneryExtensions ( "foldername " ) 

where "foldername" is the name of a folder within the ACTIVITIES main folder; within "foldername" the modified .w files could reside. Additional shapes and textures could be added within the route's SHAPES and TEXTURES folder. The same arrangement is already available to add or modify OR specific .w files.

The problem lies more at the activity and route editor's side: this feature should be added in sync with Goku.

The addition could be applied also to timetable files, I think.

[Genma Saotome]

YoRyan, on 04 September 2020 - 09:45 PM, said:

The simulator should be able to manage its resources automatically.

I wanted to return to this quote. I'm sure we agree that the simulator should be able to manage whatever has been handed it by content creators and in doing so has to manage the technical resources of the computer. But if the word resources also means what content is seen by the end user then I firmly disagree,

Content creators, FWIW, consider all sorts of technical aspects when making their content: How many texture files to use in EVERYTHING you make (a draw call issue)? How many named parts n EVERYTHING you make (another draw call issue)? How many polys in EVERYTHING you make (a performance issue)? How much track to place? Roads? Trees? Buildings? (more performance issues)? How many car spawners? How many AI trains? What is the view distance? How much distant mountains make sense? How many tiles of near terrain to include? Where should it be included? What LOD values should be used on EVERYTHING you make.

In short, EVERYTHING handed to the software has already been assessed for how each and every item you see will affect performance. OR is a data driven application. No content data, NOTHING for OR to manage. WRT performance, the responsibilities of the software is strictly limited to doing the job as efficiently as possible. It should not include predetermining how much content is given it.

I understand that nothing about this issue can be done any time soon, as well as understanding that any decision about doing that work and when the work might be done, is entirely in the hands of the OR team. It has always been that way and will continue to be that way. And for what's done on this side of the fence, do understand the extent to which managing performance is a factor in what we do.