Transport Tycoon Forums

This topic is for the discussion of features and problems in the 2.6 nightly or alpha series.

The first new feature is the advanced signal GUI. Because Ctrl-clicking signals to set the right signal type is kind of annoying, eis_os wrote a new signal GUI which pops up if you Ctrl-click on a signal.

To enable it, set "experimentalfeatures.signalgui on". Then you can directly choose the signal type and toggle between light signals and semaphores (top right button).

Finally, the bottom right button with the arrows and three signals plus number activates the "autosignal" tool that I wrote, which repeats the selected signal in both directions at the given separation (counting normal-length wagons between signals). It doesn't copy any special signal state such as presignal or PBS signal, but it does copy the one-way state properly to allow placing many signals on a long track easily, as well as preserving the light/semaphore type of the signal being copied.

The autosignal tool stops at the first tile that already has a signal, the first junction where the track diverges, or anything isn't plain track (such as bridges, tunnels) except crossings.

Anyway, these features need testing, especially the autosignal tool

[edited for nightly r759]
[edited for making it a general 2.6 topic]

Backup of old thread:
http://grfcrawler.tt-forums.net/restore ... backup.htm

Pretty neat. Didn't try the autosignal bit as I didn't properly read the earlier post and struggled a mite getting the right config setting.

One problem. Nightly r733 objects strenuously to my version of ttdw (3.02.1011, 11th Oct 96) claiming it doesn't recognise the version. Patch 2.5 beta 7 has no such objections. I'm pretty sure that this is an untouched exe file...

In any case, I overrode the warning and despite a few seconds thought, the nightly burst into life. I didn't have time to perform an extensive test but might get a chance tonight.

Longtime lurker, first time poster...

I have the same problem as 3iff, but it works fine. The autosignal GUI works as far as I can see (short testing) but will make things 100 times easier.
Scautura

It's the signalgui and the autosignal feature... the window gets redesigned a bit to allow to change the distance ingame...

3iff wrote:Nightly r733 objects strenuously to my version of ttdw (3.02.1011, 11th Oct 96) claiming it doesn't recognise the version.

http://nightly.ttdpatch.net/latest/ wrote:Here you can download the very latest TTDPatch versions. The files you see here are:

<snip>

Feel free to try it, but be aware that this code may be even more unstable than regular alpha or beta versions. Furthermore, it is compiled without version data, so TTDPatch will warn you about this when you run it.

(Emphasis mine)

Dalestan...you're right.

This is the first nightly I've downloaded and I only skimmed the intro text (as highlighted by Dalestan). I did see the warning about making sure I use an unmodified exe but didn't register the lack of version data...

It's been a tricky time using alphas and then betas...nightlys are a whole new area of confusion.

Thanks for everyone's patience... I'll get me coat.

Oooops... Doh.

OK, on to real testing... Latest (740) version, while trying to use the autosignal feature (which incidentally is *awesome* - no more RSI!) with enhanced tunnels, the feature fails (see attachment).

There are two signals on that piece of track - if the track stops to the left of the highlighted signal, there is an error when pressing the button for autosignal ("Cannot place signal"), and doesn't attempt to place a signal on the other side of the tunnel. If the track is the length shown, there will be no error message no matter where the tunnel is.
Works beautifully if the tunnel is a level crossing (road) - as in the patchnotes. But doesn't it "fail to place a signal" with the enhanced tunnel as well? To replicate, just make a short(ish) piece of railway over an enhanced tunnel and try to use autosignal. Then lengthen the track and try again to not get the error, but still get failure.

Scautura (my bug reports suck... I just hope somebody understands my random babble)

The code stops whenever it encounters a tile that isn't a regular track tile or a level crossing, without even trying to build a signal.

I suppose I could make a special exception for enhanced tunnels as well, in addition to track under bridges. It'll definitely stop at bridge ramps and tunnel entrances though. Maybe I should also make it place the signal at the most recent valid signal tile instead of the next one when it fails to place a signal.

News:
The currently build signal type is grayed in the signalgui

Question:
Should the change between semaphores and light signal cost money?

Yes it should.

I concur. It should reflect some reality and cost money.

then why would anyone change to light signals? If you ask money for changing them then maintaining semaphores should be more expensive as maintaining light signals.

eis_os wrote:News:
Question:
Should the change between semaphores and light signal cost money?

Yes, but not so much like a brand new signal.
And I think it shouldn't close the window.
Is it posible to add rightclick-contex-sensitiv informations about the signals (eg. "exit-signal, pathbased")

And, what is the empty button with the 2 arrows below for?
It's only proudcing a "Cannot place a signal on this tile"-error for me.

> what is the empty button with the 2 arrows below for?

I guess it´ll variate the distance between signals.

regards
Michael

The empty button is the auto-signals tool as explained in the first place, and those arrows will eventually change the signal separation.

broodje wrote:then why would anyone change to light signals? If you ask money for changing them then maintaining semaphores should be more expensive as maintaining light signals.

Then it'd be possible to have some semaphores and some electrics on the railway, like in real-life (at least in the UK).

I sniff a heritage railway! They'd be pretty easy to create!

Patchman wrote:explained in the first place

I mean first post. In this thread.

/me goes to have his brain checked out

hmm, "Cannot place a signal on this tile" shouldn't come when you press the arrows, I guess I need need to debug that code a bit more...

About the cost, I will see maybe only the remove cost as convert cost, I think thats fair...

Patchman wrote:The empty button is the auto-signals tool as explained in the first place, and those arrows will eventually change the signal separation.

Great!!!

The autosignaldistynce-swich says:
The / and \ directions count as 4, the others as 3, so a value of 12 places signals every 3 resp. 4 tiles.


Well, shoudn't it be better if you give a value X, and this value+1 is user for / and \ (in TTD the straight tiles), and X*2+1 is userd for - and | (in TTD the diagonal tiles)?

So a X=5 value will place a signal on every 6th straigh tile, and on every 11th diagonal tile.

Because a train uses in diagonal direction for every wagon a tile, in straight direction one tile for two wagons.

What i want to say is, you give TTDPatch the standart train lenght, and the patch will calculate the signal-distance automaticaly, so tha a train with lenght X fit in the signal-block.

Hope you understand, i can explain in german via PN if requested.


edit: Hmm, have tested it a bit.
Nice, it works round corners, too
But the algorithm is a bit, sorry, useless, because the distance between the signals are completly different if you mix __ and / tracks.

An other idee to my suggestion above:
TTDP goes along the track, uses internal X*2, and count 2 for a / and \ tile, and 1 for a _ and | tile.
After X*2 is counted, TTDP will place a signal.