Minetest logo

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

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

All times shown according to UTC.

Time Nick Message
00:32 zat joined #minetest-dev
01:11 Selah joined #minetest-dev
01:45 alexxs joined #minetest-dev
01:50 MinerDad I can't seem to find a use for ItemType::ITEM_CRAFT. Is it still being used somewhere?
01:52 johnnyjoy left #minetest-dev
01:54 johnnyjoy joined #minetest-dev
02:05 paramat left #minetest-dev
02:16 prozacgod joined #minetest-dev
02:48 kahrl hmmmm: errno expands to a "modifiable lvalue" according to the C99 standard draft (7.5.2)
02:48 hmmmm how about C++08
02:48 hmmmm and, yeah, I know for a fact that MSVC defines errno as geterrno() or something
02:48 kahrl the C++ standards just point to the C standards for <c..> headers
02:49 hmmmm C++98 i mean
02:49 hmmmm what standard of C++ do we conform to
02:49 hmmmm 98 or 03?
02:49 kahrl both I guess
02:49 hmmmm well
02:50 hmmmm i would prefer more solid code overall
02:50 hmmmm surely, manually setting errno should not be necessary
02:50 kahrl I'm not saying the semaphore code is great (haven't looked at it really) but that particular thing is a non-issue
02:53 kahrl MinerDad: ITEM_CRAFT is for items registered with register_craftitem
02:54 kahrl basically "everything that is not a node or tool"
03:01 MinerDad thanks
03:01 Miner_48er joined #minetest-dev
03:33 paramat joined #minetest-dev
03:40 MinerDad celeron55: I've updated the pull request (https://github.com/minetest/minetest/pull/1963) with the comment changes.
04:05 Tesseract MinerDad: There are many missing periods.
04:05 mfw joined #minetest-dev
04:06 Tesseract (and doxygen cares because it generates the breid by going to the first period)
04:06 MinerDad you mean brief?
04:07 Tesseract MinerDad: Yes.
04:07 MinerDad I'll add periods but it looks like it is generating the brief based on the new line (I've generated it locally)
04:08 Tesseract MinerDad: Also extra /* */s, but looks pretty good now (just a quick scan though)
04:08 MinerDad Tesseract: what do you mean by the extra /* */?
04:11 Tesseract MinerDad: C98 comments instead of C++ line comments.
04:12 MinerDad Tesseract: Sorry, I'm still not quite understanding you.
04:13 MinerDad Tesseract: And I just added a bunch of periods. I'm rewriting the commit each time so you won't see a diff with the latest changes.
04:13 Tesseract /* Foo. */       vs.      // Foo.
04:15 MinerDad ok, so you don't want any of /* */ style.  Doxygen doesn't handle plain //.  You have to use ///.  I think you can also use //! but I've never used that style.
04:30 MinerDad Tesseract: I switched from /* */ to ///, Does it look better?
04:31 Tesseract MinerDad: No, I mean use // for single-line comments.  The big ones should still use /* */ multiline comments.
04:32 Tesseract Sorry about the confusion.
04:32 MinerDad lol, that's ok
04:38 MinerDad Tesseract: Now it should look better. The confusion stems from the fact that my personal preference is having doxygen related comments always having the same comment syntax. So it is strange to me to use /* */ style and // style together for doxygen.
04:49 Tesseract MinerDad: Put usefull method comments next to the methods, don't put _everything_ in the class comment.  Otherwise looks good.
04:50 MinerDad lol, That's what celeron55 asked for
04:50 MinerDad http://irc.minetest.ru/minet​est-dev/2014-12-14#i_4064169
05:05 Wuzzy2 joined #minetest-dev
05:09 Tesseract MinerDad: That's not what he meant.  "focus on documenting classes as a whole" vs "stuff everything into the class doc comment".
05:11 MinerDad He also said http://irc.minetest.ru/minet​est-dev/2014-12-14#i_4064118 and http://irc.minetest.ru/minet​est-dev/2014-12-14#i_4064123.
05:13 Miner_48er joined #minetest-dev
05:14 Tesseract MinerDad: "don't comment" isn't "comment, but in the class doc comment".  And it's a guideline, you should still comment non-obvious things.
05:17 MinerDad Tesseract: I'll wait and see what celeron55 has to say. Also, in this file, CItemDefManager is not declared (it is only in the .cpp) but that is the class that should be commented on. Would you want the comments in the .cpp, attached to the interfaces, or atteched using doxygen tags (like I have @class CItemDefManager).
05:19 MinerDad Tesseract: is there a file that does have good doxygen commenting?
05:20 Tesseract I don't know about interface commenting.  Or any well-documented files (we started with doxygen fairly recently).
05:22 kahrl "Should not be implemented by any other class." <-- why?
05:23 kahrl it would be completely valid e.g. to implement a MockItemDefManager for testing purposes
05:27 MinerDad It is kind of based off of http://irc.minetest.ru/minet​est-dev/2014-12-14#i_4064070. I understood that to me that these interfaces were solely for this class.
05:29 kahrl yeah the main motivation is to reduce header dependencies, but allowing other implementations of the interface is a side benefit
05:29 kahrl this benefit is not used currently but there is no reason to prevent it from being used in the future
05:30 MinerDad I can remove the line, then.
05:40 Garmine joined #minetest-dev
06:01 RealBadAngel hi
06:01 RealBadAngel does feature freeze apply to #1971 or not?
06:01 ShadowBot https://github.com/minetest/minetest/issues/1971 -- Enable shaders for CAOs. by RealBadAngel
06:02 hmmmm that commit is on the edge between a new feature and a bugfix
06:03 hmmmm it's pretty trivial though so i'd have to say it's allowed
06:03 hmmmm i just had a look
06:04 jin_xi joined #minetest-dev
06:04 hmmmm i really wish you didn't store the entire gamedef just to get the IShaderSource
06:05 hmmmm oh well, it already seems to be passed to the constructor of that class...
06:06 hmmmm whatever happened to separation of concerns?  seems to me that IGameDef was just a way to easily recycle the game state and not so much a heirarchical thing
06:06 RealBadAngel somehow that class is used way before the game starts
06:07 hmmmm so what happens if gamedef is null
06:08 RealBadAngel it is used then to register CAOs types
06:09 hmmmm no, it crashes
06:09 hmmmm that's what happens
06:09 hmmmm you have my approval pending this fix
06:17 OldCoder joined #minetest-dev
06:26 blais3 joined #minetest-dev
06:26 jin_xi_ joined #minetest-dev
06:33 OldCoder joined #minetest-dev
06:41 Hunterz joined #minetest-dev
06:44 sol_invictus joined #minetest-dev
07:06 paramat left #minetest-dev
07:30 Megaf joined #minetest-dev
08:01 kilbith joined #minetest-dev
08:14 kilbith joined #minetest-dev
08:21 MinerDad joined #minetest-dev
09:19 Amaz joined #minetest-dev
09:27 Anchakor_ joined #minetest-dev
09:40 celeron55 hmmmm: not using global state in a game tends to cause unnecessary headache when programming, but C-style global state is bad because you can't have multiple instances of it if you want to; the gamedef is basically a global state that can be copied and it offers other flexibility too by being an abstract class
09:40 celeron55 i mean, not really copied but... like, having multiple ones and edited ones of it if needed
10:26 ImQ009 joined #minetest-dev
10:30 kilbith joined #minetest-dev
10:45 Anchakor_ joined #minetest-dev
10:55 shmancelot joined #minetest-dev
10:56 proller joined #minetest-dev
10:57 kilbith joined #minetest-dev
11:10 MinerDad joined #minetest-dev
11:15 proller joined #minetest-dev
11:15 selat joined #minetest-dev
11:24 PilzAdam joined #minetest-dev
11:32 kaeza joined #minetest-dev
11:39 FR^2 joined #minetest-dev
12:27 exio4 joined #minetest-dev
12:37 mfw joined #minetest-dev
12:56 exio4 joined #minetest-dev
12:57 kaeza joined #minetest-dev
12:57 exio41 joined #minetest-dev
13:41 ImQ009 joined #minetest-dev
14:28 electrodude512 joined #minetest-dev
14:43 MinerDad joined #minetest-dev
14:45 ImQ009 joined #minetest-dev
14:48 hmmmm joined #minetest-dev
14:48 celeron55 joined #minetest-dev
14:58 jin_xi joined #minetest-dev
15:05 shadowzone joined #minetest-dev
15:06 electrodude512 joined #minetest-dev
15:09 proller joined #minetest-dev
15:42 MinetestForFun joined #minetest-dev
15:44 MinetestForFun joined #minetest-dev
16:11 msanchez joined #minetest-dev
16:15 electrodude512 joined #minetest-dev
16:21 msanchez hi there, is there anyone with 2 min to take a look to this issue: https://github.com/minetest/minetest/issues/1976?
16:21 proller joined #minetest-dev
16:21 msanchez As far as I can tell the taskbar does not display the "Minetest" text, nor the icon, and it seems to be related to WM_CLASS not being set
16:31 neoascetic joined #minetest-dev
16:55 electrodude512 joined #minetest-dev
16:55 swaaws joined #minetest-dev
16:56 Calinou joined #minetest-dev
17:23 iqualfragile joined #minetest-dev
17:31 roniz joined #minetest-dev
17:32 proller joined #minetest-dev
17:32 NakedFury joined #minetest-dev
17:32 HoloIRCUser4 joined #minetest-dev
17:33 Hunterz joined #minetest-dev
17:40 HoloIRCUser5 joined #minetest-dev
17:42 iqualfragile_ joined #minetest-dev
17:43 rubenwardy joined #minetest-dev
17:49 proller joined #minetest-dev
17:51 Krock joined #minetest-dev
17:53 hmmmm hrmmm, I don't see this problem at all on Xfce
17:54 msanchez hmmmm: but in XFCE you don't see "Minetest" in the taskbar, but "Minetest [Main Menu", right?
17:55 msanchez that suggests to me that the WM is just picking the title of the window
17:55 hmmmm perhaps, yeah
17:55 msanchez in GNOME Shell / Unity you expect to see just "Minetest" and the proper icon, as specified in the minetest.desktop file
17:55 msanchez so that's why WM_CLASS has to match the filename of the .desktop file
17:56 msanchez I've tried in LXDE and XFCE already, that's why I know that :)
17:56 hmmmm indeed, xwininfo -wm shows no hints
17:57 msanchez so, I think the solution would probably be to do something like what SuperTuxKart does, only for Linux
17:59 hmmmm yup, I see, XSetClassHint
17:59 hmmmm set both name and class
18:00 HoloIRCUser5 In unity I only see the window without a border or title
18:01 msanchez #if defined(__linux__) && !defined(ANDROID)
18:01 msanchez // Set class hints on Linux, used by Window Managers.
18:01 msanchez const video::SExposedVideoData& videoData = m_video_driver
18:01 msanchez ->getExposedVideoData();
18:01 msanchez XClassHint* classhint = XAllocClassHint();
18:01 msanchez classhint->res_name = (char*)"SuperTuxKart";
18:01 msanchez classhint->res_class = (char*)"SuperTuxKart";
18:01 msanchez XSetClassHint((Display*)video​Data.OpenGLLinux.X11Display,
18:01 msanchez videoData.OpenGLLinux.X11Window,
18:01 msanchez classhint);
18:01 msanchez XFree(classhint);
18:01 msanchez #endif
18:01 msanchez hmmmm: that's the bit from SuperTuxCart
18:01 hmmmm yeah, we got that
18:02 hmmmm but you should pastebin the next time you're pasting over three lines in the channel...
18:02 msanchez oops, sorry about that :(
18:07 hmmmm sort of wondering how this works with Gallium
18:12 msanchez hmmmm: would it be ok to use a similar approach here (using Xlib, for linux)?
18:13 hmmmm i'd like to get it actually working first
18:13 rubenwardy https://github.com/minetest/forum​.minetest.net_template1/issues/2
18:14 msanchez fwiw, forcing the WM_CLASS string with 'xprop -name "Minetest [Main Menu]" -format WM_CLASS 8s -set WM_CLASS "Minetest"' gets it "working" for me
18:14 hmmmm really wish xlib's documentation specified the return types and error codes
18:14 msanchez not sure that's what you meant, though
18:16 hmmmm after running that command, xwininfo -wm still tells me that there are no window hints defined
18:18 msanchez same here
18:18 msanchez but if I run xprop -name "Minetest [Main Menu]" I can see the WM_CLASS string defined
18:19 hmmmm but you claim it 'works'?
18:19 msanchez it does
18:19 msanchez yes
18:19 msanchez I don't just claim it, I can see it
18:19 msanchez let me get a screenshot
18:20 hmmmm alright, i see it too that way
18:20 hmmmm but if it's set programatically, I see two "Minetest"s
18:21 zat joined #minetest-dev
18:21 hmmmm msanchez, could you load up SuperTuxCart and inspect the xprop output for that window?
18:21 msanchez sure
18:22 ImQ009 joined #minetest-dev
18:22 msanchez hmmmm: http://pastebin.com/dGcLzuNu
18:23 hmmmm yep, the first string is the WM_NAME prop
18:23 hmmmm funny thing is that it doesn't seem like you can set one thing but not the other with XSetClassHint
18:23 msanchez see the before and after running that xprop command over the minetest window:
18:23 msanchez http://pastebin.com/r1iNZiVs
18:25 hmmmm can irrlicht be run on unix platforms without Xorg?
18:25 hmmmm i.e. wayland
18:25 msanchez and the associated screenshot: https://dl.dropboxusercontent.com/u/1381​586/minetest-issue-fixed-with-xprop.png
18:26 msanchez no idea, we can ask on #irrlicht I guess
18:29 roniz joined #minetest-dev
18:31 FR^2 joined #minetest-dev
18:33 msanchez I've just asked there, and it seems the answer is no, unless you want to use irrlicht just as a server or with the ascii renderer :)
18:36 hmmmm hrm
18:36 hmmmm i'm trying to figure out how to handle the case of __APPLE__ defined but it has no xorg
18:40 Calinou msanchez, that's sad :(
18:40 Calinou is Wayland support planned?
18:40 HoloIRCUser6 joined #minetest-dev
18:42 shadowzone joined #minetest-dev
18:44 msanchez no idea. To be honest I didn't even know what irrlicht was until today :)
18:45 Calinou ask them
18:48 hmmmm https://github.com/kwolekr/minetest/commit​/446af6f5365084490b5eb9ae117c1a4dfc0b9f81
18:48 msanchez Calinou: done, and the answer is "no, but i guess it's still pretty early"
18:48 Calinou Fedora offers a Wayland option ;)
18:48 msanchez seems that they are not very concerned about that while KDE does not support it
18:49 msanchez that's right, yes
18:52 hmmmm rather, how about this one https://github.com/kwolekr/minetest/commit​/8661b3587b4854f18f747a5577d0bb62998e569d
18:52 domtron joined #minetest-dev
18:52 hmmmm didn't mean to hard code "Minetest" ni
18:53 msanchez hmmm: :)
18:53 hmmmm well
18:54 hmmmm i guarantee somebody's going to complain about how minetest doesn't compile for them since i added this because of their wonky setup
18:54 hmmmm pushing to upstream if there aren't any complaints...
18:54 * msanchez reads
18:55 hmmmm welp
18:55 hmmmm forever hold your peace
18:57 msanchez with my limited knowledge of the codebase I guess it's fine
18:58 hmmmm we have a policy that 2 other developers need to approve a commit before it gets pushed to upstream
18:58 hmmmm it's really inconvenient though
18:58 msanchez still, I think it would be cleaner to have both the whole definition of setXortClassHint inside the #ifdef
18:59 hmmmm if I did that, then I would need to move the #define into porting.
18:59 hmmmm porting.h
18:59 hmmmm and if I did that, then it wouldn't work because win32.h doesn't get included until after porting.h does
19:00 hmmmm and then after i messed with the order of includes, i'd need to add #ifdefs around the call inside of main.cpp
19:00 hmmmm so, how much preprocessor messiness do you really prefer?
19:01 pro joined #minetest-dev
19:01 msanchez I'm not a minetest dev, so I'm fine with either option
19:01 msanchez just pointing it out because from a less-informed perspective it seemed strange to me to have an Xorg dependant function visible to all the ports :)
19:02 hmmmm #ifdef implies something is platform specific
19:02 hmmmm the whole point of having a porting.cpp and porting.h is to abstract away platform specific things
19:02 msanchez yes, that's why I would not see it as dirty to have an #ifdef in main.cpp, when calling a platform specific func
19:03 hmmmm so to have a porting.cpp and porting.h, but then include #ifdef in code outside of the porting source files seems to defeat the purpose
19:03 msanchez oh! that's right too
19:03 msanchez maybe is the name of the function what's messing up with my brain
19:03 hmmmm i hope people would figure out that probably doesn't do anything if xorg isn't on the system
19:04 msanchez although I would not know how to call it otherwise: setAppNameForWM()?
19:04 hmmmm otherwise i could just rename it to setXorgClassNameIfXorgSupported
19:04 hmmmm nope, because that implies it does things for all platforms
19:04 hmmmm that function does nothing in windows though, e.g.
19:04 msanchez it would be a no-op in other platforms :)
19:04 hmmmm setting the app name in windows is done in CreateWindow by irrlicht though
19:05 hmmmm so that'd be a lie
19:05 msanchez ok then, I can't really complain anyway, as I said before
19:05 msanchez I'm not a minetest developer and, at the same time, you just fixed a problem I reported in a matter of a few hours
19:05 * msanchez shuts his mouth up :)
19:06 hmmmm how quickly issues get resolved highly depends on which person sees it
19:08 electrodude512 joined #minetest-dev
19:12 msanchez hmmm: btw, I just applied your patch locally and can confirm it fixes the issue
19:19 msanchez I've just updated the issue with a comment: https://github.com/minetest/minetest/issues/1976
19:19 msanchez now off for dinner
19:21 Wuzzy joined #minetest-dev
19:21 GrimKriegor joined #minetest-dev
19:34 neoascetic joined #minetest-dev
19:38 Wuzzy joined #minetest-dev
19:38 Wuzzy hey, somewhere around line 2393 in lua_api.txt it says PseudoRandom can be 6553 at max
19:38 Wuzzy Are you sure its not 65535?? lol
19:40 Krock ^ iz ushort max
19:41 Wuzzy Was that a yes or a no? ;)
19:41 Wuzzy quote:
19:42 Wuzzy (max - min) must be 32767 or <= 6553 due to the
19:42 Krock pseudorandom has its limit somewhere at 65550, yes
19:42 Wuzzy simple implementation making bad distribution otherwise.
19:43 Wuzzy I am rewriting lua_api.txt to Markdown format and stumpled upon this.
19:43 Calinou fix typos if you find them, I guess that's OK
19:43 Wuzzy and I thought, while I am it, apply some fixes
19:43 Calinou there are at least 10 typos in lua_api.txt
19:43 Calinou or inconsistencies
19:43 Wuzzy ok then I assume its 65535
19:44 Wuzzy and omg this was like a shitton of work
19:44 Wuzzy I am practically done, I just make the final checks
19:45 HoloIRCUser5 joined #minetest-dev
19:48 domtron joined #minetest-dev
19:48 Wuzzy joined #minetest-dev
19:49 rubenwardy Wuzzy: https://github.com/rubenwardy/mtluaapi
19:49 Wuzzy Whyyyy
19:49 rubenwardy Not done
19:49 rubenwardy Just continue with yours
19:49 rubenwardy Calinou and I started it
19:49 Wuzzy whatever.
19:50 rubenwardy The one needs updating to latest git changes, probably
19:50 Wuzzy converting this file to markdown was a lot of work, but it was totally worth it.
19:50 rubenwardy Good luck Wuzzy, it really needs it
19:50 rubenwardy Have you done it?
19:50 Wuzzy oh, I didn’t use any of that GitHub-flavor bullshit
19:50 Wuzzy yes
19:50 Wuzzy just normal Markdown
19:50 rubenwardy Excellent
19:51 rubenwardy If a lua_api.md PR gets rejected, just supply a lua_api.txt with MD formatting - it is better than nothing.
19:51 rubenwardy Thank you so much
19:52 Wuzzy I just post lua_api.txt first and then I see if .md suffix is requested =)
19:54 rubenwardy Excellent
19:56 rubenwardy Maybe one day we will finally be able link to the lua_api without worrying about line numbers
19:57 Wuzzy lol
19:57 Wuzzy I just checked the diff
19:57 Wuzzy lol, almost every line is either red or green
19:57 Amaz joined #minetest-dev
19:57 Wuzzy only a few remain unchanged
19:57 Wuzzy okay I will make PR any moment now.
19:57 rubenwardy #Rewrite
19:58 Wuzzy ?
19:58 rubenwardy Oh no. Shoot me. I used a hashtag.
19:58 rubenwardy And I meant to say #AbsoluteRewrite
19:58 rubenwardy Nevermind.
20:01 sebastia joined #minetest-dev
20:08 Wuzzy The Markdown PR: https://github.com/minetest/minetest/pull/1977
20:09 Calinou already? :o
20:13 blaise joined #minetest-dev
20:20 celeron55 Wuzzy: 6553 is not a typo
20:20 Wuzzy shit
20:20 celeron55 don't go soloing if you don't know what you're doing 8)
20:27 PilzAdam Wuzzy, https://github.com/Wuzzy2/minetest/b​lob/9002cb419e7dee69acf3f7dcd6d35d44​48d361a3/doc/lua_api.txt#L475-L500 I would use a list here
20:28 Wuzzy its a code block
20:29 PilzAdam its a list of drawtypes
20:31 Kray joined #minetest-dev
20:31 Guest76227 joined #minetest-dev
20:32 johnnyjoy joined #minetest-dev
20:32 PilzAdam why do you put comment blocks in the definition tables at the bottom?
20:32 PilzAdam it's not supposed to be valid Lua syntax anyway
20:32 HoloIRCUser4 joined #minetest-dev
20:34 kaeza funny how "nodebox" drawtype is still labeled "experimental" implying they are not stable or well tested, after what, 2, 3 years?
20:36 Amaz Well they don't really exist anymore :P
20:36 Amaz Converted to meshes on load.
20:43 Wuzzy PilzAdam: because it is more readable
20:52 VanessaE guys, what's the story with the visual_scale parameter on plantlike draw type?
20:52 VanessaE https://github.com/VanessaE/​plantlife_modpack/issues/25
20:52 VanessaE am I, or am I not patching around an engine bug here?
20:53 VanessaE someone please solve this or comment on that bug report.
20:54 domtron joined #minetest-dev
20:54 PilzAdam VanessaE, AFAIK it wasn't change intentionally
20:55 VanessaE PilzAdam: I didn't expect so, but I can't seem to get ANYONE to actually DO anything about it, and it needs fixed before 0.4.11 goes out
20:56 PilzAdam create an issue on github, ask somebody to mark it as blocker
20:56 VanessaE I've discussed it with RBA since it happened when he fiddled with the positioning of plants, but I guess he hasn't the time to look into it
20:57 HoloIRCUser7 joined #minetest-dev
20:58 VanessaE https://github.com/minetest/minetest/issues/1978
20:58 HoloIRCUser4 joined #minetest-dev
20:59 PilzAdam added some labels
20:59 VanessaE thanks
21:02 celeron55 joined #minetest-dev
21:02 ImQ009 joined #minetest-dev
21:03 deltib joined #minetest-dev
21:07 blaise joined #minetest-dev
21:08 JZTech101 joined #minetest-dev
21:14 swaaws joined #minetest-dev
21:15 OldCoder joined #minetest-dev
21:15 OldCoder joined #minetest-dev
21:17 cg72 joined #minetest-dev
21:18 cg72 left #minetest-dev
21:21 n4x joined #minetest-dev
21:29 Wayward_One joined #minetest-dev
21:29 roniz_ joined #minetest-dev
21:36 electrodude512 joined #minetest-dev
22:18 ErronousNickname joined #minetest-dev
22:21 eeew joined #minetest-dev
22:28 ErronousNickname Hello humans. Webpage says, communication is more important than I think, therefore I'm here. I have yet to think myself into the code but one thing that I think is important is to make crafting/inventories more convenient with things like moving a stack from one part of the inventory to another with one (shift?-)click or "drawing" a shape in the crafting grid to evenly split up a stack for a reciepe (like when you want to make
22:28 kilbith joined #minetest-dev
22:30 VanessaE ErronousNickname: "...want to make--"
22:30 VanessaE got cut off.
22:30 VanessaE however such a feature exists
22:31 VanessaE you can right click to grab some items, then right click again and hold the button to "paint" those items into empty inventory/crafting slots as you move the stack around
22:31 ErronousNickname Aha! Good to know :)
22:34 ErronousNickname But this way it's still not so easy to craft high quantities. To craft 99 sticks into ladders you would still have to paint the ladder 14 times.
22:35 msanchez_afk joined #minetest-dev
22:35 VanessaE I see what you mean
22:36 VanessaE I'll see if I can catch zeno and ask him about that, he might have an idea how to implement it
22:37 VanessaE something like shift+(paint action) --> distribute the whole held stack equally among all the targets of the "paint" action  ?>
22:40 jin_xi joined #minetest-dev
22:40 ErronousNickname yes. But I might even find a solution myself
22:42 VanessaE kahrl: *poke*
22:58 kaeza in MC, "painting" with RMB transfers one item per slot; LMB distributes the stack in the slots, leaving the rest "grabbed" (i.e. you paint 6 slots with a stack of 15, it transfers 2 items to each one, and leaves 3 in hand)
22:59 kaeza maybe it could be done so that painting with MMB distributes stacks of 10 (like MMB clicking does)
22:59 VanessaE that might work.
23:04 ErronousNickname I think the LMB in MC very useful and I'd be trying to get that working.
23:35 domtron joined #minetest-dev
23:49 ErronousNickname I only changed guiFormSpecMenu.cpp and make rebuilds everything? o_O
23:53 Tesseract ErronousNickname: No, it should only rebuild that file and the version file.
23:55 ErronousNickname hmm, something's wrong then.

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