[cjakeman]

NickonWheels, on 15 May 2020 - 08:05 AM, said:

Here it is, who ever wants to deal with it.

Thanks for making this contribution.

I've downloaded it and will check it out. If it fits in with the other ORTS parameters, then I'll package it up and add it to the Unstable version of Open Rails so that it can get wider exposure.

If you have more good ideas, then it would be worthwhile using GitHub to submit your contributions in the same way as other coders.

[NickonWheels]

Thanks, Chris

According to numerous test runs with the private version it works perfectly and in conjunction with the Davis lines already established, also positive feedback.

Maybe I should figure out GitHub for more trials.

[YoRyan]

Hi NickOnWheels,

I have some interest in this feature, so I've pulled it into my GitHub repository and will submit a pull request for mainline inclusion after I've completed some refactoring and cleanup.

In the future, to make your contributions easier to merge into the master branch, please use Git for version control instead of sharing customized versions of files. Your MSTSWagon.cs file was dated from February, so I had to manually merge in changes that have been made to that file since then.

[NickonWheels]

Thanks, Ryan

I´m running back and forth about joining GitHub myself, have currently no experience with this and not wanting to mess the main code up by accident. I also sill have the fear of someone else removing such code changes because they think it´s unnecessary. If you know the formula to main code changes I´m very thankful.

[YoRyan]

Just keep in mind that if you want your features to be included into the core, it's in your interest to make the developers' jobs as easy as possible. Merging changes from concurrent efforts and adding manual documentation takes precious time and manpower. Conservatively speaking, writing the actual code is only a quarter of the battle.

The good news is that there's a well-defined process: You submit a pull request, or a set of proposed changes, that you have the ability to revise, and that the core team can approve or reject. So, mistakes are easily caught and aren't permanent. And nobody else will break or revoke a feature without going through peer review first.

(By the way, I am not a core developer either, but I will try my best to integrate and advocate for this feature. :) )

[markus_GE]

NickonWheels, on 04 June 2020 - 11:10 PM, said:

Thanks, Ryan

I´m running back and forth about joining GitHub myself, have currently no experience with this and not wanting to mess the main code up by accident. I also sill have the fear of someone else removing such code changes because they think it´s unnecessary. If you know the formula to main code changes I´m very thankful.

Hi NickOnWheels,

you need not fear Git at all. By coincidence, I have been in the same situation as you are now just a bout two months ago. But let me tell you the whole story in a few sentences.

I have been translating ORTS to German since translations were introduced way back in 2014 (IIRC) but I have been out of the hobby for the last few years due to real life keeping me too busy. I kept updating the translations during that time until the switch from SVN-based source code management to Git was announced in 2017 (IIRC), which intimidated me similarly to you right now. When I recently came back to the hobby (originally through my renewed interest in updating the translation again), I had to learn Git from scratch after all - or so I thought. I asked for help and got really great support from Chris Jakeman (cjakeman) who is part of the OR Management Team (sort of the core of the core team) and who has kindly provided me with a manual on how to work on ORTS' translation files via Git. It took me a matter of mere hours to get my head around the basics then.
Now, Git will require one or two additional steps when working on the actual code, as translations do not require the use of so-called branches. Yet, I have taught myself how to use those on a private programming project that I decided to bring to Git after my experiences with ORTS and Git.

Additionally, as Ryan has already mentioned, it's almost impossible to break anything since any submission to the code base (a so-called pull-request) will be reviewed twice by experienced ORTS devs.

Summing it up, Git is nothing to be afraid of. It's just another (very useful) piece of software and as with any software, you just need to find a place where it is explained in a way you can handle. I know such a resource (as mentioned above), but will have to ask for permission to share it first.

Cheers, Markus

[NickonWheels]

Thanks, Markus

After joining ET I just never thought about such things in advance, same as many others, making me just quite nervous. However I´m thankful for every advice.

[markus_GE]

Hi NickOnWheels,

you got a PM :)

Cheers, Markus

[cjakeman]

Hi NickonWheels,

NickonWheels, on 16 May 2020 - 08:30 AM, said:

According to numerous test runs with the private version it works perfectly and in conjunction with the Davis lines already established, also positive feedback.

Ryan (YoRyan) has submitted your code for inclusion in the Unstable version of Open Rails.

If it works fine there, we can consider it for inclusion into the Testing version (and ultimately the Stable version). As part of the approval process, submissions are linked to any ET forum thread (done) and a "blueprint" for the feature. These blueprints are kept onwww.launchpad.net/or along with the Bug Reports. Please would you register there and add a blueprint which sets out what the feature achieves.

Just a couple of sentences should be enough.


Thanks,

[NickonWheels]

Thanks Chris.

Yes hopefully I can make this done, sounds like a small documentation is what you want.

For the last days I was indeed in the process of joining GitHub but had registration issues, which would be nice to solve in the scope of possible future code experiments.

Having some 'crashing' problems with the latest few unstable versions it may take some time before I really want to go back to them, certainly this means a lot of going back and forth between unstable and testing versions to verify everything you mentioned. Should be no problem however...