PDA

View Full Version : Cannot override native function with non-native function in TANE - see question link



JCitron
November 17th, 2015, 02:22 PM
There is a question in this thread here regarding this issue:

http://forums.auran.com/trainz/showthread.php?124308-Cannot-override-native-function-with-non-native-function-in-TANE

The function worked in previous versions of Trainz, however, it is now broken in T:ANE.

So my questions to the developers are:
Why was this restriction added?
Would it be possible to remove it so that we can use our signal system in TANE?

From user korvtiger...


Thanks,

John

WindWalkr
November 17th, 2015, 07:15 PM
The compiletime check was added because the script VM doesn't actually support this; ie. it has never worked and now the compiler is smart enough to point this out rather than leaving you wondering why your code compiles but doesn't work properly.

chris

JCitron
November 18th, 2015, 02:41 AM
Thanks... I'll let the kortiger know.

John

JCitron
November 18th, 2015, 06:26 PM
Chris,

Here's another question from Korvtiger....

I have another question for Chris then;
I am not fully read up on the classes related to signals in Trainz, but why does the TrackSide only have getters for SignalState and SignalStateEx but not setters? These setters are added in the derived class Signal (where I think it would be more logical to also define the getters). Would it be possible to move the SetSignalState and SetSignalStateEx from Signal to TrackSide, since the variables these are stored in must be located in that class anyway, because of the getters? This would probably make our work to update the signal system much easier and I can't see any reasons that it would break older code since you only extend the scope of the setters.

WindWalkr
November 18th, 2015, 09:10 PM
I am not fully read up on the classes related to signals in Trainz, but why does the TrackSide only have getters for SignalState and SignalStateEx but not setters?

That's a very good question. I might have been able to answer this one ten years ago, but I think that it's a bit lost in the mists of time at this point.

We don't have any reason or desire to move the signal functionality from Signal down to Trackside. If you're going to implement signal functionality, you should be using Signal- everything in the game expects this, and there's no real reason why you'd want to avoid this.

chris

JCitron
November 18th, 2015, 10:59 PM
Thanks....

John