TrueSatan wrote:Thanks Cirdan
Will compile it later.
I really enjoy the new tunnel behavior.
Would really like to see that in trunk. It make long tunnels finally more usable.
I would love to, as that would spare me from maintaining my own branch, but there is so much I can do about it.
TrueSatan wrote:Dunno if signals on bridges really needed.
Since your patch brings at least signals on bridgeheads.
They can really help with long bridges.
TrueSatan wrote:Only feature i really would like to see currently is PBS support at the end of a tunnel.
Since i usually build my bigger stations with PBS and sometimes a long tunnel
connects up to the station so i need one tile track for the PBS.
That should already be possible. Have you tried cycling the signal at the exit of the tunnel? The exit signal can be either a normal signal or a one-way path signal.
TrueSatan wrote:But i am very satisfied with the patch as it is, using it since month now and had no crash so far.
Thanks! Testing is always welcome.
wallyweb wrote:cirdan wrote: I may begin work on some other feature (suggestions?).
A while ago I had some chat and the possibility of the flat bridge abutment accomodating a station tile.
I have also seen mention of station tiles being buildable on bridges.
Gee, I announce that I am putting off signals on bridges because I cannot find the right way to code them and you suggest
stations on bridges...
...or that is what I first thought. But a good question is better than a good answer, and on second thought your suggestion made me look at the problem in a different way. What if we stopped trying to always pack all the information about a bridge in the map array? When I designed the new map array, I reserved 4 bits for the information about a bridge above a tile, which is enough to store whether there is a bridge and whether there is a signal on the particular bridge segment and its state, if any, independently for both axes. But now I wonder if we could store the bridge as a sequence of tiles elsewhere, off-map, and make them full-fledged tiles. This does not mean that everything will be allowed on a bridge, and would not be required for
all bridges either, only for those rail bridges that are not a simple long piece of track.
I will have to give these ideas some thought.
TrueSatan wrote:Sorry Cirdan, but i found some let me call it unusual behavior
There is nothing to be sorry about.
TrueSatan wrote:If you use the auto completion tool for signals (CTRL + Direction)
I miss some signals or they are in the wrong direction.
No problem, its easy to fix, just click a few times until they are
completed or in the right direction, but maybe you could have a look (or two)
I had hoped nobody would notice...
Seriously, that is more of a feature than a bug. Signals in tunnels are "magical" in that they do not obey the same rules as other signals, because the signal into a tunnel may be green even if there is a train inside, so I decided that automatic placement of signals should not mess with tunnels.
HackaLittleBit wrote:I found small bug tough.
You have to check the signal placing code.
Placing and removing is not consistent.
To reproduce:
Place signal.
does not place signal on both sides.
Change signal direction places signal on other side.
removing:
Sometimes take both, sometimes only one.(depends on tunnel side)
That is intended, as well. There must always be a signal at the tunnel exit. When you first build a signal in a tunnel end, it is placed to make that end the exit of the tunnel. But, if you toggle the direction it faces, a signal is automatically built at the other side. Similarly, if you remove the signal out of a tunnel, the signal into it, if any, is also removed.
Then again, being intended does not mean that it must remain this way. I am open to discussion about any and all features, particularly UI-wise. So if there is a general consensus that another UI for signals in tunnels would be better, I will happily change it (subject to technical limitations, of course).
wallyweb wrote:I downloaded the snapshot tar.gz
Assuming that it is a fork and not a patch, I compiled it with MinGW.
The result is a playable version of OpenTTD and it does all that Cirdan said it should do.
However, the splash screen does not show a version number. Is this normal?
Yes, snapshots do not have any version information.
By the way, on the subject of compilation, the code is known not to compile under MSVC 2008 (9.0?). But, if somebody feels like helping and has access to such a compiler, I would appreciate if they could try a patch that I am carrying around but have not commited yet for lack of testing.