joe7575 / techpack Goto Github PK

In your plan of your big energystorage, you have there:

A hull of 5x5x5 concrete, needs 27 gravel.
A hull of 7x7x7 concrete, needs 125 gravel.
A hull of 9x9x9 concrete, needs 343 grave.
This is, what your mod is calculating, so far ok.

But when i have a hull of 5x5x5, don't need i 64 gravel?

Because i calculate hull 5x5x5, volume 4x4x4 = 64 gravel.
Same in 7x7x7 hull, 6x6x6 volume = 216 gravel.
A hull of 9x9x9, 8x8x8 volume = 512 gravel.

Maybe I have a mistake in my thinking ...

Greetings, Clyde.

It would be great if the machines, harvester and quarry,
would support ethereal nodes & ores. (with an optional dependency of course).

I have a quarry but it doesn't get the bakedclay for example.
My Harvester doesn't care about onions :)
etc.

Thanks for this awesome mod.

(note: how do i mark this as an enhancement?)

I've written a compatability mod to include nodes from moretrees, as well as some crops from farming that aren't harvested for no reason i can understand.

https://github.com/obl3pplifp/techpack_compat

I can re-submit this as a PR if that is more helpful, but i figured I'd let you decide how to integrate it into techpack.

Guess who!

As usual, the fix is already done, but it is a work in progress and any feedback is welcome as this is a new feature as it may not have been implemented in the best way

Sieves are currently not configurable, we should be able to configure what can be processed, and what it is processed into.

It would also be nice to modify the probability multiplication factor and the speed the sieves operate at without needing to make code changes - these should be changeable so people can nerf the sieve as they see fit

I'm inviting you to play on Blocky Survival. We're one of the biggest public minetest servers, and we use techpack heavily. Billy-S, who's submitted issues to you before, is the admin. If you check in semi-regularly, we'd love to show you our numerous weird tubelib issues. We have work-arounds for many of them, but I thought I'd extend an offer for you to check it out firsthand.

This is a feature request, or at least, request for the idea to be considered, as opposed to the bug report in #22 . It'd be nice if some of the other machines allowed on_pull_stack, particularly the autocrafter, grinder, and HighPerf pushing chest, but those never supported it in the past, and you might consider such a capability to be unbalanced.

Instead of storing everything in mod memory, and fetching based on IDs, why don't you just use the position of the node? Then you can store it in the nodes meta, and even if you did it right, you wouldn't have to replace the node. Your current system is rather inefficient, and is broken.

Since the introduction of defect dummies as a solution to cloned/moved tubelib machines, many players on Blocky Surival have reported that their entire factories, or a few machines in their factories, have mysteriously turned into defect dummies. I know for a fact that many of these machines were not placed w/ a node replacement tool or worldedit, or moved with a piston, and that many of these machines had valid ID numbers beforehand. I'm not entirely sure what is going on. For the moment, I have just disabled the code that turns machines into dummies, which is a stopgap until I find the the time to investigate this further.

As I don't have any detailed information at the moment, this Issue is mostly an FYI.

Unsure why I couldn't find an existing issue for this one, it's been known on BLS for quite a while - to the point where we had to disable crafting teleporters, as this is very exploitable.

As usual I'm making this issue because I just fixed it! Expect a PR for this project & tubelib2 to come through immanently.

Basically, placing a tube next to a teleporter will redirect the teleporter as if it is a tube, this is annoying as it is, but after it has been redirected both the destination and origin teleporters can be removed without breaking the connection.

This effectively means you can teleport items anywhere with no cost.

To replicate:

• Set up [ chest > pusher > teleporter ((airgap)) teleporter > chest ]
• Either the pusher or the chest should not be high-perf, so you can use fewer items to test, sending them through one at a time will let us test for longer
• Pair the teleporters together, put items in the first chest, switch the pusher on and confirm items are coming through
• Place a tube next to the destination teleporter (at a face which does not have the hole in it)
• You will now see items coming out of the tube, as if they have been redirected
• Remove the destination teleporter, connection remains
• Remove the source teleporter, connection remains

When being fed by a HighPerf machine, a black hole displays the number of times a stack/partial stack was disappeared, not the number of "items".

