Csantucci, on 14 January 2020 - 07:37 AM, said:
...however VS says that they aren't used, so you should delete such two lines.
Moreover re writing code please read the paragraph "General Requirements" of this document
https://github.com/t...CONTRIBUTING.md and the documents linked within such paragraph, and try to adhere to what is written there where reasonable.
Don't consider the rest of the document as of now, because I'm unsure whether it is still up to date.
Sorry for unconventional nameings in the code - I didn't think it could be adopted that quickly and I'll read the "General Requirements" right away.
The two unused variables are in fact "development backlogs" and I delete them, thanks hinting me.
Csantucci, on 14 January 2020 - 07:37 AM, said:
I've inserted your patch in my local copy of OR NewYear MG, and I must say that your clocks look out very well! I have the intention to upload such copy within tomorrow, so everyone has an easy way to test the feature.
I am very glad about this and it is really good news! Not because it's my code (which, by the way, was only possible with the active advice of a good OR programmer), but above all because it finally brings the subject of OR-clocks forward and everyone can try it easely. So, of course I like that :-)
First and foremost, I wanted to refresh the discussion here on the topic station clocks with the patch and to hear the opinions of the community.
For an OR-programmer-crack (and unfortunately I'm not one!) it seems to me to be a not too big next step to "beam" a digital clock in form of a 3D text to certain shapes like station buildings or clock-shapes, similar to how platform names work or the digital clock in a Cabview is seen. Easy to say when I can't do it myself, but am I wrong?
Anyway, I would be interested in a discussion about whether, for example, such digital clocks should also be listed parametrically in the Clocks.dat and whether the patch shows the right way for OpenRails to implement external clocks at all.