2.6 nightly/alpha discussion

Patchman · Post by **Patchman** » 31 Jul 2006 19:41

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]

eis_os · Post by **eis_os** » 31 Jul 2006 19:59

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

3iff · Post by **3iff** » 01 Aug 2006 07:00

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.

Scautura · Post by **Scautura** » 01 Aug 2006 07:33

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.

Code: Select all

TTDPatch V2.6 alpha 0 r733 (Windows) starting.
TTDLOADW.OVL not found, looking for original files:
Copying GAMEGFX.EXE to TTDLOADW.OVL
This is the Windows executable.
The program name is:
  Transport Tycoon (Deluxe) V3.02.011 Copyright (C) 1995 Chris Sawyer
The exact version is 3.02.011  11th October 1996 17:29:44
Parsed version is V3.02.011, size 1696256
Setting program size to 8.5 MB.
Installing code loader.
TTDLOADW.OVL is OK.

WARNING! Your program version is not known to this program. We can now try
         to start it anyway and determine the necessary information, but if
         that fails, TTD may receive a Protection Fault and terminate.

         Depending on how well your operating system handles a GPF, it may
         cause your computer to lock up, and you may lose data. Please read
         the "Version Trouble" section in the TTDPatch manual for more
         information.

Answer 'y' only if you really know what you are doing. YOU HAVE BEEN WARNED!
Do you want to start TTD anyway?

Scautura

eis_os · Post by **eis_os** » 01 Aug 2006 08:25

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

DaleStan · Post by **DaleStan** » 01 Aug 2006 09:36

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)

3iff · Post by **3iff** » 01 Aug 2006 09:48

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.

Scautura · Post by **Scautura** » 01 Aug 2006 19:33

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?

Code: Select all

r735, patchman: don't have autosignals stop at level crossings or whenever the code fails to place a signal

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)

Patchman · Post by **Patchman** » 01 Aug 2006 19:55

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.

eis_os · Post by **eis_os** » 03 Aug 2006 19:01

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

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

Rob · Post by **Rob** » 03 Aug 2006 19:02

Yes it should.

Ramshill · Post by **Ramshill** » 03 Aug 2006 19:24

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

broodje · Post by **broodje** » 03 Aug 2006 19:45

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.

pETe! · Post by **pETe!** » 03 Aug 2006 20:08

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.

michael blunck · Post by **michael blunck** » 03 Aug 2006 20:34

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

I guess it´ll variate the distance between signals.

regards
Michael

Patchman · Post by **Patchman** » 03 Aug 2006 20:50

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

Post by **Dave** » 03 Aug 2006 22:02

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 · Post by **Patchman** » 03 Aug 2006 22:15

Patchman wrote:explained in the first place

I mean first post. In this thread.

/me goes to have his brain checked out

eis_os · Post by **eis_os** » 04 Aug 2006 07:52

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...

pETe! · Post by **pETe!** » 04 Aug 2006 08:45

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.

Transport Tycoon Forums

2.6 nightly/alpha discussion

2.6 nightly/alpha discussion

Who is online