This is, admittedly, a low-priority issue. The only time that number matters to me is when I'm testing the efficacy of various setups in a single-player world.

$get_msg() returns both the ID of the source node AND the message string.
But $get_term() only returns message string.

It's possible to connect several Terminals to one SaferLua Controller, but you can't send the answer string back to the user's terminal, because you don't know what terminal it is.

If something like msg, termID = $get_term() will be implemented, the, old scripts will continue to work, while new scripts will be able to utilize multi-terminal approach.

What if there was a pusher that you could click on and it would have slots thatnyou could put items in, and the items in the slots were the only items it would push? I also wonder anout a stackwise pusher... and a stackwise distributer... they would push/distribute items in stacks, onstead of by single items.

Already solved, just writing this up

This is related to joe7575/tubelib2#4
And also addresses issues related to teleporters described here #67

Using the new feature that disallows tubes from connecting to teleporters, except for the front face with a hole in it, you can still create "spooky" connections by pushing items directly into the wrong side of the teleporter.

All the defect variant of the warehouses do this:

	after_dig_node = function(pos, oldnode, oldmetadata, digger)
		wh.after_dig_node(Box, pos, oldnode, oldmetadata, digger)
	end,

wh.after_dig_node does not exist, causing a crash of you dig this node, worth looking back in the code to try and figure out why this is here in the first place.

I will probably get to it soon if you don't

Hello again,
It's possible for players to use warehouses to create oversized stacks.

Steps to reproduce:

1. Place a warehouse
2. Get several stacks of a stackable item
3. Put set a filter and put multiple (3 or more) stacks into it
4. Drag the contents of the factory onto an arbitrary item in your inventory that's different than what's in the factory

You'll end up w/ a stack in your inventory that's much larger than it should be (though it seems to be one stack less than what the machine contained). The other item disappears.

Tested using current tubelib (master branch, checked out today) with minetest 0.4.17, on linux.

Hello Joe,

I'm very new to Minetest (which has come a long way from 2 years ago when I last checked on the progress). I have taken residency on a server and ran into a tubelib specific bug. I have an area that is under protection where I have rather badly placed some tubelib blocks and want to rearange them, but I cannot mine them with any tool to pick them up to be moved.

Is there a special item or is this a bug to be further looked into?

Thank you!

 -Dallas (ExeVirus)

A HighPerf distributor with one or more active unfiltered channels, but no active filtered channels, will never output anything. This is in contrast to a regular distributor, which will round-robin between available active unfiltered channels in such a situation.

My current work-around in such a situation is to set up a "dummy" filtered channel in the HighPerf distributor, making use of some item that will absolutely never enter the distributor. However, this has the downside of leaving only 3 usable channels.

I experienced this bug a couple of times. I think it should be possible to reproduce the error with this part of the debug file:

2018-06-19 22:06:37: ACTION[Server]: singleplayer places node tubelib:tube1 at (-59,13,-53)
2018-06-19 22:06:37: ACTION[Server]: facedir: 3
2018-06-19 22:06:39: ACTION[Server]: singleplayer places node tubelib:tube1 at (-58,13,-53)
2018-06-19 22:06:39: ACTION[Server]: facedir: 0
2018-06-19 22:06:42: ACTION[Server]: singleplayer places node tubelib:tube1 at (-58,11,-53)
2018-06-19 22:06:42: ACTION[Server]: facedir: 0
2018-06-19 22:06:46: ACTION[Server]: singleplayer places node tubelib:tube1 at (-58,12,-53)
2018-06-19 22:06:46: ACTION[Server]: facedir: 3
2018-06-19 22:06:46: ERROR[Server]: Map::setNode(): Not allowing to place CONTENT_IGNORE while trying to replace "tubelib:tube1" at (-58,12,-53) (block (-4,0,-4))
2018-06-19 22:06:46: ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod 'tubelib' in callback item_OnPlace(): ...e\Minetest\bin..\mods\techpack-master\tubelib/tubes.lua:161: attempt to index a nil value
2018-06-19 22:06:46: ERROR[Main]: stack traceback:
2018-06-19 22:06:46: ERROR[Main]: ...e\Minetest\bin..\mods\techpack-master\tubelib/tubes.lua:161: in function 'nodetype_to_pos'
2018-06-19 22:06:46: ERROR[Main]: ...e\Minetest\bin..\mods\techpack-master\tubelib/tubes.lua:203: in function 'delete_meta_data'
2018-06-19 22:06:46: ERROR[Main]: ...e\Minetest\bin..\mods\techpack-master\tubelib/tubes.lua:319: in function 'update_tube'
2018-06-19 22:06:46: ERROR[Main]: ...e\Minetest\bin..\mods\techpack-master\tubelib/tubes.lua:328: in function 'update_tubes'
2018-06-19 22:06:46: ERROR[Main]: ...e\Minetest\bin..\mods\techpack-master\tubelib/tubes.lua:510: in function 'after_place_node'
2018-06-19 22:06:46: ERROR[Main]: C:\Dokumente\Minetest\bin..\builtin\game\item.lua:307: in function <C:\Dokumente\Minetest\bin..\builtin\game\item.lua:208>
2018-06-19 22:06:46: ACTION[Server]: singleplayer leaves game. List of players:

