pipeworks/wielder.lua:113: bad argument #1 to 'ipairs' (table expected, got nil) #1816

New Issue

AliasAlreadyTaken · 2022-04-23T09:02:44Z

AliasAlreadyTaken commented

2022-04-23 09:02:44 +00:00

2022-04-23 10:31:57: ERROR[ConnectionSend]: con(4/1) dropped reliable packet for non existent peer_id: 899
2022-04-23 10:32:05: ERROR[Main]: ServerError: AsyncErr: Lua: Runtime error from mod 'xp_redo' in callback environment_Step(): ...ve/5.5.0/Minetest_live/bin/../mods/pipeworks/wielder.lua:113: bad argument #1 to 'ipairs' (table expected, got nil)
2022-04-23 10:32:05: ERROR[Main]: stack traceback:
2022-04-23 10:32:05: ERROR[Main]: [C]: in function 'ipairs'
2022-04-23 10:32:05: ERROR[Main]: ...ve/5.5.0/Minetest_live/bin/../mods/pipeworks/wielder.lua:113: in function 'wielder_on'
2022-04-23 10:32:05: ERROR[Main]: ...ve/5.5.0/Minetest_live/bin/../mods/pipeworks/wielder.lua:147: in function 'action_on'
2022-04-23 10:32:05: ERROR[Main]: ...Minetest_live/bin/../mods/mesecons/mesecons/internal.lua:193: in function <...Minetest_live/bin/../mods/mesecons/mesecons/internal.lua:186>
2022-04-23 10:32:05: ERROR[Main]: ...etest_live/bin/../mods/mesecons/mesecons/actionqueue.lua:137: in function 'old_execute'
2022-04-23 10:32:05: ERROR[Main]: ...ve/worldmods/mesecons_debug/overrides/mesecons_queue.lua:20: in function 'execute'
2022-04-23 10:32:05: ERROR[Main]: ...etest_live/bin/../mods/mesecons/mesecons/actionqueue.lua:111: in function <...etest_live/bin/../mods/mesecons/mesecons/actionqueue.lua:73>
2022-04-23 10:32:05: ERROR[Main]: ...ive/5.5.0/Minetest_live/bin/../builtin/game/register.lua:425: in function <...ive/5.5.0/Minetest_live/bin/../builtin/game/register.lua:409>

2022-04-23 10:31:57: ERROR[ConnectionSend]: con(4/1) dropped reliable packet for non existent peer_id: 899 2022-04-23 10:32:05: ERROR[Main]: ServerError: AsyncErr: Lua: Runtime error from mod 'xp_redo' in callback environment_Step(): ...ve/5.5.0/Minetest_live/bin/../mods/pipeworks/wielder.lua:113: bad argument #1 to 'ipairs' (table expected, got nil) 2022-04-23 10:32:05: ERROR[Main]: stack traceback: 2022-04-23 10:32:05: ERROR[Main]: [C]: in function 'ipairs' 2022-04-23 10:32:05: ERROR[Main]: ...ve/5.5.0/Minetest_live/bin/../mods/pipeworks/wielder.lua:113: in function 'wielder_on' 2022-04-23 10:32:05: ERROR[Main]: ...ve/5.5.0/Minetest_live/bin/../mods/pipeworks/wielder.lua:147: in function 'action_on' 2022-04-23 10:32:05: ERROR[Main]: ...Minetest_live/bin/../mods/mesecons/mesecons/internal.lua:193: in function <...Minetest_live/bin/../mods/mesecons/mesecons/internal.lua:186> 2022-04-23 10:32:05: ERROR[Main]: ...etest_live/bin/../mods/mesecons/mesecons/actionqueue.lua:137: in function 'old_execute' 2022-04-23 10:32:05: ERROR[Main]: ...ve/worldmods/mesecons_debug/overrides/mesecons_queue.lua:20: in function 'execute' 2022-04-23 10:32:05: ERROR[Main]: ...etest_live/bin/../mods/mesecons/mesecons/actionqueue.lua:111: in function <...etest_live/bin/../mods/mesecons/mesecons/actionqueue.lua:73> 2022-04-23 10:32:05: ERROR[Main]: ...ive/5.5.0/Minetest_live/bin/../builtin/game/register.lua:425: in function <...ive/5.5.0/Minetest_live/bin/../builtin/game/register.lua:409>

AliasAlreadyTaken commented

2022-04-23 09:06:05 +00:00

 if data.eject_drops and inv and inv:get_list("main") then
                for i, stack in ipairs(inv:get_list("main")) do
                        if not stack:is_empty() then
                                pipeworks.tube_inject_item(wielder_pos, wielder_pos, dir, stack)
                                inv:set_stack("main", i, ItemStack(""))
                        end
                end
        end

``` if data.eject_drops and inv and inv:get_list("main") then for i, stack in ipairs(inv:get_list("main")) do if not stack:is_empty() then pipeworks.tube_inject_item(wielder_pos, wielder_pos, dir, stack) inv:set_stack("main", i, ItemStack("")) end end end ```

AliasAlreadyTaken added the

1. kind/bug

2. prio/critical

3. source/mod upstream

labels 2022-04-23 09:06:54 +00:00

flux commented

2022-04-23 18:17:14 +00:00

that's ... bizarre. there's a nil check on inv:get_list("main") right before it gets passed to ipairs?

that's ... bizarre. there's a nil check on `inv:get_list("main")` right before it gets passed to ipairs?

AliasAlreadyTaken commented

2022-04-23 19:39:30 +00:00

This nil chekc is my doing. That's the dumfix I noted.

THis line

 if data.eject_drops and inv and inv:get_list("main") then

looked like that before:

 if data.eject_drops then

This nil chekc is my doing. That's the dumfix I noted. THis line ``` if data.eject_drops and inv and inv:get_list("main") then ``` looked like that before: ``` if data.eject_drops then ```

flux commented

2022-04-23 20:03:35 +00:00

hm. that means that the "main" inventory for that wielder node is uninitialized, which means it's not a proper wielder node? placed or moved w/ worldedit, perhaps?

it'd be useful to log the cases when it is empty, to see what/where the locus of the problem is.

hm. that means that the "main" inventory for that wielder node is uninitialized, which means it's not a proper wielder node? placed or moved w/ worldedit, perhaps? it'd be useful to log the cases when it *is* empty, to see what/where the locus of the problem is.

flux commented

2022-04-23 20:15:58 +00:00

Yeah, was able to replicate this locally (against a different version of pipeworks?)

AsyncErr: Lua: Runtime error from mod 'player_api' in callback environment_Step(): ...n/../worlds/rolling_test/worldmods/pipeworks/wielder.lua:69: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
	[C]: in function 'ipairs'
	...n/../worlds/rolling_test/worldmods/pipeworks/wielder.lua:69: in function 'wielder_on'
	...n/../worlds/rolling_test/worldmods/pipeworks/wielder.lua:162: in function 'action_on'
	/opt/minetest/bin/../mods/mesecons/mesecons/internal.lua:192: in function </opt/minetest/bin/../mods/mesecons/mesecons/internal.lua:185>
	/opt/minetest/bin/../mods/mesecons/mesecons/actionqueue.lua:137: in function 'execute'
	/opt/minetest/bin/../mods/mesecons/mesecons/actionqueue.lua:111: in function </opt/minetest/bin/../mods/mesecons/mesecons/actionqueue.lua:73>
	/opt/minetest/bin/../builtin/game/register.lua:425: in function </opt/minetest/bin/../builtin/game/register.lua:409>

steps:

place a mesecons lever against a solid node at say {x=0,y=0,z=0}
break the node at {x=0,y=0,z=0}, leaving air
//fp set1 0 0 0
//fp set2 0 0 0
//r air dispenser_off
flip the lever on

Yeah, was able to replicate this locally (against a different version of pipeworks?) ``` AsyncErr: Lua: Runtime error from mod 'player_api' in callback environment_Step(): ...n/../worlds/rolling_test/worldmods/pipeworks/wielder.lua:69: bad argument #1 to 'ipairs' (table expected, got nil) stack traceback: [C]: in function 'ipairs' ...n/../worlds/rolling_test/worldmods/pipeworks/wielder.lua:69: in function 'wielder_on' ...n/../worlds/rolling_test/worldmods/pipeworks/wielder.lua:162: in function 'action_on' /opt/minetest/bin/../mods/mesecons/mesecons/internal.lua:192: in function </opt/minetest/bin/../mods/mesecons/mesecons/internal.lua:185> /opt/minetest/bin/../mods/mesecons/mesecons/actionqueue.lua:137: in function 'execute' /opt/minetest/bin/../mods/mesecons/mesecons/actionqueue.lua:111: in function </opt/minetest/bin/../mods/mesecons/mesecons/actionqueue.lua:73> /opt/minetest/bin/../builtin/game/register.lua:425: in function </opt/minetest/bin/../builtin/game/register.lua:409> ``` steps: 1. place a mesecons lever against a solid node at say `{x=0,y=0,z=0}` 2. break the node at `{x=0,y=0,z=0}`, leaving air 3. `//fp set1 0 0 0` 3. `//fp set2 0 0 0` 4. `//r air dispenser_off` 5. flip the lever on

