Open numberZero opened 7 years ago
(You could save the content somewhere else in game with luacontroller.)
@DS-Minetest That would be a horrible hack. BTW, according to #34 that’s unreliable now.
Related: #49. @Hawk777 what do you think on this?
Personally, I guess I see there being three options:
Between 1 and 2, I prefer 2. The reason is that some consumers will care about contents and others will care about changes. If you only have 1, calculating 2 from it is quite annoying, because you have to iterate the contents, establish a way of comparing two stacks for equality, and then generate all the changes from it. Calculating 1 from 2, on the other hand, is easy: it’s basically just accumulating puts and takes by count. So it’s easier for people who care about contents to calculate it from changes, than for people who care about changes to calculate it from contents.
I also think that sending the entire contents of the chest could turn into a really big message, especially if some items have nontrivial metadata attached. I’m also mildly opposed to building equipment that does more than it needs to to get the job done, so on both of those points, I prefer 2 over 3, but not too strongly.
I’m not sure why you think remembering the contents is a huge hack? It seems pretty sensible to me.
I really think the API should change to only report ACTUAL puts/takes (the current API is very confusing, and easily overheats a Luacontroller) AND respond with a simple table format to a request ("GET" perhaps?) for total contents.
I really think the API should change to only report ACTUAL puts/takes
This should now already be the case. Update your digilines to the newest version (not the one from contentdb, it's a year old).
(the current API is very confusing, and easily overheats a Luacontroller)
Use a luacontroller code, that does not send a digiline signal every event. This should avoid the overheating, probably.
Also try print(event)
.
The speed of multiple events being sent from the digilines chest to the luacontroller is what is causing the issue.
If that is already the case, why is this issue still open?
I do not know what version the server I am playing on is using but I will recommend they update.
On Fri, May 3, 2019, 11:59 AM DS notifications@github.com wrote:
I really think the API should change to only report ACTUAL puts/takes
This should now already be the case. Update your digilines to the newest version (not the one from contentdb, it's a year old).
(the current API is very confusing, and easily overheats a Luacontroller)
Use a luacontroller code, that does not send a digiline signal every event. This should avoid the overheating, probably. Also try print(event).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/minetest-mods/digilines/issues/42#issuecomment-489204399, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTE6PZVO6E6I2L3NHVOWVDPTSDPPANCNFSM4DAWHIXA .
The speed of multiple events being sent from the digilines chest to the luacontroller is what is causing the issue.
I see. Either there are ridiculously many interactions with the chest in a short time or the server has changed a overheating setting.
If that is already the case, why is this issue still open?
It's still not possible to request the contents of a digiline_chest.
I do not know what version the server I am playing on is using but I will recommend they update.
Existing builds with digiline chests might (= will probably for sure) break.
This should now already be the case. Update your digilines to the newest version (not the one from contentdb, it's a year old).
I have checked and they are already up to date with the latest version.
Current behavior:
On taking a stack with more than one item, two messages come through, one with the correct number of items removed, and one with 1 item removed. On taking a stack with only one item, a message comes through without a number, and then another with 1 item removed.
Also takes are reported from moving stacks around in the chest.. I would at least understand if puts were also reported, but they aren't. These are at least reported differently enough from the true takes that I haven't had an issue with accurate tracking of the chest itself.
I have checked and they are already up to date with the latest version.
Digilines in minetest-mods: https://github.com/minetest-mods/digilines dates: 20 Oct 2017 We are on the "latest" state rofl
The newest commits are from march 6th (see https://github.com/minetest-mods/digilines/commits/master).
I have Minetest 0.4.17.1 and Digilines 434010bdd0362b79a67a07a2055d690c50d9311f. I put this code on a Luacontroller:
print("=====")
function dump(x)
if type(x) == "table" then
print("{")
for k,v in pairs(x) do
print(k .. ": ")
dump(v)
end
print("}")
else
print(x)
end
end
dump(event)
When I take part of a stack (more than one, but less than all of them), I get this in the console:
"====="
"{"
"type: "
"digiline"
"channel: "
""
"msg: "
"{"
"stack: "
"{"
"meta: "
"{"
"}"
"metadata: "
""
"count: "
50
"name: "
"digilines:chest"
"wear: "
0
"}"
"action: "
"utake"
"from_slot: "
1
"}"
"}"
2019-05-16 22:30:31: ACTION[Server]: singleplayer takes stuff from chest at (-31,20,78)
When I take the rest, I get this:
"====="
"{"
"type: "
"digiline"
"channel: "
""
"msg: "
"{"
"stack: "
"{"
"meta: "
"{"
"}"
"metadata: "
""
"count: "
49
"name: "
"digilines:chest"
"wear: "
0
"}"
"action: "
"utake"
"from_slot: "
1
"}"
"}"
"====="
"{"
"type: "
"digiline"
"channel: "
""
"msg: "
"{"
"action: "
"empty"
"}"
"}"
2019-05-16 22:30:39: ACTION[Server]: singleplayer takes stuff from chest at (-31,20,78)
Looks like exactly what’s expected: only one utake
, followed by an empty
if that’s the case.
The newest commits are from march 6th (see https://github.com/minetest-mods/digilines/commits/master).
@DS-Minetest To be honest, I'm not sure why it's shown this way on GitHub, but the latest commit referenced there and here is the one from 2017 ..and is also dated March 6, 2019.
Edit: I'm guessing the original commit was created in 2017 but not pulled until 2019.
434010bdd0362b79a67a07a2055d690c50d9311f has this metadata:
Author: Christopher Head
AuthorDate: Fri Oct 20 00:24:32 2017 -0700
Commit: Auke Kok
CommitDate: Tue Mar 5 22:04:56 2019 -0800
so I guess Github is showing commit date, and @TangentFoxy is looking at author date instead.
To be clear: @TangentFoxy are you seeing something other than what I posted above, using the same commit (434010bdd0362b79a67a07a2055d690c50d9311f)?
GitHub shows commit date in one place, and author date in another.
Back to topic, though, my real question was: @TangentFoxy, you said “On taking a stack with more than one item, two messages come through, one with the correct number of items removed, and one with 1 item removed. On taking a stack with only one item, a message comes through without a number, and then another with 1 item removed.” Do you see this unexpected behaviour with 434010b? Can you help us reproduce this behaviour? Can you perhaps run my sample code I posted in a comment above and explain what actions to take in the chest, what output it produces, and why that output is wrong?
Currently it only reports changes, that’s weird and rarely useful (although I know some use cases for that too).