get_rendering (surface, position)

[darkfrei]

Hi devs!

Is it possible to get the rendering rectangle by some position? Something like

Code: Select all

local id = surface.get_rendering (position, mod_name)

[eradicator]

I have to admit that it would be quite nice to not have to remember all ids ever used in global but instead be able to retrieve them from the world somehow. Though i think for me it would me most useful to get a) renderings attached to a specific LuaEntity and b) only retrieve ids of renderings that the calling mod created itself.

[Rseding91]

I don't understand what you're asking for. You want "get_rendering" but then reference a draw rectangle function? Additionally the other post is talking about getting render object IDs?

[Rseding91]

I have to admit that it would be quite nice to not have to remember all ids ever used in global but instead be able to retrieve them from the world somehow. Though i think for me it would me most useful to get a) renderings attached to a specific LuaEntity and b) only retrieve ids of renderings that the calling mod created itself.

Those would all be O(N) operations. Just store the IDs you make when you tell the game to draw them.

[eradicator]

I have to admit that it would be quite nice to not have to remember all ids ever used in global but instead be able to retrieve them from the world somehow. Though i think for me it would me most useful to get a) renderings attached to a specific LuaEntity and b) only retrieve ids of renderings that the calling mod created itself.

Those would all be O(N) operations. Just store the IDs you make when you tell the game to draw them.

So are LuaSurface.find_entities_filtered operations i presume. And i *do* store my entity references and render IDs i create (obviously, as that's currently the only possible way to do it). But sometimes in non-performance-critical applications it would reduce mod-side code complexity if i didn't *have* to. It's imho a typical "if it was in base game mods wouldn't have to reinvent the wheel" situation.

As stated this is rather low priority to me. But if "it's O(N)" was a valid counter argument then half of the modding api would never have been implemented.

[Rseding91]

find_entities_filtered is O(N) on the entities that overlap the area you ask for rounded up to 2 tiles. LuaRendering is O(N) on the number of things stored in LuaRendering for that surface.

[darkfrei]

So if i have the rendering.rectangle somewhere on the map, but I know the position (or connected entity), then the best way is to scan all rendering objects, check them if they are rectangles, get the corners for this rectangles and check if the input position is inside of this rectangle?

Yes, I need to check that they are on the same surface.

[Bilka]

So if i have the rendering.rectangle somewhere on the map, but I know the position (or connected entity), then the best way is to scan all rendering objects, check them if they are rectangles, get the corners for this rectangles and check if the input position is inside of this rectangle?

Yes, I need to check that they are on the same surface.

Yes, that is what the C++ would be doing. Which is why it's not a thing: It's not only O(n), the operation that that to be done for every n is also pretty expensive.

[slippycheeze]

So if i have the rendering.rectangle somewhere on the map, but I know the position (or connected entity), then the best way is to scan all rendering objects, check them if they are rectangles, get the corners for this rectangles and check if the input position is inside of this rectangle?
Yes, I need to check that they are on the same surface.

Nope, the "best" way to do this, for the most common values of best, is using a tree structure to index the space for efficiently locating the device -- typically a variant of an R-tree, a BSP-derived tree like a k-d tree or quadtree, or maybe if you are feeling really exotic, some other structure using exotic space filling hibbert curves, or something. Since you have very limited search requirements a k-d tree should sort you right out, though, and is the easiest of those to implement. (Index surface as a Z dimension if you really can't limit your range to even same-surface indexes.)

The performance of this won't really be substantially different to having it done on the C++ side, though, since you already want to do this in a terrible way with an index operation, rather than just remembering where you put things -- or indexing them together yourself, using a classic map, which Lua does a really nice job on.

...but, yeah, if you want to fetch them from the world, do it by indexing them into an appropriate data structure. I mean, it'd be a terrible way to do it compared to, y'know, just writing those 64 bytes of memory or so into the save file, but YOLO, right?