YoRyan, on 07 July 2020 - 01:30 PM, said:
Keep in mind that streaming will be necessary for some kinds of data. For example, you probably don't want to load all of the scenery for an entire 200-mile route in one shot. Internet resources are another case.
Nevertheless, your point about improving OR's code structure rings very true. When I was writing the cab pillarboxing feature, I think I found at least 7 locations where the current display resolution is stored. We could spend time refactoring things - for example, by making use of the ISerializable interface instead of sticking Save() and Restore() methods on every class on an ad-hoc basis - but this has to be weighed against the risk of breaking something that slipped through testing.
Agreed, but if we never try to set a direction it will continue head in the direction that it is currently heading.
So the question is, "is the project at risk by doing nothing"? Will it break of its own accord? If the answer is no, then we don't need to worry about it, and we can continue as we are.
To change direction always takes a huge amount of effort, and it is often easier if it is done incrementally, rather then in one huge effort.
Perhaps we could do this in a number of stages, such as:
i) Stage 1 - Set the desired direction and structures for OR to reach its full potential.
ii) Stage 2 - encourage developers to develop any new code to align with the directions identified in i) above.
iii) Stage 3 - encourage developers to rework older code that they are working on to align with the desired direction
iv) Stage 4 - when the amount of rework reaches a point that the effort is not too daunting, start a program of code refactoring.
YoRyan, on 07 July 2020 - 01:30 PM, said:
There is a very good document on Open Rails' architecture floating around on this forum, which, unfortunately, I cannot link as it is in the private section.
Apart form a basic architectural block diagram, I am unaware of any architectural documents. If you find something then I would be interested.
Certainly it is not available via the link in
CONTRIBUTING.md .
YoRyan, on 07 July 2020 - 01:30 PM, said:
So to write off the current codebase completely, even as messy as it can get, is, I think, a little premature.
It would not be a case of writing off the existing code base, but developing an appropriate transition approach.
Ideally if somebody wants MSTS compatibility, then a lot of that is probably already existing. The issue comes when OR features are added over the top, so the struggle is then to keep some form of legacy compatibility. Perhaps a way to do this would be to internally parallel stream the two simulators (the user starts it in either MSTS compatibility mode or OR mode)? MSTS features could remain as they are and OR uses a "new" parallel version that uses any relevant features from the MSTS stream, but also adds its own new features without needing to worry about legacy issues.
YoRyan, on 07 July 2020 - 01:30 PM, said:
With respect to my new consists proposal, I believe that the bulk of the work would involve debating the new format, whereas writing the actual loader would be a trivial task. A new editor would, undoubtedly, involve more work, but nothing that a few months of spare time couldn't accomplish. Are you in?
So does it need to be a "full blown" editor? Given the fact that the files need to be read by OR anyway, we are possibly half way there with an editor(?), so could a simple text type screen be provided to a user which displays the current values, and allows them to overwrite any values as desired, and then save them? This approach may not be as good as a purpose built editor, but it might potentially provide an "acceptable" alternative until somebody has the time and desire to develop a fully featured editor?