[Mod] Digtron tunnel boring/building machine [digtron]

ThatGraemeGuy
Member
 
Posts: 138
Joined: Thu Jul 31, 2014 11:02
Location: Cape Town, South Africa
GitHub: thatgraemeguy
IRC: ThatGraemeGuy
In-game: thatgraemeguy

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by ThatGraemeGuy » Sun Aug 18, 2019 19:46

CalebJ wrote:I've found a bug that crashed our server (Tunnelers' Abyss) 5 times. The ERROR was this, and maybe this is already reported, but here goes:
Code: Select all
 ERROR[Main]: stack traceback:
.../mods/digtron/util.lua:315: in function "update_builder_item"
.../mods/digtron/nodes/node_builders.lua:131: in function "?"
.../game/register.lua:419: in function <.../game/register.lua:399>

I know exactly how this bug happens, but I don't want to say it publically. I will PM you instead.

I think this may be caused by me..... so sorry! And I think I just did it a few more times.
 

FaceDeer
Member
 
Posts: 352
Joined: Sat Aug 29, 2015 19:01
GitHub: FaceDeer

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by FaceDeer » Sun Aug 18, 2019 20:39

ThatGraemeGuy wrote:
CalebJ wrote:I've found a bug that crashed our server (Tunnelers' Abyss) 5 times. The ERROR was this, and maybe this is already reported, but here goes:
Code: Select all
 ERROR[Main]: stack traceback:
.../mods/digtron/util.lua:315: in function "update_builder_item"
.../mods/digtron/nodes/node_builders.lua:131: in function "?"
.../game/register.lua:419: in function <.../game/register.lua:399>

I know exactly how this bug happens, but I don't want to say it publically. I will PM you instead.

I think this may be caused by me..... so sorry! And I think I just did it a few more times.


Well, I still haven't figured out what the root cause of this is, the circumstances are peculiar. But I've thrown a couple of "is this thing that couldn't possibly be in a bad state actually in a bad state anyway?" checks into the code right before that callstack says a crash happened, and hopefully that'll tide digtron 1.0 over until DIGTRON 2.0 catches up and eats it. :)

