Time Nick Message 08:14 Krock that feeling that you messed up a lot when minetest does not start up after an in-game change 08:14 Krock but then you remember that it's not built on top of your experimental branch so there's still a bug in the engine which hasn't been fixed 08:15 Krock aagh had this shock moment 08:18 * VanessaE zaps Krock with a live Technic LV cable 08:18 VanessaE there's another ;) 08:18 Krock ouch 08:18 Krock bzzzbzzg 08:19 Krock *lights spark* 08:19 VanessaE you gotz pull requests to merge, btw :) 08:19 Krock oh right 08:19 Krock but please let me work on this attachment mess 08:19 VanessaE yeah yeah. 08:19 VanessaE ;) 08:30 Krock HEHAHHAH 08:30 Krock it works lol 08:32 Krock just a few more minutes 08:32 Krock and a gdb backtrace 08:40 VanessaE inb4 "few" minutes turns into hours ;) 09:46 Krock well sorry that I cannot iterate & modify an unordered:set at the same time 09:46 VanessaE heh 09:46 Krock will review that stuff after meal. it's not important after all 09:46 VanessaE called it. ;) 09:46 Krock at least for me 09:46 Krock bbl 10:33 Krock hmm.. is "node.name" always equal to the registration name in the node callback in regard to aliases? I think so 10:40 VanessaE thanks, Krock. finally no more duplicated itemstacks :) 10:41 Krock ..duplicated? 10:41 VanessaE yeah, that's what those PRs fix 10:41 VanessaE if you place a neutral UD-colored node, without colorizing it, then dig it, it won't stack with the ones still in your inv. 10:42 VanessaE this fixes that 10:44 VanessaE it's sort of an engine glitch, but not entirely. those PRs (well, the function in UD that they call) is probably the most appropriate way to fix it, and easier than jacking around with the engine ;) 10:55 Krock oh. that's not item duplication 10:56 Krock it's just a different kind of item which isn't stackable 10:56 VanessaE right 10:56 Krock item duplication is when you can make two out of one 10:56 VanessaE by duplication I just mean what it looks like to the player 10:56 Krock or one out of nothing 10:56 VanessaE /giveme two, place one, dig one, you have two, but as separate stacks 10:57 VanessaE mo matter. fixed now :) 10:57 VanessaE no* 12:06 Krock BillyS: as a side note: there are many unnecessary set_attach(nil, ...) calls on Blocky Survival. These objects have no parent (attach to nothing) 12:07 Krock although it does not appear to happen at spawn, since the parents are not known to the client there 12:19 Krock can't say what kind of luaentity it is. that information is not available to clients 13:40 BillyS Krock: Alright, are you theorizing that this could be causing the memory leak, or merely pointing out that it's inefficient? 13:47 Krock just inefficient. the IDs are in the range of 49k now, but that means nothing since that number is only counted upwards 13:48 Krock it's something I noticed while testing a PR. Maybe there are too many forceloaded blocks, or nodes with much metadata, or entities with much static data 13:49 Krock but I don't know where the memory issue comes from 14:16 BillyS could be nodes with metadata 14:16 BillyS The server is covered with huge tubelib / terumet factories 14:26 Krock setAttachment() id=42106, parent=0, name=Krock 14:26 Krock repeated 30 times in a row. no parent, but still getting updates 14:27 BillyS Hmm 14:27 BillyS Alright, probably some poorly written mod 14:27 Krock yeah. one that affects lua entities and players 14:27 BillyS Btw, you can always submit issues to https://github.com/BlockySurvival/issue-tracker 14:30 Krock 200 OK 14:37 rubenwardy Krock: CTF destroys and recreates attachments a ton 14:37 rubenwardy Would it be helpful to remove that when testing your pr? 14:37 rubenwardy Probably 14:39 Krock still less setAttachment() calls than on BLocky Survival xD 14:39 Krock if you want, don't hesitate to get a build so two of us can test this simultaneously while other people are upset about the missing tags 14:40 Krock that or I'll fire up a local testing server to let people here join it for testing 16:30 Sokomine i've got a problem with git (not concerning mt): logfiles accidentally got added. .gitingore needs to be extended. the files shall not be removed on any repro - just no longer synced (as if they'd have been part of .gitignore from the beginning). any clues? 16:36 Krock add them manually 16:37 Krock so, would you like to remove the logs? 16:37 Sokomine from git. git shall no longer care about them. logfiles change, but that's no reason for a commit. they need to be synced diffrently 16:47 celeron55 i don't think it's possible to have anything in git without git synchronizing it, unless the one invoking the fetch uses a shallow clone that was started after the logfiles were added 16:48 celeron55 not being able to permanently remove anything without rewriting history is part of git's security design 16:49 celeron55 really the issue is that git doesn't warn about large files being added and then people notice them only after pushing, it's kind of silly 17:42 Sokomine perhaps. there may really be no clean way to get rid of those files. i've now added them to .gitignore and used git rm --cached filename and hope that that'll do what i need 17:43 Sokomine having to do a commit for changed logfiles seems inappropriate. also having them linger around forever as something that has changed would be equally annoying 17:50 Sokomine admittedly, large files on a public repository might be even more annoying than that :/ 18:21 celeron55 well 18:21 celeron55 there's an old irrlicht dll in the minetest repository 18:22 celeron55 about 3 megabytes of something that isn't even historically interesting 8) 18:26 Krock now minetest is 3 times that size 18:29 Calinou <@celeron55> really the issue is that git doesn't warn about large files being added and then people notice them only after pushing, it's kind of silly 18:29 Calinou that can be done with a pre-commit hook, GitLab also offers an option to do it 18:29 Calinou but yeah, it's not standard :(