Tile measurement tool [v.8]

[MeusH]

r6758 is our happy revision.
Thanks to great help of Darkvater and other developers, and of course your tips and ideas, the patch is ready

_____________________________________________________________


Hello. Some time ago I've been making a tile measurement tool based on tooltips. [Link]

This was, however, producing random tooltip flickering and other problems.
Basicly, the tooltip is a window, and it had been found, destroyed, and created again each tick.
In this new version, main statusbar is being updated only when holding shift/relasing shift, so it works much faster.

The code is messy, because I didn't start cleanup. It is full of comments. My changes can be found via diff or via Search:MEUSH.
Be aware, it doesn't work yet for length=2 in regular directions(NE, NW, SE, SW), but it is visible only when doing NW.

Thank you in advance for global suggestions on performance and this patch in general.

[gigajum]

Nice work But i had solved it with an extra window in which you can put the text things. For the bridge build hint: If the bridge start tile is an the same hight as the end tile there is no difference. if its + or - one or more tiles it is a difference. But on the same hight tile plus or minus 1 is no hight difference shown. It begins with -/+ 50m at the second tile, not at the first from the destination tile. See attached screenshot.

On the Picture with length 5 is nothing shown, but it should (at least in my opinion).

i'll try to brush a picture with the box i suggested

[MeusH]

Good note. I knew something was wrong with height difference on slopes. Especially these slopes that have corners in 3 different height levels.
I'll try work on that, but please I need a help, preferred from someone who knows that heights things (build on slopes author maybye? )

Have you coded that window, and it works in game, or is it a quick mock-up?

[Darkvater]

I think the original tooltip method looked a lot better. You also don't need to create/destroy it each tick, just move it .

I think it's a bit confusing in the status bar, you won't expect it there.

[gigajum]

I think the original tooltip method looked a lot better. You also don't need to create/destroy it each tick, just move it .

I think it's a bit confusing in the status bar, you won't expect it there.

Yeah, the old way looked better, but the option with the extra window needs not to be repainted so often like the old way. To get the info in the status bar you have to press shift, which shows the estimated cost when you release the mouse button, which is not such handy.

I also found another small bug. When you build a dialog track with the autorail tool and your track is over 2 tiles diagonal it showes a length of 2, with 4 tiles it' a length of 2, too. With a length of 3 there is no length notice. Only the company name is shown. This only appears on north to south diagonal tracks, not on east to west tracks, there is it correct with a length of 2 over 4 tiles (diagonal).

[webfreakz.nl]

Meush, you reworked my idea of this patch! Cool!

But your 'old' one had some bugs, sometimes it was flashing and didn't seem to be able to count very good, but if you paused the game, and used 'built in pause mode' from the cheats-menu, everything worked fine!

I will try your rework of this patch as soon as I get back from the movies tonight ( Ice Age 2 )

[richk67]

In this new version, main statusbar is being updated only when holding shift/relasing shift, so it works much faster.

It sounds as if there are one or two quirks to be worked out. I will keep an eye on it, and add to Mini IN when all is happy. Thanks for working on this MeusH.

[MeusH]

I'm still wondering whether status bar or new window would be better for the measaurement.

I may work on displaying measurement in new window, just like tooltip. I hope won't have to destroy and create again the window just to move it. Also, tooltip-like window is generally better and more flexible IMO

The problem is that statusbar and tooltip are mutually exclusive, and I wouldn't like to double my work doing both ways. Any ideas? Constructive advices, please?

