mesecons_mvps/init.lua:221: in function 'mvps_move_objects' to pistons, internal to actionqueue.lua:93: in function 'execute'

[Festus1965]

trafficstars

after updated server from 5.2.0 with weeks, moths of NOT a failure, or yes a CRASH the mod I took from 11.04.2021

now with 5.4.1 this:

2021-06-12 22:30:10: ERROR[Main]: ServerError: AsyncErr: environment_Step: Runtime error from mod 'technic' in callback environment_Step(): /home/thomas/.minetest/mods/mesecons/mesecons_mvps/init.lua:221: attempt to index a nil value
2021-06-12 22:30:10: ERROR[Main]: stack traceback:
2021-06-12 22:30:10: ERROR[Main]: 	/home/thomas/.minetest/mods/mesecons/mesecons_mvps/init.lua:221: in function 'mvps_move_objects'
2021-06-12 22:30:10: ERROR[Main]: 	...thomas/.minetest/mods/mesecons/mesecons_pistons/init.lua:116: in function 'action_off'
2021-06-12 22:30:10: ERROR[Main]: 	/home/thomas/.minetest/mods/mesecons/mesecons/internal.lua:213: in function 
2021-06-12 22:30:10: ERROR[Main]: 	.../thomas/.minetest/mods/mesecons/mesecons/actionqueue.lua:93: in function 'execute'
2021-06-12 22:30:10: ERROR[Main]: 	.../thomas/.minetest/mods/mesecons/mesecons/actionqueue.lua:84: in function <...>
2021-06-12 22:30:10: ERROR[Main]: 	/usr/local/share/minetest/builtin/game/register.lua:422: in function 
2021-06-12 22:30:10: ERROR[Main]: stack traceback:

[Festus1965]

it was not under 5.2.0, as it was under 5.3.0 and 5.4.1 and now also at MultiCraft 2.0.0

some build of a gamer, that is NOW with 5.3.0 + not working. What I have to search for ?

[Desour]

1. Make sure you are using the newest master.
2. Describe a minimal scenario for reproduction of the crash. Ie. provide a minimal list of installed mods, and give steps for what to build/do to trigger the crash.
3. Describe what happens (here a backtrace).

[Festus1965]

this issue happened also older master, and a update some time ago didn't solve it, as this issue started with 5.3.0 and still in 5.4.1 ... and now also in MultiCraft 2.0.0 fork 5.4.1

scenario: when activation that mapblock be visiting ... but I don't know what is build there, as of crash, and as of other gamer visit it ... so I have not the exact idea where and what is build there (maybe was Zentro, the selling or plant tower)

what happens: I only see crash - with that report

... I am not sure if I wanna be again the tester (as we are more than a vaccine receiver) and try newest master, as that part of mod mvps hasn't changed 15 months, and it's boring to test ... after 6 years of gaming mt.

That builder made a construction, that was legal and no crash before 5.3.0 ... it happened exact THEN, and not with any update of mesecons.

[Desour]

It's still unclear what minimal set of mods need to be used and what to build to reproduce your crash.

Also, I kinda doubt that your traceback came from the newest mesecons master as of 11.04.2021, because there's no index happening at mesecons_mvps/init.lua:221 and hence attempt to index a nil valueis impossible: https://github.com/minetest-mods/mesecons/blob/65793514fe614147c5141ae7797be402b5e6d25d/mesecons_mvps/init.lua#L221

So, to make it a easier for you, here are some step for step instructions that could help you:

1. Get the newest mesecons master.
2. Deactivate all mods.
3. Go to the location that causes the crash.
4. Look at what has been built there.
5. Activate everything in mesecons except mesecons_mvps.
6. Go there again. And take a screenshot.
7. Activate the whole mesecons modpack.
8. Go there again.
9. If it crashes, report.
10. If not, activate some of your mods.
11. Go back to step 8. On crash, disable mods again and only keep those that are needed for the crash.
12. Then paste the minimal list of mods, and the screenshot.
13. Try to rebuild the crashing construction.

Also note that there are some known issues with mvps things moving stuff like gates. So this might be a duplicate, but we can't know without enough information.

[Festus1965]

ohoh, this is my starting string put in every new / updated mod to remember: modcounter = modcounter + 1 -- from : https://github.com/minetest-mods/mesecons print("[Mod] mesecons (6579351/10.04.2021) - (" .. modcounter .. ") - end with "..math.floor(collectgarbage("count")).." KB")

my line 221 in the download I marked with this release local cbox = obj:get_properties().collisionbox

ok, so

• first you wanna tell me, that this is not a mod collection, it is a set, witch where-ever inside the mod on parts got an update, I have to update the hole file-set ? (What mean also, that with one issue solved, I might but another 2 that will be new ...)
• I downloaded the full mesecons, put my starting set in with actual release and date, and put it on server,
• but I will NOT do this research then ... I will wait for a time I have no gamer online, or a crash restart by accident,
• and then MAYBE searching for this build that makes the crash I am not anymore a mineTESTER, I am a MultiCrafter now haha

added: 4 hours later I had an travelnet crash 3rd time, so your/this new version is active. We will see

[Desour]

first you wanna tell me, that this is not a mod collection, it is a set, witch where-ever inside the mod on parts got an update, I have to update the hole file-set ?

I'm not sure what you're referring to with "this". Normally one would want to use for everything to the same version, to avoid compatibility issues, this is not only in minetest the case. And you obviously have to use the newest mesecons master, otherwise you're maybe just reporting an already fixed bug. :P

I would definitely not recommend doing this testing on a production server. Just copy the map and test locally.

[numberZero]

my line 221 in the download I marked with this release local cbox = obj:get_properties().collisionbox

That line was there until Sep 21, 2019. Closing as clearly outdated.

P.S. It is also irrelevant what line was there in the download, the important thing is what line was actually executed.