Transport Tycoon Forums

Tunnel oddities:
A train came halfway out of a tunnel, and for some reason, it took a wrong turn. So I stopped it and reversed it. Half of the train was still inside the tunnel. (A safe operation when tunnels are not involved - following trains will be stopped behind some path signal, and the reversing train will never reverse through a one-way path signal.) Tunnels turned out to behave differently - the train crashed after reversing only a little into the tunnel. Ok, the tunnel signals are perhaps different from the one-way path signals I otherwise use. Intuitively, reversing into a dark one-way tunnel could be dangerous.

The worse part is that the tunnel never clears. I have fast-forwarded several game years - the train wreck is long gone, but traffic never resumes. All trains on that track is stuck. Demolishing and re-building the tunnel will get trains rolling again, but surely traffic is meant to restart automatically after the wrecks are gone?

The savegame is attached. Made with the latest tracerestrict-cirdan. A few signals have conditionals, but none near this tunnel problem.

romazoon wrote:imho it would bother because dragging is much slower than clicking, and so if you want to raise some land (more than one tile up) it s very handy to be able to do it with squares of 2 or 3 or even more (instead of just 1 tile as in a normal game).

Fair enough.

romazoon wrote:Of course the ability to drag is a nice addition, but i would prefer to keep the old behavior than being able to drag ( i don t know if you can keep both, the question would not be raised i supose if you could)

Now you have given me an idea: keep the current interface, but allow to drag when the selected size is 1. Would this be fine with you?

Hafting wrote:Tunnel oddities:
A train came halfway out of a tunnel, and for some reason, it took a wrong turn. So I stopped it and reversed it. Half of the train was still inside the tunnel. (A safe operation when tunnels are not involved - following trains will be stopped behind some path signal, and the reversing train will never reverse through a one-way path signal.) Tunnels turned out to behave differently - the train crashed after reversing only a little into the tunnel. Ok, the tunnel signals are perhaps different from the one-way path signals I otherwise use. Intuitively, reversing into a dark one-way tunnel could be dangerous.

I am aware of this. Reversing a train in a tunnel when there is another train behind it is a recipe for disaster. I could make it so that trains in one-way tunnels cannot reverse, but it would have its own drawbacks, because you may need this to solve a deadlock (start reversing at the last train into the tunnel).

Hafting wrote:The worse part is that the tunnel never clears. I have fast-forwarded several game years - the train wreck is long gone, but traffic never resumes. All trains on that track is stuck. Demolishing and re-building the tunnel will get trains rolling again, but surely traffic is meant to restart automatically after the wrecks are gone?

What do you mean, "traffic never resumes"? Is the signal into the tunnel still red after the crash is cleared?

cirdan wrote:Would this be fine with you?

that sound like a very good idea

What do you mean, "traffic never resumes"? Is the signal into the tunnel still red after the crash is cleared?

I have attached a picture. The tunnel signal is green, but the path signal immediately behind never turns green. Looks like something went wrong with the signalling, when the crash happened in a tunnel.

The Signal in tunnels and over bridge were ignored by the path singnal (failure in the patch). So at the end of the tunnel something wrong, so the path signal cannot reserve the line for the train.
As a workaround : for and after the tunnel a blocksignal.

am i really the only person in this world that thinks that behaviour totally invalidates the usefulness of the entire patch?

Eddi wrote:am i really the only person in this world that thinks that behaviour totally invalidates the usefulness of the entire patch?

You are not the only one

I have to ask ... Why does one need to reserve a path on a line that only accomodates one train at a time. I thought that path based signalling was designed to be used only at junctions where a train needs to reserve a safe path through a junction that can accommodate more than one train at a time.

why do you assume there is only ever one path into or out of the tunnel? it is perfectly valid to have a junction right before or right after the tunnel

Eddi wrote:why do you assume there is only ever one path into or out of the tunnel? it is perfectly valid to have a junction right before or right after the tunnel

There is no junction in the screenshot.

Hafting wrote:I have attached a picture. The tunnel signal is green, but the path signal immediately behind never turns green. Looks like something went wrong with the signalling, when the crash happened in a tunnel.

Did I mention that I never test crashing trains? The tunnel entrance was left with a stale reservation because of the train that had reversed. I have pushed a fix to the repo; if you already have such a stale reservation in your game, you can fix it by telling the stuck train to ignore the red signal.

cirdan wrote:I have pushed a fix to the repo

For those unguaranteed stale reservations we have an unguaranteed Win32 binary fix:
and from JGR
Enjoy!

Lightyears after Wallys windows version here are my versions for as usual Ubuntu.
Thanks cirdan and jgr

Hello Cirdan. Congratulations on your work and commitment. I like the look of these features which address a few of my pet peeves in OpenTTD.
I've only just stumbled across this topic and see there are 44 whole pages, so I wonder if anyone can point me to a list of all the current features in case I have missed any. I'm not expecting a manual but a summary would be nice.

A feature on my wish list that I haven't seen mentioned here, but which I would guess is related to this work, is signals on railway junction tiles, at least on the straight branch, to avoid having to leave an extra tile before converging tracks. It would be a massive help when trying to tuck a large station into a busy city centre and/or when constructing complicated junctions.
As an unrelated shot in the dark, on the cargo handling front I'd love a way of specifying minimum percentage loads for vehicles at stations instead of the current full or empty choice. I know there are kludges like oscillating the train in the station until it achieves the desired percentage. And I know that there's even a patch, but it's a quick and dirty one involving hijacking conditional instructions.