flux commented

2022-04-24 00:25:07 +00:00

I'm unsure of what a proper solution for this would be. On one hand, pipeworks shouldn't have to assume that nodes might come into existence unitialized. On the other hand, Worldedit would become even slower if it had to initialize every node.

I'm unsure of what a proper solution for this would be. On one hand, pipeworks shouldn't have to assume that nodes might come into existence unitialized. On the other hand, Worldedit would become *even slower* if it had to initialize every node.

flux added

3. source/integration

and removed

3. source/mod upstream

labels 2022-04-24 00:26:10 +00:00

flux commented

2022-04-24 00:27:26 +00:00

For comparison, on Blocky Survival (which didn't have pipeworks, but had similar issues w/ machine mods and worldedit), the rule of thumb was "don't WE regions with machines".

AliasAlreadyTaken added the

3. source/mod upstream

label 2022-04-24 04:16:55 +00:00

AliasAlreadyTaken commented

2022-04-24 04:19:11 +00:00

I reported this to upstream, I think its both: integration AND upstream, but no clue who is at fault here.

Did we worldedit regions with amchines at that time? Not that I can recall.

https://github.com/mt-mods/pipeworks/issues/24

I reported this to upstream, I think its both: integration AND upstream, but no clue who is at fault here. Did we worldedit regions with amchines at that time? Not that I can recall. https://github.com/mt-mods/pipeworks/issues/24

AliasAlreadyTaken commented

2022-04-30 01:24:35 +00:00

your-land/administration#112

How did this ever work??

https://gitea.your-land.de/your-land/administration/issues/112 How did this ever work??

flux commented

2022-04-30 04:35:29 +00:00

How did this ever work??

how did what ever work? pipeworks? it works fine if you want to run pipeworks and don't care about what other mods might assume. using pipeworks basically requires that all other mods be coded as if pipeworks were a fundamental part of the minecraft lua API.

> How did this ever work?? how did *what* ever work? pipeworks? it works fine if you want to run pipeworks and don't care about what other mods might assume. using pipeworks basically requires that all other mods be coded as if pipeworks were a fundamental part of the minecraft lua API.

flux commented

2022-04-30 04:36:53 +00:00

and that's been the position of both VanessaE as well as mt-mods, which took over her mods when she gave up on the community.

flux commented

2022-04-30 04:46:31 +00:00

aside: sometimes i feel like my constant criticism of the community makes people feel less welcome to contribute. that is absolutely not what i want. but i feel like the community needs to follow "best practices" for developing open source software (e.g. don't break documented things that most users assume won't change), far more than the current norm. if you change basic functionality, give trivial options for restoring it. and try not to break trivial functionality in the first place, even if that takes a little longer. cf what i'm doing to keep integration between the IRC mod and verbana, or smartshops and a number of other mods.

aside: sometimes i feel like my constant criticism of the community makes people feel less welcome to contribute. that is absolutely not what i want. but i feel like the community needs to follow "best practices" for developing open source software (e.g. don't break documented things that most users assume won't change), far more than the current norm. if you change basic functionality, give trivial options for restoring it. and try not to break trivial functionality in the first place, even if that takes a little longer. cf what i'm doing to keep integration [between the IRC mod and verbana](https://github.com/fluxionary/minetest-verbana/tree/rework/compat), or [smartshops and a number of other mods](https://github.com/fluxionary/minetest-smartshop/tree/redo-redo/compat).

AliasAlreadyTaken referenced this issue

2022-05-03 19:10:40 +00:00

shanish reports: A newly placed nodebreaker dro ... #1871

AliasAlreadyTaken referenced this issue

2022-05-13 00:24:01 +00:00

Nodebreakers do not put items in tubes anymore #1916

AliasAlreadyTaken commented

2022-05-13 02:15:19 +00:00

Fixed in 57ec3e7b62

Fixed in https://gitea.your-land.de/your-land/pipeworks/commit/57ec3e7b6264bf251ca37de921f85863c10269dd

AliasAlreadyTaken closed this issue

2022-05-13 02:15:32 +00:00