[Genma Saotome]

IMO the fundamental problem here is not that the OR team drifted or that the goal of MSTS compatibility was wrong, it is that for a very, very long time no one on the OR team was sufficiently interested in either route or content creation to take on the task of doing what the OR project was intended to do -- from the start -- which was to design and create a new, highly accurate railroad simulator, one that could avoid the massive error exhibited by what is now called the Railworks suite of programs: Not using extant content.

IOW, MSTS compatibility was never the goal, it was merely a means to kick-start the future simulator by having usable content in-hand.

The cause for the failure to follow that strategy is not attributable to any one person or persons but rather something inherent in Open Source projects: You can only get people to work on what they want to work on and AFAIK Wayne Campbell was the only OR member who had both the interest and capability to do what needed to be done. AFAIK the gap left by his departure has never been filled -- to the least degree -- until Goku showed up, and Goku's work, which is a significant amount of time and effort, was created within the context of what MSTS did and not in any context of what OR would do as no such context had yet been defined.

As many of you already know, this failure has been a huge source of frustration and anger for me and at this point in time I rather doubt things can be turned around. 1.0 should have been the last of MSTS as an objective for anything within the game loop; everything since, while valued by many end users, has been wasted time.

Returning to the basenote, I've already offered my comment on managing "new hires"; this post is on finding the right staff: The project team desperately needs people who can code who want to do design, build routes, create content. There is likely enough expertise in those presently on the team to enhance the game loop functions with new features enabled by a new design -- I have always trusted James' technical skill to get the project off .XNA and on to something else that would enable keeping abreast of the continual flow of technological change. Absent people with this different interest the project will continue to wallow in place as a mere MSTS emulator and w/o new routes and better models, will completely stagnate and die.

[jamesc25313]

A lot of people in serious denial in this thread..

[SP 0-6-0]

Care to explain your point of view?

Robert

[Csantucci]

While it is a pity that there are so few active OR developers, I don't think this is due to the fact that MSTS compatibility was seeked.
One of the causes is, in my opinion, that going beyond MSTS undergoes to a too bureaucratic approval process, and the problem is that developers with fantasy don't like bureaucracy. I'd like to mention that some of the most interesting developments that go beyond MSTS, that is multiplayer, 3Dcabs and timetable mode were developed and introduced in OR almost in despite of someone managing OR (later everyone was convinced about this being important improvements, or at least I hope that).
I was just asked by a former active developer to explain him the procedure to get some functional improvements approved. I had to write lines and lines of text (Trello, blueprint, ET thread) to describe that. I didn't get feedbacks from him.
It's true that we can't support anarchy, but we can't kill fantasy and vision.
I can agree with James that migrating to Git can encourage people contributing more with own public forks. However this must not again be accompanied by more approval rules. If e.g. I can't directly commit in the official code a bug correction without getting approvals or even technical steps by other people, I will be less willing to commit bug correction. And if possible SVN should be maintained operational in parallel, at least for some time, because not all us old developers will have it so easy to switck.

I can't say that I have a global view about simulators, but it's not true that there isn't development of OR content. I can mention at least one German route and trainset developer who wrote in February 2017: "Also my personal progress direction wasn't clear - further with MSTS /OpenRails or switch to Railworks / TS2016 - but now this is cleared, I stay with OR and will use my abilities with TSD / MSTS RE to develop new projects for this simulation." (he exhibits the OR proud supporter logo now).
As well known, also the payware developer SLI is an OR supporter.
In my country I see also developments of activities for OR, despite the missing specific editor.

The most critical problem I see is that the MSTS development set does not run on Windows 10. While the MSTS RE can be replaced by Goku's TSRE5 (Goku, please don't abandon it and continue removing bugs when they appear), the lack of an OR activity editor (capable to develop activities that OR can run now and to support features to be developed in OR) is a very serious problem. I'd say it's the most serious problem.

[roeter]

In a way, this thread is typical for the development of OR as such : it is drifting in various directions, almost loosing sight of it's original intention, with each contributor highlighting his own particular interest - and the odd one claiming it's all rubbish.

I'll try to keep this short, but that won't be easy given the many items touched upon in the posts above.

First, back to the original question :

cjakeman, on 23 April 2017 - 12:15 AM, said:

