Transport Tycoon Forums

It's great to see you working out my idea, but it's far from original. I don't mind that, but this will costs you more and more of work! You also have to think of the fact that if you edit more code, more code can change with every update of the SVN source. And read my signature as well (the quote in it)

Yeah, your signature is really funny

but it's far from original.

What do you mean?

More progress:

Tooltip is visible after pressing shift. I don't like shift, so if you have some proposals on key, please post. However, no ctrl - it is being used by diagonal selection patch.

It works with tunnels. However, it shows lenght of dock (2), too

Height difference for bridges works with no problems

The tooltip is no longer behind a mouse cursor. It is moved down. However, it can go behind the cursor at the very bottom of the screen

{} (new line sign) works in tooltip. Hacky way, but it works with no problems


TODO: Compatibility with railway construction (autorail and signals)

Attached file is still a r3165 diff because .dsp and .dsw files were not updated in the diff. Belugas' patch removed the errors, however, it created many errors with AI files

Sorry from triple posting but it is next case:

I've made autorail\signal placement in standard OTTD directions (NW, NE, SW, SE) but odd directions (N S W E) are true pain.

Dominik and Ludde wrote it, but real live caught them. Dominik was last logged in on IRC 37 weeks ago, Ludde 5 weeks ago. On the forum? Don't even try to count.

For anyone interested, now I'm working on CalcRaildirsDrawstyle in viewport.c. If you scroll down to it will be the N S W E direction code. At least I think "complicated direction" mean so...

By the way, here is a preview of working part of railway construction measurment

Great!
I compiled r3165 from SVN with your latest patch, deleted this line in misc_gui.c:

if(_shift_pressed) {

and the corresponding:
}
So now I don't have to press Shift to see the tooltip. Much better!

And I've found some little bugs, which are quite difficult to explain but I will try with a lot of screenies

just wait for the edit

MeusH wrote:Tooltip is visible after pressing shift. I don't like shift, so if you have some proposals on key, please post.

OK...

webfreakz.nl wrote:I compiled r3165 from SVN with your latest patch, deleted this line in misc_gui.c:

if(_shift_pressed) {

and the corresponding:
}
So now I don't have to press Shift to see the tooltip. Much better!

How about simply having it as a patch? I know I'd like this to be always-on. This relieves the need for any more keypresses, leaving more keys available for the rest of the game.

The no-shift patch, and behind that 2 pictures with minor tooltip-bugs

The red-arrow in tooltip#1.png shows an 7 which sometimes appears when pressing shift(the price function) + click.

How about ? It is working, so if you want a diff now, write and I'll post it

I still need help with the rail construction. About bug from picture tooltip#1, it is TT bug with strings. Sometimes strings are not updated and you can see letters' remains scattered on the ground

About tooltip#2, that's what I'm currently wondering about. Slope height is equal to height at the base of the slope. For example, if you measure height and go uphill, OTTD won't see height difference.
However, if you want to make a slope fondation, which will level the land, OTTD will think it is 50 meters below.

All I can do, and I think I should do it, is to check the slope heading and modify displayed height difference.

MeusH wrote:How about

Code: Select all

if (_shift_pressed || _patches.always_measure_tool) {

I still need help with the rail construction. If you want a diff now, write and I'll post it

That sounds better! You can always send the diffs to my email addres ( ronald {AT} webfreakz {DOT} nl ) and i'll try to respond to it asap!

webfreakz.nl wrote:

MeusH wrote:How about

Code: Select all

if (_shift_pressed || _patches.always_measure_tool) {

I still need help with the rail construction. If you want a diff now, write and I'll post it

That sounds better! You can always send the diffs to my email addres ( ronald {AT} webfreakz {DOT} nl ) and i'll try to respond to it asap!

I'll post all diffs here, just check this thread. I'll take care of fixing values on slopes and post next diff when I fix slopes or rail construction

I think the height diffrence should be measured in squares not meters..

That's what I've been thinking about, but on the IRC we (I and developer) has discussed that we'll stick to minimap's height measurment (50 meter steps)
However, I think it can be also toggleable

webfreakz.nl, this one will fix some errors regarding height at slopes. But not all. Please test it.

This, imo, might be more logical as 3x1 since that's the actual area of land that will be flattened.
As it is, if you wanted to flatten land for a 7x7 station you would have to drag an 8x8 area which might be a bit confusing.

Here the 2 screenshots about the bug
The arrow shows the drag-direction:

It is because the white dot means tile under, to the left of it. This is why you're getting this bug. I'll think about it soon, but now I've met Darkvater on IRC and we'll talk about railway construction.

You could also write the estimated cost for these things. It would be very helpful to calculate expenditures when working with not too much money...

mr.adam wrote:You could also write the estimated cost for these things. It would be very helpful to calculate expenditures when working with not too much money...

what about pressing the Shift button before building?

If you write the cost with the size & height data, pressing shift becomes unnecessary... You get one less "red" message, and a free hot key.

I'm not sure about the query cost, since:
* It's easy to press shift and then repeat the procedure
* Functions I'm working on have nothing to do with type of construction (is it rail? road? station? tree planter tool?)

I may do some research on query cost later, first I'll work on finishing the current measurment patch.