[gpz]

After investigation I see, that I still cannot remove the test above, because that method works only in AUTO_SIGNAL mode, as you mentioned in your post #9. So I have to keep reading this_sig_speed directly in these modes.

But now I don't understand what you tried to explain in your prior post #5. I am still totally confused. :good2: For me now looks like that what you suggested was already implemented, and what you say not to use, has no alternatives. I must be wrong somewhere, but I am confused.

[gpz]

To sum up the problem, the following signalling related functions need delegates:

Script.TrainSpeedLimitMpS = () => Locomotive.Train.TrainMaxSpeedMpS;
Script.CurrentSignalSpeedLimitMpS = () => Locomotive.Train.allowedMaxSpeedSignalMpS;
Script.CurrentPostSpeedLimitMpS = () => Locomotive.Train.allowedMaxSpeedLimitMpS;
Script.NextSignalSpeedLimitMpS = () =>  ??? I am confused
Script.NextSignalAspect = () => ??? I am confused
Script.NextSignalDistanceM = () => ??? I have no clue
Script.NextPostDistanceM = () => ??? I have no clue

The functions delegated here would need to work in all circumstances, in all playing modes.

[gpz]

James Ross, on 30 January 2014 - 06:29 AM, said:

Feel free to see what other people have done in other projects, so long as no incompatibly-licensed code is copied.

Looks like Unity scripts do contain the "using"-s and the namespace, probably because of the same issue. Maybe the script should be pre-parsed in some way before compiling, to remove the tricky references?

[James Ross]

gpz, on 31 January 2014 - 06:46 AM, said:

Looks like Unity scripts do contain the "using"-s and the namespace, probably because of the same issue. Maybe the script should be pre-parsed in some way before compiling, to remove the tricky references?

Mm. We could parse the script into CodeDom, verify through that that it doesn't do anything untoward and compile that, but it might be more trouble than its worth at that point. I'd take out the prefix/postfix text for namespace and using for now. If we want to add a paranoia mode we can do so.

[gpz]

Csantucci, on 30 January 2014 - 12:35 AM, said:

Do you plan to take into account on board subsystem and on earth subsystem in a modular way?

I am doing only the onboard equipment. Unfortunately the ground equipment should communicate through the signalling code. When a transponder will be available, it will have to generate an event, that should be transferred to the TCS. But now we are back to the old transponder-in-route-editor problem. :wheelchair:

[roeter]

gpz, on 31 January 2014 - 06:46 AM, said:

Looks like Unity scripts do contain the "using"-s and the namespace, probably because of the same issue. Maybe the script should be pre-parsed in some way before compiling, to remove the tricky references?

If you're heading that way, you might as well head to a full parser rather than a script.
A parser based on similar logic as sigscr.dat could be build onto the existing sigscr.cs code. That code is 'parameterized' to quite a high level, and adding specific functions for TCS would not be too much work.
It would also have the added advantage that it is more familiar to many users, more so than C# language.
Also, any errors in the script would be caught by the parser and not lead to crashes. I think there are many users and engine-builders out there who would not know how to debug C# code.

By the way - did you check on the PM I send you for the code to collect required information?

Regards,
Rob Roeterdink

[gpz]

Yes, I received your PM, and thank you for the code, that makes it absolutely clear. (Just I was at work, and didn't have time to incorporate it yet.) Looks very promising!

About a parser: I didn't mean to parse the main code itself, rather just looking for some keywords, which would prevent the compilation. But I would be happy if nothing such would be needed.

C# has many advantages over the sigscr.dat language: It is absolutely easy to learn; it is a full object-oriented language, which can be fully used in the script; runs without any runtime interpretation, it is the same as if was written directly into the main program; intellisense support, etc. I just feel it more professional in long term.

[roeter]

Object-oriented is not easy to learn for those who do not know the concept. Not everybody out there is a software expert.
The question here is : is the general user interested in a high-level full singing and dancing objec-oriented professial language, or in something basic he (or she) allready knows?

Regards,
Rob Roeterdink

[gpz]

The first such scripts will might be coded by me (or us), and the others later probably will be copies with some modifications. And neither I know the sigscr.dat-language, nor am interested in learning it. :wheelchair: If it is such basic, then even less. I'm doing it for fun, and programming in a simple language isn't fun at all. (It's enough for me to s...ck with Aveva PDMS pml macro language at work.)

Don't misunderstand me, I really appreciate the work you have done with the parser for sigscr.dat, it might have been a really hard task, and it is an essential part of the success of OpenRails. I would like to say thank you for this, and of course the continuous work with the signalling you are doing!!

[James Ross]

I'm all for a fully-defined, integrated language like C#. With a little tweaking of how we load scripts, we can have it such that you can actually breakpoint your TCS code in VS and debug your way through it, and with Edit and Continue. It makes sigscr look like assembly programming. :wheelchair:

It's worth remembering that, even within the set of people who make content, those that will want or have the knowledge to make a TCS is small. Most people will just be using pre-made TCSes.

Anyway, I'd consider this a interesting experimental feature which we may remove or completely change at any time.