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

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

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

by ThatGraemeGuy » Post

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: 506
Joined: Sat Aug 29, 2015 19:01
GitHub: FaceDeer

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

by FaceDeer » Post

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.

User avatar
BuckarooBanzay
Member
Posts: 435
Joined: Tue Apr 24, 2018 05:58
GitHub: BuckarooBanzay
IRC: BuckarooBanzai
In-game: BuckarooBanzai

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

by BuckarooBanzay » Post

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...
¯\_(ツ)_/¯ Not active here anymore, contact me on the minetest discord, irc, lemmy or github (for programming issues)

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

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

by FaceDeer » Post

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: 50
Joined: Tue Aug 08, 2017 18:24
GitHub: KatzPetz
IRC: LadyK
In-game: LadyK
Location: (IG: Depends) (RL: USA)

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

by KatzEyez » Post

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).
Why wish upon a star when you can pray to the one who created it.

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

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

by Odracir » Post

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

User avatar
BuckarooBanzay
Member
Posts: 435
Joined: Tue Apr 24, 2018 05:58
GitHub: BuckarooBanzay
IRC: BuckarooBanzai
In-game: BuckarooBanzai

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

by BuckarooBanzay » Post

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 :(
¯\_(ツ)_/¯ Not active here anymore, contact me on the minetest discord, irc, lemmy or github (for programming issues)

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

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

by Odracir » Post

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 97 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: 21
Joined: Thu Sep 19, 2019 00:55

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

by Odracir » Post

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: 21
Joined: Thu Sep 19, 2019 00:55

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

by Odracir » Post

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: 115
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 » Post

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
screenshot_20191107_103549.jpg (386.81 KiB) Viewed 5730 times
Linux Forks, the Best Forks: linux-forks.de // Play @ LinuxWorks Next Generation

User avatar
GreenXenith
Member
Posts: 1356
Joined: Wed Oct 28, 2015 01:26
GitHub: GreenXenith
Location: UTC-8:00
Contact:

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

by GreenXenith » Post

Is the Digtron 2.0 rewrite still active or is it dead in the water?
YouTube | Mods | Patreon | Minetest Discord @greenxenith

You should not be able to read this message.

User avatar
FreeGamers
Member
Posts: 650
Joined: Sat May 25, 2019 00:15
GitHub: is proprietary I use NotABug
Location: United States
Contact:

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

by FreeGamers » Post

AFAIK its WIP
FreeGamers.org has moved to MeseCraft.net | FreeGamers on this forum is now MeseCraft

User avatar
Hume2
Member
Posts: 709
Joined: Tue Jun 19, 2018 08:24
GitHub: Hume2
In-game: Hume2
Location: Czech Republic

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

by Hume2 » Post

Nice mod!
I have a feature request for you: digtron seats
It's annoying that the digtron sometimes leaves the player on the ground. A player could sit into the seat and then he would be moved together with the digtron as long as he would be sitting in it.
If you lack the reality, go on a trip or find a job.

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

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

by FaceDeer » Post

Sorry about the hiatus on Digtron 2.0. A real-life situation came up that knocked me off of modding for a bit, and then when I came back to it I wasn't feeling mentally ready to face the beast that is Digtron 2.0 again.

I've resumed work on Digron 2.0 now, however, and I think I'm getting back into the groove of it. The hiatus actually let me look at some of my design decisions again with a fresh perspective, so hopefully it'll be good for the codebase in the long run.

hisforeverkid
Member
Posts: 11
Joined: Fri Aug 29, 2014 22:16
In-game: Hisforever

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

by hisforeverkid » Post

I hp[e this is the place to report a bug? here is part of the debug page

2020-06-29 14:06:50: ACTION[Server]: [gravelsieve] glooptest:alatro_lump : 1 / inf
2020-06-29 14:06:50: ACTION[Server]: [gravelsieve] Overall probability 0.579722
2020-06-29 14:07:06: WARNING[Main]: NodeDefManager::deSerialize(): already defined with different ID: infrastructure:road_sign_crosswalk
2020-06-29 14:07:06: WARNING[Main]: NodeDefManager::deSerialize(): already defined with different ID: infrastructure:road_sign_crosswalk_on_post
2020-06-29 14:07:06: WARNING[Main]: NodeDefManager::deSerialize(): already defined with different ID: infrastructure:road_sign_stop
2020-06-29 14:07:06: WARNING[Main]: NodeDefManager::deSerialize(): already defined with different ID: infrastructure:road_sign_stop_on_post
2020-06-29 14:07:06: WARNING[Main]: NodeDefManager::deSerialize(): already defined with different ID: infrastructure:road_sign_yield
2020-06-29 14:07:06: WARNING[Main]: NodeDefManager::deSerialize(): already defined with different ID: infrastructure:road_sign_yield_on_post
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:06: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:08: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:08: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:08: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:08: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:10: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:10: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:10: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:10: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:12: WARNING[Main]: Irrlicht: PNG warning: iCCP: known incorrect sRGB profile
2020-06-29 14:07:29: WARNING[Main]: TextureSource::getPalette(): the specified palette image "unifieddyes_palette_extended.png" is larger than 256 pixels, using the first 256.
2020-06-29 14:07:36: WARNING[Main]: Irrlicht: Could not open file of texture: rail.png
2020-06-29 14:07:36: WARNING[Main]: Irrlicht: Could not open file of texture: rail.png
2020-06-29 14:07:36: WARNING[Main]: Irrlicht: Could not open file of texture: rail.png
2020-06-29 14:07:36: WARNING[Main]: Irrlicht: Could not open file of texture: rail.png
2020-06-29 14:07:46: ACTION[Server]: singleplayer [127.0.0.1] joins game. List of players: singleplayer
2020-06-29 14:07:48: ERROR[Server]: LuaEntity name "cube_mobs:box" not defined
2020-06-29 14:07:48: ERROR[Server]: LuaEntity name "cube_mobs:box_shoot" not defined
2020-06-29 14:07:48: ERROR[Server]: LuaEntity name "cube_mobs:box_small" not defined
2020-06-29 14:07:48: ERROR[Server]: LuaEntity name "cube_mobs:box_fire" not defined
2020-06-29 14:07:48: ERROR[Server]: LuaEntity name "cube_mobs:box_spike" not defined
2020-06-29 14:07:48: ERROR[Server]: LuaEntity name "cube_mobs:box_small" not defined
2020-06-29 14:07:52: WARNING[Server]: Assignment to undeclared global "ground" inside a function at /home/hisforever/.minetest/mods/water_life/spawn.lua:129.
2020-06-29 14:07:52: WARNING[Server]: Assignment to undeclared global "coraltable" inside a function at /home/hisforever/.minetest/mods/water_life/spawn.lua:140.
2020-06-29 14:07:58: ERROR[Server]: LuaEntity name "cube_mobs:box_fire" not defined
2020-06-29 14:08:00: ERROR[Server]: LuaEntity name "cube_mobs:box_small" not defined
2020-06-29 14:08:00: ERROR[Server]: LuaEntity name "cube_mobs:box" not defined
2020-06-29 14:09:55: ACTION[Server]: singleplayer digs default:brick at (-29,8,231)
2020-06-29 14:09:58: ACTION[Server]: singleplayer places node default:brick at (-29,8,232)
2020-06-29 14:10:00: ACTION[Server]: singleplayer places node default:brick at (-29,8,231)
2020-06-29 14:10:01: ACTION[Server]: singleplayer places node default:brick at (-30,8,232)
2020-06-29 14:10:07: WARNING[Main]: Irrlicht: Could not open file of texture: mobs_cow_map.png
2020-06-29 14:10:34: ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod '' in callback node_on_receive_fields(): /home/hisforever/.minetest/mods/digtron/util.lua:175: bad argument #1 to 'pairs' (table expected, got nil)
2020-06-29 14:10:34: ERROR[Main]: stack traceback:
2020-06-29 14:10:34: ERROR[Main]: [C]: in function 'pairs'
2020-06-29 14:10:34: ERROR[Main]: /home/hisforever/.minetest/mods/digtron/util.lua:175: in function 'burn'
2020-06-29 14:10:34: ERROR[Main]: ...hisforever/.minetest/mods/digtron/util_execute_cycle.lua:234: in function 'execute_dig_cycle'
2020-06-29 14:10:34: ERROR[Main]: ...orever/.minetest/mods/digtron/nodes/node_controllers.lua:143: in function 'auto_cycle'
2020-06-29 14:10:34: ERROR[Main]: ...orever/.minetest/mods/digtron/nodes/node_controllers.lua:254: in function <...orever/.minetest/mods/digtron/nodes/node_controllers.lua:228>
2020-06-29 14:10:34: ACTION[Server]: singleplayer leaves game. List of players:
2020-06-29 14:10:34: ACTION[Main]: Server: Shutting down
2020-06-29 14:10:34: ACTION[Main]: [Tubelib] Store data...
2020-06-29 14:10:34: ACTION[Main]: [Tubelib] Data stored. t=564us
2020-06-29 14:11:45: ERROR[Main]: Please choose a name!

Merak
Member
Posts: 116
Joined: Sat Nov 05, 2016 20:34

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

by Merak » Post

Is something going to be done about Digtron crashing in recent Minetest builds? -- either by fixing it or releasing Digtron 2? It would be good to make Digtron2 easier to find for people who want to check up on progress.

Ignaramico
Member
Posts: 78
Joined: Fri Sep 04, 2020 21:23
GitHub: ignaramico

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

by Ignaramico » Post

im getting this error when trying to get my digtron in a crate
Spoiler

Code: Select all

AsyncErr: ServerThread::run Lua: Runtime error from mod 'digtron' in callback item_OnPlace(): ...inetest/1619/.minetest/mods/digtron/nodes/node_crate.lua:62: attempt to index field 'players' (a nil value)
stack traceback:
	...inetest/1619/.minetest/mods/digtron/nodes/node_crate.lua:62: in function 'store_digtron'
	...inetest/1619/.minetest/mods/digtron/nodes/node_crate.lua:102: in function 'on_rightclick'
	...inetest/1619/bin/../share/minetest/builtin/game/item.lua:426: in function <...inetest/1619/bin/../share/minetest/builtin/game/item.lua:419>
Edit: i just read the award stuff in the main topic

qawsedrftgzh
Member
Posts: 32
Joined: Sat Jul 25, 2020 08:36
GitHub: qawsedrftgzh
Location: Germany

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

by qawsedrftgzh » Post

Im am just wondering what "Digtron has 13 blocks but only enough traction to move 6 blocks." is meaning I am german and deepl neither google could translate Friction in this setence. D = Digger, 0 = Air, I = Inventory module, P = Placer, C = Controllor, F = Fuel module
first layer | second layer | third layer
DDD 000 000
DDD 0I0 0C0
DDD 0P0 00
Attachments
2021-03-04_18-56.png
2021-03-04_18-56.png (124.77 KiB) Viewed 5730 times
My English is not so good, because I am german

User avatar
Nathan.S
Member
Posts: 1147
Joined: Wed Sep 24, 2014 17:47
GitHub: NathanSalapat
IRC: NathanS21
In-game: NathanS21
Location: Bigsby Texas
Contact:

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

by Nathan.S » Post

qawsedrftgzh wrote:
Thu Mar 04, 2021 17:56
Im am just wondering what "Digtron has 13 blocks but only enough traction to move 6 blocks." is meaning I am german and deepl neither google could translate Friction in this setence. D = Digger, 0 = Air, I = Inventory module, P = Placer, C = Controllor, F = Fuel module
first layer | second layer | third layer
DDD 000 000
DDD 0I0 0C0
DDD 0P0 00
The Digtron can't dig if there is nothing below it. You either need to manually place some nodes below it or put a placer node in to put a node for it to travel on.
I record Minetest videos, Mod reviews, Modding tutorials, and Lets plays.
Check out my website, and brand new Minetest Modding Course

Maverick2797
Member
Posts: 128
Joined: Sun Aug 05, 2018 12:37
In-game: Maverick2797
Location: Poking about here and there...

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

by Maverick2797 » Post

Node idea: Randomized Builder

Same as a regular builder except that it has multiple item slots, selecting a random one per cycle. If there's no more of Slot 1 left in the inventory then it gets skipped to Slot 2 as a fallback, and so on.

Would really make "textured" walls/floors etc a lot easier.
The number you have called is not available during a solar eclipse. This message will self destruct in ten seconds in protest... [BEEP]

User avatar
loppi
Member
Posts: 162
Joined: Sat May 29, 2021 11:30
In-game: loppi Lolstadt
Location: Niedersachsen,Germany

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

by loppi » Post

nice
"ich liebe industrie!" And yes, its a Russian Bulldozer 😁

dman810
New member
Posts: 2
Joined: Tue Feb 13, 2018 13:56
IRC: Dennis_Kelley
In-game: dkelley810

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

by dman810 » Post

I have idea for a possible module to add for the digtron. Is it possible to add an outcrafter type module. I use stone ladders for vertical shaft creation. And thought it would be cool to be able to create my ladder from the cobble that the machine digs up. Also a thought is a type of furnace that can smelt ore for crafting purposes. so I could smelt iron and then have a autocrafter make minecart rails. I would just need a supply of wood planks. Any thoughts on if this is possible. Thanks in advance!

MegaMegaMega
Member
Posts: 14
Joined: Sun Feb 26, 2023 04:17

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

by MegaMegaMega » Post

Hello. The OP mentions that it's possible to use the item ejector to send the minerals up through pipeworks tubes. Does anyone have a working example of this that I can see? I'm interested in seeing how you can automate the mining process so that you don't need to manually click and delete stacks of cobblestone and other junk to clean the digtron's inventory.

If someone has a setup like this working with the hopper mod I'd also be curious to see it. Thanks!

User avatar
Blockhead
Member
Posts: 1622
Joined: Wed Jul 17, 2019 10:14
GitHub: Montandalar
IRC: Blockhead256
In-game: Blockhead Blockhead256
Location: Land Down Under
Contact:

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

by Blockhead » Post

MegaMegaMega wrote:
Mon Jul 24, 2023 00:41
Hello. The OP mentions that it's possible to use the item ejector to send the minerals up through pipeworks tubes. Does anyone have a working example of this that I can see? I'm interested in seeing how you can automate the mining process so that you don't need to manually click and delete stacks of cobblestone and other junk to clean the digtron's inventory.
The ejector is.. niche in its uses and a potential lag source since I don't think it's rate-limited. The usual way to unload from a digtron with pipeworks is to use pipeworks' filter-injectors. You place the filter-injector with the arrow facing away from the inventory towards a pipe, and it goes places from there, typically a sorting system, then often a grinder-smelter for the ores, a compressor for the cobble (compressed cobble from moreblocks) and so on.
MegaMegaMega wrote:
Mon Jul 24, 2023 00:41
If someone has a setup like this working with the hopper mod I'd also be curious to see it. Thanks!
I checked the source of digtron, and unfortunately I don't think it has built-in support for connections to item transport except for pipeworks. However, there is support from the other side from some mods. But since "hopper" is actually two mods, one by FaceDeer and one by Tenplus1, let's talk about both. It's actually my first time using either of them today.

FaceDeer Hopper

This hopper doesn't pull from digtron inventory storages. I don't think it can be reasonably automated, unless there's some other mod I haven't thought of yet. You can always set up a hopper underneath and behind the ejector, and that will eject items into the top of the hopper, and the hopper will then pick them up. You can also see in the same screenshot that the mesecons wires don't attach to the ejector, so they can't be used to automate it either.
digtron_hopper.jpeg
digtron_hopper.jpeg (74.68 KiB) Viewed 3632 times
Now there is also a setting on the ejector itself, a tickbox for "Automatic" operation on the ejector's formspec. This will drop a stack for every cycle. Of course, that will often fail to clear the inventory if you're digging more than one kind of node (so pretty much all the time). You could theoretically empty the inventory by running the digtron in circles. So as to not waste fuel, you could use the Digtron HV power connector. But at that point, you may as well use pipeworks I think.

I tried using multiple digtron controllers at once to try to get the digtron to go in circles (on different cycles was the theory) but the last-used controller is always the one that fires and cancels the others. I think you could do it with a pipeworks deployer and a screwdriver, where you rotate the digtron each time it hits the corner of a large room. Ah but you still wouldn't be able to restart the digtron from the controller that way - it's an advanced formspec interaction not a simple punch, node break and so on like you can automate with pipeworks. Again, if you're going to need pipeworks, may as well just use the pipes.

Tenplus10 Hopper

This hopper supports digtron inventory storages properly and will slowly remove items from them like it would from a chest above. So, if you want to empty the digtron with hoppers instead of pipeworks, this seems to be the hopper mod you should use.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ Advtrains enthusiast | My map: Noah's Railyard | My Content on ContentDB ✝️♂

Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests