[RFD] Signaling

[aarona]

Obviously people haven't been thinking about this...

What does it mean for a 50% reduction in speed?
The maximum speed on the line?
This now means that we have to have tracks, or areas of tracks which have speed limits. Do we want this? Is this part of the design?

The maximum speed of the train?
A 300km/hr train will slow down to 84km/hr on the 25%,25%,50% idea. (For those playing along at home 300*0.75*0.75*0.5). How far does it take a train to stop from 84 km/hr? Quite a distance I would imagine!
(Its 100km/hr for m3henry's suggestion)

Would the stop sign activate when the train passes? Before it passes? Will this mean we need line of sight of the signal for the train driver to "know" when to stop or slow down? Will it start to stop when the train enters the "square" of the signal, can a train stop in this time? What if it goes over?

I'm currently considering my opinion on smart trains vs smart signals because of the above points!

[Hyronymus]

Can't we use the pathfinder to "alert" signals of an incoming train and let the pathfiner influence signals?

[XeryusTC]

I ain't really in favor of a customisable signal system. People can screw up things for themselves pretty badly, and the devs would have to fix their mess. DominionSpy's system would also need to involve quite some intelligence, the game would have to check which state the next signal(s) is/are in and change the color and max speed in the signal block according to that. This could also lead to some unintended behavior.
People should try to keep in mind that we're making a transport simulator, not a train simulator.

Obviously people haven't been thinking about this...

What does it mean for a 50% reduction in speed?
The maximum speed on the line?
This now means that we have to have tracks, or areas of tracks which have speed limits. Do we want this? Is this part of the design?

The maximum speed of the train?
A 300km/hr train will slow down to 84km/hr on the 25%,25%,50% idea. (For those playing along at home 300*0.75*0.75*0.5). How far does it take a train to stop from 84 km/hr? Quite a distance I would imagine!
(Its 100km/hr for m3henry's suggestion)

Would the stop sign activate when the train passes? Before it passes? Will this mean we need line of sight of the signal for the train driver to "know" when to stop or slow down? Will it start to stop when the train enters the "square" of the signal, can a train stop in this time? What if it goes over?

What you basicly have is a speed reduction depending on the speed of the train that CAUSES the speed reduction. So your 300km/h TGV would have to slow down to 20km/h if it is behind a train with the current speed of 20km/h. This would be quite benevicial because your trains never have to stop, they would only travel quite slow.
As for the breaking distance, a train should brake when it encounters the signal (can be on the same tile, or 1-2 tiles in front of it depending on the driver's view). You should take the following into consideration:

Code: Select all

1: T1 - G - O - R - T2
2: T1 - O - R - T2

G, O and R are signal colors. Tx is the train number. T1 is currently passing the signal next to it. Trains drive to the right.
Case 1: T1 can travel at max speed, because the next block is free (the signal is green).
Case 2: T1 would have to slow down when passing the orange as the block behind the orange block is red (T2 is there). This would mean that T1 will get ready to stop at the next signal, a sudden stop (as found in TTD) can be avoided by giving the train a few tiles look ahead.

And with the smart signals vs smart trains: it comes down to the pathfinder both times, smart signals would need to check where the train is heading and then calculate a path based from its location to the train's destination and decide what to do. This would basicly mean that you'll let the signal decide what the train should do, but it would actually have to signal the direction the train should take instead of just changing color.
Smart trains would have to check their stored path (maybe recalculate it as YAPF does at splits etc) and make the decision to stop or keep going. Doing it this way would make signal states mostly cosmetic, which also avoids a bit of the coders problems by giving only one place to work on. It is also faster because you can just call the cached path and then decide what the train should do, and which state the signal should have.

This might not sound like a big difference to some of you, but it would make a big difference code wise. I prever to take the smart trains as they have the pathfinder linked to them basicly so they can alter the signal state when they need to (except from turning red signals into green if a part of track is occupied).

[m3henry]

this is only a small idea, but could have huge changes at signal/even PBS junctions: you could have a flag in the train status window that allows you to set a low medium or high priority [/copying RRT2]
and i do think that 4 aspect is best, that will give lots of warning, but not exsessive warning

[Hyronymus]

I suggested priority settings for trains too. That way you have less problems when a train approaches a crossing with signals. The pathfinder (that passes a signal before the train does) tells the signal the priority setting of the train too. If another train arrives at the same crossing with a lower priority then the signals exchange information on the train priority and decide which signal goes green first.

If both trains have an equal priortiy then speed or cargo type should be determining factors. I.e. passengers have top priority, then comes perishable cargo (livestock, food, refrigerated) and then bulk goods (coal, iron ore).

[m3henry]

I suggested priority settings for trains too.

oh right sorry, i couldnt find it with search. but yes, thats baisicly what i meant.

[m4rek]

cant we build realistic junctions with points and the lot, with an internal micromanagement program running the show from the nearest signal box, taking into consideration routes of trains, acceleration, top speeds, track ahead, track behind...?

[m3henry]

cant we build realistic junctions with points and the lot, with an internal micromanagement program running the show from the nearest signal box, taking into consideration routes of trains, acceleration, top speeds, track ahead, track behind...?

no thats too complicated, I think, but keeping the code simple, where possible, is the main point?

[XeryusTC]

cant we build realistic junctions with points and the lot, with an internal micromanagement program running the show from the nearest signal box, taking into consideration routes of trains, acceleration, top speeds, track ahead, track behind...?

The game's engine is the micromanagement program here.

On the topic of priorities, it wouldn't be very hard to implement this, but it would be quite hard to optimise it. You could loop through every train (that has a path planned through the intersection in question for a bit of optimalisation) to see which trains have a higher priority and shouldn't be stopped. Another thing could be that trains X tiles away from an intersection will reserve it with their priority, any trains with a lower priority would be blocked (some kind of LoMo way, trains reserve intersections there too, but there is no priority implemented in LoMo).
I think we'll need a developer discussion about this when we get to coding this.

[m4rek]

yeah, but the specific mircomanagment part of the program for where you place the signal box, would have to ID every train that passes through that juncton, see which trains have urgent cargo (another feature that could be added to the game), which trains are travelling faster, which trains regain speed quickly when stopped, when the trains will reach the junction,when pathes cross and trains need to be stopped. then it changes points - visually - for the trains in question to pass through...

get my drift? Realism is maxed, but user is left unaffected...


kinda like using signals and such from SimSig or similar and writing a program to play it for you

[XeryusTC]

yeah, but the specific mircomanagment part of the program for where you place the signal box, would have to ID every train that passes through that juncton, see which trains have urgent cargo (another feature that could be added to the game), which trains are travelling faster, which trains regain speed quickly when stopped, when the trains will reach the junction,when pathes cross and trains need to be stopped. then it changes points - visually - for the trains in question to pass through...

get my drift? Realism is maxed, but user is left unaffected...

So you wan't someone to put a box next to the rail and assign trains to it? This seems kinda stupid to me as the game can figure everything out itself, possibly A LOT faster and users can't forget to assign trains to the signal box.
Realism is fine in every game, as long as you keep as much simplicity as possible, the 8 year old next door should be able to play it. Also, complex games can be fun, after reading a 300 page manual and spending a month figuring out how it works. This is the general method to loose players.
Remember that this is a transport simulator, not a train emulator.

[m4rek]

no, the box itself would detect any trains passing throught the junction/station it is assigned to.

plus, most of m suggestions are based on simplicity with a much more advanced level of gameplay being available should you wish to explore it.
just like sid meier's alpha centauri. ive been playing it for 3 years or so because theres a simple level of gameplay and then theres an advanced level of gameplay you can explore at your leisure. increases playability 10fold

[XeryusTC]

I still don't see the point in the signal box except from adding an extra 3D model to the game. It is suppose to do what the game's engine does and what the game's engine will keep doing as we won't have other programs taking tasts of TE AFAIAC. And you should be able to control the trains priority and stuff through a simple interface (setting low, normal, high) and changing settings in an advanced settings window (something like OTTDs/TTDPs .grf files.
Note that I'm looking from a coders point of view, which doesn't view objects in the landscape as "controlling" objects, just as a visualisation of the engine's code, which your signal box is.

[m4rek]

thats fair enough, a simple visual represantation suits me fine.


as for priorities, manually setting priorities might not be the best idea unless you can see that the train isnt being handled the way you wanted by the junction. i still feel priority should be set by each individual train as said above, and each signal box could become a user interface for priority override at that particular junction/station.

the override would consist of a list of all trains scheduled to pass through that junction/station, colour coded to show conflicting trains and in exact order of priority against each other with marker showing whether the priority was set automatically or manually. changing a trains priority at that junction is as easy as drag and drop.

by the colour coding i mean: the very next train to pass throught the junction is assigned colour 1, any trains arriving before it leaves and cross its path are marked with the same colour. with the exception of those, the very next train is assigned colour 2 and so on....
when the whole colour group passes, the colours are reset. very much a user interface thing and not crucial

[XeryusTC]

Well, overriding priorities could be quite nice, but it can become complicated to keep track of all overrides. And another problem is that a train doesn't keep track of all junctions it runs through, the pathfinder only plans from the train to it's destination, but we can find another way to cache this.
Another problem could be that trains pick an alternate route, which means that they come across junctions where they don't have an altered priority, which could blow the functioning of the junction. Not a very big problem, but the possibility that it would occure is there.

[m4rek]

my point here being, you shouldnt alter the automatic priority unless that particular junction is handling your train wrong, ie, you have a slow passanger train trying to cross a badly designed junction that handles HSTs is stopped there for a long time because its on the bottom of the list

[aarona]

Why not let signals be externally programmable? (Through Lua)

The signal program which comes with the default installation will be relatively basic and the user can, at their own peril, create a more complicated instruction set.

[eis_os]

Hi.

While I have the lua idea already in my mind ages ago, however Lua ingame via a simple click of logic blocks. (Which gets saved with the game). If you make something that is changeable externally you should save the state of this script/object in the savegame. Otherwise your savegame will not work properly on other players and start to work strange or even crash without a reason.

Here are some concepts I have:

Signed Priority Number (Default 0) which controls a priority for a train or a shared order. Negative less priority then normal higher priority as normal. (not the nicest)

Tag System. You can give shared orders or trains a special tag, like "High speed Passenger Service". You have a Tag Control Panel where you can change priority for each tag. (as number or b as drag & drop re sortable list) and add or remove new tags, as well a get trains by tag function.

When a train needs to change a signal, you need a priority backtrace, so you have to find all exits of junction, and then find trains on the lines, sort them by highest priority first. Then you can do PBS for the highest train and going down priority. So even Trains with a low priority may use a junction if it doesn't block high speed traffic. Still this kind of setup can always create some form of blocking of a junction. Actually to create a properly working junction is one of the challenges of a transport sim.

[DaleStan]

1) Do Lua interpreters have the necessary speed for that?
If so:
2) What hooks do you propose and/or intend to provide, and
3) Provide an example script that uses those hooks to program TTDPatch-equivalent presignals.

I ask because Lua seems to be the latest programming panacea, (especially among those who aren't real programmers) and I am convinced that such a thing quite simply cannot exist.

[XeryusTC]

1) Do Lua interpreters have the necessary speed for that?

Lua can execute code as fast as it can switch between executing your script and executing C(++) (due to interpreter overhead). Compiling Lua will make it even faster, so speed is not a very big issue.

2) What hooks do you propose and/or intend to provide, and

You can allow Lua to use every function in your game, this is done in the TRoS GUI for example. This holds no limits, but it isn't very wise to allow your script to hook into your entire engine .

3) Provide an example script that uses those hooks to program TTDPatch-equivalent presignals.

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

I ask because Lua seems to be the latest programming panacea, (especially among those who aren't real programmers) and I am convinced that such a thing quite simply cannot exist.

Lua is just Yet Another Scripting Language, but the fact that it is used by big projects (World Of Warcraft, MDK) and it simplicity to implement make it very highly rated. Using bare Lua can be a bit of a pain though, that is why TRoS also use tolua++, this tool can convert C++ classes (the classes must be a bit edited though, that's why TRoS uses binders which aren't pure C++) to Lua which obviously saves A LOT of time for developers.