Minetest logo

IRC log for #minetest-dev, 2014-01-12

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:14 sapier left #minetest-dev
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.
03:17 Miner_48er joined #minetest-dev
03:33 jin_xi joined #minetest-dev
04:07 ShadowBot joined #minetest-dev
04:07 BrandonReese joined #minetest-dev
05:10 kaeza joined #minetest-dev
05:27 nore joined #minetest-dev
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 <SHA> ... 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 <SHA> 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:22 ImQ009 joined #minetest-dev
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.sourceforg​e.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...
06:44 us_0gb joined #minetest-dev
08:06 werwerwer_ joined #minetest-dev
08:25 us_0gb joined #minetest-dev
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:37 sapier joined #minetest-dev
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
10:22 rsiska joined #minetest-dev
10:27 PilzAdam joined #minetest-dev
10:30 Guest69047 joined #minetest-dev
10:58 Calinou joined #minetest-dev
11:12 nore sapier, found it: http://irc.minetest.ru/minet​est-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:47 salamanderrake joined #minetest-dev
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 jin_xi joined #minetest-dev
11:51 mrtux joined #minetest-dev
11:51 darkrose joined #minetest-dev
11:51 Exio4 joined #minetest-dev
11:51 Kray joined #minetest-dev
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 grrk-bzzt joined #minetest-dev
11:59 PilzAdam forceloaded blocks are emerged with allow_generate=false ...
12:26 Gethiox2 joined #minetest-dev
12:31 bas080 joined #minetest-dev
12:45 MMN-o joined #minetest-dev
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?
12:59 e1z0 joined #minetest-dev
13:20 e1z0 joined #minetest-dev
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:46 Megaf joined #minetest-dev
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
14:22 ImQ009_ joined #minetest-dev
14:29 ImQ009 joined #minetest-dev
14:29 zat joined #minetest-dev
14:57 hmmmm joined #minetest-dev
15:12 Yepoleb_ joined #minetest-dev
15:17 iqualfragile joined #minetest-dev
15:41 bas080 joined #minetest-dev
15:44 nore hmmmm, forceloading does not generate new blocks... do you have an idea about that?
15:46 Evolykane joined #minetest-dev
16:04 VanessaE joined #minetest-dev
16:25 kaeza joined #minetest-dev
16:35 Zeitgeist_ joined #minetest-dev
16:35 Zeitgeist_ joined #minetest-dev
16:39 salamanderrake joined #minetest-dev
16:44 ImQ009 joined #minetest-dev
16:52 Calinou joined #minetest-dev
17:16 ImQ009 joined #minetest-dev
17:33 xyz nore: yes, that was my point
17:34 EvergreenTree joined #minetest-dev
17:34 EvergreenTree joined #minetest-dev
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:02 EvergreenTree joined #minetest-dev
18:03 EvergreenTree joined #minetest-dev
18:08 xyz https://github.com/freeminer/freeminer/comm​it/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:24 Evolykane joined #minetest-dev
18:28 grrk-bzzt joined #minetest-dev
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
18:58 VargaD_ joined #minetest-dev
19:11 bas080 joined #minetest-dev
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 Calinou joined #minetest-dev
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/minet​est-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
20:05 NakedFury joined #minetest-dev
20:44 sapier1 joined #minetest-dev
21:06 grrk-bzzt joined #minetest-dev
21:40 smoke_fumus joined #minetest-dev
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
23:55 us_0gb joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext