[HighAspect]

From a 'newbie' perspective, I think having a mentor is a great idea.

[YoRyan]

Forgive my necroposting, but as the newest member of the developer team, I thought I'd offer my thoughts on this subject. I got involved in Open Rails by forking the code on GitHub and submitting changes back upstream - so I am exactly the kind of developer attracted by the migration to Git. It took me a few rounds to get used to the architecture of the project and learn the necessary bookkeeping, but now I believe I'm in a position to offer some constructive feedback.

As this thread has covered so thoroughly, it's clear that the biggest barrier facing Open Rails is the perception that it's merely an emulator for MSTS, a dead and beta-quality platform. We needed native formats and editors yesterday, but that won't happen without additional developer talent. ;) So, from the perspective of a newbie developer, here are some parts of the process that could be improved:

• Elvas Tower is the de-facto meeting place for Open Rails developers, but that is not at all clear from the website, where the link to ET is buried behind the "Share > Community > Communities Supporting Open Rails" submenus and is presented as just one of a number of discussion boards. Contrast this with the layout of the OpenBVE homepage: "Links > Discussion Board." Before we can bring new people on board, they need to be able to find us, first.
  
  • And where should content creators go? Elvas Tower registration, once approved, only grants access to the software development forum.
• Trello cards are not a good fit for proposed code changes - by experienced or inexperienced developers - because they can only be submitted anonymously and, once submitted, cannot be subsequently edited. I think it would be better to steer developers toward Launchpad blueprints instead.
  
• The machinations of our automated processes, like the GitHub code bot and its automatic merges and "unstable" builds, are somewhat opaque and should be documented if possible.

Here's to a new, brighter decade for Open Rails.

[Genma Saotome]

 YoRyan, on 05 July 2020 - 02:07 PM, said:

As this thread has covered so thoroughly, it's clear that the biggest barrier facing Open Rails is the perception that it's merely an emulator for MSTS, a dead and beta-quality platform.

That's not a perception, it's exactly what it is. That IS a considerable accomplishment and for that purpose everyone who helped deserves a warm thank you. That said, it is not what the original goal was. The intention was to build a modern, highly accurate, railroad simulator to replace MSTS. Bringing along the MSTS content was an idea I pushed to avoid the perceived mistake made by (what is now known as) Railworks with their first ever product -- no MSTS compatibility whatsoever. From a content perspective theirs was an empty world and I thought it important not to repeat that mistake.

I still think that was a smart decision but the unintended consequence was that everyone that had MSTS content wanted to use it in OR EXACTLY as it had been used before.

So somewhere between then and OR 1.0 everything to do with making a replacement for MSTS had been shoved into the garbage can and was replaced by building a MSTS emulator. What that really meant – a fly in amber -- may not have been apparent to everyone, but the community pushed hard to trampling out any discrepancy between MSTS and OR when running an activity and the OR Team complied.

So no editors, no new file formats; only the .eng and .wag files evolved to any degree.

A large part of the issue is that nobody wanted to take on the task to create editors; any discussion about new file formats was about the type of file, not about what data it held. No interest… no work… no results.

And so here we are.

[YoRyan]

Well, you're not wrong - we're in a tough spot. Had I been around in 2010, I would have advised the project to draw a line in the sand: No ORTS-specific features until the new data formats are available. No .eng parameters, no .wag parameters, and no extended sigscr.dat functions. We're in this weird state where we're an MSTS emulator, but not really, because we have these extensions like advanced adhesion that break backwards compatibility.

But that ship sailed about 10 years ago. Surely we can find a way to move forward. Let's start with linking this forum on the website.

[cjakeman]

 YoRyan, on 05 July 2020 - 02:07 PM, said:

So, from the perspective of a newbie developer, here are some parts of the process that could be improved:

• Elvas Tower is the de-facto meeting place for Open Rails developers, but that is not at all clear from the website, where the link to ET is buried behind the "Share > Community > Communities Supporting Open Rails" submenus and is presented as just one of a number of discussion boards.

Does this do the job?

[YoRyan]

Yes, that looks perfect! I would also suggest adding a little note designating Elvas Tower as the primary Open Rails forum on the communities page.

[cjakeman]

 Genma Saotome, on 05 July 2020 - 06:28 PM, said:

So no editors, no new file formats; only the .eng and .wag files evolved to any degree.

Yes, the plans have been kicked down the road time and again - and are no longer even set out clearly.


New data formats enable us to do new things, for track this might be superelevation, transition curves and spirals. For each format, after firming up on the data it can support, we need first a translator from MSTS format to OR format, then the code to use the new format thereafter and finally, as Dave says, an editor to build content in that format.

If I remember correctly, James' preferred sequence has been Activities Editor, then Consist Editor and finally World Editor on the grounds that the Activities was easiest and the skills developed along the way would be needed for the more challenging World Editor.

So, yes, the tasks need talent but also commitment as they are major pieces of work. Without them, though, Open Rails is indeed limited by its success as an emulator.

[Genma Saotome]

When it comes to redesigning the contents of files -- the data -- I'd be very happy to take a leading role (I'm a retired data architect). To date that offer has not be accepted by any of the developers, all of whom either were well past the stage where such help would be feasible in their eyes or rejected my analysis as requiring too much work. As for just doing it, again, developers prefer to work on what they like/want to do (dance to their own tune so to speak) and find it too intrusive to be told to take a look at this proposal.

In short, a volunteer project is much like herding cats: things move in a particular direction only when the cats have already made up their minds to go that way.

[YoRyan]

On that note, Dave, I would appreciate your thoughts on my JSON consist format proposal.

Thanks,

[steamer_ctn]

If we are really trying to move away from MSTS, then I believe that we should be thinking about the overall architecture, and not just constraining our thinking to "data architecture".


A couple of examples might be:

i) I suspect that there is an amount of code that could be considered "initialisation" code, and only needs to be run at startup. However some of it appears to be also included in normal runtime routines. So to streamline, we need an architecture that facilitates code (functions) which need to run once, and code which needs to be constantly checked, and hence run often. Currently it appears that initaialisation code, and runtime code is distributed across multiple modules. A better OR code structure might be to have discrete combined functionality where perhaps all data is read first, then simulator is initilised, and lastly simulator runs. Similarly a structured function for save and restore might also be good, again rather then distributing this function across various modules.


ii) Where in OR should data be read (there appear to be a couple of instances where similar data is read in multiple different locations depending upon features selected)? How is (should) it shared such that it is available for use in any feature?

iii) Given the complexity of OR, a better way to "self debug" any issues might be worth considering.

iv) Some guidance for new developers in terms of naming conventions, other coding related principles would be helpful to ensure consistency of code development.


I am sure that there are more things that should (could) be tidied up, and a consistent approach defined for coders. I suspect that if we embark upon this, we should really be creating a separate version of software (ie OR only) that is not constrained by the current architecture, and code structures, etc.

Dave's comments in regard to the fact that this is a volunteer project is very relevant, and is one of the main reason why we are were we are. So in short, whilst I am supportive of a full MSTS divorce, I would hate to see that we only achieve half of the job, as in that case, we will be no better off then what we are at the moment.


So lets set realistic goals and achievable outcomes rather then just rearranging the "deck chairs". What do we have the resource to realistically achieve?