Digtron corruption solved ? (may be)
Tested with
- minetest-5.0.1-win32
(Windows XP , 32 bits , Pentium III 3.20 Ghz 2 GB RAM, noisy old fragmented HD)
Game minetest
digtron 0.8
mg_name = flat
chunksize = 3 Dont remember have set this, probably mgflat default
Simple downwards 1x1 shaft with steel ladder digging machine, 8 nodes high
digger-fuelstore-inventory-auto_controller-structure-structure-inventory-builder (steel ladder)
Overclocked x5 digtron to add stress. config.lua "cycle_time" 0.2
Digtron soon stops, 'obstructed', 'out of fuel'... , vanished nodes, shifted inventories...
I believe metadata are OK, nodes bad.
Bad nodes are those inside a new generated mapblock.They are 'timeshifted' some cycles backwards
My theory: (humorous version)
This is a relativistic problem.
Advancing digtrons suffer
Lorentz contraction due to their speed.
In normal mapblocks, contraction is negligible , speed << c
But new generated mapblocks are highly excited, unstable, which drastically lowers light speed.
In scale, digtron speed grows compared to c, Lorentz contraction grows to an unbearable amount, digtron
nodes are forced to contract, but, as quantum particles they are, they cant.
A node is a node, cant be 0.98 nodes.
This stress causes high node unstability, leading to vanishment of one of the nodes.
Metadata are tachyonic, unaffected.
My theory: (the serious one)
Keeps being a little relativistic, space-time involved, ha,ha.
- Digtron reaches unloaded mapblock and detects "ignore".Calls emerge_area
- Digtron detects the "ignore" node has become other.Mapblock is loaded.
- Digtron advances. (1 node A inside new block).
- Digtron advances. (2 nodes AB inside new block).
- XXX copies the mapblock to a voxelmanip to update something (with 2 digtron nodes AB in it)
- Digtron advances. (3 nodes ABC inside new block).
- XXX writes back the updated mapblock (with 2 digtron nodes AB in it)
Digtron inside the new block has time-traveled 1 cycle backwards, ha, ha
- Digtron corrupted.Node C has vanished.
XXX ? WTF is XXX? - May be cavegen, oregen, decorations, liquid flowing calculations, other mods on_generate, some world database weirdness...
Conclusion:
Do not rely on "ignore" node turned to another type to tag the mapblock as safe.To soon.
Nothing wrong with inventory location.Node location fails.
emerge_area(...)
Researched what
emerge_area does, using its callback.
Good example in "emergeblocks" chat command def,
\minetest-5.0.1-win32\builtin\game\chatcommands.lua
Got 1331 calls (11 x 11 x 11)
And saw digtron advances BEFORE all the area emerged.
Callback receives 'pos' of generated mapblock, measured in mapblock units, not nodes.
It loops the area in usual voxelmanip order
Digging at x = 3000 , z = -3000
Code: Select all
for z = -193, -183
for y = -349, -339
for x = 182, 192
Callback operates in another thread, [Emerge-0] versus [Server] in debug.txt.
THE SOLUTION
Tried editing node_controllers.lua to advance at
emerge_area completion: when the callback receives
num_calls_remaining = 0
Have drilled at x5 speed a couple thousands nodes without problems.(aside of damned lava)
Modified
node_controllers.lua (only file changed)
The first bad news:
Only tested drilling downwards.
Not massive tests, could be the problem is only less frequent.
The second bad news:
Before, digtron stopped 3 to 5 sec awaiting block load.
Now, 19, 14, 11 ... secs (1331 mapblocks are much)
But this is an old PC.
This could be made a "overheating pause", "autocalibrating...", ha, ha
Or emerge smaller area, only needed:
- minimal cuboid containing digtron + 1 to build/dig
- and minimal cuboid containing first/last digtron cuboid after moving N nodes towards its working dir.
Or call emerge in advance
The third bad news:
Some warnings.But all works OK.
May be must pass some variable more to the callback, or digtron unrelated, or... dont know.
Code: Select all
2019-10-16 17:35:35: WARNING[Server]: StaticObjectList::remove(): id=685 not found
2019-10-16 17:35:35: WARNING[Server]: StaticObjectList::remove(): id=684 not found
2019-10-16 17:35:36: WARNING[Server]: ServerEnvironment::deactivateFarObjects(): id=686 m_static_exists=true but static data doesn't actually exist in (187,-457,-188)
2019-10-16 17:35:36: WARNING[Server]: StaticObjectList::remove(): id=686 not found
2019-10-16 17:37:00: WARNING[Server]: ServerEnvironment::deactivateFarObjects(): id=893 m_static_exists=true but static data doesn't actually exist in (187,-470,-188)
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=893 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=892 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=891 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=890 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=888 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=887 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=886 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=885 not found
2019-10-16 17:37:00: WARNING[Server]: StaticObjectList::remove(): id=889 not found
The fourth bad news: involves SAND, HA,HA,HA
(May be due to x5 speed, not tested at normal)
Another kind of corruption, seems not related to mapblock load.
Digtron gets stuck reaching a cave ceiling with sand.
Usually the second node (fuelstore) dissapears and there is a sand node in its place, above digger node.
First case was weird.The fuelstore was itemized inside a sand node, above a trembling sand node entity in the place of the digger.
Tried to make it fall, no.
Tried to dig, dig, dig it, noo.
Entity? This has hp and can be killed. No ?
I shot it 15 bullets with a rangedweapons M200 Intervention .... Nooo.
Immortal.
Coding tasks become weird sometimes.
Then I look at the thing from below, and see a digger head at the sand node-entity bottom.
Dug the digger, and the thing fell and turned to good kind sand node.
It was a
"__builtin:falling_node" stuck in the digger.
(Good, one more think learned, how nodes fall )
Related:
minetest-5.0.1-win32\builtin\game\falling.lua
Seems that sand nodes at ceiling turned to entities, digtron sees "air", enters the node before the entity falls, and
the entity gets stuck if nothing below (digger case), or "falls" on the digger (without having moved), turns to node and destroys
or itemizes the fuelstore.
Hard to debug, must find ceilings with sand.
Surely they arent there if you need them, ha, ha.
Or may be build it with Worldedit and stack it.Or a Lua mapgen in singlenode.
Hmm, too many bad news, but still good news...