OMG, KRS team have finally posted!

[jamespetts]

Having been a programmer myself (had to retire after a coronary)...

Goodness, is programming that stressful?

...I shall look into the problem myself. However, I think (or rather, hope) that somebody else will beat me to it

AndiS is doing some work on the signal scripts, but I don't know whether he's working on that particular feature.

[AndiS]

Dralex, stay clear from Lua, it is very bad for your health. It is one of those "user friendly" language where you do not declare variables, so for every typo you get either a programme crash or a random value in your variable, or a nil value in the variable, and you never know. And different Lua implementations react differently. However, this is not a particular KRS weakness, it is the same in other languages. People just never learn -- for decades it is known that the time to write the code is about 10% of the total development time. You save writing a few characters and trade it for a major debugging headache.
End of Rant.

Different times for different actions are on my todo list (and not among the difficult issues). Current plans are this.
Semaphores are replaced at danger when the end of the train passed
Light signals should be replaced when the head of the train is some distance away from the signal, must look up the info in the signalling forum, I remember 184 m or so. Since signals loose trains out of sight when they are 100 m away (their tail end in this case), these 180m will shrink to 100m for light engines - people will not mind.

Overlap will default to 100m for the above reason, but there will be an optional overlap marker (implemented as a signal, looking like a box or whatever) which the route modeller can place where he sees fit, nearer or further away.

SPAD alarm will be very near to the link 0, just a few m beyond it I guess because sometimes you do not place the link 0 too precise and it would make people very angry if they stop exactly at the post and still get punished, just because the link slipped by 1 m or because the signal was moved a little and the link forgotten.
I plan to give you a choice of reactions to SPAD, now it is always "game over". "TPWS blocked" and "AWS blocked" sound like alternatives, but I have not tested that yet.

[Dralex]

Thank you, Andi. The first programming language I have learnt was Fortran where you do not declare variables either. It is the same with Python, as I understand. So I am very familiar with the problem of mis-spelling identifiers. I do understand what happens in LUA scripts, however.
As for a closer look into the problem, I just discovered that I am one of the unlucky guys who have not received the complete source files. I know there is a thread there that deals with the problem. Could very well be because I have got an Athlon 64-bit processor, but not with a 64-bit OS. By the way, you seem to be doing the same thing anyway. I would have to clone the signal and do my tests on the cloned version as I do not dare to touch the original code, for the reasons you just gave me.
Yes, programming seems to be that stressful, especially when you have managers who want everything done day before yesterday.

Greetings to everybody,
Dralex

[AdamsRadial]

"Implicit none" would stop all those integer variables popping up all over the place, Dralex. I've retired before the coronary, but I'm sure it'll catch up with me sooner or later. To be honest though, I never found the programming or testing stressful, it was the users that drove me to despair

Most of the modern scripting languages create variables as and when required. I certainly don't see that as a reason to refuse to use them. I'll be interested to see how you get on.

[AndiS]

As for a closer look into the problem, I just discovered that I am one of the unlucky guys who have not received the complete source files. I know there is a thread there that deals with the problem. Could very well be because I have got an Athlon 64-bit processor, but not with a 64-bit OS.

I guess there must be a misunderstanding here. Everybody gets a lot of Lua scripts in Rail Simulator\Assets\Kuju\RailSimulator\RailNetwork\signals and no one gets other sources. The confusing point about the signal scripts is just that you get a lot of shared files and then find copies of them in each of the individual scripts. The point is that they replaced the original require statement by some --include= which makes the Asset Editor append a copy of the included file to the including file. Don't ask my why, performance maybe (although not a good argument).

By the way, you seem to be doing the same thing anyway.

In http://forums.uktrainsim.com/viewtopic. ... 78&t=76059 you find a link to an early write-up where I sketch what I am doing, and where I also give a detailed introduction to the existing scripts. However, this was written before docu was available, so see http://forums.uktrainsim.com/viewtopic. ... 78&t=76989 for corrections to the original assumptions. However, as of this writing, I am mostly back at the original design, after having found a way to deal with the restriction that signals need to know the orientation of the receiving signal when they send a message to it.

I would have to clone the signal and do my tests on the cloned version as I do not dare to touch the original code, for the reasons you just gave me.

What I do is make a backup of the Lua scripts. Then I make a little test route with only one type of signal (e.g., the combined semaphore with distant and home arm) and then I hack about the code of that signal until I have enough for the night. More seriously, I use LuaEdit, which comes with integrated interpreter and debugger. While the interpreter only says "error" whatever you mess up, the debugger helps you figure out your latest typos. Unfortunately, you cannot run KRS scripts in the LuaEdit environment, I tried something along these lines and it was a waste of time.

Of course, if you want to run the default routes in between coding sessions, you better clone a signal and rename its script, so your scripting experiments do not disturb enjoying a leisure time ride.