Use map_y1 and map_y2 fields in Gui::DwarfmodeDims

[lethosor]

Needed for #746, mifki/df-twbt#21

[pronvit]

Not map_y1/y2. Something like map_width/height_in_map_tiles.

Examples of the things plugin may want to do:

• Print text in the menu area - need to know menu x1/x2/y1/y2 in text tiles, need to be able to output to the text buffer.
• Draw some text/dialog centred over the map - need to know map x1/x2/y1/y2 in text tiles (y1/y2 are the same as for the menu and area map), need to be able to output the text buffer.
• Find visible objects, draw something on the map (using map tiles) - need to know map width/height, need to be able to output to the map buffer. In the map buffer, map obviously starts at (0,0) always, so no x1/y1 needed here.

[lethosor]

A height and width wouldn't be consistent with the other fields. Anyway, what's the difference? Wouldn't you be able to get height and width with (map_y2 - map_y1) and (map_x2 - map_x1)?

For your second point, you could use map_y1 and map_y2 and set the map parameter of drawing functions to true to use map tiles, or use y1 and y2 and set map to false to use text tiles, e.g. for stuff like message boxes. (The latter is the default, I believe.)

[pronvit]

(map_x2 - map_x1) is usable of course, it just that max_x1/map_y1 do not make sense - they are "left/top edge of the map in 'map tiles'", while 'map tile' units exist only inside the map.

As for the drawing, yes, that was the idea, I just mentioned it for the sake of completeness.

[lethosor]

map_x1 and map_y1 both being 1 is more consistent with the other DwarfmodeDims fields, though - e.g. map_x1, map_x2, menu_x1, menu_x2, area_x1, and area_x2 are all absolute tile positions, so it's easy to draw text to the screen at, say, (menu_x1, y) and have it show up in the leftmost column of the sidebar menu. Without TwbT, map_y1 and map_y2 would be usable in the same way if they're absolute coordinates, so I think it's a cleaner solution.

Anyway, it turns out that I did add map_y1/y2 in 2a2ab00, but didn't update anything to use them.

[lethosor]

Update: I got some work done on this a few weeks ago, although it's not finished (or merged). The map_x1/y1 fields are actually set properly in C++, and the Lua gui library is partially refactored to use the C++ function internally.

[PeridexisErrant]

My build scripts just noticed that we have a stable DFHack release, and that I was planning to check on this issue. So:

• when is this expected to be merged? (from the tag I guess r2 😉 )
• will it mean that TwbT can distribute a single plugin only, instead of patching automaterial/mousequery/resume as well?

(No pressure, just to let me set the next build failure appropriately)

[lethosor]

Thanks for reminding me, but I somehow didn't get a notification for it, which is strange.

Anyway, yes, I do expect to work on this before r2, and it should allow TwbT to avoid distributing those three plugins as well. That depends on @pronvit to modify TwbT to use the hooks and on us to merge in whatever changes he's made (I believe there were a couple mousequery modifications).

[lethosor]

I've fixed the three plugins here, and fixing Lua scripts wound up being pretty easy, so I'm closing this.