alxki

string.split is just Lua's imported function, and it returns table, not Array.

I was forced to use Array(unpack(string.split(...))) trick to get the "conventional" SaferLua's Array and be able, for example, to iterate over the splitted literals.

(feature request)

The node replacement tool from https://github.com/Sokomine/replacer does not work well with techpack blocks (mostly tubelib). For instance, tubelib machines that are placed with this tool do not get any WLAN (machine?) ID. I don't know what a solution to this problem looks like; it may have to be fixed on the replacement tool's side.

It has often been suggested that tubelib needs some way of "counting" - the ability to see how many items have traveled through a certain system.
In my own designs I have also desired the ability to "request" items, I want to be able to send a piece of coal through some system and get back a stack of coal.

I believe the solution to both of these is a "pushing detector", that will push items when it detects items going through it (in another direction to the one it is pushing in) - to be clearer, it will push left-to-right each time it sees items going through it front-to-back

This can currently be achieved using 5 nodes:
Pusher > Detector - Mesecons Converter > Mesecons Converter - Fast Pusher

One might imagine this can be achieved with only 3 nodes:
Pusher > Detector - Pusher

However, this never turns the output pusher off.

The 5-node solution is also not 100% reliable, and depends on the fast pusher because of the brief time the mesecon signal is on, it is also generally inconvenient to use the mesecons converters as a pass-through.

Therefore, I believe the "pushing detector" is a helpful and appropriately powerful device to add to techpack.

stacktrace.txt

How to replicate:

  TT
CPDT

C = chest
P = pusher
D = detector
T = tube

The tubes connect the output side of the detector to one of its "inaccessible" sides.

My splint to fix this on Blocky Survival is to prevent any machine from pushing to itself, but this doesn't feel like the "correct" solution. There's some instances where it seems like a machine pushing to itself should be allowed, e.g. distributors and HP pushing chests, though i can't think of any actual use for such a configuration..

This one's a hard one, I have a fix but I'm sure it will need a lot of testing & some discussion about the best way to actually do it.

The primary issue is that the last two slots in the warehouse never seem to fill, this only occurs when you are pulling items out of the warehouse with a pusher - as well as presumably pushing them in to keep it replenished.

To replicate I recommend you set up:

Chest (High Perf) > Pusher (High Perf) > Warehouse > Pusher (High Perf) > Chest (normal)

The final chest (right most) should be full
Both pushers should be turned on until the right most one is blocked
The warehouse should be as full as possible
The first chest (left most) should be full and constantly fed with items (to fill up the warehouse)

Personally I crafted logs into planks into sticks to try and fill the warehouse as quickly as possible

The warehouse should be configured to accept this item only

Once the first 6 slots get full, the last two never manage to get above a few hundred, any further items pushed in simply disappear.
This only happens when pulling items out into a full inventory.

Any further details are part of the solution, not the problem, so will be detailed in the PR.

While writing up #77 & #78 I pulled master to get the latest but it kept crashing the game without even starting, had to base those off of my last commit because I know it works.

Will look into this now, but no guarantees

Actual error is:

