[2.1] Unintuitive force behaviour on LuaRendering methods

[BraveCaperCat]

Quite strangely, the draw methods on LuaRendering will draw to all forces if the forces parameter is set to an empty table. Thankfully, this behaviour is documented, (otherwise this would definitely be going in Bug Reports) but I don't see any reason why anyone would want this behaviour or how it could arise without explicitly adding it in.

I'd like this confusing and unintuitive behaviour to be removed, or if not, an explanation of why it's there to begin with.

[Rseding91]

Why?

[robot256]

Quite strangely, the draw methods on LuaRendering will draw to all forces if the forces parameter is set to an empty table. Thankfully, this behaviour is documented, (otherwise this would definitely be going in Bug Reports) but I don't see any reason why anyone would want this behaviour or how it could arise without explicitly adding it in.

I'd like this confusing and unintuitive behaviour to be removed, or if not, an explanation of why it's there to begin with.

What should it do instead? Crash the game? Create invisible rendering objects?

[eugenekay]

From an API design perspective, leaving forces and players as optional parameters simplifies the function-calling stack in the trivial case of a Singleplayer game or Multiplayer-all-players-on-the-same-force (default), since you do not need to worry about them at all. If you are trying to render only to a specific player/force chances are good that you know what you are doing. Changing them to required parameters at this point would create Runtime errors for every mod which relies upon this default behaviour - leading to more Bug Reports.

[robot256]

From an API design perspective, leaving forces and players as optional parameters simplifies the function-calling stack in the trivial case of a Singleplayer game or Multiplayer-all-players-on-the-same-force (default), since you do not need to worry about them at all. If you are trying to render only to a specific player/force chances are good that you know what you are doing. Changing them to required parameters at this point would create Runtime errors for every mod which relies upon this default behaviour - leading to more Bug Reports.

I don't think OP minds that nil=all forces. I can speculate (based on my own similar experiences) they just got frustrated after spending a lot of time debugging some code that selectively removes forces from a list which appeared to be fine until it removed all the forces from the list and then seemed like the filter wasn't working at all.

The documentation is there, so the solution is trivial: "if table_size(force_list)>0 then draw(...)". If you want to argue that forces={} should crash, then you still need the if statement. I don't know what value a render object visible by no forces would have.

[eugenekay]

I don't see any reason why anyone would want this behaviour or how it could arise without explicitly adding it in.

I'd like this confusing and unintuitive behaviour to be removed, or if not, an explanation of why it's there to begin with.

I don't think OP minds that nil=all forces.

Null/nil generally means that no argument was provided to the function; an empty table would value-check to null since no forces match the selector, so the default behavior (all forces) makes total sense.