[YoRyan]

I take your point - all content is in some way tuned for performance - but it's also true that players use a wide variety of hardware, and some computers are more capable than others. That is why we have sliders that influence LOD's, view distances, distant mountains, etc. - all factors that determine what amount of content is shown - so that end users can tweak the simulator's performance for their own systems. Content influences all of these factors, but at the end of the day we leave things open-ended enough for users to decide what level of graphical fidelity is appropriate for their own circumstances.

So the name of the game is to avoid a one-size-fits-all approach, and that goes for both content creators and developers. To return to the car spawner problem, one could easily imagine a new settings slider that influences the maximum number of car spawners visible in a single world tile. There are key advantages to letting the simulator determine which car spawners can be removed, or reduced in frequency:

• It puts players in control of their own experiences.
  
• It means considerably less work for route builders and activity designers.
  
• It works with existing content, which is no small advantage.

As previously discussed, there is certainly merit to the idea of activities that modify scenery, but this is not a good solution to the performance problem. If, it is important to note, there is such a problem. Are there any routes notorious for car spawner abuse to the point of tanking performance?

[Genma Saotome]

YoRyan, on 19 September 2020 - 01:13 PM, said:

I take your point - all content is in some way tuned for performance - but it's also true that players use a wide variety of hardware, and some computers are more capable than others. That is why we have sliders that influence LOD's, view distances, distant mountains, etc. - all factors that determine what amount of content is shown - so that end users can tweak the simulator's performance for their own systems. Content influences all of these factors, but at the end of the day we leave things open-ended enough for users to decide what level of graphical fidelity is appropriate for their own circumstances.

Yes, I agree completely. But by that logic you would have a slider that controls how many AI trains are going to be active, or even how many cars get to see in a train. That's not acceptable of course because somewhere there is a line beyond which the player has to accept "this is what you are going to get". Effectively that is the content placed in the route.

The sliders you mention are there to REDUCE that content when it's just too much for the hardware... and that's good too. The irony here is you have been arguing that no, all those users are going to get all those car swaners no matter what! :D and I'm the one saying there are going to cases where that is just too much.

YoRyan, on 19 September 2020 - 01:13 PM, said:

So the name of the game is to avoid a one-size-fits-all approach, and that goes for both content creators and developers. To return to the car spawner problem, one could easily imagine a new settings slider that influences the maximum number of car spawners visible in a single world tile. There are key advantages to letting the simulator determine which car spawners can be removed, or reduced in frequency:

I disagree entirely because it's not juts a performance issue. More on this below.

YoRyan, on 19 September 2020 - 01:13 PM, said:

If, it is important to note, there is such a problem. Are there any routes notorious for car spawner abuse to the point of tanking performance?

I don't know. I will say tho the two routes I have a hand in both half a whole lot of street running and in such cases you probably don't want cars tootling along within the width of the train rolling down the street. And yet change the activity and run the train on a different path, 90d off the first run and you'll want those cars you suppressed to be active now.

Let's try this: Like so many contentious conversations things can be settled quickly enough in some discovered middle ground. How does this sound: In the long run it might be better for some car spawener paths to be conceptual similar to the paths used by AI trains (perhaps even including "switches" to change lanes or have some subset make a turn at an intersection). If you want them on, you define it in the activity. As for the rest, such as over on the freeway, let 'em drive. There may even be an interum solution -- Carlo had an interesting idea.

[Genma Saotome]

An example of my point: Every purple line is a double-tracked streetcar path occupying the two fast lanes.

click on image to enlarge to full size.


This is downtown Chicago, second largest city in the US in 1947, with lots of cars and the worlds largest streetcar system having lead times downtown of 30 seconds or less in rush hour. I have no expectation the problem I have raised will be solved any time soon, probably not ever, but do take a look at the cross and parallel traffic and ask yourself "How would I do activities here?".

FWIW the heavy reed lines are the above ground commuter rail... no car problems up there. And each name (in blue) is a custom built city block sized model of the buildings present in 1947.

[YoRyan]

Genma Saotome, on 19 September 2020 - 05:40 PM, said:

But by that logic you would have a slider that controls how many AI trains are going to be active, or even how many cars get to see in a train. That's not acceptable of course because somewhere there is a line beyond which the player has to accept "this is what you are going to get". Effectively that is the content placed in the route.

But in some sense, we do have such a slider! AI trains and railcars that are located beyond the view distance, or in a distant world tile, are present in the simulator but will not be rendered.

