Add a city-block tracker

[veger]

From https://mods.factorio.com/mod/TLBE/discussion/6498a5ed070072bbaa7d044c#post-2

other options for setting the camera target location - the one I frequently need is to center on the chunk the player is in, plus a half chunk around it, but I guess this can be a "center on player with radius x" with a "chunk-aligned" toggle; this happens when doing city block designs, where you want the camera to always be city-block-aligned

Basically you want to have some sort of a grid based camera positioning, where the city block area is the grid size? Or you see other use-cases where the player is the real/actual center of a (chunk) aligned tracker? (I guess it will be fairly easy to add some 'chunk align' or 'city block' tracker to implement this.

For this we'dthe following config in the tracker:

• grid size
• grid offset (no-one will have the first block in 0,0 on the map :stuck_out_tongue: )
• current block that should be zoomed on
• maybe (minimum) amount of blocks that should be zoomed on (to be able to zoom out on a bigger part of the factory)

[drdozer]

chunk-aligned city block blueprints will typically have a corner of the city block aligned with 0,0 but I take your point :D

[drdozer]

also for the ux, "focus on block the character is standing in"

[veger]

Alignment of the block/blueprint will be (likely) at 0,0. I mean the map coordinates which won't be aligned to the block (block 0,0 won't be at map 0,0). For this an offset is required,

focus on block the character is standing in

This is a nice QoL addition :+1:

[drdozer]

I'm happy to start work on this one next, once the box visualisation is wrapped up.

[drdozer]

Starting to look at this - there seems to be a single Tracker "class" shared by all trackers, with the type-specific logic mostly not actually in tracker.lua (my IDE finds 13 references to tracker.type in 5 files) -- this is the kind of thing where I'd usually reach for a strategy object or polymorphism but I have no idea the normal way to handle this in lua. I'm reading through it all now.

[drdozer]

OK, so digging into this, it's probably a lot of refactoring for only marginal gains to make this refactoring. I'll work with what we've got :D

[veger]

I have been thinking about refactoring the trackers and camera 'classes' into 'real' classes (Lua doesn't have a class concept, but with some trick it is kind of possible. I used this for TransistionData as an experiment).

The current implementation is (besides using 'packages' instead of 'classes') also messy. In the main.lua is tracker logic that should have been in the tracker.lua for example.

I am fine with refactoring and even willingly to do so myself if you don't feel like it, as the mod becomes bigger and the mess will backfire for sure.

[drdozer]

For my initial sketch, I've introduced:

Tracker.cityBlock = {}
--- @class Tracker.cityBlock
--- @field blockSize TilePosition The size of a single city block
--- @field blockOffset TilePosition The offset where the "first" city block begins
--- @field blockScale number How many blocks to hold in view (1=1 block, 1.5=1.5 blocks etc.)
--- @field currentBlock TilePosition An abuse of the TilePosition type to number the blocks (1,4 is one block over and 4 blocks up)

This at least keeps all the city block specific vital stats in one coherent place.

[drdozer]

fyi I see a lot of types like MapPosition.0 where I think they are supposed to be MapPosition without the dot digit.

[veger]

This at least keeps all the city block specific vital stats in one coherent place.

This is a singleton, so it would allow to configure only one city block tracker. That is why I was thinking about properly introducing classes, so we can have multiple instances and store tracker specific data inside them.

fyi I see a lot of types like MapPosition.0 where I think they are supposed to be MapPosition without the dot digit.

There are 2 possibilities for MapPosition: with x and y and with indices. These correspond to MapPosition.0 and MapPosition.1 (see the document about the lua language server support.) The mod only uses x and y, so I used MapPosition.0.

[drdozer]

I understand re MapPosition.0 now -- thanks.

I'll open a PR with some code for you to look at once I've figured out the GUI stuff.

[veger]

Hm... I was reading a bit about classes and I suddenly realized their meta tables are probably not serialized (and saved). And it seems that this is true: https://forums.factorio.com/viewtopic.php?p=397731

I'll check in-game so validate

Edit yep, the metatable is not stored causing:

Error while running event TLBE::on_tick (ID 0)
__TLBE__/scripts/camera.lua:197: attempt to call method 'lerp' (a nil value)
stack traceback:
    __TLBE__/scripts/camera.lua:197: in function 'followTrackerSmooth'
    __TLBE__/scripts/camera.lua:164: in function 'followTracker'
    __TLBE__/scripts/main.lua:143: in function 'takeScreenshot'
    __TLBE__/scripts/main.lua:42: in function 'tick'
    __TLBE__/control.lua:45: in function <__TLBE__/control.lua:44>

when saving during a transition...

So, lets move/stay away from Lua classes (bdbe1d9) :smile:

[drdozer]

OK. So at the moment I'm just using it to tell my IDE about fields. I'm not using any methods. I don't know how else to document fields for a struct (table?).

[veger]

You can add the documentation without actually defining the class:

---@class MyClass
--- ...
local MyClass = {}

At least I am doing this already (see Camera.camera, Tracker.tracker, etc), no idea if this is 'offcialy' allowed but it works with/for sumneko.lua extension of vscode.

[drdozer]

52 is now a MVP I think

[drdozer]

Can we close this now? It will feel nice to have the issues list go down in size :D

[veger]

I usually keep the issues open until it is released, so the reporter knows the request is available

[drdozer]

Cool.

[veger]

Released in v1.5.0