Or to frame it as a more personal question, "How did you get involved in Open Rails? What can we learn from your experience?"

It was out of frustration with MSTS (signalling and AI train behaviour in particular) that I got myself involved in OR. The trigger was a small remark on OR's website that new developers would be welcome. By getting involved I hoped to make some kind of useful contribution to get better signalling as what MSTS could offer. That 'some kind of contribution' rather got out of control and the rest is history.
Anything the team could learn from this experience? I fear not - apart from that note on the website (which I think is still there).
As for guidance into the project : I was 'thrown in at the deep end' - and without lifebelts or anything. But I survived.

Goku, on 24 April 2017 - 02:56 PM, said:

There is no new developers, because no one is intrested in old MSTS S.HIT. Open Rails had to go forward, made some amazing new things etc. But some important users didn't wanted this direction for OR. And now we see the results.

The result of starting off with MSTS contents is that we're still here - and I think it's because of that start, and not in spite off it. As Gemna has pointed out above, it gave OR a jump start as it could start off as a simulator without the need to first build it's own contents. Ironically, it was the success of OR in setting up this alternative using MSTS contents that brought in the MSTS community and led to the drive for 'absolute' compatibility. That was not what was intended from the start. Whether that was a good thing or not is debatable - it did, however, stifle new development as time spent on reaching this compatibility could not be spend on new development. It also, sadly, split the team in those aiming for an MSTS 'clone', and those wanting a different direction.
Another important side-effect is that it restricted the view forward - there was 'nothing' to aim for beyond the compatibility issues, no consensus whatsoever as where to move next. I warned about this when version 1.0 was reached (as did some others), but nothing much has changed.
Back to Goku's point above : using MSTS gave OR the jump start it needed. There wasn't much else around to choose from at the time. If OR had decided to set up it's own formats at the time, it would never had got anywhere at all - with the limited capacity for development, it would have been impossible to create enough 'environment' to get anyone interested. A simulator with nothing to simulate will have only a short life indeed. And it's an illusion that any project based merely on volunteers can ever keep up with the commercial enterprises. Whatever format would have been chosen at the time would be outdated by now, but we would still be stuck with it as simply there would not have been the capacity to renew it.

As for the future?
As time goes by, people will move off to pastures new - that's just reality. No game, computer or otherwise, lives forever. And computer games generally have a rather short lifespan. Train simulation is only a 'niche' market - otherwise MSTS would not have abandoned it. Commercial developers will come and go, and with the small volunteer base on which this project rests, there's no hope we can keep up with this. So, one day, OR will come to an end. None of us is playing the same games as we were playing 30 years ago, and none of us will still be playing the same games in 30 years time either (those still around, anyway). That's just life.
Which doesn't mean I will be giving up OR any time soon. But will the community still be here in a few years time? And - just as important - if we do get around to new development, will the community follow?
And that latter point is my greatest worry - the present OR community is adicted to MSTS and wants to stay that way. Oddly enough, away from the development team there is no drive for large-scale new development.
Here's an example : MSTS was very poor at AI train control, and many signal systems reflect this - they work fine for the player train but have only very limited facilities for AI trains as MSTS could not deal with that anyway. OR has greatly improved on that, not only having a better AI train control, but also adding lots of new functions to the signalling to handle AI trains properly. But just look through the route section of trainsim.com : there is not a single update of any route - freeware or payware - introducing new signalling functions based on what OR can now offer.
So what would happen if we did develop new contents - new shape formats, texture formats or whatever? Would the outside world follow us and start to offer these new items, or would it all just be a waste of time?

Some final short points.
I don't agree with Carlo that the present set-up around development is stifling new ideas. Blueprints need not be complete books on what to do, and it does give both the developer and the team time to reflect on what is needed. Trello is nice but not compulsory - it's more a way to get a feeling of what people want, not so much a limitation on what can be done.

As for editors : Goku is doing a great job at the route-editor (despite his apparant dismay over MSTS contents).
As for an activity editor : most 'ingredients' allready exist. OR has an excellent path editor - much better as what MSTS could offer. There are allready plenty of consist builder tools - freeware and payware. Traffic could be set up along the same lines as for timetable mode, using a spreadsheet and reading the info from a .csv file. So all that's required is a small tool to bring it all together.
But - that brings back the compatibility issue, as such an editor can not read existing activity files.
And so we're back to what is the most basic decision to make : to look backward or to look forward.