Genma Saotome, on 19 September 2020 - 05:40 PM, said:

The sliders you mention are there to REDUCE that content when it's just too much for the hardware... and that's good too. The irony here is you have been arguing that no, all those users are going to get all those car swaners no matter what! :D and I'm the one saying there are going to cases where that is just too much.

You misunderstand? I'm not suggesting we render every car spawner in perpetuity (although we do that right now, seemingly without issue...). I'm saying that, if this is a performance problem we really need to worry about, we should implement an algorithm that determines which subset of car spawners to render based on objective and generalizable criteria, such as view distance and available resources.

Genma Saotome, on 19 September 2020 - 05:40 PM, said:

How does this sound: In the long run it might be better for some car spawener paths to be conceptual similar to the paths used by AI trains (perhaps even including "switches" to change lanes or have some subset make a turn at an intersection). If you want them on, you define it in the activity. As for the rest, such as over on the freeway, let 'em drive.

No, I cannot agree with this because AI trains and car spawners are drastically different concepts. AI trains are distinct entities defined individually in an activity, while car spawners spawn vehicles on fixed paths with headways as short as a few seconds. One is a crucial component of railway operation, while the other is just eye-candy.

So, here's my personal strategy for reaching a consensus: What specific, actionable thing do we want to implement in the simulator? We've identified two distinct problems in this thread:

• We want activity designers to be able to modify the scenery of the route, of which car spawners are one component. This is a sound and desirable idea. You've identified one use case, which is selecting active and inactive car spawners for street-running sections.
  
• Activating every single car spawner when a world tile is loaded may be harmful to simulator performance. But, again, to what degree? This needs to be quantified and triaged, and then "softer" workarounds and optimizations could be identified before taking the drastic step of introducing yet another graphical setting.

There are good reasons to implement (1), but you can't argue it's a sound solution to (2), because the "pick which car spawners you want" strategy places an unfair performance burden on the activity designer, and it doesn't do a thing for existing content.

[Genma Saotome]

I can live with your suggestion #1 w/o any fuss. :dance: :party: :fiesta: :burp: <== yes, sports fan, an agreement CAN be reached.

I'd just move the car spawers in the congested areas I've outlined under the activity umbrella and as I said, over on the freeway, let 'em drive.

Moving on (there is always more), how about the same solution for some siding names?

[YoRyan]

Sure, I think the ability to define sidings (or arbitrary track locations in general) would be a natural extension to the activity format.

[Genma Saotome]

Siding NAMES. not the track itself.

As an aside, I am convinced KUJU got it backwards when they put road and track names into the tsection file. That file should be for dimensional data only and the reference between shapes and their dimensions should have been specified in the .sd file of the shape. That way any number of alternative appearances could have been created without requiring a reserved entry in the tsection file... you just make whatever track shape wanted and so long as it's dimensions were already defined, you are done. Changing models any time later would be a simple name change in the world file and that wouldn't damage any interactive at all. I wonder how many routes were trashed over the years because of this mistake. I mention this as I am in the process of replacing thousands of road shapes and every time I have to use my text editor do a mass value change in the .rdb I get the willies. After that, over 1000 track switches to swap out.

[rickloader]

Hi Dave! Why don`t you alias the existing track shapes to the new shapes in the world file? That way you don`t need to disturb the .tdb .rdb.
Rick

[Genma Saotome]

rickloader, on 21 September 2020 - 01:32 AM, said:

Hi Dave! Why don`t you alias the existing track shapes to the new shapes in the world file? That way you don`t need to disturb the .tdb .rdb.
Rick

That's exactly what I'm doing right now w/ roads. The .rdb and the world file hold the SectionInx() value. The number I'm now using is for a generic stand-in shape. That defines the path only -- that way there is only one block of tsection numbers required instead of 4 to 6 blocks. Over in the world file the Filename() value will be changed from the stand-in shape name to whatever real model I want and doing it this way means I can change my mind about appearance at any time... concrete, asphalt, cobblestone, gravel, or dirt. That change would have no effect upon level crossings or car spawners.

The problem is Open Rails (apparently) can't deal with the file name I've put into the world files.

KUJU could have done the same thing for both roads and tracks and built their editor to handle it with no fuss at all... but recall they built their editor in a rush at the very end of the development. They had no time for reflection, probably no time to take feedback from whomever was building their routes. The project pocketbook was damn near empty and when that happens you ship the product, period.