Factorio Forums

I'm currently writing a mod where I would like visibility of a rendered object to be enabled/disabled as a player option. There's no difficulty with this, except there is a slightly bothersome interface: the player visibility in rendering functions.

I can store player visibility as a table local to the file, and the most obvious / performant / convenient expression is keying by player_index, and the value being true or the key being absent. i,e, {[1] = true, [2] = true, (player 3 was removed), (player 4 has setting = false so key is not present), [5] = true... }

However, according to LuaRendering, all the player tables should be arrays:
https://lua-api.factorio.com/1.1.42/LuaRendering.html

Effectively I need to poorly represent the visibility settings, adding or removing players by looping over the whole table every time a player changes the setting (so it's prepared for draw_* functions), or I have to build the table every time I want to draw. The former is cumbersome, the latter would scale very poorly.

In my case, the frequency of visibility is an entity selected with on_selected_entity_changed, and changing settings would be infrequent.

The table pattern is similar to the existing pattern of collision mask:
https://lua-api.factorio.com/1.1.42/Con ... lisionMask

A speculative difference is that since players can be uints, strings, luaPlayers, the first value would need to be tested as true to be loaded "the other way". If collisions masks were dependent on the key type being string vs uint... then that logic doesn't work. Edit: (actually I guess it does)

Turns out I can't use force *and* players to restrict only to those players on a certain force... I still have to build the table anyway. I guess there's 2 API requests, players-as-dictionary and filterable by force (even only filtered by a single force would be enough - an optional me-and-us-vs-them visibility).

Hmm, I think you can just use a map of `[index] = index`, which would be performant enough and easy to maintain

Honktown wrote: ↑Mon Oct 18, 2021 2:23 am The table pattern is similar to the existing pattern of collision mask:
https://lua-api.factorio.com/1.1.42/Con ... lisionMask

The specific reason it was supported for collision mask as input, was that the EntityPrototype would return the collision mask as `[string] = true`,
And then if you wanted to put that into a function such as surface.find_entities_filtered, you would need to loop through and unpack it

So the input of collision mask was extended to allow the input from the prototype format, ie, read the collision mask as `[string] = true`
In this case there is only the one representation of the collision layer, the string,
So the differentiation between an array of strings and a map of string->bool was trivial

With this player input, as you said, the player can be represented by a string, index, or LuaPlayer,
So the determination of what format being given is less clear to evaluate

Klonan wrote: ↑Mon Oct 18, 2021 12:30 pm Hmm, I think you can just use a map of `[index] = index`, which would be performant enough and easy to maintain

Thanks for the reply. With your hint, I tried with a numbered key, and with a string - both work (assumed you were offering a player index used twice).

Edit: also I think I didn't realize an empty players table meant "render to everyone" - from what I can see, looks like players are filtered by force provided, which simplifies a LOT