Time Nick Message 01:50 MinerDad I can't seem to find a use for ItemType::ITEM_CRAFT. Is it still being used somewhere? 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 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: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: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/minetest-dev/2014-12-14#i_4064169 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/minetest-dev/2014-12-14#i_4064118 and http://irc.minetest.ru/minetest-dev/2014-12-14#i_4064123. 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/minetest-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. 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 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 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 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 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 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*)videoData.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 hmmmm msanchez, could you load up SuperTuxCart and inspect the xprop output for that window? 18:21 msanchez sure 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/1381586/minetest-issue-fixed-with-xprop.png 18:26 msanchez no idea, we can ask on #irrlicht I guess 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: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 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 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: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: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: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 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:08 Wuzzy The Markdown PR: https://github.com/minetest/minetest/pull/1977 20:09 Calinou already? :o 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/blob/9002cb419e7dee69acf3f7dcd6d35d4448d361a3/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: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: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 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:58 VanessaE https://github.com/minetest/minetest/issues/1978 20:59 PilzAdam added some labels 20:59 VanessaE thanks 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: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 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 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: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.