Factorio Forums

BraveCaperCat wrote: Sat Jul 18, 2026 2:40 pm 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.

eugenekay wrote: Sat Jul 18, 2026 4:43 pm 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.

BraveCaperCat wrote: Sat Jul 18, 2026 2:40 pmI 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.

robot256 wrote: Sat Jul 18, 2026 6:28 pmI don't think OP minds that nil=all forces.

robot256 wrote: Sat Jul 18, 2026 4:27 pm

BraveCaperCat wrote: Sat Jul 18, 2026 2:40 pm 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 wrote: Sat Jul 18, 2026 4:43 pm 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 wrote: Sat Jul 18, 2026 6:28 pm

eugenekay wrote: Sat Jul 18, 2026 4:43 pm 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 wrote: Sat Jul 18, 2026 7:30 pm

BraveCaperCat wrote: Sat Jul 18, 2026 2:40 pmI 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.

robot256 wrote: Sat Jul 18, 2026 6:28 pmI 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.

BraveCaperCat wrote: Mon Jul 27, 2026 10:23 pm

eugenekay wrote: Sat Jul 18, 2026 4:43 pm 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 understand what you're talking about. I'm not asking for forces to become a required parameter. I wasn't even talking about players at all. (although I should mention that it has the same unintuitive behaviour that forces does)

My problem is with how the methods behave when forces (or players) is an empty table.

draw_line{color=…, width=…, gap_length?=…, dash_length?=…, dash_offset?=…, from=…, to=…, surface=…, time_to_live?=…, blink_interval?=…, forces?=…, players?=…, visible?=…, draw_on_ground?=…, only_in_alt_mode?=…, render_mode?=…}