New signals - coding

[Max-Max]

This thread is intended for the development of the "new" signal system. The brainstorm and discussion about the signal functionality are discussed here.

This thread will discuss the code implementation only.

[Max-Max]

We need to get the code ready for development. I'm not quite sure of how you meant regarding the repository.

If I create a local copy of the master and Erik creates a local copy of the master how do we synch our local copies (Erik's and mine) without a server?!?

By the way, I found this excellent page about TortoiseGit vs TortoiseSVN

[Erik]

I've no big experience with Git servers. So I don't border about what it will become.
I've to learn it at anyway. 

Further, the first thing what we needed is a function "signal_speed_limit()" who limits the allowable speed.

[jamespetts]

What you need to do is as follows:

(1) each create a fork of my 112.x-private-car-merge branch;
(2) one of you create a new signalling-overhaul (or something) branch on your own repository;
(3) the other one of you pull from the signalling-overhaul repository;
(4) each of you work on changes on your own signalling-overhaul repositories as necessary;
(5) each of you push to your own repositories each time that you have a single coherent set of changes/fixes;
(6) each of you pull from each other's repositories when the other has pushed a set of changes/fixes;
(7) each of you pull new changes from my 112.x-private-car-merge branch (or any successor branch, such as a probable future 11.x branch) whenever I make changes onto your own local master branches; and
( each of you merge those changes from your own local master branches into your own signalling-overhaul branches so as to keep your code up to date with mine.

Alternatively, you might want to create multiple branches each, and have each set of changes in one branch: for example, having distant and multiple aspect signal functionality in one branch, signal boxes in another, cab signalling in a third, the parser (if this is done) in a forth, and so forth, and have an additional branch where you merge all of the changes into one testing branch to see how they all work together (but actual code changes are applied to the sub-branches not the combined testing branch).

This latter approach is probably preferable, as it gives more robustness and flexibility, although set against that is the fact that it will be more time consuming to maintain.

I hope that this helps!

[Max-Max]

The part I don't see to understand how to do is:

(6) each of you pull from each other's repositories...

How can his Git client find my repository behind my firewall? NAT setup?
I'm not willing to share even a sector of my Harddrive to the whole internet.

[jamespetts]

Ahh, no, what you do is set up a repository on Github (it's free for public projects), and synchronise each branch on Github with an equivalent branch (with the same name) on your local hard drive. You each do that, and then you can merge from each other's branches.

[Max-Max]

Alright, that was what I meant in the first place but you said I should create one locally, so I thought we could do it without a GitHub server

Okay, I will have a look at GitHub then...

[Max-Max]

James & Erik

I have made a new fork at GitHub and posted you both a PM.

[Max-Max]

I cloned the 112.x-private-car-merge and tried to compile.

There seems to be some files missing:

Error   434   error C1083: Cannot open source file: 'tpl\debug_helper.cc': No such file or directory   D:\Projects\Simutrans Experimental\Signals\c1xx   Simutrans-Experimental
Error   446   error C1083: Cannot open source file: 'utils\cstring_t.cc': No such file or directory   D:\Projects\Simutrans Experimental\Signals\c1xx   Simutrans-Experimental
Error   458   error C1083: Cannot open source file: 'gui\colors.cc': No such file or directory   D:\Projects\Simutrans Experimental\Signals\c1xx   Simutrans-Experimental

The master branch compiles fine.

[jamespetts]

What are you using to compile it? Other people seem to have compiled without difficulty.

[Max-Max]

I did a fresh clone from your 112.x-private-car-merge. I'm using VC 2012 Express. I'm using the project file as it is after I added the usual include and lib path to OpenTTD...

I have looked and those fie are indeed missing. Maybe ppl added the missing files manually. I wasn't sure if your intention was to remove them or not.

[Erik]

I don't see those files in the master branche also. Perhaps they've never existed.

[jamespetts]

At least one of those files has been renamed and no longer exists with that name - which project file are you using?

[Max-Max]

I opened Simutrans-Experimental.vcxproj in VC 2012 Express.

[jamespetts]

Did you try opening the .sln file instead?

[Max-Max]

Okay, so I tried the .sln file, same thing there... Same files missing...

I went back to GitHub and browsed your repository jamespetts / simutrans-experimental and checked both in the Master and 112.x-private-car-merge branch and they aren't to be found there either.

Do you have those file in your local copy? They seems to be missing in the repository...

[Junna]

Okay, so I tried the .sln file, same thing there... Same files missing...

I went back to GitHub and browsed your repository jamespetts / simutrans-experimental and checked both in the Master and 112.x-private-car-merge branch and they aren't to be found there either.

Do you have those file in your local copy? They seems to be missing in the repository...

Have you made sure you have added all the required libraries and includes? These kinds of errors I get when not having added all, but as long as I add all required it will compile all right and I have not had any errors.

[jamespetts]

The problem is, I think, that these files are erroneously listed in the first place: they ought not to be in the solution at all. If you can delete them from your solution/project, you should be able to compile (all other things being equal). I am not sure why you are getting a version in which these are included, however. Which branch are you using? You should really be making sure that you are on the 112.x-private-car-merge branch.

[Max-Max]

I deleted my local copy and started over and suddenly it compiled fine!?!
I also managed to setup the upstream remote and updated my copy from it.

[jamespetts]

Splendid!

[Max-Max]

I have to admit that I got caught in a completely different subject in the code.

It started with some test of the skin system and I got curious when I found some "undocumented" skin images in the code. One thing led to another and now I'm kind'a fixing the skin system to actually use the D_TITLE_BAR_HEIGHT and other constants correctly.

There are a lot of dialogues using magic numbers in their size and position calculations and I'm trying to replace them with the defined element dimensions.

I have also added a D_GADGET_SIZE so the gadgets can be customized a little bit more in the future...
Anyhow, I have to start to learn the code somewhere, so why not start here

I'm sorry Erik, but I will catch up with you as soon I have fixed this...
We can still discuss the implementation if you want, or you can just poke around meanwhile to get an understanding of how things work.

[Erik]

And I was afraid that I was falling behind. 
It's itching to pick up an old project as well.
The rebuild of the ns-pakset (dutch railways), but let me be careful that it consumes my complete concentration again.

In the mean time I've figured out how to implement the signal_speed_limit. Unfortunately something goes wrong.
One of the speed_limits goes to zero. It could be the signal_speed_limit but it could also the corner_speed_limit.
I hope to fix this soon.

[Erik]

Finally I've figured out how GitHub works and pushed my work to my fork.

https://github.com/Erik-Krom/simutrans-experimental.git
In the branch "signals" I've put the implementation of the "signal_speed_limit".
I also changed the pre-signal so it can be tested.

[jamespetts]

Thank you all for your work on this - most interesting. I am currently away from my development environment, so can't test the signal speed limit code. May I ask: how in principle does this work? In real life, the signal speed limit is based on a precise relationship between the breaking performance of trains and the distance between signals; what happens when the player does not observe this precise relationship in placing signals, and places them too close together?

[Erik]

The lowest speed_limit is valid.
So the red signal is overruling the signal_speed_limit and the train will slowdown and stop in time for the red signal.

For the test I've set a fixed signal_speed_limit for the "pre-"signal if it's set on caution.

There are a few bugs with the signal itself.
Like the pre-signal it will activate the next signal if it's free. If that signal is also a "pre-"signal it will also activate the signal after that.
The speed limit of the last signal counts so if the last "pre-"signal is on caution the train will continue with a reduced speed.
Those has to be solved a next time.

[jamespetts]

Hmm - you mean that the train will travel at the slowest of the fixed speed or the speed at which it needs to travel to stop at the next signal? Is this how operating practice actually works in countries with speed signals?

[kierongreen]

Presumably not because that would require route knowledge...

[Erik]

I've some trouble to find a clear explenation.
I've put the signal_speed_limit with the corner_speed_limit and overweight_speed_limit.

Abbouth the fixed speed limit.
For now I've it set on 45km/h. So if a train reach a (pre-)signal on caution it will reduce it's speed to 45 km/h.
Signals who can give an adjustable speed_limit (speed signals) aren't build jet. I'm working on that.

[jamespetts]

Erik,

I am not sure that I follow. In the current Experimental, trains will always start braking soon enough before a signal that they will stop in time for that signal. Have you changed that in your code? How does the 45km/h limit fit in with that system?

[Erik]

I've done nothing about the breaking for a red signal. That's completely unchanged. So the train will still beak soon enough for a red signal anyway.

The 45 km/h is just the lowest speed limits on the Dutch railways and I use that for testing. Later is could be set by the designer of the signal. I will give it also the possibility that the speed limit is calculated by the distance of the next signal or that the train reduces its speed smoothly.

I will try to make the different variants so it can be tested and discussed what's the best balance between reallity simulation and game play.

[jamespetts]

If the trains still automatically start braking soon enough for the next stop signal in any event, what is the function of the signal speed limit? I thought that, in the real world, a signal speed limit was intended to slow trains to the correct speed to stop/slow furhter in time for the next signal by the time that they see it.

[merry]

If you are interested, at least according to UK practice, closely spaced signals are handled as follows. NB this is a bit mind-bending to start with. There are better (longer) explanations on-line (e.g. http://www.signalbox.org/) but this is just the most relevant bits.

In MAS installations, if a signal is to close to the signal in advance of it (in advance=next), then the signal is 'approach released'.
This means that the signal is held at Danger, until the train is close enough that (on the normal braking curve) the train will be travelling below the speed safe for approach to the signal in advance. This is usually done by timing the occupancy of an approach track circuit. At that time the signal will be released to the correct aspect for the next signal.

In semaphore practice with Absolute Block, it's a bit different. For a signal box that is a block post, if signaller has not received 'line clear' for the block section in advance, then the 'first' stop signal (the 'home') controlled by the box is held at danger until the train is nearly at a stand, and then cleared so the driver knows he does not have a clear run and must stop at the signal protecting the next block section. This is in addition to the distant signal which can only be clear if the next block post has given 'line clear' for the section in advance ans all 'stop' signals are cleared. there are variations allowing some more complex approach conditions such as a double amber aspect at the distant, which then allows clear signals for entry to (say) the platform but indicates the next block is not at 'line clear'
This is relevant because in effect, all the 'stop signals' controlled by the signaller are too close together for braking from line-speed, except the home which protects all shunt / conflicting movements in the signal box's area and has a clearing distance beyond the signal before any conflicting movements can occur.

Hope this is of some help.
Note that Simutrans signalling - even with semaphores - is fundamentally 2-aspect MAS with automatic routing at junctions. I know there are ideas to vary the signalling methods in future, but it's true now.

TTFN,
Merry

NB I am not a signalling engineer, just an interested party...

[Max-Max]

Remember that UK distant signals are very different from the.. Uhmm... non-UK signals
When a non-UK system signals at danger, a max speed limit (may it be distant signal, track or whatever) is used to slow down the train immediately and be prepared for a red main signal.

In practice the non-UK train will move slowly all the way up to the main signal and stop in time if needed. With the slower speed there is a chance that the initially red main signal will turn green and the train can continue at full speed from the main signal without stopping.

A UK train will reach the main signal faster because the driver knows where and when to hit the breaks in case of a red main signal light.

In an ATC system the driver will receive the max speed in real time depending on where it is and the state of the next signal. ATC overrides a distant signal's max speed.

By the way, great work Erik!

[jamespetts]

This all still leaves open the question of how we handle (1) determining what the maximum speed should be in the speed signal types; and (2) what to do when the spacing of these speed signals together with the braking capability of trains is such that the speed is too high for the distance between the signals. Without a clear way of handling this, such a system is open to exploitation by players deliberately placing speed signals with a high speed very close to the stop signals that they are protecting, knowing that one cannot actually have a crash in Simutrans, to get out of trains having to take the correct distance to brake.

[Erik]

(1) At the moment I will let determine it by the one who designed the signal. In the .dat file it will be possible to define a couple of levels with each its own speed limit. The implementation of the UK-way the distant signal works has to be done later.

With the code I'm stuck with that. With vehicles you can define constrains about witch vehicle can be put previous and next. This works with strings. For a list of speed limits for the signal I need it with integers. My programming skills aren't high enough yet.
Also I've to figure out how the version control works and how to set to the next version.

(2) On that point the distant signal becomes meaningless. For the gameplay the distant signals has a purpose to increase the distance the  train will start to brake so the signal has more time to go on green before the train has to stop completely.