Thank you to everyone who has contributed to this valuable project.

notafrog wrote:Hello Cirdan. Congratulations on your work and commitment. I like the look of these features which address a few of my pet peeves in OpenTTD.

Well, thank you.

notafrog wrote:I've only just stumbled across this topic and see there are 44 whole pages, so I wonder if anyone can point me to a list of all the current features in case I have missed any. I'm not expecting a manual but a summary would be nice.

The first post in this thread lists the most prominent ones (look under "update").

notafrog wrote:A feature on my wish list that I haven't seen mentioned here, but which I would guess is related to this work, is signals on railway junction tiles, at least on the straight branch, to avoid having to leave an extra tile before converging tracks. It would be a massive help when trying to tuck a large station into a busy city centre and/or when constructing complicated junctions.

It would be nice, but I wonder how easy it would be to implement. Too many things in the code depend on junctions not having signals.

notafrog wrote:As an unrelated shot in the dark, on the cargo handling front I'd love a way of specifying minimum percentage loads for vehicles at stations instead of the current full or empty choice. I know there are kludges like oscillating the train in the station until it achieves the desired percentage. And I know that there's even a patch, but it's a quick and dirty one involving hijacking conditional instructions.

Vehicle orders could really use some improvement, but so far I have been unable to find a clear, usable spec that is better than the current one and deals with all kinds of vehicle "components" (train wagons, articulated parts, aircraft cargo holds) in a sane way: You may want to say "load 60% of this cargo, and 40% of that one"; or to leave certain wagons empty; or to refit a wagon to a specific cargo, but the next one to any cargo available. Once you are up for this, there are so many things you can sensibly ask for, and I cannot see the "right" way to do it.

You could achieve similar results by allowing station tiles to have signals, rather than junctions to have signals. No idea which would be more feasible, though.

notafrog wrote:As an unrelated shot in the dark, on the cargo handling front I'd love a way of specifying minimum percentage loads for vehicles at stations instead of the current full or empty choice.

cirdan wrote:Vehicle orders could really use some improvement, but so far I have been unable to find a clear, usable spec that is better than the current one and deals with all kinds of vehicle "components" (train wagons, articulated parts, aircraft cargo holds) in a sane way: You may want to say "load 60% of this cargo, and 40% of that one"; or to leave certain wagons empty; or to refit a wagon to a specific cargo, but the next one to any cargo available. Once you are up for this, there are so many things you can sensibly ask for, and I cannot see the "right" way to do it.

Well I did say it was a long shot, so please don't think I'm hounding you.
My motive is quite simple really. Stop vehicles leaving without a decent payload, but don't keep them waiting forever to fill up. The load division isn't really important, just make sure there is enough total cargo to make the journey worthwhile.

If game scripts could control all the parameters that AI scripts control, I wouldn't even be raising the matter. As far as I can determine, programming a solution in Squirrel would be quite trivial, the idea being to intercept any conditional order that jumps to the very next order on the list. Such an order would serve no meaningful purpose if used in normal play, but it does give a way of specifying a percentage load, and it would actually look as though it made sense:
1. Go to Baltimore (far end)
2. Jump to 3 if load more than 30%
3. Go to Chattanooga
But I digress...

Supercheese wrote:You could achieve similar results by allowing station tiles to have signals, rather than junctions to have signals. No idea which would be more feasible, though.

Well, maybe, maybe not. I have junctions with no stations involved where that extra tile makes life difficult.

Besides, if for example the last tile in a station had a signal, how would that differ functionally from just not having a station on that tile? If the train has to stop at the signal, there might as well be no station where the signal is. Or am I missing something?

cirdan wrote:

notafrog wrote:A feature on my wish list that I haven't seen mentioned here, but which I would guess is related to this work, is signals on railway junction tiles, at least on the straight branch, to avoid having to leave an extra tile before converging tracks. It would be a massive help when trying to tuck a large station into a busy city centre and/or when constructing complicated junctions.

It would be nice, but I wonder how easy it would be to implement. Too many things in the code depend on junctions not having signals.

i always imagined that signals should actually be between the tiles, instead of on them. (converting from the old method to the new method would be troubling, though)

I have updated my branch. Only a few user-visible changes this time, but one of them is a crash:

• You can now terraform by dragging in the scenario editor, if the selected tool size is 1.
• You can now place individual houses in the scenario editor. Many thanks to adf88 for most of the work!
• Fixed a crash with the optimised (sprite-caching) blitters when the GUI zoom level was set lower than the minimum viewport zoom level, as the sprites required for the GUI were not encoded by the blitters.

notafrog wrote:Well I did say it was a long shot, so please don't think I'm hounding you.

Oh, not at all. I welcome suggestions—it is only that this is something that I had already considered myself, and I was sharing my thoughts on the matter.

notafrog wrote:

Supercheese wrote:You could achieve similar results by allowing station tiles to have signals, rather than junctions to have signals. No idea which would be more feasible, though.

Besides, if for example the last tile in a station had a signal, how would that differ functionally from just not having a station on that tile? If the train has to stop at the signal, there might as well be no station where the signal is. Or am I missing something?

I think that the signal should behave as if placed at the end of the platform, unlike normal signals, which are placed at the middle of a tile and make trains stop at the previous tile.

Big thanks for the new version, Cridan.
Here is the unmodified NMF Ubunutu 14.04 64 bit version first.
And now for the JGR modified version.

Thank you both for your hard work