Apologies for the double Extension Request posting but I've been playing a fair bit recently and I can't sleep :D
I suspect this is either an unworkable suggestion but I can see many situations in which it could add a great deal of "intelligence" to the signalling system (and possibly remove some of the more specific signal Extension Requests)
My suggestion is as follows: a customisable signal which can display red/green/"no entry" or otherwise affect pathing in response to a selection of if/then clauses.
Possible uses:
- Various priority reservations "$if $cargotype=passengers, $reserveblocks = 2 else $reserveblocks = 1" would (for example) make a cargo train coming off a branch less likely to be able to cut in front of a passenger service. (and vice versa)
- Track Branching: Two Tracks with "if $maxspeed < 150kph THEN NoEntry" on one and "if $maxspeed > 150kph THEN NoEntry" on the other would filter the traffic into a fast and slow track.
- A specific choose signal designating which order platforms should be checked. "IF platform($1) empty SHOW green ELSEIF platform($3) empty SHOW green" etc
- Allowing a single platform to be used for a supplier with multiple consumers by having input tracks signal red unless the amount of cargo waiting for them at the station was 100% or a significant portion of their capacity
The advantage I can see is that this is merely an environment to provide rather than specific functions which would allow for far greater customisation and a closer simulation of signalling methods which are controlled by humans (rather than just block based as now)
I acknowledge this is probably an epic task to set up but I think its potential is pretty much limitless.
Oh, also it would probably allow for the construction of a track and train computer (for fun and jokes) in a similar vein to those produced in the game Dwarf Fortress http://df.magmawiki.com/index.php/DF2010:Computing (http://df.magmawiki.com/index.php/DF2010:Computing)
Computing is possible also with much simpler signals, see:
http://www.tt-forums.net/viewtopic.php?f=29&t=51710
http://www.tt-forums.net/viewtopic.php?f=29&t=37902
However this requires group signals like in version 88.05.10. There you could construct similar stuff using pre-signals and choose signals and strategically placed stations.
I did consider attempting something like this by designating the underground as a "computational layer" though unfortunately it seems that anything complex enough to have a useful effect would become restrictively large and slow.
I do like the idea of using trains as bits though, since the running costs would simulate the running costs of an actual computer system :D
I have been thinking about the advantages one could get by allowing some scripting in Simutrans. My ideas mostly revolved around adding scripts to waypoints, but scripting the signals might be more useful.
The reason I focused on the waypoints was to allow more dynamic schedules, typically for freight trains. I would then be able to send trains into a waiting area or depot if another train is waiting at the station. Another possibility would be having one train deliver goods to two or more stations, but only actually route to and/or stop at the station if it actually has goods for that station. Even having the trains wait at a station until there are goods for it at any one of the stations it serves.
I think a programmable element (it would need to be a Use-at-own-risk feature) would go a long way to letting people interested in handling the crunchy bits do just that without making the ordinary players deal with it. And if people create some really cool features, the scripting could act as pseudocode for migration into experimental and/or standard.
I know it's a huge programming challenge to add scripting, but I see the potential for it to solve multiple feature requests at once, including future ideas.
I realize this is not something the main team wants to tackle, but perhaps someone ought to set up a subproject (like experimental) to tackle the idea of a scripting layer.
:o don't look at me!!!
Yeah, I think that so many people have their own ideas about how to awesomely deal with various challenges that, if widely appreciated I suppose could be induced in some way into the game.
Anyone else have any awesome ideas as to when this would be useful and impossible/impractical to hard code into the game? My thoughts on impracticality largely realise that some features would be incredibly difficult to write a compact and simple GUI for.
The GUI is the easy part. It's deciding on the scripting syntax and features, and then implementing those, that is hard. :)
That's my point, it's the GUI for implementing many specific features that's hard. Pretty sure all you'd need is a text window for something like this.