And I failed - I did not manage to keep it short :sign_sorry:
Regards,
Rob Roeterdink

[edwardk]

If we look at the ups and downs of Trainz from Auran, you would have thought that they would have failed at one point, but they did not. OR is no different. There will always be people who will be interested in trains and as long as these people are out there, OR will always have a chance. With this in mind, Rob finished with a statement of either looking forward or looking backwards. I do agree that we need to look forward. What needs to be done is to put our heads together and figure out how this is to be done.

As for me, I got involved with this project because I do have an interest in trains and I always wanted to work with code. I remember my first test with this project was a bug fix. There were issues with the headlights when the distance was beyond 6,000 meters. I was able to determine that part of the headlight operation was including part of an old distance operation that was no longer being used. Since that point, my focus changed to learning how to get the bogies to rotate on articulated container cars. This work was not complete at the time I became involved and this shows that there was a lot of jumping around at the time. As you can see, my overall involvement was fixing bugs.

Like I mentioned above, we need to continue looking forward. With this in mind, there are 3 critical areas. The first which was mentioned is the activity editor. Having the editor will make more people even more comfortable with wanting to move to OR. The last 2 are combined. To fortify the foundation of OR along with ensuring the future, we do need to move from XNA which is critical because this needs to be done to be able to work on the 64bit process. Both of these items will involve much work and realistically, I can't see just one person working on it since there is a greater chance of burnout. At this time, the steam locomotive area is being worked on as well as work being done in the 3d cab area along with continued bug fixes and small tweaks here and there. This shows that this project does require a diverse group of people.


Edward K.

[cjakeman]

roeter, on 26 April 2017 - 03:46 AM, said:

First, back to the original question :

It was out of frustration with MSTS (signalling and AI train behaviour in particular) that I got myself involved in OR. The trigger was a small remark on OR's website that new developers would be welcome.

As well as registering our project at Open Hatch, Up-For-Grabs and moving to GitHub, we shouldn’t forget our website. We get a lot of traffic - 200 downloads a day and, of course, many more visitors than that.

James Ross, on 24 January 2017 - 02:05 PM, said:

Download data up to and including Monday 23rd Jan:

http://james-ross.co.uk/temp/orts_147.png

With all this web traffic then, perhaps I should prepare a web-page or two for a recruitment campaign, one page to present the opportunity/challenge and one to set out what is involved and how to proceed.


There is something I would like advice on though, because it might be controversial:- How about adding a pop-up to the Open Rails menu? After the user has used the simulator more than 10 times (i.e. after showing a definite interest), he is asked to consider a role as a contributor. The options might be "Yes, please contact me at <Enter email address here>", "Maybe later", "Never".

I think this would get us more candidates and more capable candidates than the website (though we should aim to do both) but it is a break from the "no surprises" approach to marketing that Open Rails has taken so far.

Should we give it a try?

[Genma Saotome]

I'm going to assume here that the tart comments about someone saying everything is rubbish is about my second post. Fine... people are completely entitled to hold contrary opinions here at ET and to express them politely and that was indeed the case.

I'm going to repeat my opinion: The OR Project team has avoided doing what the project intended to accomplish: create a new rail simulator that brought along old, MSTS content so everyone could enjoy their existing stuff and would not have to wait years for new routes to appear. It was never intended to be just a MSTS emulator, full stop.

Do recall I was there at the beginning and participated in those discussions. One of hte positions I held at that time, which I still believe was correct, was to hang on to the MSTS content. That opinion was based on what I saw as a near fatal mistake by the RS team to offer almost no content in their first release. This opinion was NOT because I thought MSTS content was wonderful, the best thing that could ever be done. In fact, I thought most freeware routes and content were garbage (an OPINION, for all those now gasping) and that MSTS was a technological dinosaur: dead, dead, DEAD.

The problem/criticism is not that a replacement for MSTS has been built. That is a very appreciated contribution, a difficult task in many ways, and the degree of completeness so far achieved is both remarkable and admirable. If my comments were interpreted as denial of that or asserting it's all rubbish then my written comments were very poor expressed.

