Scriptable train control system
#11
Posted 30 January 2014 - 12:51 PM
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.
#12
Posted 30 January 2014 - 01:13 PM
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.
#13
Posted 31 January 2014 - 06:46 AM
James Ross, on 30 January 2014 - 06:29 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?
#14
Posted 31 January 2014 - 06:51 AM
gpz, on 31 January 2014 - 06:46 AM, said:
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.
#15
Posted 31 January 2014 - 07:03 AM
Csantucci, on 30 January 2014 - 12:35 AM, said:
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:
#16
Posted 31 January 2014 - 08:09 AM
gpz, on 31 January 2014 - 06:46 AM, said:
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
#17
Posted 31 January 2014 - 10:19 AM
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.
#18
Posted 31 January 2014 - 10:39 AM
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
#19
Posted 31 January 2014 - 11:12 AM
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!!
#20
Posted 31 January 2014 - 12:51 PM
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.