ORMT - Sessions Open Rails Management Team
#11
Posted 18 May 2023 - 02:37 PM
Also, there is the situation of the TSRE5, can the OR Team bring the project to continuing the updates?
#12
Posted 20 May 2023 - 02:45 AM
FS.E652 091, on 18 May 2023 - 02:37 PM, said:
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.
#13
Posted 21 May 2023 - 07:41 PM
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?
#14
Posted 26 May 2023 - 11:22 AM
FS.E652 091, on 18 May 2023 - 02:37 PM, said:
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.
#15
Posted 27 May 2023 - 08:18 AM
#16
Posted 18 August 2023 - 11:52 PM
Is there any topic that you would like ORMT to discuss?
#17
Posted 23 August 2023 - 12:07 AM
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.
#18
Posted 23 August 2023 - 01:17 AM
#19
Posted 23 August 2023 - 09:06 AM
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?
#20
Posted 25 August 2023 - 06:07 AM
I would also like to hear about how the migration of issues to GitHub is going. Is it planned for after OR v1.6?