FS#283 - Tile Measurement Tool

Attached to Project: OpenTTD
Opened by Meush (Meush) - Thursday, 17 August 2006, 10:20 GMT
Last edited by Bjarni (Bjarni) - Sunday, 20 August 2006, 19:52 GMT
Type Patch
Category Interface
Status Closed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This tool allows user to measure amount of highlighted tiles by pressing shift during "drag'n'dropping" (placing railway, signals, road, trees, buldozzing area, building bridges, levelling land)
It works also when "presizing" tunnels and docks.
This patch also measures height difference between start and end tile for easy construction planning.

This patch is (almost?) finished, so please voice your comments and tips on coding style and what else to do to get it committed. Thank you in advance
This task depends upon

Closed by  Darkvater (Darkvater)
Sunday, 22 October 2006, 12:30 GMT
Reason for closing:  Implemented
Additional comments about closing:  Damn flyspray, forget to close its bugs :s
Comment by Loïc GUILLOUX (glx) - Thursday, 17 August 2006, 23:47 GMT
I only checked the style :)

Remove commented out code:

Don't add too many empty lines in VpSetPresizeRange() (viewport.c)
Check trailing white spaces/tabs
Add spaces where needed:
+ display_x = abs(TileX(to) - TileX(from))+1; <-- spaces around "+"

Respect coding style for if and switch:
Comment by Meush (Meush) - Friday, 18 August 2006, 10:57 GMT
I cleaned it up a bit, thank you glx
Comment by Meush (Meush) - Friday, 18 August 2006, 12:39 GMT
Thanks to Tron for pointing multiple color markers in lang file
Comment by Meush (Meush) - Monday, 21 August 2006, 15:22 GMT
I've added more comments and made docks not show length tooltips (as long as we don't have bigger docks).
Unfortunatelly I stumbled upon a problem that tunnels (and docks before) don't show estimated cost (estimated cost works in all other functions besides VpSetPresizeRange, and I don't really see why)
Comment by Darkvater (Darkvater) - Saturday, 26 August 2006, 15:11 GMT
I've looked at the patch (and rewritten about 90% of it ;p).

I have 5 points in which input/suggestions would be desired:

1. You see the tooltip with SHIFT. Isn't it better to make it a patch option and always see it if on?
2. Some tooltips have a newline in them ({}). The tooltip needs more height; so the StringID is checked. Not so nice and very rigid. Easiest solution would be to loop the string and check for newline characters. Is there perhaps a better way?
3. CalcHeightDifference() is really sucky with height calculation on slopes. Really needs something better, have no idea yet. Input very much appreciated
4. To show tooltip in viewport.c method is checked again for VMP_X_OR_Y/VPM_FIX_X/VPM_FIX_Y. Can this second check be skipped somehow (it's already checked in the switch statement before), without writing the code 3 times?
5. There are 2 GuiShowTooltips functions. One without vararg, one with. Chosen because otherwise you would need to get the StringPtr and parse it to see how many parameters you need. Good, bad, suggestions?

I can get rid of points 2 and 5 by using MeusH's original GetStringPtr() function and scan that for parameters and the inevitable newline-scan. Advantage: unlimited newlines, only one GuiShowTooltips function. Disadvantage: pull out internal getstringptr function from strings.c, probably something else as well; forgot.
Comment by Darkvater (Darkvater) - Saturday, 26 August 2006, 20:27 GMT
New patch, points 3 and 4 still stand. 4 I can live with but point 3 is a real picker and I'm still out on what to do about it.
Comment by Meush (Meush) - Monday, 28 August 2006, 08:08 GMT
Measuring height difference works fine on slopes.
My method was to measure height of opposite corners of both start and end tile, which just works :)
Comment by Darkvater (Darkvater) - Tuesday, 05 September 2006, 23:25 GMT
MeusH: you conveniently forgot the correct heightdiff for autorail, eg vertical/horizontal drag :)

I've finished the patch, but it needs polishment which I unfortunately really not have. It would need some cleanup, some higher compression hopefully.
Otherwise I think it works in all aspects.
Comment by Meush (Meush) - Wednesday, 06 September 2006, 05:35 GMT
Thank you Darkvater.
You said about polishment and cleanup - do you mean checking the coding style and changing how all functions work?
I'd really like to see that committed, so I'll check the style, but I'm not really sure about functions - they look really ok for me.
Any other developers - is there something else to do before commit?