Visualize capture regions on the map

[veger]

From https://mods.factorio.com/mod/TLBE/discussion/6498a5ed070072bbaa7d044c

map visualisation of capture regions - I know we can't draw rectangles onto the map, but perhaps we can use bookmarks or something to demarcate the rectangle being captured, and when panning, the target rectangle

[veger]

I do not have any experience with the map API/possibilities

Drawing on the map would be nicest, but alternatively markers could be used to show the area(s). Although I have no idea how clear this would be and how much performance degradation it takes (updating only once in a while might counter performance issues)

I guess some experiment/test needs to be done, to make this request more clear and to see what is feasible

[drdozer]

There is no API to render extra shapes onto the map. I have no idea the performance of adding and removing map markers, so as you say, this would need testing. It would be possible to use corner marker icons as the map icons though I think. It would mean shipping those icons with the mod.

[drdozer]

I've made a start on this. I can put down a map marker at the centerPos position on the map, and it tracks about as you would expect. How do I calculate the bounding box from the centerPos and other numbers in the camera? I am guessing I need to use the zoom somehow? And possibly the width and height?

[drdozer]

This is just a proof of concept. The box width and height are hard-coded, and I would need to replace the labels rendering the box with icons, but it basically works. As I walk about or build things, the box moves as expected.

[veger]

Trackers have a size object, which is calculated into a zoom for the Camera (as factorio API requires zoom) here https://github.com/veger/TLBE/blob/master/scripts/camera.lua#L167

I guess if you reverse this you can calculate size again (where centerPos is the middle of the area defined by the size).
Alternatively, we could store size and calculate zoom on each screenshot that is taken (or both are kept), but that requires to modify the transition code, as it goes from one zoom factor to another.

[drdozer]

Is this the code I should be getting inspiration from?

function Camera.zoom(camera, tracker)
    -- Calculate desired zoom
    local zoomX = camera.width / (tileSize * tracker.size.x)
    local zoomY = camera.height / (tileSize * tracker.size.y)
    return math.min(zoomX, zoomY, maxZoom)
end

If I'm following this, the values have the following units:

tileSize: pixels per tile
tracker.size.{x,y}: tile
camera.{width,height}: pixel
zoomX,zoomY: dimensionless

So I think to calculate my boundary in tiles I use:

local width = zoom / (tileSize * camera.width)
local height = zoom / (tileSize * camera.height)

The logic in the zoom method seems to clip the captured region. So if the region was very long and thin, it would cap the zoom to capture the height, and if it was very tall and narrow, it would cap the zoom to capture the width. Is this the intended behaviour? It may explain why I was having difficulty with some captures where I thought it would be maximal over the bookmarks I set for corners. If we are reworking the rectangles and zoom logic, perhaps this return value could become:

    return math.min(
      math.max(zoomX, zoomY),
      maxZoom)

But perhaps I have misunderstood the zoom and got it inverted in my head. Bigger zooms show fewer tiles, right?

[drdozer]

See #48

[veger]

I'll be merging #46 soon, which adds the transitionData object in the camera. This object has the start and end positions/zoom factors. So I guess it makes sense to use that info.

It also adds more info on the fields (in an attempt to start documenting the code)

The logic in the zoom method seems to clip the captured region

More to extend the captured region, I guess. So it will contain at the least the intended area of the tracker. With a perfect ratio zoomX and zoomY are equal. Otherwise the smallest zoom factor is picked (smaller zoom is bigger area screenshotted) making sure that the screenshots indeed contain the tracker area.

[drdozer]

Ok. I'll pull tomorrow, and depending on how inspired I am, add a box for the tracker target.

…

On Tue, 27 Jun 2023, 18:57 Maarten Bezemer, ***@***.***> wrote: I'll be merging #46 <#46> soon, which adds the transitionData object in the camera. This object has the start and end positions/zoom factors. So I guess it makes sense to use that info. It also adds more info on the fields (in an attempt to start documenting the code) The logic in the zoom method seems to clip the captured region More to extend the captured region, I guess. So it will contain *at the least* the intended area of the tracker. With a perfect ratio zoomX and zoomY are equal. Otherwise the smallest zoom factor is picked (smaller zoom is bigger area screenshotted) making sure that the screenshots indeed contain the tracker area. — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEOOXDXRYKYVCOMHWCATLDXNMNIJANCNFSM6AAAAAAZTXMYSQ> . You are receiving this because you commented.Message ID: ***@***.***>

[veger]

I believe it is possible to change the tint of sprints? No idea whether this is possible for map tags... If so it would be nice to have different colors for the different areas on the map?

[drdozer]

Yes. I learned how to make an icon today. Tomorrow I will learn how to tint them.

…

On Tue, 27 Jun 2023, 19:02 Maarten Bezemer, ***@***.***> wrote: I believe it is possible to change the tint of sprints? No idea whether this is possible for map tags... If so it would be nice to have different colors for the different areas on the map? — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEOOXCKYNXD3KZTLVK5YWTXNMN4NANCNFSM6AAAAAAZTXMYSQ> . You are receiving this because you commented.Message ID: ***@***.***>

[drdozer]

Tints implemented for 'corners' icons.

[drdozer]

note to self - the current code crashes if used with an old save with an old mod, as the camera doesn't have the new field for the tags - it just needs a nil check added, not an upgrade script, but if I don't document the issue I will forget it