[FS.E652 091]

Well, my suggestion is discuss for improvements on Graphic Render such Water Shaders, Weather Conditions and other similar improvements..
Also, there is the situation of the TSRE5, can the OR Team bring the project to continuing the updates?

[cjakeman]

FS.E652 091, on 18 May 2023 - 02:37 PM, said:

Well, my suggestion is discuss for improvements on Graphic Render such Water Shaders, Weather Conditions and other similar improvements..
Also, there is the situation of the TSRE5, can the OR Team bring the project to continuing the updates?

At its core, I think this is a people issue. Improving the graphics is a terrific opportunity for the right developer as great advances can now be made.

The Project Team have done much to increase the appeal of Open Rails for developers:

• James Ross has moved us onto Git (as new developers expect) and made it easy to contribute new code.
• PerpetualKid has helped us move from the 32-bit to 64-bit platform and from .NET 4.7 to .NET 5.
• Carlo has helped us move off XNA to Monogame (which extends the potential for graphics)
• Peter has introduced the GlTF for better rendering of individual models.

We'll certainly discuss it; and TSRE5 too.

[Weter]

Hello.
Alas, I'm likely late to mentioned session's event date, but maybe, you consider my proposal worthful for the next one:
How about 2-d viewer-only mode (I've seen something like that among Trello cards/plans)?
Currently, we have already "timetable" tab for dispatcher window - the advanced map mode, done by Chris.
But now, it's called by Ctrl+9 after runactivity have already started 3-d viewer, with all it's resource-consuming graphic and sound.
My motive is: more efficient in terms of time, attention and electricity consumption (overheating shortens computer's life) timetable development/debugging.
Now I have to load full 3-d game, then accelerate time up to 5000+% (which gives result as 1 minute in 1 second) for verifying timetable in progress.
That lasts in such mode about half an hour for 24-hours observation. Computer overheats, 3d viewer causes some trains to overshoot their stop points.

So, may standalone 2-d only runactivity visualization mode be established for efficient timetable (activity) tuning?

[James Ross]

FS.E652 091, on 18 May 2023 - 02:37 PM, said:

Well, my suggestion is discuss for improvements on Graphic Render such Water Shaders, Weather Conditions and other similar improvements..
Also, there is the situation of the TSRE5, can the OR Team bring the project to continuing the updates?

There are many visual ideas already catalogued and, in particular, I am currently improving the wind as part of a bigger improvement of the environmental effects.

I would recommend you vote on the ideas you like and feel free to start new discussions on specific ideas or suggestions.

[FS.E652 091]

Hi James, I'm glad to read your answer, regarding this, I already voted my preferences time ago, and I also had the opportunity to encourage and motivate in the implementation of these improvements in some other threads on this forum, of course, they will be a fundamental part to make it even more ' fun driving experience! Greetings

[cjakeman]

Our next session is in a week's time, on Sat 26th Aug.

Is there any topic that you would like ORMT to discuss?

[Csantucci]

I am raising the topic of changes to the braking behaviour of rolling stock. It is of course welcome that OR provides an ever more realistic braking behaviour. But what if this occurs at costs of existing rolling stock becoming practically unusable (e.g. because of highly increased brake pipe recharging time)? I think that this would break the principle that existing OR content continues to run with newer OR releases.

This thread http://www.elvastowe...post__p__299956 is about ORNYMG, but the issue raised is common to the official OR, because the train physics is the one used by the official OR. What occurred (see from here http://www.elvastowe...post__p__299821 ) is that starting from a certain commit one consist that before could have a reasonable recharge time now requires unplayable times. I got the same experience with an original MSTS trainset using a later ORNYMG version.

To be frank, I don't think that this http://www.elvastowe...post__p__299957 can be the solution. First because much rolling stock hasn't been published with .inc files, and second because I don't think one can pretend that people periodically update their rolling stock to be able to use it. I'll add that discussion on this in this forum is by nature biased, because most of the people writing here are experienced OR users, but I think that the majority of OR players don't follow this forum, and expect that they don't get problems once they have downloaded and correctly installed OR content.

Is there a straightforward and fully satifactory solution? Maybe not. However I think that, before changes to braking behaviour are introduced, tests on a predefined set of rolling stock should be performed to see that it is still playable. It is not, a way to have it still playable must be found. Some years ago I introduced the "Correct questionable braking parameters", that wasn't further extended. Maybe in the case above the braking code developer could investigate what .eng or .wag parameter would make the locomotive or wagon unplayable, and add a further condition under the above option.
This is only a suggestion; maybe there are other ones.

[eric from trainsim]

Can't hurt to ask: make an effort to recruit someone to decipher Goku's editor code and refactor it into something that fits the coding direction for ORTS....

[Weter]

Indeed, Carlo:
Since instead of bad, or missing steam parameters, its reported to us in .log, that appropirate for such loco parameters from default tables were guessed/used, why not to do the same with brakes?

[Looky1173]

I second eolesen's request about a route editor. However, I think a fresh start would be better instead of trying to decipher and patch TSRE. I had tested invoking/using a few of the current OR classes from a .NET6 WinUI 3 application, and it seems to work. This could serve as the foundation for a new route editor, and there would be no need to reimplement, say, an STF parser (etc...)

I would also like to hear about how the migration of issues to GitHub is going. Is it planned for after OR v1.6?