ModError: Failed to load and run script from /home/cam/snap/minetest/1619/.minetest/mods/techpack/tubelib_addons2/init.lua:
...t/1619/.minetest/mods/techpack/tubelib_addons2/timer.lua:195: attempt to call field 'register_node' (a nil value)
stack traceback:
	...t/1619/.minetest/mods/techpack/tubelib_addons2/timer.lua:195: in main chunk
	[C]: in function 'dofile'
	...st/1619/.minetest/mods/techpack/tubelib_addons2/init.lua:19: in main chunk
Check debug.txt for details.

Tried commenting out that module, same error occurs in the next one loaded

If there is no liquid in front of the sampler, its state switches to 'fault' and you need to reset it manually. Some mods are able to generate liquid sources automatically and for better compatibility with them I think it's better to set state to 'idle' when no liquid was found.

For example, terumet mod has a lava melter that generates lava sources. The process of generating is pretty slow and while you wait for lava, sampler goes to 'fault', so you can't grab the generated lava automatically.

Example of what I was trying to do:

Could you please advise us if it was meant to not be displayed on the sfinv's Crafting Guide?

We ended up having to find it online and I am not sure if that was supposed to happen since new players might not know this.

Thanks very much in advance for your help!

I've been patching various mods to fix an inventory handling bug partly triggered by Unified Dyes, and ran across a couple of UD-compatible nodes in TechPack's tubelib_addons2 component.

Below is a tiny patch (only two lines added) that I think will fix the affected items. Requires Unified Dyes commit 9ff40a7f or later.

However, tubelib_addons2 depends on tubelib, but that mod depends on tubelib2. That mod is not part of TechPack as far as I can see... since I don't have it, I can't test my fixes with any degree of certainty (I composed it before I noticed the dependency issue). Since I don't use TechPack, I can't be sure of anything. 😃

Once you can apply the patch and run the mod, just test if placing and digging colorable items (both neutral and already colorized) keeps the itemstacks under proper control.

commit 5896064b2013b1b0f4af4f9a36d6f8074542f0e6 (HEAD -> master)
Author: Vanessa Dannenberg <[email protected]>
Date:   Thu Jul 18 02:34:34 2019 -0400

    use Unified Dyes on_dig where needed - requires Unified Dyes commit 9ff40a7f or later

