Page 1 of 1

[0.18.35] Calling LuaInventory::set_bar() with nil argument causes error

Posted: Thu Jul 09, 2020 4:47 pm
by robot256
System:
Factorio 0.18.35
x64 PC Running Windows 10

What happened:
Calling "LuaInventory::set_bar(nil)" generates the following error:

Code: Select all

Error while running event VehicleWagon2::on_tick (ID 0)
'bar': real number expected got nil.
stack traceback:
	__Robot256Lib__/script/save_restore.lua:441: in function 'restoreFilters'
	__Robot256Lib__/script/carriage_replacement.lua:178: in function 'replaceCarriage'
	__VehicleWagon2__/script/loadVehicleWagon.lua:29: in function 'loadVehicleWagon'
	__VehicleWagon2__/control.lua:116: in function <__VehicleWagon2__/control.lua:80>
stack traceback:
	[C]: in function 'set_bar'
	__Robot256Lib__/script/save_restore.lua:441: in function 'restoreFilters'
	__Robot256Lib__/script/carriage_replacement.lua:178: in function 'replaceCarriage'
	__VehicleWagon2__/script/loadVehicleWagon.lua:29: in function 'loadVehicleWagon'
	__VehicleWagon2__/control.lua:116: in function <__VehicleWagon2__/control.lua:80>
Calling "set_bar()" with no arguments at all clears the bar as expected.

What I expected to happen:

The documentation says "bar :: uint (optional): The new limit. Omitting this parameter will clear the limit." I expected that calling "set_bar(nil)" and "set_bar()" should have the same behavior, because in the Lua vernacular "nil" and "missing" mean the same thing. I believe this is a minor inconsistency that could be corrected.

Re: [0.18.35] Calling LuaInventory::set_bar() with nil argument causes error

Posted: Thu Jul 09, 2020 4:52 pm
by Rseding91
Thanks for the report however that's not how this works. If the thing says "omitting it" it means omitting. "nil" is not omitted: it's passing "nil".

Re: [0.18.35] Calling LuaInventory::set_bar() with nil argument causes error

Posted: Thu Jul 09, 2020 10:59 pm
by robot256
Okay, thanks for the clarification. This makes sense now that I remember "get_bar()" always returns a number even when the player has not changed it, so it's not an asymmetry like the bug with "color" you fixed recently. My code was saving it as nil when it had not been changed by the player, so I will handle that correctly myself.