RichK67 suggested on IRC to put the measurements into a box similiar to chatbox (correct me if I'm wrong), but this is probably the most difficult way.

[richk67]

I'm still wondering whether status bar or new window would be better for the measaurement.

RichK67 suggested on IRC to put the measurements into a box similiar to chatbox (correct me if I'm wrong), but this is probably the most difficult way.

Yeah, something like that. The chat history area must have a routine to allow transparent printing in a defined area. You may be able to reuse some code, and just modify where it prints. Then it could be just above the status bar, and overlay the background.

[Darkvater]

I still think the yellow-tooltip is the best for this. If it is recreated every tick, which I frankly do not believe because then also the real tooltips will need to be redrawn every tick which they aren't, then that part needs to be changed/fixed instead of putting it in the status bar, or in the chat area. The chat area has the same problem as the status bar, it is not at the right place.

[richk67]

The chat area has the same problem as the status bar, it is not at the right place.

I wasnt suggesting the chat area; I meant do what it does, not do it where it does it! So have a separate place on the screen, which is not too obtrusive, where the tooltip is placed with a transparent background.

OTOH, if it can stop flickering, the yellow box near the mouse is what a user expects of a tooltip.

[MeusH]

Hello. I'm working on completly own window, which will eventually display all measurements. This way will be more efficient and safe than regular tooltip, and it will be more practical than showing measurements in the main statusbar.

However, I'm experiencing slight problem and I beg someone who had worked with windows and widgets to help me. The problem is, that I don't see any window.
Of course, shift and left mouse button must be hold.

The patch file looks messy because of commented out code, but I hope it won't cause problems.

Patched against r4438.
Thanks in advance

[gigajum]

i'll take a look on the code and see what i can fix. But not now time to go sleeping

edit: i took a look at the diff file and recognized that the widget defines are missing and the function which defines which widget define and which proc function to use. This may be the problem why you do not see the window

[MeusH]

I was wondering about _widget and proc declarations, but searching i.e. "ErrmsgWndProc" resulted in only one file. Besides, these are statics which IMO and IIRC do not need to be declared

[gigajum]

take a look at my waypoint stats diff file. There i added a new window for the stats. Maybe it's that what you're looking for.

[Darkvater]

MeusH, why don't you change the tooltips_d WP macro for example to:

Code: Select all

typedef struct {
	StringID string_id;
	uint32 param0;
	uint32 param1;
	uint32 param2;
	uint32 param3;
	uint32 param4;
	byte   param_count;
} tooltips_d;

This way you can easily set up the params and show them. Perhaps an idea?

[gigajum]

for the forum: (i posted it into MeusH's query on IRC)

GuiShowMeasureTooltips gets only called when using GuiShowMeasureTooltips()

Code: Select all

w = FindWindowById(WC_MEASUREMENT, 0);
if (w != NULL) {

needs to be (he should paint a window if he finds none, not repaint the not existing window

Code: Select all

w = FindWindowById(WC_MEASUREMENT, 0);
if (w == NULL) {

and the case "WE_PAINT:" needs to call "DrawWindowWidgets(w);" to get it's widges painted, without you get a window which has it's background as it's own

[MeusH]

MeusH, why don't you change the tooltips_d WP macro for example to:
...
This way you can easily set up the params and show them. Perhaps an idea?

If it would be optional and I wouldn't need to change every GuiShowTooltips entry, it's a good idea. I think you (devs) wouldn't like such a change.

Do you imagine I'd use DrawStringCentered in TooltipsWndProc?

It's all about distinguishind normal tooltip from measure tooltip (especially because the first one require right mouse button, and the latter one requires left mouse button to be hold)

[Darkvater]

To sum up the ongoing IRC chat. I think a general tooltip function using varargs (look up some tutorials if you are not familiar with it) would be just perfect. You can pass along any StringID and needed parameters and it will be drawn.

Do you imagine I'd use DrawStringCentered in TooltipsWndProc?

I don't see why you would need to draw centered strings there. The tooltip is as wide as the string (plus a few fixes left&right), so a simple DrawString() should do the trick.

It's all about distinguishind normal tooltip from measure tooltip (especially because the first one require right mouse button, and the latter one requires left mouse button to be hold)

That is the beauty of varargs. You don't need to distinguish. With that in place ShowToolTip(STR_BLA) will be handled EXACTLY the same as ShowToolTip(STR_BLB, 15) or ShowToolTip(STR_BLB, t->index, t->population, t->whatever) (all parameters except for the first one are string parameters).

Now I don't know how exactly you want to do it, but this would be a general, preferred way to go.

[MeusH]

v.3 is ready.
Great thanks to peter1138, glx and Darkvater. Especially for peter1138.


The tooltip, however, doesn't move with the mouse, and isn't yet shift-sensitive. This causes tooltip sometimes not to change height when going multiline.

Also, I have still problems with VPM_X_AND_Y_LIMITED (placing trees).

And of course, there are still problems with measuring height, but that will be fixed at the end, at least I'm planning to do that lastly.

Have fun!