Owen wrote:If I was going to implement something like that... I would have just used the Squirrel interpreter OpenTTD already ships. The intention was that it should be possible for non programmers to use.
Additionally, your proposal has another issue: How do these files get into the game? How do you handle this in network games?
Ah i see so there already is an engine to support it, that's good to hear.
Considering the current implementation of ProgSigs i think it's already a bit too much for the average Joe to take in IMO. Here's the timeline that i am just thinking up on the fly:
- Learn to build rails, build one rail for every train. (The very beginner)
- Learn to put two way signals on rail to allow more trains on that rail at the same time.
- Learn to build double tracks for one way traffic.
- Learn to make junctions that doesn't needlessly cross tracks that wouldn't take a train going over/under it.
- Learn to build RoRo or other complex stations with path-based signals. (or if you are really fancy or started playing before working PBS, pre-signals, combo signals and exits)
- *Possibly* learning more advanced techniques such as load balancing (with signals) and priority tracks.
At this point in time, most people should have a fairly basic understanding of logical operation on train tracks. However, they might not know what IF, ELSE, AND, NOT, OR, XOR etc means.
Let's call those that do know this "conditional programmers" thus
Programmable signals requires at least some knowledge of programming conditional statements... Right?
Sorry to take it this far just to prove a point but the point is that ProgSigs are already quite complex for those who don't know programming or have worked with logic operators in the past.
And the reason i would rather have a text box to input my program to is because every time i see a need for ProgSigs i feel the work behind setting them up is quite tedious because of all the clicks all over the place.
Instead of just having a textbox where i can do:
Code: Select all
@inputs a b
@outputs c
if (a & b) { c = true }
Then it's just a matter of hooking up a and b to a source of data. Like clicking a button for input a and then clicking on a signal from where to get the data.
When in the input/output mode one could even have lines drawn that point to the various inputs and outputs. As it is right now i have to set up sign posts to show where my ProgSig is taking in data.
And with the possibility of having an output you might not even need to have a special programmable signal in the first place. Instead you have a new type of object that is placed on the ground that can control the state of an entire block of signals.
To make this work in multiplayer (while i have limited knowledge of the inner workings of OTTD) i would just suggest doing it like they do in wiremod, every time an expression gate is changed it uploads the code to the server and the server runs the code. The expression on the client is in plain text but when sent to the server as a program it's more like op codes. It's compiled so to speak but very crudely.
That way, the client isn't actually running the program but the server is.