Time Nick Message 01:47 iqualfragile minetest realy need so me paralisation for some searches 02:10 iqualfragile & minetest realy needs a primitive for on and of (as used in furnances and mesecons etc 02:10 iqualfragile ) 02:10 iqualfragile because otherwise its freaking impossible to destroy blinking wires and i suspect that a high amount of bandwidth might be wasted 03:08 ShadowNinja Wut? I can't parse that first sentence iqualfragile. 03:15 iqualfragile minetest should execute some things in paralel 03:15 iqualfragile for example pathfinding could be done in another process 03:16 ShadowNinja Ah, yes, that's what the Async API is for, although only the mainmenu has access to it ATM. 05:51 xiong Is it acceptable to nest modpacks (so long as each enclosed dir contains an empty modpack.txt)? 05:51 nore IIRC yes 05:52 xiong Thanks, nore. 06:01 xiong Is any work being done towards cascading or included minetest.conf files; and/or managing sets of mods in git? Anything of which I should be aware before I start breaking trail? 06:02 BrandonReese something like apache does with it's conf.d directory, loads all files in the directory as a config file? 06:03 xiong Hi, BrandonReese. Some sort of management, you know. Installing a mod is not as simple as dropping it into a dir; there's hair all over. 06:04 * BrandonReese nods 06:04 xiong At minimum, I should think it obvious, any mod that accepts config of any sort should ship with its own minetest.conf -- if only as documentation. 06:05 xiong If that mod-specific file can't be included or called from the main file then this loses half of its usefulness. 06:06 BrandonReese true. Maybe if the mod includes a minetest.conf or mod.conf file in the mod folder that file is automatically processed like minetest.conf, which I think it kind of what you are getting at 06:06 xiong As I understand it, that's not now the case. 06:06 BrandonReese right. 06:07 xiong I'm of two minds about multiple config files for a given application; there's much to be said for separation of concerns but also for the convenience of knowing that all your conf is in one place. Some mods, the only conf demanded is a line to enable. 06:09 xiong I think it should be a user choice whether to rely on one big file or join several small ones. The small files might not even be mod-specific; one guy might say "I want all my worlds to be like *this* but I want world 5 to have *that* and *that*." 06:09 BrandonReese I just remembered some mods are doing their own config file, like technic, pipeworks, moretrees, landrush :) 06:10 xiong That's another issue -- the private config file. I don't approve... and I'm doing that now. But then, that mod is planned to be half-written in Perl; and the Perl is the only part written so far. 06:10 BrandonReese I think for multiple worlds it makes the most sense, you have one base file, then load a supplimentary file or files from a directory to fine tune the server config for that world 06:11 xiong But then, there's also a reason to keep secret the contents of the private conf; so there's that. 06:11 VanessaE my hods have private config files only because I didn't, at the time those options were added, read config values from minetest.conf. 06:11 VanessaE mods* 06:11 VanessaE didn't know how to, that is. 06:12 xiong Well, VE, if I complain about what you did then it's the pot calling the kettle black. But I do not think it's the right way. 06:12 BrandonReese I like the private/per world config files. For the sole fact it makes it easy to configure mods differently per world 06:13 xiong Anyway, I'm working toward an external solution that will concatenate multiple conf files and generate the one big one demanded by the engine. Before I do that I just wanted to check that there wasn't another solution. 06:13 xiong Everyone will see the feature through a different lens, BR. Which is a good thing. 06:14 BrandonReese yep 06:15 xiong In general, I'm working toward a solution for juggling mods for a server through a shell; that does not fight with git, either. And trying to do as little original work as possible. 06:15 xiong One would like commands as simple as $ borkbork snow enable 06:16 xiong Or $ borkbork snow checkout ... which gets tricky because git doesn't tolerate having its entire dir deleted. 06:18 BrandonReese You should be able to do a git --reset hard instead of deleting the folder and recloning it 06:18 xiong Um, I mean to say that $ borkbork snow disable -- is not a problem if we go through minetest.conf; but if we delete the dir then we have a devil of a time re-enabling it later. 06:18 xiong Ah, you are still thinking in terms of one big repo, though, yes? 06:19 xiong Yet to preserve the integrity of each mod, each mod must be in its own little repo. 06:19 xiong Otherwise the link to upstream is broken; and there's no obvious way to push to a fork and offer a pull req. 06:20 BrandonReese No, I'm thinking of individual repos. My setup now is I have a mods folder outside of minetest, git repos when they have one, I symlink from minetest/mods to the mods I want in this outside folder. 06:20 xiong On the other hand, once one has juggled mods successfully and got a set of them to play nice together -- one would then like to be able to push that and publish the working set. So one needs both the super repo and the subs. 06:21 xiong Okay, that's another approach I've considered: symlink shootout. 06:21 BrandonReese I originally did that before the world.mt file because deleting symlinks when I didn't want a mod was eaiser than deleting or moving directories 06:22 xiong Then there's the two-shelf model, where there's a shelf full of books *and* the one big volume... and you copy back and forth. 06:23 xiong Lately I've been looking into git-specific strategies, starting with git submodules, which turns out to be a tarpit. Also git subtrees, which also looked good; but apparently bind even tighter than submodules. 06:24 xiong Today I fussed with gitslave, which binds more loosely, which is good; but is specifically tailored for big projects that contain little projects more or less all done in-house; the home page contents are about half devoted to workarounds for the foreign-repos case. Obviously not a great fit. 06:26 xiong It's the best approach so far but just way too complex -- overpowered and still does not cover our use-case? http://gitslave.sourceforge.net/tutorial-basic.html 06:26 xiong Something is wrong with a solution whose *basic* tutorial is that long. 06:27 xiong We want (a) enable this mod; (b) checkout a different SHA for this mod; (c) disable this mod; and we want to be able to push or pull either the whole thing or any given mod by itself. Simple... in conception. 06:30 BrandonReese Oh I think I see kind of what you are wanting to do. Yeah pretty complicated to get started it looks like 06:30 xiong If I don't plan ahead for these tasks then they may be very difficult to do later. 06:31 xiong I would very much appreciate it if you were able to push your entire world and I could pull it and fiddle with it. 06:31 BrandonReese failing to plan is planning to fail 06:31 BrandonReese I'll zip it up so you can download it. Probably do that tomorrow. I should really head to bed 06:31 xiong However I don't want your world in the shape of a dead stack of trees; my fiddling might reasonably take the shape of pulling upstream. 06:32 xiong I'll take the zip! Thanks. But it's not what I think serves all of our needs best. Have a nice nap, BrandonReese. 06:33 xiong Um, zip minus the map itself, neither of us wants to horse that whole big thing around. 06:33 BrandonReese Oh, I thought that's what you wanted 06:34 xiong Oh no, the map is of the least interest. If it were smaller I'd not mention it but yours must be up to several GB by now. 06:34 BrandonReese I'll see what I can do about getting the rest of it in a repo. Maybe send me a forum PM of what exactly you want. 06:34 xiong The main interest is the setup, the conf, the mods. 06:34 BrandonReese ok 06:35 xiong Quite honestly I thought your conf would be enough to tell all. But the specific versions of each mod are critical; and then there's those private conf files and, dunno, mods you've edited on the spot. 06:36 xiong I progress from blindness to blindness... in hope of less darkness. 06:37 xiong Anyway, nice chat you, have a nice sleepy... 09:02 nore I have an idea to fix #944: 09:02 ShadowBot https://github.com/minetest/minetest/issues/944 -- bug: item loss due to moving items out of output-only inventory to an occupied slot 09:03 nore instead of storing the stack that is under the pointer in an inventory slot, 09:04 nore store it instead in a special place, and generate metadata_inventory_take/put events (so no metadata_inventory_move anymore, since they won't be needed) 09:05 nore metadata_inventory_move == metadata_inventory_take then metadata_inventory_put 09:05 nore any thoughts? 09:42 nore hi sapier... are inventories in the client/server for you? 10:01 sapier I think so yes, but I don't know that much about that part yet. If I remember correct a similar suggestion was written here some days ago. Seems to be a valid way to do it 11:12 nore sapier, found it: http://irc.minetest.ru/minetest-dev/2013-12-23#i_3510867 11:13 nore well, the conclusion was that get_lists would be useful, which have been added yesterday... 11:39 PilzAdam /builtin/forceloading.lua:25: attempt to compare string with number 11:39 PilzAdam add a tonumber() arround setting_get() 11:43 xyz lol 11:44 sapier does anyone understand why a mutex protecting the client list is called m_con_mutex? 11:46 xyz thinking about it, the idea to save list of blocks to forceload is really weird 11:47 PilzAdam doesnt Minetest generate blocks that are forceloaded? 11:48 xyz to properly use it this way mods will have to do very complex shit 11:48 xyz like keeping list of blocks that this mod managed to get loaded 11:48 xyz saving it to a file as well 11:49 xyz it's really hard to keep this in sync 11:49 xyz probably a better idea would be just to not "keep the forceloaded areas after restart" 11:50 sapier https://gist.github.com/sapier/8383662 ShadowNinja VanessaE could one of you test if this fixes the client connect race condition causing hud not beeing shown? 11:51 sapier btw this is practically splitting the conlock to quite small parts so next would be env lock 11:52 xyz nore: ^^^^ 11:52 PilzAdam minetest.get_position_from_hash() isnt documented in lua-api.txt 11:59 PilzAdam forceloaded blocks are emerged with allow_generate=false ... 12:50 nore PilzAdam, I thought I had put a tonumber there... have you already fixed it, or not? 12:54 nore https://github.com/Novatux/minetest/commit/9a7ebd2a7c4e56e9fb56c94057b7c0b8a734f9bd <-- PilzAdam, is it ok for merging? 12:55 nore xyz, so you think blocks should not be saved from forceloading after restart? 13:31 PilzAdam nore, yes 13:31 nore ok 13:31 nore pushed 13:32 nore what was that thing about allow_generate? 13:34 sapier if I understand correct pilzadam meant that it isn't usefull to forceload a non generated block ... correct interpretation? 13:34 PilzAdam yep 13:34 nore that's strange, because it loads blocks the same way a player does... 13:35 nore and the player generates blocks... 13:35 PilzAdam you have to change env.cpp:1150 to true 13:35 PilzAdam I may be wrong, though 13:36 nore how did the player generate the world previously then? 13:37 PilzAdam in RemoteClien::GetNextBlocks() ? 13:37 PilzAdam +t 13:38 nore ah... so it was not in the activate code 13:38 nore anyway, those blocks near the player need to be generated too, so I will do that fix 13:39 nore should I push the fix? 13:39 sapier are you sure about the generation thing? 13:39 PilzAdam what fix? 13:40 PilzAdam sapier, not at all 13:40 nore the change from "false" to "true" 13:40 PilzAdam better dont do that 13:40 sapier I'd like to have someone who knows generation code better then me to judge this change 13:40 PilzAdam I guess its there for a reason 13:40 nore perhaps test it a but before... 13:41 sapier I have quite a lot of work with locks because of minetest doesn't honor clients need to be initialized prior sending messages to them ... did work on pure chance by now 13:42 sapier generating things that haven't been generated before may cause similar effects 13:42 sapier +timing 13:46 nore ... it does not seem to work correctly (even with the change) 13:46 nore minetest.after(5, function() print(minetest.forceload_block({x = 0, y = -2000, z = 0})) end) 13:46 nore minetest.after(30, function() print(dump(minetest.get_node({x = 0, y = -2000, z = 0}))) end) 13:46 nore ^ this code prints "ignore" 13:46 sapier timing effects usually don't occur on your machine ... those I'm fixing right now don't occur for me too 13:47 sapier of course you could be right too ... I just don't know 13:47 nore well, anyway, PilzAdam's change was not enough 13:49 sapier If you're not sure about it ask someone who knows that code it's not a shame 13:50 nore of course... ;) I will wait a bit (who should I ask? hmmmm?) 13:52 sapier yes hmmmm should be best to ask about this issue 13:53 sapier talking about asking PilzAdam how skilled are you in terms of multithreading and locking? 13:54 PilzAdam I have no experience in c++ with it 13:54 sapier :-/ someone should check that patch I referenced some lines up spliting the conlock/clientslock is quite risky and I guess I didn't see any sideeffect 15:44 nore hmmmm, forceloading does not generate new blocks... do you have an idea about that? 17:33 xyz nore: yes, that was my point 17:53 sfan5 src/jthread/win32/jsemaphore.cpp:64: error: ‘assert’ was not declared in this scope 17:53 sfan5 someone fix that pls 17:58 ShadowNinja I'll merge formspec_table soon if it still works and nobody has any objections. (I haven't heard any yet) 18:02 ShadowNinja sapier: Can you look at #862? It needs to be rebased now, but you probably know best how to do that... 18:02 ShadowBot https://github.com/minetest/minetest/issues/862 -- Add the option to bind to a specific address by ShadowNinja 18:08 xyz https://github.com/freeminer/freeminer/commit/165b5244ff867fefae7b40f101b6947cb6dda849 18:11 Kray i like it how there's almost no mention of minetest in any material related to freeminer 18:13 xyz do you mean i should mention minetest in every commit message? 18:14 Kray no 18:14 xyz then what's the problem? 18:22 ShadowNinja xyz: That looks good. 18:29 ShadowNinja I've rebased #675 and ammended it with proller's patch. Any objections to merging it? 18:29 ShadowBot https://github.com/minetest/minetest/issues/675 -- Allow vertical axis particle rotation constraint by khonkhortisan 18:30 VanessaE +1 19:55 nore ShadowNinja, perhaps you could fix #944 now that InvRef:get_lists() is in... 19:55 ShadowBot https://github.com/minetest/minetest/issues/944 -- bug: item loss due to moving items out of output-only inventory to an occupied slot 19:55 nore anyway, gtg 19:58 ShadowNinja No, I don't know how get_lists helps with that bug. 19:59 nore (well, from what I read of the last discussion, it was about serializing the player inv for the new optional "holding" stack) 19:59 nore there: http://irc.minetest.ru/minetest-dev/2013-12-23#i_3510867 20:00 Sokomine ah. yes, thanks for the idea, nore. hope that gets fixed. i'm not versed enough in the code to really fix it. my approach would be to check - prior to actually taking the content out of the slot - if there's either a willing receiving slot in the players inventory or if the slot something was taken from is willing to take what the player had in his inv. else deny the move 20:00 Sokomine a new holding stack might solve that, yes 20:02 nore anyway, I have really got to go now 20:02 nore bye 20:03 ShadowNinja That's just for mods like bones to get all of the lists. But they need a place to store that. Maybe you could punch bones to have them restore all of your inv, and drop anything that doesn't fit. 20:04 Sokomine can't bones move surplus stuff into the player's crafting grid? that's where the items most likely where stored previously anyway 22:36 sapier1 we've got a problem with the recent added on_prejoin handler 22:37 sapier it's called prior client is initialized, therefore doing anything causing messages beeing sent to client in there may cause issues 23:22 ShadowNinja xyz: Can you push your patch to Minetest? 23:25 xyz ShadowNinja: what patch? 23:27 ShadowNinja xyz: The one that fixed the switch statement be adding breaks and checked for a zero division error. 23:28 xyz ah, ok