data:extend({nil}) does not error, but causes the NEXT prototype to fail to register

[Reika]

That is to say, if I have prototypes A, B, C, and D, and data:extend({a, b, c, d}), if b is nil, there is no error thrown at any point, but c also fails to be created in the game.

[Nexela]

Code: Select all

function data.extend(self, otherdata)
  if type(otherdata) ~= table_string or #otherdata == 0 then
    error("Invalid prototype array " .. serpent.block(otherdata, {maxlevel= 1}))
  end

  for _, e in ipairs(otherdata) do

Not a bug in the sense that it is doing what ipairs does by stopping iteration at the first nil. I wouldn't be surprised if rseding changes it to use pairs though, because pairs always works

[Reika]

Code: Select all

function data.extend(self, otherdata)
  if type(otherdata) ~= table_string or #otherdata == 0 then
    error("Invalid prototype array " .. serpent.block(otherdata, {maxlevel= 1}))
  end

  for _, e in ipairs(otherdata) do

Not a bug in the sense that it is doing what ipairs does by stopping iteration at the first nil. I wouldn't be surprised if rseding changes it to use pairs though, because pairs always works

At the very least, "nil" should throw an error as a prototype value, the way random garbage does.

[eradicator]

At the very least, "nil" should throw an error as a prototype value, the way random garbage does.

You're basically calling data:extend{[1]=a,[2]=b,[4]=d}. Lua doesn't make a difference between you explicitly setting [3] to nil or if [3] just accidentially happens to be nil, same as for [5] and following.

Changing to pairs() sounds like a reasonable solution.

[Rseding91]

Thanks for the report however I don't consider this worth adding a custom error for.

Currently even the "type" checks in data:extend have a measurable overhead to how long it takes prototypes to load. Since the *extreme* normal use-case is the inputs are correct I think it's fine if it doesn't handle "nicely" when they aren't.