[RFD] Signaling

[DaleStan]

Only an example script won't help, we would also need a bit of documentation/manual .

The proper documentation should be in the answers to 2 and 3. The hooks should all be properly documented as to what causes them to be called, what data they provide, and what results they expect to receive/acheive, and the script should be properly commented.

And, just in case there's a misunderstanding: By "hooks" I meant "things that cause the Lua code to be called", not "things that the Lua code can call". Maybe that's not the right word (callbacks? bindings?) but that's the one I used.

Clearly, there also has to be some way for the Lua scripts to query, and possibly set, the game state, and those should also be properly documented in #2.

This is basically a "Show me it can be done sanely" line of questioning. What game-state is required? How complex is the script? How often does it get called?

[XeryusTC]

And, just in case there's a misunderstanding: By "hooks" I meant "things that cause the Lua code to be called", not "things that the Lua code can call". Maybe that's not the right word (callbacks? bindings?) but that's the one I used.

There was a misunderstanding on my part then .

Clearly, there also has to be some way for the Lua scripts to query, and possibly set, the game state, and those should also be properly documented in #2.

This is basically a "Show me it can be done sanely" line of questioning. What game-state is required? How complex is the script? How often does it get called?

Usually you would call a script everytime an event occurs (this how it's done in TRoS GUIv2, which is the only current scripting part in TRoS). it will become overkill when you'll try to call a script everytime a train passes a signal. The best way of "culling" this is to build scriptable signals, everytime a train passes (looks ahead probably) this signal it will call the script.
For complexity: you can make a script as complex as you want, but we want to discorage that behaviour so there would have to be loads of C++ wrappers.
Anyway, it would become quite a job to make signals scriptable. It would be quite hard to get a decent speed out of it when event driven (although my above solution would solve it for a big part). And ofcourse scripting signals should be easy enough so your avarage 14 year old with 2 weeks of PHP experience can do it, and for others there could be some (ingame) editor.

[aarona]

So should we have scriptable signals?

If we do, then we need not discuss this further.

If we don't then we need to compromise on what the best method of signalling is, and how its going to work.

[Hyronymus]

I just prefer the latter for now and keep the first in the back of our head.

[XeryusTC]

I would prefer build in signal systems too, but we could always implement scripting support when there is a big demand for it.

[Dave]

A bit of both maybe?

Surely there should be a default system, which can be edited?

[Hyronymus]

A bit of both maybe?

Surely there should be a default system, which can be edited?

Isn't that what I said? Start with the latter and keep the first in the back of our head .

[Dave]

A bit of both maybe?

Surely there should be a default system, which can be edited?

Isn't that what I said? Start with the latter and keep the first in the back of our head .

Sorry I assumed you meant it in another context.

[Hyronymus]

Don't be sorry, I'm not too clear all the time.

Locked until the DD discussion arrives at this issue.