Transport Tycoon Forums

Well when I added the up/down buttons already told Josef about the distance problem, as the GUI for it should display some meaningfull easy to get value.

The current system doesn't. Say you press two times the up arrow and it still builds the signal the way as it did before... (and to make a difference you shouldn't need to click 4 times on the same button)

pETe! wrote: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)?

You made me realize that my thinking was wrong. When TTD calculates how much a train should move, it takes that distance times 0.75 on - and | tiles. Somehow I ended up thinking that I should do the same for signals, not realizing that | and - pieces are also much shorter...

In any case, I will change the signal separation to mean that you can fit N normal-length vehicles between signals, so 0 would put a signal on every tile, 1 would put on on every tile in / and \ and every other tile on - and |, and so on.

That will make Oskar's GUI happier too

When TTD calculates how much a train should move, it takes that distance times 0.75 on - and | tiles.

The feeled [gefühlte] Speed is different on _ and / tiles.
Seems that TTD calculates Speed different from dimensions, perhaps to emulate some more perspective view...

Nightly r759 works like that now, the distance setting is the number of normal-length wagons between signals. I've removed the switch because it's now set in the signal gui window too.

Only that it doesn't seem to be multiplayer safe, because it's not passed via the action handler ... I guess that needs fixing aswell.

But it is!

Ok,sorry, would be nice if you comment it at the action handler aswell:
http://svn.ttdpatch.net/trac/browser/tr ... i.asm#L434


Otherwise you will get spamed with such comments in the future aswell

Having tried the new autosignal tool, I've found a few things I personally would find an improvement. (r759)

Is it possible to either:
A: Add/return a switch for a default distance, or
B: Save the distance from savegame to savegame.

The reason I ask this is I use a distance of 10, but when reloading my game it defaults to 6 again - I didn't even notice the first time I clicked on it as I have a tendency to go through things without looking anymore (touch typists rule ) so placed signals at a distance that was incorrect (alarm bells rang when it looked wrong, so I checked the next time)

This is a huge improvement over huge distances, I no longer have to count tiles and place a hundred signals!

Scautura

Scautura: will look into it, I guess I will put the data into enhancegui and so it can be saved...

Changes in the next nightly (r764-r769):
If the signalgui window is open and ctrl-click gets pressed, ctrl clicking will change signal type as without gui.
Signalgui moved a bit to the right to allow through clicking (for previous feature)
Signalgui will look ever 7 gui ticks at the tile for changes.

eis_os wrote:Scautura: will look into it, I guess I will put the data into enhancegui and so it can be saved...

Well, how can i stick the depod-window-size since it have been ripped out of the enhanced gui?

The bottom right corner of each depot window is dragable such that the window can be resized.
The dimensions of each depot window type is stored when modified by the user, such that they are reapplied when the window is reopenned, hence making a global setting in the enhanced gui menu unnecessary.

OK, so I've made this topic the general 2.6 discussion topic now, because I want to draw attention to some changes in the recent nightly (r778).

TTDPatch now properly supports articulated wagons with cargo. When multiple vehicles in the wagon carry the same cargo, they only use one line in the info window unless the cargo is from different sources, in which case it'll be broken up. Different cargo types always go on separate lines even if all of them are empty.

Because these changes are also in the 2.5 release branch, they require extensive testing, mainly whether I've accidentally broken something else. So please have a look if any vehicles in the buy menu or in the game suddenly have very strange capacities, thanks.

Patchman wrote:TTDPatch now properly supports articulated wagons with cargo.

Neatsticks

/me runs to test

> show correct artic capacities in buy menu
> move vehicle info text to the right for artics
> [...]

Very nice!

regards
Michael

It doesn't seem to be showing the articulated capacity in the buy menu here. Otherwise, all good.

(Also, only the vehicle weight of the first vehicle is used - I assume this is the intended behaviour as otherwise it would require recoding all vehicle sets which use tenders, etc, but just checking).

Pff, Josef you made me fear the topic is again gone

About enhancegui:

Mek changed the code totally so I am bit lost in it, I think I will separate the code and redesign certain aspects... but first I need to understand Meks code. (I guess enhancegui window gets completely removed and I will put the options to some more natural places, say the options for setting TTD/Enhancegui style of station names...

The station gui code gets integrated into newstations, the code for Meks winsize, sticky and so on gets it's own bit switch...

> It doesn't seem to be showing the articulated capacity in the buy menu here.

Did you include CB16 in the action03´s "FF branch" as well?

regards
Michael

michael blunck wrote:Did you include CB16 in the action03´s "FF branch" as well?

Ahah. Thanks Michael.

PikkaBird wrote:It doesn't seem to be showing the articulated capacity in the buy menu here. Otherwise, all good.

I'd even documented that!

(Also, only the vehicle weight of the first vehicle is used - I assume this is the intended behaviour as otherwise it would require recoding all vehicle sets which use tenders, etc, but just checking).

Well, it's intended, but it's a bit of a hack and I'd be inclined to change that. I don't remember the rationale to do it this way... the problem doing it this way is that if you have variable-length artics (e.g. 3 parts before 1950 and 4 after 1950), then the weight will be wrong for one of them.

However as you say it would require recoding all existing artics if it were to be changed, so hmm...

Would it be possible for the Patch to look in the GRF for some code announcing version compatibility, so as to be able to tell if it was or wasn't coded correctly to take advantage of that?