Digilines is a mod for minetest which adds data bus wires
License: Other
This mod adds digiline wires, an RTC (Real Time Clock), a light sensor as well as an LCD Screen. Can be used together with the luacontroller from mesecons. See the luacontroller manual for more information.
Send "GET" to RTC or light sensor to retrieve Data, send any text to LCD to display it. Select channel by right-clicking items.
License: Code: LGPL Textures: WTFPL
Currently it only reports changes, that’s weird and rarely useful (although I know some use cases for that too).
2018-04-20 23:24:27: WARNING[Server]: ServerEnv: Trying to store id = 139 statically but block (14,0,76) already contains 1183 objects. Forcing delete.
2018-04-20 23:24:29: WARNING[Server]: ServerEnv: Trying to store id = 140 statically but block (14,0,76) already contains 1183 objects. Forcing delete.
2018-04-20 23:24:31: WARNING[Server]: ServerEnv: Trying to store id = 142 statically but block (14,0,76) already contains 1183 objects. Forcing delete.
2018-04-20 23:24:33: WARNING[Server]: ServerEnv: Trying to store id = 144 statically but block (14,0,76) already contains 1183 objects. Forcing delete.
2018-04-20 23:24:35: WARNING[Server]: ServerEnv: Trying to store id = 150 statically but block (14,0,76) already contains 1183 objects. Forcing delete.
with the simple luacontroller program:
interrupt(1)
digiline_send("lcd", "Test")
I have found that digilines mod leaks a lot of stuff to global namespace.
box_bump1
box_bump2
box_center
box_xm
box_xmy
box_xp
box_xpy
box_zm
box_zmy
box_zp
box_zpy
create_lines
digiline
generate_line
generate_texture
tiles
wiredesc
By the way, should digilines own namespace be digilines rather than digiline?
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "zm" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:67.
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "xm" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:68.
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "zp" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:69.
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "xp" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:70.
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "xpy" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:72.
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "zpy" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:73.
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "xmy" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:74.
16:20:10: ERROR[ServerThread]: Assignment to undeclared global "zmy" inside a function at ...in/../mods/mods/digilines/digilines/wires_common.lua:75.
Could you add an "empty" message when a digiline chest become empty? It allow to create various automated systems
pull request #20
Perhaps when it is digged it causes a new item to be created and put into the users inventory. The item saves its code somewhere so that when placed again it can be re-coded automatically.
Rekon it can be done?
Currently this mod does not have a screenshot or description file included. Both are used when displaying the mod in the Mods tab of the main menu of Minetest.
The screenshot should be in a 3:2 aspect ratio, be named "screenshot.png", and be placed in the main directory of the mod.
The description file should be a small text file with a short description of the mod, be named "description.txt", and be placed in the main directory of the mod.
That’s a must for a complex automated system.
The reason is that mipmapping blends transparent and opaque pixels together, but the resulting pixels are alpha-tested and not alpha-blended (that is, each pixel is either drawn or not, no intermediate states). But there is a simple workaround: use opaque background in the entity.
To render that, I replaced
local texture = "[combine:"..LCD_WITH.."x"..LCD_WITH
with
local texture = "lcd_anyside.png^[resize:"..LCD_WITH.."x"..LCD_WITH.."^[combine:"..LCD_WITH.."x"..LCD_WITH
but that looks blurry when filtering is enabled.
Hi!
Can you add vertical digilines, similar to mesecons?
When you place and use an LCD, it works, but if you go away for a bit, then return to the area, forcing the text entity to re-load, its position is now too close to (or flush with) the LCD surface, causing Z-fighting or making the text entirely invisible:
I had similar problems with signs_lib at one time. The solution was to simply move the entity out a bit further from the sign. Far enough away to avoid Z-fighting, but still close enough that you have to get your nose right up on it to notice it isn't flush.
Hi!
Is there a command to clear the LCD screen?
I'd like to register a node which conducts the digiline signal vertically. Any idea how to do this?
This is a discussion topic.
Currently, there is very little value in making this a modpack. Modpacks are nice if each sub-mod are usable separately and when it's likely that they can be split up.
In this case it appears that the likeliness, as far as I can see, is pretty much zero, that people will use the parts separately.
Now that we have the mod.conf file, there is no need to make this a modpack, and I'd like to convert it back to a simple mod.
Not everybody uses pipeworks, so tubelib support is required.
If tubelib support was provided, terumet support would not be needed since the tubelib upgrade or input / output upgrade could be used.
However, terumet can already insert and remove items from the digilines chest if the chest is configured as the input or output when the input / output upgrade is being used - but it doesn't send any events.
This could be worked-around if #42 were taken care of.
Game: devtest
ModError: Failed to load and run script from /home/et/.minetest/mods/digilines/init.lua:
/home/et/.minetest/mods/digilines/inventory.lua:172: attempt to index field 'sounds' (a nil value)
stack traceback:
/home/et/.minetest/mods/digilines/inventory.lua:172: in main chunk
[C]: in function 'dofile'
/home/et/.minetest/mods/digilines/init.lua:88: in main chunk
Check debug.txt for details.
Problematic segment: https://github.com/minetest-mods/digilines/blob/master/inventory.lua#L172C11-L172C54
Solution: If no default mod then no sound
Would it be possible to give the ability to send a digiline signal to only one side?
eg. add an optional 3rd option to digiline_send(channel,msg,port) if no port is given then it sends to all else if it's a, b, c or d then only send in the direction
It would be really useful.
I'm trying to figure out how to get the contents of a digiline chest, so I know how much of a particular item is has. I can't see how to do this from reading what I think is the code for it: https://github.com/minetest-mods/digilines/blob/master/inventory.lua
I've tried:
digiline_send("name_of_chest_channel", "GET")
Also "get", nothing happens.
It is supposed to distribute the signal to other devices through its tip but its unable to do so, I tested it with digiline and lcd display connected to luacontroller but the lcd was not able to display any thing please try to solve the issue .
Hello,
As currently written, Digilines does not handle long wires. For one, if an intermediate mapblock is unloaded, messages will be lost, even if the effector on the far end is loaded. For another, digiline:transmit is recursive (and not tail-recursive) which could use up a lot of stack space for a very long wire.
How do you feel about the idea of using a VoxelManipulator to load intermediate mapblocks¹ and rewriting digiline:transmit to do an iterative graph search?
I would be happy to submit a pull request to do both of these things, but I would like to know whether you agree or disagree with the idea first so I don’t waste my time making something you will reject, and also if you have any comments about preferred implementations you would like to see or alternative ideas.
¹I realize that using a VM to load mapblocks through which wire passes would not necessarily be enough to get a circuit working properly, because the receiving effector might not be able to act on the received message in a suitable manner without the mapblock being active. However, this would mean that the number of forceloaded blocks needed to operate a circuit with two nodes a long way apart could be reduced from hundreds (covering the whole wire) to just two (covering the ends).
Currently the LCD screen has quite big borders and a very limited amount of text that can be displayed. I have come across intentions to connect multiple LCDs to one big display array. In that case, there is much less space to print characters than one would expect. Maybe it would be better to do this in a separate mod, probably there were some considerations why the limits were set as they are and I'd like to hear them and what your thoughts are about making more characters fit on screen.
I fixed the calculations in #64 enabling me to play around with this a bit:
Old screen with 5 lines, 12 chars each (fixed positioning as of #64):
Max character cramming (6 lines by decreasing line height by one, 14 chars each):
Inbetween with 6 lines, 13 chars each:
There is much space between the lcd node and the letter entities. It doesn't look good sometimes.
In my opinion the space between should be less.
From c20514d305f41281fa04c0ec6da8e99fc5f6a7ca Mon Sep 17 00:00:00 2001
From: Zefram <[email protected]>
Date: Mon, 4 Aug 2014 13:56:15 +0100
Subject: [PATCH] Define digiline chest from scratch
The digiline chest was attempting to work by adding to the default:chest
definition, as modified by pipeworks, but this didn't really work. As no
dependency on pipeworks was declared, it was not predictable whether
digilines would see the version of default:chest that had been modified
by pipeworks or not. The addition of the channel field to the chest form
depended on the default:chest form having a particular layout, with the
specific gap onto which digilines would superimpose the channel field.
This layout assumption got broken by a recent change to the default mod,
which shifted inventory slots around and reduced the size of the gap, and
also more drastically by technic_chests's redefinition of default:chest,
which shifted all the inventory slots down to accommodate a title line.
This is all fixed by defining the digiline chest from scratch. This is
feasible because the behaviour that is shared with the default chest is
a fixed and small quantity, in fact taking up only about the same amount
of space as the code that was needed to defer to the default definition.
This change incidentally makes the digiline chest be registered even if
pipeworks is not also loaded. The chest still works without pipeworks:
it emits digiline signals describing manual inventory operations.
---
digilines_inventory/init.lua | 142 ++++++++++++++++++++----------------------
1 file changed, 68 insertions(+), 74 deletions(-)
diff --git a/digilines_inventory/init.lua b/digilines_inventory/init.lua
index 4fe9397..e44359a 100644
--- a/digilines_inventory/init.lua
+++ b/digilines_inventory/init.lua
@@ -1,77 +1,92 @@
-if not minetest.get_modpath("pipeworks") then
- print("[Digilines] Install pipeworks if you want to use the digilines chest")
- return
-end
-
-local defaultChest = minetest.registered_nodes['default:chest']
-
-local sendMessage = function (pos, msg, channel)
+local function sendMessage(pos, msg, channel)
if channel == nil then
channel = minetest.get_meta(pos):get_string("channel")
end
digiline:receptor_send(pos,digiline.rules.default,channel,msg)
end
-tableMerge = function(first_table,second_table)
- if second_table == nil then return end
- for k,v in pairs(second_table) do first_table[k] = v end
-end
-
-tableMergeImmutable = function(first_table, second_table)
- if first_table == nil then return second_table end
- if second_table == nil then return first_table end
- copy = digiline:tablecopy(first_table)
- for k,v in pairs(second_table) do copy[k] = v end
- return copy
-end
-
-local mychest = digiline:tablecopy(defaultChest)
-
-function defer(what,...)
- if what then
- return what(...)
- end
-end
-
-function maybeString(stack)
+local function maybeString(stack)
if type(stack)=='string' then return stack
elseif type(stack)=='table' then return dump(stack)
else return stack:to_string()
end
end
-mychest = tableMergeImmutable(defaultChest,{
+local function can_insert(pos, stack)
+ local can = minetest.get_meta(pos):get_inventory():room_for_item("main", stack)
+ if can then
+ sendMessage(pos,"put "..maybeString(stack))
+ else
+ -- overflow and lost means that items are gonna be out as entities :/
+ sendMessage(pos,"lost "..maybeString(stack))
+ end
+ return can
+end
+
+local tubeconn = minetest.get_modpath("pipeworks") and "^pipeworks_tube_connection_wooden.png" or ""
+local tubescan = minetest.get_modpath("pipeworks") and function(pos) pipeworks.scan_for_tube_objects(pos) end or nil
+
+minetest.register_node("digilines_inventory:chest", {
description = "Digiline Chest",
- digiline = {
- receptor = {},
- effector = {
- action = function(pos,node,channel,msg) end
- }
+ tiles = {
+ "default_chest_top.png"..tubeconn,
+ "default_chest_top.png"..tubeconn,
+ "default_chest_side.png"..tubeconn,
+ "default_chest_side.png"..tubeconn,
+ "default_chest_side.png"..tubeconn,
+ "default_chest_front.png",
},
+ paramtype2 = "facedir",
+ legacy_facedir_simple = true,
+ groups = {choppy=2, oddly_breakable_by_hand=2, tubedevice=1, tubedevice_receiver=1},
+ sounds = default.node_sound_wood_defaults(),
on_construct = function(pos)
- defaultChest.on_construct(pos)
local meta = minetest.get_meta(pos)
- -- we'll sneak into row 4 thanks
- meta:set_string("formspec",meta:get_string("formspec").."\nfield[2,4.5;5,1;channel;Channel;${channel}]")
+ meta:set_string("infotext", "Digiline Chest")
+ meta:set_string("formspec", "size[8,10]"..
+ ((default and default.gui_bg) or "")..
+ ((default and default.gui_bg_img) or "")..
+ ((default and default.gui_slots) or "")..
+ "label[0,0;Digiline Chest]"..
+ "list[current_name;main;0,1;8,4;]"..
+ "field[2,5.5;5,1;channel;Channel;${channel}]"..
+ ((default and default.get_hotbar_bg) and default.get_hotbar_bg(0,6) or "")..
+ "list[current_player;main;0,6;8,4;]")
+ local inv = meta:get_inventory()
+ inv:set_size("main", 8*4)
+ end,
+ after_place_node = tubescan,
+ after_dig_node = tubescan,
+ can_dig = function(pos, player)
+ return minetest.get_meta(pos):get_inventory():is_empty("main")
end,
on_receive_fields = function(pos, formname, fields, sender)
if fields.channel ~= nil then
minetest.get_meta(pos):set_string("channel",fields.channel)
- return defer(defaultChest.on_receive_fields, pos, formname, fields, sender)
end
end,
- tube = tableMergeImmutable(defaultChest.tube, {
- -- note: mese filters cannot put part of a stack in the destination.
- -- space for 50 coal with 99 added will pop out 99, not 49.
+ digiline = {
+ receptor = {},
+ effector = {
+ action = function(pos,node,channel,msg) end
+ }
+ },
+ tube = {
+ connect_sides = {left=1, right=1, back=1, front=1, bottom=1, top=1},
connects = function(i,param2)
return not pipeworks.connects.facingFront(i,param2)
end,
+ input_inventory = "main",
+ can_insert = function(pos, node, stack, direction)
+ return can_insert(pos, stack)
+ end,
insert_object = function(pos, node, stack, direction)
- local leftover = defaultChest.tube.insert_object(pos,node,stack,direction)
+ local inv = minetest.get_meta(pos):get_inventory()
+ local leftover = inv:add_item("main", stack)
local count = leftover:get_count()
if count == 0 then
local derpstack = stack:get_name()..' 1'
- if not defaultChest.tube.can_insert(pos, node, derpstack, direction) then
+ if not inv:room_for_item("main", derpstack) then
-- when you can't put a single more of whatever you just put,
-- you'll get a put for it, then a full
sendMessage(pos,"full "..maybeString(stack)..' '..tostring(count))
@@ -86,25 +101,16 @@ mychest = tableMergeImmutable(defaultChest,{
end
return leftover
end,
- can_insert = function(pos, node, stack, direction)
- local can = defaultChest.tube.can_insert(pos, node, stack, direction)
- if can then
- sendMessage(pos,"put "..maybeString(stack))
- else
- -- overflow and lost means that items are gonna be out as entities :/
- sendMessage(pos,"lost "..maybeString(stack))
- end
- return can
- end,
- }),
+ },
allow_metadata_inventory_put = function(pos, listname, index, stack, player)
- if not mychest.tube.can_insert(pos,nil,stack,nil) then
+ if not can_insert(pos, stack) then
sendMessage(pos,"uoverflow "..maybeString(stack))
end
- local ret = defer(defaultChest.allow_metadata_inventory_put, pos, listname, index, stack, player)
- if ret then return ret end
return stack:get_count()
end,
+ on_metadata_inventory_move = function(pos, fromlistname, fromindex, tolistname, toindex, count, player)
+ minetest.log("action", player:get_player_name().." moves stuff in chest at "..minetest.pos_to_string(pos))
+ end,
on_metadata_inventory_put = function(pos, listname, index, stack, player)
local channel = minetest.get_meta(pos):get_string("channel")
local send = function(msg)
@@ -113,27 +119,15 @@ mychest = tableMergeImmutable(defaultChest,{
-- direction is only for furnaces
-- as the item has already been put, can_insert should return false if the chest is now full.
local derpstack = stack:get_name()..' 1'
- if mychest.tube.can_insert(pos,nil,derpstack,nil) then
+ if can_insert(pos,derpstack) then
send("uput "..maybeString(stack))
else
send("ufull "..maybeString(stack))
end
- return defer(defaultChest.on_metadata_inventory_put, pos, listname, index, stack, player)
+ minetest.log("action", player:get_player_name().." puts stuff into chest at "..minetest.pos_to_string(pos))
end,
on_metadata_inventory_take = function(pos, listname, index, stack, player)
sendMessage(pos,"utake "..maybeString(stack))
- return defaultChest.on_metadata_inventory_take(pos, listname, index, stack, player)
+ minetest.log("action", player:get_player_name().." takes stuff from chest at "..minetest.pos_to_string(pos))
end
})
-
-if mychest.tube.can_insert == nil then
- -- we can use the can_insert function from pipeworks, but will duplicate if not found.
- mychest.tube.can_insert = function(pos,node,stack,direction)
- local meta=minetest.get_meta(pos)
- local inv=meta:get_inventory()
- return inv:room_for_item("main",stack)
- end
-end
-
--- minetest.register_node(":default:chest", mychest)
-minetest.register_node("digilines_inventory:chest", mychest)
--
1.7.10.4After all the merges, it appears the LCD no longer functions properly, and I don't understand why.
@numberZero @DS-Minetest
Since 5.0.0 is out now it would be a nice thing getting rid of the deprecated minetest.setting_* functions and use the minetest.settings object.
2019-03-05 18:54:56: WARNING[Main]: WARNING: minetest.setting_* functions are deprecated. Use methods on the minetest.settings object. (at /home/dirk/.minetest/mods/digilines/init.lua:68)
2019-03-05 18:54:56: WARNING[Main]: WARNING: minetest.setting_* functions are deprecated. Use methods on the minetest.settings object. (at /home/dirk/.minetest/mods/digilines/init.lua:72)
2019-03-05 18:54:56: WARNING[Main]: WARNING: minetest.setting_* functions are deprecated. Use methods on the minetest.settings object. (at /home/dirk/.minetest/mods/digilines/init.lua:76)
2019-03-05 18:54:56: WARNING[Main]: WARNING: minetest.setting_* functions are deprecated. Use methods on the minetest.settings object. (at /home/dirk/.minetest/mods/digilines/init.lua:80)
HI,
i have this behavior of RTC and light sensor:
both of them causes burned luacontoler when i try to get status from them. it not depends on code.
i can just type:
digiline_send("sensor","GET")
and got burned lua controller - same when used on interupt(1)
strange is that, if write code for something else after this line - controller do that, but it is like it will be burned in next repetion of code.
in debug.txt is nothing about this - no error, warning...
only this i have in debug.txt:
10:01:11: ACTION[ServerThread]: Deprecated call to "get_entity_name
10:01:11: ACTION[ServerThread]: stack traceback:
10:01:11: ACTION[ServerThread]: [C]: in function 'get_entity_name'
10:01:11: ACTION[ServerThread]: .../dalibor/.minetest/mods/digilines/digilines_lcd/init.lua:42: in function 'clearscreen'
10:01:11: ACTION[ServerThread]: .../dalibor/.minetest/mods/digilines/digilines_lcd/init.lua:67: in function 'action'
10:01:11: ACTION[ServerThread]: .../dalibor/.minetest/mods/digilines/digilines/internal.lua:80: in function 'transmit'
10:01:11: ACTION[ServerThread]: .../dalibor/.minetest/mods/digilines/digilines/internal.lua:88: in function 'transmit'
10:01:11: ACTION[ServerThread]: /home/dalibor/.minetest/mods/digilines/digilines/init.lua:13: in function 'receptor_send'
10:01:11: ACTION[ServerThread]: ...e/dalibor/.minetest/mods/mesecons_luacontroller/init.lua:242: in function 'func'
10:01:11: ACTION[ServerThread]: /usr/share/minetest/builtin/game/misc.lua:19: in function </usr/share/minetest/builtin/game/misc.lua:9>
10:01:11: ACTION[ServerThread]: /usr/share/minetest/builtin/game/register.lua:348: in function </usr/share/minetest/builtin/game/register
.lua:336>
but LCD working fine...
i heve it on ubuntu 14.04, minetest 0.4.11 (same is on 0.4.10)
is it possible, that i can broke it with adding recipe only for light sensor? but i dont think, that it can broke different code in RTC
It would be cool to have a wiki page or something listing all the mods that use digilines to see what kind of ideas people would get by using them together.
Hello, it appears that there is a length limit for digilines? It seems that I get to a certain point, the signal stops propagating.
I know mesecons has buttons and meselamps/lightstone, but it would be nice to have versions of those that accept/emit digilines signals directly, so that I don't have to put an LuaC behind them (after all, LuaCs take up space, and I don't always /have/ space).
Due to the test string.len(line)+string.len(word) < LINE_LENGTH, if the first word is more than 11 characters (not 12!) long, then the first line is actually rendered completely empty, with the first word pushed to the second line. Subsequent lines always consume at least one word, even if the words are very long, and are also able to properly display words up to 12 characters long.
I believe this project would be much more modder-friendly if there was a sane documentation in this project.
README:
API documentation:
digilines table formatCenter alignment annoys. It is nice for signs, but the LCD should avoid that.
Also, the LCD dimensions (in letters) should be documented.
Because the item is recorded as "put" over digiline when can_insert is called, it is impossible to tell after receiving the message when the item is actually in the chest. This is a problem when using with pipeworks if you need to activate an injector that removes things from the chest, because it may fire before the item is actually in there.
The message should be sent in insert_object rather than can_insert.
Hi, I get this crash on server start up.
[MOD] WorldEdit loaded!
[UnifiedDyes] Loaded!
[Colored Wood] Loaded!
---- Dark Age is Loading! ----
Currency mod loading...
[Currency] Craft_items Loaded!
[Currency] Shop Loaded!
[Currency] Barter Loaded!
[Currency] Safe Loaded!
[Currency] Crafting Loaded!
[Currency] Income Loaded!
Coloured Stone Bricks [colouredstonebricks] has loaded!
[Mod]Bees Loaded!
Streets: Creating variables and tables...
Streets: Checking installed mods...
Streets: Setup completed, have fun with StreetsMod 1.5!
[Plants Lib] Loaded
[Moretrees] Loaded (2013-02-11)
[Poison Ivy] Loaded.
[Flowers] Loaded.
19:25:17: ERROR[main]: ========== ERROR FROM LUA ===========
19:25:17: ERROR[main]: Failed to load and run script from
19:25:17: ERROR[main]: /home/minetest/Server/bin/../mods/minetest-mod-digilines/digilines_inventory/init.lua:
19:25:17: ERROR[main]: ...er/bin/../mods/minetest-mod-digilines/digilines/util.lua:60: attempt to index global 'mesecon' (a nil value)
19:25:17: ERROR[main]: stack traceback:
19:25:17: ERROR[main]: ...er/bin/../mods/minetest-mod-digilines/digilines/util.lua:60: in function 'tablecopy'
19:25:17: ERROR[main]: ...mods/minetest-mod-digilines/digilines_inventory/init.lua:28: in main chunk
19:25:17: ERROR[main]: ======= END OF ERROR FROM LUA ========
19:25:17: ERROR[main]: Server: Failed to load and run /home/minetest/Server/bin/../mods/minetest-mod-digilines/digilines_inventory/init.lua
19:25:17: ERROR[main]: ERROR: An unhandled exception occurred: ModError: Failed to load and run /home/minetest/Server/bin/../mods/minetest-mod-digilines/digilines_inventory/init.lua
In thread b6918220:
/home/minetest/Server/src/main.cpp:1955: int main(int, char**): Assertion '0' failed.
Debug stacks:
DEBUG STACK FOR THREAD b6918220:
#0 int main(int, char**)
(Leftover data: #1 Dedicated server branch)
Aborted
There's a diagonal wire connection between digilines (but not mesecons) and luacontrollers (but not microcontrollers)
Copying this text in a Microcontroller editor
digiline_send("lcd", "Test: öäüß")
causes error: <invalid wide string>
LuaError: error: ...n/../mods/build/digilines/digilines/wires_common.lua:45: attempt to index field '?' (a nil value)
This issue seems to be fixed in mesecons.
I would like to have a setup where a machine starts up when somebody removes an item from a digilines chest, and it stops when the chest is full. However, if the chest's formspec is exited with the ESC key, the channel is reset to an empty string. It would be nice if this didn't happen, or better yet, if there was a "Settings" button that would bring the user to a different formspec, which would set the channel (and maybe lock/unlock the chest, and whatever other stuff).
When doing an investigation on some theft I lost track of items because multiple items were put / taken and the log just says
player:get_player_name().." moves stuff in chest at "..minetest.pos_to_string(pos)
My question: what stuff can not be answered by investigating the log.
Also when a player moves stuff into the chest item stack by item stack, the quantities are not logged, thus loosing track of what was stolen.
I don't know how important such things are to other mods/admins, but it just bugs me that information is lost (information being data that someone finds valuable)
I fully understand that you can't really log everything(or maybe I don't if I'm truly honest ;), so I would like to request that such information is logged, perhaps using a 'verbose logging' option.
Please take this under advisement,
Kind regards,
MCLV
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.