| 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/minetest-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/minetest-dev/2014-12-14#i_4064118 and http://irc.minetest.ru/minetest-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/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. |
| 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*)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 |
|
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/1381586/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/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: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. |