Speaking of which, I feel I've made some good progress on re-laying the foundations of Digtron in a better place. The basic plan for how 2.0 will work is that you'll build your Digtron from nodes like you currently do, tinkering with facing directions and builder settings and whatnot as normal, and then you'll open the control node's formspec and click on a "Construct Digtron" button. That will cause the layout of that Digtron to be committed to a persistent storage under a unique identifier, along with a unified detached inventory just for that particular Digtron. All of the Digtron's individual nodes will have their inventories pooled together into that one big inventory. You won't be able to add or remove nodes to the Digtron in this state, but the control panel will now have a "Deconstruct Digtron" button that will reverse the process (distributing the Digtron's inventory back out to the individual storage nodes) and make the Digtron editable again.

There are a lot of upsides to doing it this way. Most of them are under-the-hood improvements; Digtron will no longer be writing massive amounts of node metadata and inventory information to the map every time it moves, which should hopefully put to rest the persistent bugs that come from Minetest occasionally failing to keep up with that and will also hopefully greatly reduce the network bandwidth used in the process. But by making this externally-stored "image" of the Digtron into its authoritative representation I'm going to be able to simplify some of the other user-facing stuff as well. In theory you'll be able to just pick up the controller node and take the whole Digtron into your inventory that way, no need for mucking about with crates. I may be able to remove the size cap on Digtrons as a result. You'll be able to interact with the Digtron's inventory and control formspec while the Digtron is in motion - maybe even add a "remote control" item after the main 2.0 release is finished. Digtrons will be able to collide without sticking to each other, and I may be able to add some sort of protection system to let a Digtron be "owned" by someone and prevent others from running up and stealing bits of it while it chugs around eating the landscape.

The main downside is just that there's that extra step of having to "deconstruct" the Digtron before you can fiddle with its nodes. Hopefully not a huge hassle compared to everything that this will allow me to improve.

As for an ETA, I have no idea. Couple of weeks at least. I published the DIGTRON 2.0: DIGPOCALYPSE work-in-progress branch if you want to watch me work, but as of right now what I've got in there is only the very basic-most skeleton of a Digtron and I'll be checking in half-finished mostly-broken stuff there as I go.
 

BuckarooBanzay
Member
 
Posts: 305
Joined: Tue Apr 24, 2018 05:58
Location: Switzerland
GitHub: thomasrudin-mt
In-game: BuckarooBanzai

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by BuckarooBanzay » Tue Aug 20, 2019 18:42

FaceDeer wrote:
Yvanhoe wrote:The one thing I wanted to explore was what would happen if I were to add a block in digtron that would attach the 6 blocks touching it to the machine? I wondered if pipes, furnaces and autocrafters would work correctly.


It's hard to say, because mods are fully Turing-complete programs and can do basically anything they want to. So there's no telling what exactly will happen if I try to seize hold of a node and "relocate" it somewhere. Minetest wasn't written with the concept of "moving" a node, what Digtron does is destroy and recreate nodes adjacent to where they were previously. So to "move" an arbitrary node I'd need to be able to recreate it.

...


The concept of "moving nodes" actually works really well in my jumpdrive mod:
viewtopic.php?f=11&t=20073

(granted there is compatibility code for lots of mods)

According to my stats there were around 47'000 jumps on my server the last 6 months:
Code: Select all
root@magellan:/data/test.pandorabox.io/data/minetest# zgrep "jump took" debug.*.gz | wc -l
46819


Only a handful got reported for mysteriously missing chunks and the likes, most of them due to mapgen interfering...

The heart of the "moving nodes" stuff is here if you are interested:
https://github.com/thomasrudin-mt/jumpd ... r/move.lua

The performance is also quite good with the voxelmanipulator:
Code: Select all
2019-01-01 19:48:05: ACTION[Server]: [jumpdrive] jump took 37200 us
2019-01-01 19:48:45: ACTION[Server]: [jumpdrive] jump took 116961 us
2019-01-01 19:48:56: ACTION[Server]: [jumpdrive] jump took 71624 us
2019-01-01 19:49:04: ACTION[Server]: [jumpdrive] jump took 55567 us
2019-01-01 20:02:52: ACTION[Server]: [jumpdrive] jump took 33282 us


Most of the jumps take about 100 ms, the bigger ships/buildings with 31^3 nodes take at max half a second...
 

FaceDeer
Member
 
Posts: 352
Joined: Sat Aug 29, 2015 19:01
GitHub: FaceDeer

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by FaceDeer » Tue Aug 20, 2019 23:41

Well, at its core I'd say you're not moving nodes either - you're reading the source nodes' state, writing that state to the destination nodes, and then deleting the source nodes. It's the old "does a teleporter just kill you and spawn a clone at the destination?" philosophical issue. :)

Digtron does something similar, though with a lot of additional complexity because it's not a perfectly rectangular volume and it's doing a bunch of modification to surrounding nodes as it goes. And of course Digtron 1.0 is written in a terribly inefficient manner.

Digtron 2.0 doesn't use a voxel manipulator yet, and I can't say for sure whether it'll be the most efficient tool for the job - Digtron needs to do a lot of tests on each node that it passes through so the actual reading and writing of node type and param2 is likely to be a small part of the work that's needed. I'll probably use it more so that I can control the order of operations for bulk calls to "on_constructed", "on_dig", and so forth, since voxelmanips don't trigger those. I also expect my data structures will wind up looking a lot like schematics, which can be applied to voxelmanips efficiently.

The code for Jumpdrive looks very clean and generalized, even though I don't think I'll be able to make use of it directly for Digtron I expect I'll want to benchmark Digtron 2.0 next to it and see if I can get similar performance.
 

User avatar
KatzEyez
Member
 
Posts: 36
Joined: Tue Aug 08, 2017 18:24
Location: (IG: Depends) (RL: USA)
GitHub: LadyK
IRC: LadyK
In-game: LadyK

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by KatzEyez » Fri Oct 11, 2019 16:00

I'm not sure if this has been addressed or not.

Locked crate should remain "attached" unless removed by owner. If someone accidentally leaves their digtron out, let's say the server crashed... someone else comes along and finds the digtron, two things can now happen - first the entire digtron can be stolen.. second, the entire contents are free-for-all. I think the digtron should register an owner when placed, to prevent this, as well as the storage should be able to be locked and/or shared.

Sorry. This is the only reason I never use the digtrons on public servers. A lot of servers crash for whatever reason (not always caused by using digtrons).
Hiya everyone! ^_^ Got Discord? I'm LadyK#3914 if you want to add me. You can find me on Tunnelers' Abyss! See you in game!
 

Odracir
Member
 
Posts: 17
Joined: Thu Sep 19, 2019 00:55

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by Odracir » Wed Oct 16, 2019 18:36

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)
node_controllers.zip
(3.95 KiB) Downloaded 5 times


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...
 