The criticism is that more MSTS is not what is needed. More MSTS is akin to arguing combat aircraft need to have more Fokker Albatros features, more Nieuport 11 features, and more Sopwith Pup features while every other simulator is looking at and perhaps implementing more F35 features. I have believed for quite some time that more investment into a MSTS emulator is a lose:lose proposition -- a waste of valuable technical skill and domain expertise and ensuring stagnation for end users.

Yes, that aircraft analogy exaggerates of course but I'm simply trying to hammer home the opinion that a big change of direction is critically overdue. Many people cannot use KUJU's tools on WinX. That's unlikely to ever be resolved. When RGE goes, that's no more quad tree, no more mass generation of hundreds to thousands of tiles. When DEMEX goes that's no more mass generation of high resolution terrain (e.g., 10m) for those many hundreds or thousands of tiles. Other than the original aspirations the project has never addressed the needs of route builders on model content creators. And you wonder why they are moving on to other sims???? And why there is very little new content?

IMO the project very much needs to recruit programmers who have built routes and/or created 3d model content. IMO the first group is more valuable. You need to actively mentor them so their introduction to what is in place is directed and comprehendable, from the game loop, to rendering, to arcane domain functionality like steam generation or braking. And once up to speed, design a new and better way to do tiles than the example provided by KUJU, a new and better way to record object placement than the example provided by KUJU, build some tools to populate those newly designed files, and pull the game loop and domain functions over so you've got some content to use in the new environment. I would expect that having done that somebody will create some true OR routes, some true OR models, and you'll start to see the community shift off a 2001 sim to a 2017 sim.

IMO nothing less will save this project and if you don't want to hear this message and take it heart, we'll, then there really isn't any hope for the rest of avoiding the cage commercial game software have to stuff their content creators and end users into: forced incompatibility every couple of years, no medium term support, and a long term glide path into the garbage can (right next to Microsoft Train Simulator/2001), all because the money runs out.

[James Ross]

Csantucci, on 26 April 2017 - 01:01 AM, said:

I can agree with James that migrating to Git can encourage people contributing more with own public forks. However this must not again be accompanied by more approval rules. If e.g. I can't directly commit in the official code a bug correction without getting approvals or even technical steps by other people, I will be less willing to commit bug correction. And if possible SVN should be maintained operational in parallel, at least for some time, because not all us old developers will have it so easy to switck.

This probably isn't the thread to go into all the details, but at least to start with I am fine with bug fixes (simple and not), localisation updates, and documentation updates being committed directly to the main branch with no approval beyond bug reports (i.e. no different to now). For blueprint-type items (i.e. new features), I would prefer that people publish their own branch and use the merge-request process (PR), as this will allow code inspection and commenting, in addition to the current "idea inspection" of blueprints; however, using a PR would likely allow skipping the blueprint itself, as the PR can serve much the same purpose.

And it is very unlikely to be possible for us to have Subversion active alongside Git, due to fundamental differences in function and the migration process necessary to create the Git version of the code.

cjakeman, on 26 April 2017 - 10:30 AM, said:

There is something I would like advice on though, because it might be controversial:- How about adding a pop-up to the Open Rails menu? After the user has used the simulator more than 10 times (i.e. after showing a definite interest), he is asked to consider a role as a contributor. The options might be "Yes, please contact me at <Enter email address here>", "Maybe later", "Never".

In principal, I like the idea of integrating with the menu, but I am not that fond of the trend of apps asking me to rate them after a few uses. We could instead simply show a link to the new webpage somewhere in the UI (perhaps where the updates appear?), just to get people access to the information.

If we do ask users more directly, it might be worth thinking about including the basic opt-in data collection idea, as you could ask both questions together.

[Goku]

Csantucci, on 26 April 2017 - 01:01 AM, said:

I can agree with James that migrating to Git can encourage people contributing more with own public forks. However this must not again be accompanied by more approval rules. If e.g. I can't directly commit in the official code a bug correction without getting approvals or even technical steps by other people, I will be less willing to commit bug correction. And if possible SVN should be maintained operational in parallel, at least for some time, because not all us old developers will have it so easy to switck.

But you can use GIT like SVN. You can commit to github without owner approval if you are set as collaborator.