diff --git a/tubelib_addons2/colorlamp_ud.lua b/tubelib_addons2/colorlamp_ud.lua
index 08410b6..303e1c5 100644
--- a/tubelib_addons2/colorlamp_ud.lua
+++ b/tubelib_addons2/colorlamp_ud.lua
@@ -43,6 +43,7 @@ minetest.register_node("tubelib_addons2:lamp_off", {
                tubelib.remove_node(pos)
                unifieddyes.after_dig_node(pos, oldnode, oldmetadata, digger)
        end,
+       on_dig = unifieddyes.on_dig,
 
        on_construct = unifieddyes.on_construct,
        
@@ -75,8 +76,8 @@ minetest.register_node("tubelib_addons2:lamp_on", {
                tubelib.remove_node(pos)
                unifieddyes.after_dig_node(pos, oldnode, oldmetadata, digger)
        end,
-   
-       light_source = minetest.LIGHT_MAX,      
+       on_dig = unifieddyes.on_dig,
+       light_source = minetest.LIGHT_MAX,
        is_ground_content = false,
        drop = "tubelib_addons2:lamp_off"
 })

This issue seems to affect both the regular and HighPerf distributors.
It is a bit difficult to describe, so bear with me.

How to produce the issue:

1. Set up a distributor with 2 (or 3) active filtered channels, filtering on the same item.
2. Have at least 1 active unfiltered channel.
3. Obstruct the output of one of the filtered channels (with a block or a full inventory), but ensure at least one of the other filtered channels is able to output, as well as the unfiltered channel.
4. Pass several of the filtered item through the distributor.

Confusingly, some of the items will be output through the unfiltered channel, even though a filtered channel is available. I would expect that these items would be output through the filtered channels, unless all such channels were blocked, not just one of them.

Possibly relevant postscript: Until about 6 months ago (though I don't remember what version exactly), distributors would never output a filtered item through an unfiltered channel, even when all filtered channels were blocked but unfiltered channels were available. I think I've come to prefer the current behaviour, though, as long as this issue is addressed.

Warehouses, specifically gold warehouses (techpack) can be used to duplicate items infinitely (so long as you have at least 3 items)

To replicate:

1. Place a warehouse and collect 3 of the same item.
2. Use one of the items to configure the fist slot of the warehouse (left-right)
3. Put the other 2 items in the warehouse and let them find their slot
4. Pick up the 2 items and scroll up and down quickly
5. You should now have 4 items in your inventory
6. Rinse and repeat to duplicate infinitely

• This bug depends on the speed you scroll
• The normal scrolling behaviour is to put items from the stack in your inventory one by one
• The warehouse overrides this behaviour to put a full stack on each scroll (if possible)
• This has already been fixed (submitting immanently) by getting the main_stack from the node_inv each time move_to_player_inv is called instead of passing it in

2020-05-20 12:34:24: ERROR[Main]: mod "gravelsieve" has unsatisfied dependencies: "tubelib" 2020-05-20 12:34:24: ERROR[Main]: mod "sl_controller" has unsatisfied dependencies: "tubelib" 2020-05-20 12:34:24: ERROR[Main]: mod "smartline" has unsatisfied dependencies: "sl_controller" "tubelib" 2020-05-20 12:34:24: ERROR[Main]: mod "techpack_warehouse" has unsatisfied depencies: "tubelib" 2020-05-20 12:34:24: ERROR[Main]: mod "tubelib_addons3" has unsatisfied dependencies: "tubelib_addons1" "tubelib"
Probably broken. 5.1.1

The built-in translation function of minetest should be added to this modpack.

We would like to play with translation.

This happens for some tubelib items but not for all. It applies i.e. for pusher, fast pusher, grinder, harvester.

Issue: If a player digs a grinder and his inventory is full, that item will be lost. The digged item won't drop onto the ground.

(feature request)

The worldedit does not work well with techpack blocks (mostly tubelib). For instance, tubelib machines that are placed with this tool recieve THE SAME WLAN ID. I don't know what a solution to this problem looks like; it may have to be fixed on worldedit's side.

With the new "valid_sides" functionality we have the ability to disable connections and passing items through certain faces of secondary nodes, there are several secondary nodes that should only take connections from certain sides, for instance pushers, which currently allow tubes to connect from any side even though they should only accept connections from the left or right

Pull request to fix a couple of crash-causing bugs:

• Add drops for active tubelib machines to ensure that players can't obtain them with, i. e., a node replacer
• Punching a mesecons converter with an end wrench causes a crash because its on_receive_message function returns the wrong thing; fixed that

#64

Hey, it's me again :)

Quick one this time!

Already fixed, just documenting

If you quickly shift-click items into a warehouse, with a properly configured first slot, you can force the stack size to exceed the intended limit.

This occurs on any warehouse, so best to test with the smallest one (steel) to make it easier.

If you shift-click into an input stack before the current input stack has been moved into the main inventory stack, then the limit can be exceeded.

Once it is exceeded, more items can be fed in without limit.

• Place a steel warehouse
• Configure the first slot for some item
• Gather at least 5 stacks of that item
• Shift-click 4 full stacks into the first inventory slot
• Frantically shift-click the last stack into the slot, clicking it multiple times in quick succession
• The slot will have more than 400 items in it

in tubelib_addons3/distributor.lua, we got an error that filter defined in on_receive_fields is nil, not sure whey this is... can we just provide a default?

ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod '' in callback node_on_receive_fields(): ...est/bin/../mods/techpack/tubelib_addons3/distributor.lua:296: attempt to index local 'filter' (a nil value)

(feature request)

Probably because of the metadata that they include, most tubelib nodes do not behave well when they are moved using mesecons pistons or movestones. Fixing mesecons to do something sane seems intractable; the easier solution is to prevent them from being moved in the first place.

For an example of how to prevent nodes from being moved by mesecons, see

https://github.com/obl3pplifp/bad_piston_no_biscuit

This could possibly be re-submitted as a PR if desired.

This is a fairly old issue, at least 3 or 4 months, but I forgot about it.

If you move unstackable items between two HP chests using a HP pusher, most of them will disappear.

e.g. put 32 diamond picks in one chest, and push them into another. I only end up with 2 picks. This also works w/ buckets of water, terumet machines, and some other stuff.

As a change of pace I have not yet solved this one, I may get to it in the next few days ;)

Items can be injected into tubes by distributors from sides they are not connected to

This applies to tube chains of all lengths, for simplicity I am detailing the minimum possible setup:

Chest > Tube > Chest
          ^
     Distributor

If you enable the side of the distributor facing the tube (red if you placed this all left to right), put items in, and switch it on, you will see items turn up in one of the chests

Useful notes:

• This does not work with a pusher, the pusher becomes blocked
• The items always seem to end up in the North or East chests (Z+ or X+)
• This also occurs with high perf distributors
• If you make this setup, then remove it and make it again, but rotated so that the tube is in the same place but 90 degrees rotated, then the items will end up behind the tube - indicating a ghost connection remains

So, if you take:

        Empty
          .
Chest > Tube > Chest
          ^
     Distributor

then remove it, then place

        Chest
          ^
Empty . Tube < Distributor
          ^
        Chest

The items will end up in the "Empty" space

Nice

If I use "for" or ":" inside the comments, it throws errors:

• Invalid character ':'
  and
• Invalid use of 'for'
  correspondently. I don't know why these two, for example "if" keyword do not causes any problems.

Commenting still works, i.e. if my comment has no "for" and ":" substrings inside, everything works just fine.
Compiler do not tries to interpret or execute comments.

Hello again,
It seems tubelib has some sort of bug ... this is the error:
2019-04-06 01:23:39: ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod '' in callback node_on_timer(): ...llys/.minetest/mods/techpack/tubelib/node_states.lua:308: bad argument #1 to 'random' (interval is empty) 2019-04-06 01:23:39: ERROR[Main]: stack traceback: 2019-04-06 01:23:39: ERROR[Main]: [C]: in function 'random' 2019-04-06 01:23:39: ERROR[Main]: ...llys/.minetest/mods/techpack/tubelib/node_states.lua:308: in function 'keep_running' 2019-04-06 01:23:39: ERROR[Main]: ...minetest/mods/techpack/tubelib_addons1/harvester.lua:258: in function <...minetest/mods/techpack/tubelib_addons1/harvester.lua:245>

The crash happened whenever a certain player joins. To me, the issue seems to be that if self.aging_level2/num_items is 0 or inf (from a divide by zero issue), then math.random errors.

Thanks,
BillyS

PS.
For now I've hacked together a solution to prevent it from crashing, but it's probably not the best way. So, this isn't terribly urgent but it should still be fixed. Thanks :)

I get a crash/ModError when I start a game with the latest version of this mod (a7a6b50):

2019-04-23 21:57:26: ERROR[Main]: ModError: Failed to load and run script from /home/runningdroid/.minetest/mods/techpack/tubelib_addons1/init.lua:
2019-04-23 21:57:26: ERROR[Main]: ...gdroid/.minetest/mods/techpack/tubelib_addons1/nodes.lua:269: attempt to call upvalue 'gr' (a nil value)
2019-04-23 21:57:26: ERROR[Main]: stack traceback:
2019-04-23 21:57:26: ERROR[Main]: 	...gdroid/.minetest/mods/techpack/tubelib_addons1/nodes.lua:269: in function 'register_tree'
2019-04-23 21:57:26: ERROR[Main]: 	...gdroid/.minetest/mods/techpack/tubelib_addons1/nodes.lua:277: in main chunk
2019-04-23 21:57:26: ERROR[Main]: 	[C]: in function 'dofile'
2019-04-23 21:57:26: ERROR[Main]: 	...ngdroid/.minetest/mods/techpack/tubelib_addons1/init.lua:14: in main chunk
2019-04-23 21:57:26: ERROR[Main]: Check debug.txt for details.

debug.txt

It seems that you can throw a stack of blocks in a funnel but you can't pull a full stack from it even with High Perf Pusher.

Is it possible that you can add High Perf Funnel? Or maybe fix regular funnel behavior by allowing to pull full stacks from it with High Perf Pusher? I personally think it would be better to add a new block, as it fits well with other highperf stuff.

When you turn off the door block, it loses its rotation and texture, a video with this bug is available here.

What could have caused this bug? I used the latest version of the techpack, I didn't use any other mods except tubelib2 and basic_materials.

(I apologize if I speak a little incorrectly, I use google translate.)

When Blocky Survival first updated to techpack 2.? from 1.?, around March 23rd, players started having issues with teleporters, and this problem has never been resolved. The issue is that the destination teleporter, instead of putting items into the destination machine, just dumps the item onto the floor. This happens even if one or both teleporters are removed, or even replaced with new teleporters. Personally I've just stopped using teleporters. However, everyone else reports that newly setup systems with teleporters work just fine.

I've never dug too deeply into why this issue is happening, or what a resolution looks like. As I can't supply any detailed information at this time, this issue is more of an FYI, in case you have any ideas, being more familiar with the mod.

It used to pull full stacks, and is still documented as doing so, but it currently doesn't. Looks like this is because the harvester doesn't implement 'on_pull_stack'. I'm not sure if this is intentional or not. If it's an oversight, it's a trivial fix.

Hi!

I use this mod on my Minetest server, since some weeks, and I updated later to this version

# Release Notes for ModPack TechPack [techpack]
## V2.02.04 (2019-03-02)

The map is almost new, I loaded some schems, and some contained tubelibs blocks.
But not in the area where I had a crash today.

Some context:

• I use this mod since some weeks.
• Today, I placed an harvester, and configured a Tubelib timer
• But, later I moved the node with the //move from the editworld mod because I want keep the harvester number ID.
• All works fine, but when I changed the time with /time the server crashed. It's not the first time I change the time...
• If a player (me or another) reach the zone, the server crash
• I deactivated tubelib_addons1, restarted the server, and removed the harvester and the timer, and reactivated the mod and restarted the server. The crash is still the same.
  ** First error:**

2019-03-07  ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod '' in callback node_on_timer(): ...etest/mods/techpack-master/tubelib_addons1/harvester.lua:47: attempt to index local 'this' (a nil value)
2019-03-07  ERROR[Main]: stack traceback:
2019-03-07  ERROR[Main]:       ...etest/mods/techpack-master/tubelib_addons1/harvester.lua:47: in function 'formspec_func'
2019-03-07  ERROR[Main]:       ...es/minetest/mods/techpack-master/tubelib/node_states.lua:143: in function 'stop'
2019-03-07  ERROR[Main]:       ...es/minetest/mods/techpack-master/tubelib/node_states.lua:341: in function 'on_receive_message'
2019-03-07  ERROR[Main]:       ...etest/mods/techpack-master/tubelib_addons1/harvester.lua:439: in function 'on_recv_message'
2019-03-07  ERROR[Main]:       .../games/minetest/mods/techpack-master/tubelib/command.lua:317: in function 'send_message'
2019-03-07  ERROR[Main]:       .../minetest/mods/techpack-master/tubelib_addons2/timer.lua:85: in function <.../minetest/mods/techpack-master/tubelib_addons2/timer.lua:69>

The 2019-03-07 ERROR[Main]: ...es/minetest/mods/techpack-master/tubelib/node_states.lua:143: in function 'stop' won't appear later

The next errors:

2019-03-07  ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod 'tubelib_addons1' in callback LuaLBM::trigger(): ...etest/mods/techpack-master/tubelib_addons1/harvester.lua:47: attempt to index local 'this' (a nil value)
2019-03-07  ERROR[Main]: stack traceback:
2019-03-07  ERROR[Main]:       ...etest/mods/techpack-master/tubelib_addons1/harvester.lua:47: in function 'formspec_func'
2019-03-07  ERROR[Main]:       ...es/minetest/mods/techpack-master/tubelib/node_states.lua:409: in function 'on_node_load'
2019-03-07  ERROR[Main]:       ...etest/mods/techpack-master/tubelib_addons1/harvester.lua:447: in function 'on_node_load'
2019-03-07  ERROR[Main]:       .../games/minetest/mods/techpack-master/tubelib/command.lua:111: in function <.../games/minetest/mods/techpack-master/tubelib/command.lua:108>

Others harvesters and tubelib nodes works fine on the server.
If you don't see what it is, I can erase the zone, rebuild, and, try moving block again.