BuckarooBanzay
Member
 
Posts: 305
Joined: Tue Apr 24, 2018 05:58
Location: Switzerland
GitHub: thomasrudin-mt
In-game: BuckarooBanzai

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by BuckarooBanzay » Fri Oct 18, 2019 19:26

Odracir wrote:Digtron corruption solved ? (may be)
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.


But whats with all the spontaneous fusion at relativistic speeds? :) /s

No, really: is that a reliable way to provoke that error? I tried that very hard but could not reproduce it reliably :(
 

Odracir
Member
 
Posts: 17
Joined: Thu Sep 19, 2019 00:55

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by Odracir » Sat Oct 19, 2019 18:39

Reliable ?
It may depend on environment.

First time I experienced this was last spring, with Minetest 0.4.16 Android , Xiaomi Redmi 4A.
Hardly could dig 100 nodes downwards without failure.
No failure digging a parallel shaft near the last one (already generated ground), and no failure building railways over the surface.(possibly already generated by "being visible")

Moved this world to PC, and same problem.May be less frequent.
But overclocking x5 with "cycle_time" 0.2 in config.lua , failed at almost each unloaded area.

May be favoured by old PC.

(I believe) this only happens with ungenerated mapblocks.(or is much more likely)

May depend on loaded mods ( extra ores, on_generate, register global step ...)
Its a world made to test mods before deploying them in my real worlds.
A crazy mix, but not too many compared to some servers.

-------my testworld world.mt -------------------------
Code: Select all
gameid = minetest
creative_mode = true
enable_damage = false
backend = sqlite3
player_backend = files
auth_backend = files
server_announce = false

load_mod_digtron = true
load_mod_digtron_issue = true
load_mod_unified_inventory = true
load_mod_moreores = true
load_mod_rangedweapons = true
load_mod_wielded_light = true
load_mod_bows = true
load_mod_fireextinguisher = true
load_mod_army = true
load_mod_more_chests = true
load_mod_technic_chests = true
load_mod_my_door_wood = true
load_mod_my_future_doors = true
load_mod_concrete = true
load_mod_aviation = true
load_mod_aviation_hawk = true
load_mod_vehicles = true
load_mod_driftcar = true
load_mod_handholds = true
load_mod_stairpick = true
load_mod_mymasonhammer = true
load_mod_pontoons = true
load_mod_basic_materials = true
load_mod_hopper = true
load_mod_replacer = true
load_mod_wrench = true
load_mod_another_charcoal = true
load_mod_paths = true
load_mod_factory_bridges = true
load_mod_intllib = true
load_mod_ilights = true
load_mod_unifieddyes = true


--------------------------------------------------------------------------------------------------------------------------------
New tests

The idea is to isolate the problem.
No digtron.
No metadata.

Only mimic what digtron does.
- Advance if node not "ignore"
- If node "ignore", call emerge_area and wait until node becomes not "ignore", then advance

digtron_issue.zip
(1.08 KiB) Downloaded 4 times


- chat command
/test (X,Y,Z) (dirX,dirY,dirZ) steps
/test (6000,0,6000) (0,-1,0) 1000 --to move downards

calls advance

- advance function
- If node not "ignore", calls itself and keeps advancing
- If node "ignore", start emerge_area and call watch_load

- watch_load function
Watch the "ignore" node, reporting changes.
And as soon as it becomes other type (loaded, supposedly safe to use it), put there a goldblock and keep there some seconds watching it.
And then call advance.

Hmmm, dont know if this is a clear explanation, reading the code is better.

Issue the /test command on an ungenerated area, and be patient, takes somes minutes.
And leaves there a few gold blocks, beware gold fever.

Usually
"ignore" -> whatever -> goldblock

Looking for
"ignore" -> whatever -> goldblock -> whatever

The idea is finding in debug.txt things like this default:goldblock -> other

First run I got this (cleaned boring parts)
One goldblock vanished, another vanished and came back.

------------------- /test (7000,0,7000) (0,-1,0) 1000 -----------------------------
2019-10-19 08:00:56: [Server]: advance (7000,0,7000) 3532724282 ignore
2019-10-19 08:01:05: [Server]: watch_load (7000,0,7000) 3542445336 ignore -> default:desert_stone
2019-10-19 08:01:16: [Server]: advance (7000,0,7000) 3552773198 default:goldblock
2019-10-19 08:01:16: [Server]: advance (7000,-1,7000) 3552804429 default:desert_stone
.....................................................................................
2019-10-19 08:01:20: [Server]: advance (7000,-112,7000) 3556648061 default:desert_stone
2019-10-19 08:01:20: [Server]: advance (7000,-113,7000) 3556679329 default:stone
2019-10-19 08:01:20: [Server]: advance (7000,-114,7000) 3556710975 ignore
2019-10-19 08:01:26: [Server]: watch_load (7000,-114,7000) 3562757684 ignore -> default:stone
2019-10-19 08:01:27: [Server]: watch_load (7000,-114,7000) 3563992087 default:goldblock -> ignore <- GOLD GONE !
2019-10-19 08:01:40: [Server]: advance (7000,-114,7000) 3576991698 ignore
2019-10-19 08:01:41: [Server]: watch_load (7000,-114,7000) 3577608452 ignore -> default:goldblock <- GOLD BACK
2019-10-19 08:02:00: [Server]: advance (7000,-114,7000) 3597037609 default:goldblock
2019-10-19 08:02:00: [Server]: advance (7000,-115,7000) 3597069057 default:stone
................................................................................
2019-10-19 08:02:00: [Server]: advance (7000,-128,7000) 3597475111 default:stone
2019-10-19 08:02:00: [Server]: advance (7000,-129,7000) 3597506744 ignore
2019-10-19 08:02:04: [Server]: watch_load (7000,-129,7000) 3601118119 ignore -> default:stone
2019-10-19 08:02:21: [Server]: advance (7000,-129,7000) 3617552691 default:goldblock
2019-10-19 08:02:21: [Server]: advance (7000,-130,7000) 3617583942 default:stone
.................................................................................
2019-10-19 08:02:25: [Server]: advance (7000,-257,7000) 3622036925 default:stone
2019-10-19 08:02:25: [Server]: advance (7000,-258,7000) 3622068207 ignore
2019-10-19 08:02:32: [Server]: watch_load (7000,-258,7000) 3629342860 ignore -> default:stone
2019-10-19 08:02:45: [Server]: advance (7000,-258,7000) 3642126344 default:goldblock
2019-10-19 08:02:45: [Server]: advance (7000,-259,7000) 3642255197 default:stone
...............................................................................
2019-10-19 08:02:48: [Server]: advance (7000,-353,7000) 3645396150 default:stone
2019-10-19 08:02:48: [Server]: advance (7000,-354,7000) 3645426950 ignore
2019-10-19 08:02:56: [Server]: watch_load (7000,-354,7000) 3653210231 ignore -> default:stone
2019-10-19 08:03:08: [Server]: advance (7000,-354,7000) 3665489884 default:goldblock
2019-10-19 08:03:09: [Server]: advance (7000,-355,7000) 3665525651 default:stone
................................................................................
2019-10-19 08:03:13: [Server]: advance (7000,-451,7000) 3670067142 default:lava_source
2019-10-19 08:03:13: [Server]: advance (7000,-452,7000) 3670109981 ignore
2019-10-19 08:03:20: [Server]: watch_load (7000,-452,7000) 3677270161 ignore -> default:stone
2019-10-19 08:03:33: [Server]: advance (7000,-452,7000) 3690175752 default:goldblock
2019-10-19 08:03:33: [Server]: advance (7000,-453,7000) 3690208030 default:stone
................................................................................
2019-10-19 08:03:36: [Server]: advance (7000,-546,7000) 3693191361 ignore
2019-10-19 08:03:45: [Server]: watch_load (7000,-546,7000) 3702411037 ignore -> air
2019-10-19 08:03:56: [Server]: advance (7000,-546,7000) 3713317159 default:goldblock
2019-10-19 08:03:56: [Server]: advance (7000,-547,7000) 3713349056 default:stone
................................................................................
2019-10-19 08:04:01: [Server]: advance (7000,-641,7000) 3717612726 default:stone
2019-10-19 08:04:01: [Server]: advance (7000,-642,7000) 3717643771 ignore
2019-10-19 08:04:09: [Server]: watch_load (7000,-642,7000) 3726238001 ignore -> default:stone
2019-10-19 08:04:21: [Server]: advance (7000,-642,7000) 3738003024 default:goldblock
2019-10-19 08:04:21: [Server]: advance (7000,-643,7000) 3738035604 default:stone
................................................................................
2019-10-19 08:04:24: [Server]: advance (7000,-737,7000) 3741346240 default:stone
2019-10-19 08:04:24: [Server]: advance (7000,-738,7000) 3741377492 ignore
2019-10-19 08:04:34: [Server]: watch_load (7000,-738,7000) 3751080987 ignore -> default:stone
2019-10-19 08:04:44: [Server]: advance (7000,-738,7000) 3761408217 default:goldblock
2019-10-19 08:04:44: [Server]: advance (7000,-739,7000) 3761439535 default:stone_with_tin
.................................................................................
2019-10-19 08:04:49: [Server]: advance (7000,-833,7000) 3765581467 default:stone
2019-10-19 08:04:49: [Server]: advance (7000,-834,7000) 3765653493 ignore
2019-10-19 08:04:58: [Server]: watch_load (7000,-834,7000) 3774956489 ignore -> default:stone
2019-10-19 08:05:09: [Server]: advance (7000,-834,7000) 3785673260 default:goldblock
2019-10-19 08:05:09: [Server]: advance (7000,-835,7000) 3785704861 default:stone
................................................................................
2019-10-19 08:05:19: [Server]: advance (7000,-928,7000) 3795517154 default:stone
2019-10-19 08:05:19: [Server]: advance (7000,-929,7000) 3795542376 ignore
2019-10-19 08:05:24: [Server]: watch_load (7000,-929,7000) 3801257161 ignore -> default:stone
2019-10-19 08:05:25: [Server]: watch_load (7000,-929,7000) 3801705529 default:goldblock -> default:stone <- GOLD GONE !
2019-10-19 08:05:39: [Server]: advance (7000,-929,7000) 3816202246 default:stone
2019-10-19 08:05:39: [Server]: advance (7000,-930,7000) 3816321822 default:stone
................................................................................
2019-10-19 08:05:49: [Server]: advance (7000,-992,7000) 3826409562 default:stone
2019-10-19 08:05:50: [Server]: advance (7000,-993,7000) 3826938821 ignore
2019-10-19 08:06:07: [Server]: watch_load (7000,-993,7000) 3843873911 ignore -> default:stone
2019-10-19 08:06:12: [Server]: advance (7000,-993,7000) 3849139245 default:goldblock
2019-10-19 08:06:12: [Server]: advance (7000,-994,7000) 3849306237 default:stone
2019-10-19 08:06:12: [Server]: advance (7000,-995,7000) 3849467873 default:stone
................................................................................
2019-10-19 08:06:13: [Server]: ====================== END OF TEST ===================


Another 1000 steps run, only one vanished

................................
2019-10-19 18:47:21: [Server]: advance (6000,-971,6000) 463.265 default:stone
2019-10-19 18:47:22: [Server]: advance (6000,-972,6000) 463.328 default:stone
2019-10-19 18:47:23: [Server]: advance (6000,-973,6000) 464.718 ignore
2019-10-19 18:47:38: [Server]: watch_load (6000,-973,6000) 480.109 ignore -> default:stone
2019-10-19 18:47:39: [Server]: watch_load (6000,-973,6000) 480.437 default:goldblock -> default:stone
2019-10-19 18:47:49: [Server]: advance (6000,-973,6000) 490.312 default:stone
2019-10-19 18:47:49: [Server]: advance (6000,-974,6000) 490.343 default:stone
...............................


I believe it could also depend on direction x / y / z ,+/- , due to the emerge_area emerging mapblocks order

eg
Code: Select all
for z = -193, -183
  for y = -349, -339
    for x =  182,  192


And may be water flowing calculations, or lava, but water spreads more.
 

Odracir
Member
 
Posts: 17
Joined: Thu Sep 19, 2019 00:55

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by Odracir » Sun Oct 20, 2019 17:07

Found out that "overclocking x5" by changing "cycle_time", from 1.0 to 0.2 in config.lua
real effect is to change metadata "period" from 1 to 0, integer, through this:

meta:set_int("period", digtron.config.cycle_time)

So, this is not "overclocking x5" , this is "maximum possible speed"
----------------------------------------------------------------------------------------------------------------
Good news: no problem with sand on ceilings at normal speed.

Found a good spot, and tested several times with both speeds ("period" 1 and 0), restoring the sand in ceiling through
/deleteblocks here 1

- Normal speed - OK , sand falls and digtron is unaffected.

- High speed - In most cases digtron triggers sand fall, sand nodes turn to falling objects, wich digtron does'nt dig, digtron nodes enter "air" containing falling nodes objects before they have time to fall, one of them falls on digger head, turning back to sand node and breaking fuelstore, itemized inside sand.

In the weird case I told before, falling entity got stuck in digtron digger head.
Image

No problem unless trying to code a high speed sci-fi turbodriller.
----------------------------------------------------------------------------------------------------------------------------------
More info about my test environment

#minetest.registered_on_generateds --> 3
These are from MTG butterflies, fireflies, and dungeon_loot, and dont use voxelmanips.

#minetest.registered_globalsteps --> 42
36 are from rangedweapons
----------------------------------------------------------------------------------------------------------------------------------
And found some strange things to research in the digtron_issue.zip logs...
 

Odracir
Member
 
Posts: 17
Joined: Thu Sep 19, 2019 00:55

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by Odracir » Sat Oct 26, 2019 22:18

Learned that chunksize 3 in my test world is Minetest 0.4.16 Android default, according to https://github.com/minetest/minetest/issues/7550.
This world was created in my phone and moved to PC.

In order to raise the chances to reproduce the issue, I believe voxel-manipulating mods could help, for example caverealms (adds extra caves, and decorations), dfcaverns? , technic (extra ores, and voxelmanip to produce sulphur)

And placing digtron in the crossing of 4 mapchunk boundaries.
A trick to find this: view a minetestmapper image.
 

User avatar
h-v-smacker
Member
 
Posts: 96
Joined: Wed Nov 29, 2017 23:04
GitHub: h-v-smacker
In-game: Smacker

Re: [Mod] Digtron tunnel boring/building machine [digtron]

by h-v-smacker » Thu Nov 07, 2019 07:37

I made a new control node, master builder: https://github.com/minetest-mods/digtron/pull/60

Image

It allows to read&save on all builders (used for template building, on the right) or set all builders to the same setting as itself (useful for farming combines and such, on the left).
Attachments
screenshot_20191107_103549.jpg
(386.81 KiB) Not downloaded yet
Linux Forks, the Best Forks: linux-forks.de // Play @ LinuxWorks Next Generation
 

Previous

Return to Mod Releases



Who is online

Users browsing this forum: Majestic-12 [Bot] and 7 guests