Time |
Nick |
Message |
00:00 |
sovetskiy |
thanks |
00:02 |
|
shymega joined #minetest |
00:04 |
o11c |
sovetskiy: if you really want to use all your own mods, at least borrow bits of their code - open source is a thing for a reason |
00:08 |
sovetskiy |
I don't want to share my code. Relax. My mods for me only |
00:09 |
|
EvergreenTree joined #minetest |
00:17 |
|
nowhere_man joined #minetest |
00:32 |
|
lumberJ joined #minetest |
00:38 |
|
Sokomine joined #minetest |
00:42 |
|
EvergreenTree joined #minetest |
00:55 |
|
wilkgr joined #minetest |
00:57 |
orbea |
concerning that meshnode crash, we have a reliable test world to reproduce the crash now. https://github.com/stujones11/meshnode/issues/6#issuecomment-341600300 |
00:57 |
orbea |
crashes every time maybe 30 seconds |
00:57 |
orbea |
maybe amount of distance traveled? |
01:18 |
|
EvergreenTree joined #minetest |
01:22 |
|
Tmanyo joined #minetest |
01:22 |
|
ssieb joined #minetest |
02:00 |
orbea |
backtrace of meshnode crash with git version https://pastebin.com/j1HUq5aT |
02:00 |
orbea |
https://github.com/stujones11/meshnode/issues/6#issuecomment-341606980 |
02:17 |
|
Tux[Qyou] joined #minetest |
02:29 |
Calinou |
bigfoot547: "make clean" to clean all build files |
02:29 |
Calinou |
do this before switching versions, or to ensure a clean build |
02:29 |
Calinou |
to force recreation of CMake files: rm CMakeCache.txt |
02:29 |
Calinou |
no |
02:52 |
|
XeonSquared joined #minetest |
03:10 |
|
Hawk777 joined #minetest |
03:10 |
|
wilkgr joined #minetest |
03:11 |
|
Billre left #minetest |
04:15 |
|
AlexYst joined #minetest |
04:24 |
|
AlexYst joined #minetest |
05:08 |
|
soloojos joined #minetest |
06:40 |
|
xerox123 joined #minetest |
06:55 |
|
silent_elk joined #minetest |
07:02 |
|
frostsnow joined #minetest |
07:07 |
|
wilkgr joined #minetest |
08:25 |
|
Telesight joined #minetest |
08:27 |
|
nowhere_man joined #minetest |
08:32 |
|
Darcidride joined #minetest |
08:39 |
|
troller joined #minetest |
08:50 |
|
dabbill joined #minetest |
08:52 |
|
YuGiOhJCJ joined #minetest |
08:53 |
|
ensonic joined #minetest |
08:55 |
|
Fritigern joined #minetest |
09:27 |
|
ensonic joined #minetest |
09:35 |
|
troller joined #minetest |
09:41 |
|
asl97 joined #minetest |
09:43 |
|
Jousway joined #minetest |
10:18 |
|
nowhere_man joined #minetest |
10:23 |
|
troller joined #minetest |
10:25 |
|
YuGiOhJCJ joined #minetest |
10:35 |
|
Fixer joined #minetest |
10:41 |
|
troller joined #minetest |
11:07 |
|
troller joined #minetest |
11:14 |
|
nac joined #minetest |
11:20 |
|
NathanS21 joined #minetest |
11:28 |
|
Krock joined #minetest |
11:33 |
|
nowhere_man joined #minetest |
11:37 |
|
CWz joined #minetest |
11:39 |
|
deltasquared joined #minetest |
11:48 |
|
Fritigern joined #minetest |
12:18 |
Calinou |
bigfoot547: you need to recompile Minetest using "make" after doing "make clean" |
12:18 |
Calinou |
although "sudo make install" compiles if needed, IIRC |
12:18 |
Calinou |
(but it compiles as root, which isn't great for security and permission handling) |
12:19 |
deltasquared |
pretty sure the standard pattern is "make && sudo make install" |
12:21 |
|
EvergreenTree joined #minetest |
12:28 |
|
Wuzzy joined #minetest |
12:30 |
Calinou |
yeah |
12:30 |
Calinou |
or "make -j$(nproc) && sudo make install" :P |
12:33 |
deltasquared |
Calinou: hmm, I'm used to build systems that can sanely handle multi-threading safely by default |
12:34 |
deltasquared |
make can be easy to get dependencies wrong with |
12:45 |
|
Jordach joined #minetest |
12:53 |
|
ensonic joined #minetest |
13:04 |
|
RobbieF joined #minetest |
13:04 |
|
RobbieF joined #minetest |
13:05 |
|
RobbieF left #minetest |
13:24 |
|
Billre joined #minetest |
13:35 |
|
antims joined #minetest |
14:20 |
|
deltasquared joined #minetest |
14:25 |
|
Enricoo joined #minetest |
14:26 |
|
Telesight joined #minetest |
14:29 |
|
Enricoo joined #minetest |
14:35 |
|
CalebDavis joined #minetest |
14:37 |
|
Tux[Qyou] joined #minetest |
15:28 |
|
twoelk joined #minetest |
15:36 |
|
nac joined #minetest |
15:36 |
|
SanskritFritz joined #minetest |
15:45 |
|
proller joined #minetest |
16:06 |
|
paramat joined #minetest |
16:17 |
|
proller joined #minetest |
16:28 |
MinetestBot |
[git] paramat -> minetest/minetest_game: Binoculars: Only set property if necessary to reduce mesh reloading 08c60cf https://git.io/vFcet (2017-11-03T16:26:00Z) |
16:28 |
MinetestBot |
[git] paramat -> minetest/minetest_game: Player model: Remove vertical stretch of body and limbs, remove cape 9596d00 https://git.io/vFceq (2017-11-03T16:25:54Z) |
16:39 |
jas_ |
i'd love to be able to crouch in minetest. that'd be sweet. |
16:42 |
|
nowhere_man joined #minetest |
16:48 |
|
coffee joined #minetest |
16:48 |
|
coffee left #minetest |
16:50 |
|
H4mlet joined #minetest |
16:59 |
|
nowhereman joined #minetest |
17:19 |
|
QwertyDragon joined #minetest |
17:22 |
|
troller joined #minetest |
17:48 |
|
GreenDimond joined #minetest |
17:49 |
GreenDimond |
xpanes.register_pane seems to ignore `paramtype = "light",` and `light_source = bla` |
17:55 |
GreenDimond |
is there any way to get it to work? |
18:00 |
Krock |
modify xpanes |
18:01 |
Krock |
or overwrite the node definition after calling register_pane |
18:01 |
GreenDimond |
how do I overwrite the def? |
18:03 |
Krock |
in your mod |
18:03 |
GreenDimond |
I know, but what function do I use? |
18:03 |
Krock |
minetest.override_item("node name", { new def}) |
18:04 |
Krock |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L2429 |
18:04 |
Krock |
!next |
18:04 |
MinetestBot |
Another satisfied customer. Next! |
18:04 |
GreenDimond |
Ah, thankyou. |
18:04 |
GreenDimond |
I was searching the api for `overwrite` instead of `override` xD |
18:14 |
|
ensonic joined #minetest |
18:30 |
|
paramat joined #minetest |
18:42 |
|
troller joined #minetest |
18:57 |
|
ssieb joined #minetest |
19:13 |
|
sonicpp joined #minetest |
19:14 |
|
GreenDimond joined #minetest |
19:15 |
GreenDimond |
So, I am trying to use `^[transformFX` on a pane texture, but it doesnt seem to work. Using it in an override doesnt work either. |
19:17 |
|
deltasquared joined #minetest |
19:20 |
Krock |
is there any code that could be pasted? |
19:21 |
|
fwhcat joined #minetest |
19:22 |
|
johnnyjoy joined #minetest |
19:22 |
GreenDimond |
not that would help.. |
19:23 |
Krock |
sometimes it can. Are you sure .override_item is called during the mod loading |
19:23 |
Krock |
*? |
19:23 |
GreenDimond |
Yes, because the other things I override work. The reason the override doesnt work is it doesnt like def.texture |
19:24 |
GreenDimond |
I figured out I had to define def first |
19:24 |
GreenDimond |
but then it still wouldnt take the texture |
19:28 |
Krock |
minetest.override_item("mod:node", { tiles = "default:dirt^[transformFX" }) should work just fine o.o |
19:28 |
GreenDimond |
Krock: Here is the code https://gist.github.com/GreenXenith/d7ad9ccc1c82a4bdd51e01a18140bd64 |
19:28 |
GreenDimond |
well theres a problem with that |
19:28 |
GreenDimond |
the pane function changes tiles to def.textures |
19:28 |
GreenDimond |
so `tiles = {def.textures[3], def.textures[3], def.textures[1]},` |
19:30 |
GreenDimond |
overriding that in the def doesnt work if I use tiles for some reason |
19:33 |
Krock |
why don't you override "xpanes:lights_"..nodename.."_pane_flat" ? |
19:34 |
Krock |
is that not an issue? |
19:34 |
|
RedSoxFan07 joined #minetest |
19:39 |
|
LazyJ joined #minetest |
19:44 |
GreenDimond |
Krock: Sorry, was talking to someone. I do override the flat one. Or... wait. No I dont :o That might be helpful.. |
19:45 |
Krock |
Don't worry. IRC is a place where answers can take hours |
19:46 |
Fixer |
days |
19:46 |
Fixer |
or even eternity |
19:48 |
deltasquared |
is there a way I can get MT to more strictly control the memory it uses? it's getting killed from OOM related errors currently just by wandering around on a server. |
19:48 |
deltasquared |
it appears to be keeping the world in RAM and not evicting old chunks. |
19:48 |
deltasquared |
(dunno if local world saving would alleviate this) |
19:49 |
Krock |
remove luajit or ensure it's a x64 build |
19:49 |
deltasquared |
it's a 64-bit build, removing luajit would not make a difference when it's client only methinks |
19:49 |
deltasquared |
this is like 3.5GB we're talking here when it OOMs, nearly all of my system RAM |
19:49 |
Krock |
ah I see. Client non-luaJIT OOM - one of the less popular cases |
19:50 |
deltasquared |
so, it's known about? |
19:50 |
Krock |
also happens to me when using a 2048px texture pack |
19:50 |
Krock |
you can reduce the amount of cached blocks client-side |
19:50 |
deltasquared |
Krock: oh yeah? |
19:51 |
deltasquared |
*looks at advanced options* |
19:51 |
Krock |
and also a lower texture pack resolution, which helps quite much |
19:51 |
GreenDimond |
Krock: Overriding the _flat pane to set the tiles makes the front faces blank and gives the top a texture (both of which I dont want) |
19:51 |
deltasquared |
the fact that I have to set that manually kinda sucks though. |
19:51 |
deltasquared |
Krock: I'm only on 16x textures here |
19:51 |
Krock |
GreenDimond, at least something happens |
19:51 |
GreenDimond |
Yeah but it makes no sense |
19:51 |
|
KrimZon_2 joined #minetest |
19:52 |
Krock |
deltasquared, okay, that's strange. Are there any heavy mods like mobs or music-playing ones? |
19:52 |
deltasquared |
Krock: no, this is a lightweight sever |
19:52 |
deltasquared |
*server. |
19:52 |
deltasquared |
VE-building, to be precise |
19:52 |
deltasquared |
it definitely happens as I explore the world more |
19:52 |
Krock |
*checks whether there are VE-lightweight servers* |
19:53 |
Wuzzy |
"Minetest: Because blocks want to be free." |
19:53 |
deltasquared |
RAM is reasonable when I initially join and the world loads, but it only increases from there as I wander |
19:53 |
deltasquared |
Krock: point is, what's that option called, I just want MT to kick out old chunks when they're not visible |
19:53 |
deltasquared |
I don't think it's a memleak somewhere else as it doesn't continue to increase when I stand still. |
19:54 |
deltasquared |
... aha, client_mapblock_limit? |
19:54 |
Krock |
https://github.com/minetest/minetest/blob/master/minetest.conf.example#L1011 |
19:54 |
deltasquared |
it's set to 5000, ouch |
19:55 |
Krock |
see also: client_unload_unused_data_timeout = 600 |
19:55 |
deltasquared |
I'm suprised these aren't set to something more conservative by default |
19:55 |
GreenDimond |
Because by default most devices can handle it |
19:55 |
Krock |
10 minutes and 5000 blocks are hard to reach |
19:55 |
paramat |
5000 is not a big volume |
19:56 |
paramat |
it's only 266 nodes ^ 3 |
19:56 |
paramat |
so what you see with view range 133 |
19:56 |
paramat |
roughly |
19:57 |
paramat |
the amount of RAM 500 blocks uses depends on mesh complexity |
19:57 |
deltasquared |
paramat: mapblock suggests chunks though |
19:57 |
paramat |
*5000 |
19:58 |
paramat |
no |
19:58 |
paramat |
mapchunk is not a mapblock |
19:58 |
deltasquared |
huh, I was under the impression that mapblock meant chunks in the engine |
19:58 |
paramat |
block = 16 ^ 3 nodes |
19:58 |
paramat |
chunk = 5 ^ 3 blocks by default |
19:59 |
deltasquared |
paramat: ah, I had always used chunks in the MC sense |
19:59 |
paramat |
argh |
19:59 |
deltasquared |
so I guess I *should* call them mapblock just to to be sure |
20:00 |
Krock |
<paramat> it's only 266 nodes ^ 3 |
20:00 |
Krock |
moment.. I have to do the math |
20:00 |
deltasquared |
interesting, I'm setting it to 1024 and the timeout to 30 and now I'm getting segfaults not long after joining a server |
20:01 |
Krock |
yes, matches quite well. It's just that servers only rarely send blocks that far away |
20:04 |
paramat |
timeout too low is bad, unnecessary resends of blocks |
20:04 |
paramat |
maybe 300 5mins |
20:05 |
deltasquared |
paramat, right fine. still getting interesting crashes now though |
20:05 |
GreenDimond |
Krock: So, what do you figure I should do? |
20:07 |
Krock |
GreenDimond, uh.. let me check it myself |
20:07 |
deltasquared |
ok wat, now I'm getting zlib deflate errors? |
20:09 |
deltasquared |
welp now I'm getting segfaults all over the place |
20:11 |
deltasquared |
“compressZlib: deflateInit failed†|
20:11 |
deltasquared |
... |
20:14 |
sy |
sounds fun! |
20:15 |
deltasquared |
I find it hard to believe all this weirdness started just as a result of disabling overcommit on my system |
20:15 |
deltasquared |
there's still memory *free* when this stuff happens |
20:16 |
Krock |
GreenDimond, https://pastebin.com/raw/WitZiLKS .. works for me. It's shiny and the torch is animated |
20:17 |
deltasquared |
oh yeah, that's another thing, minetest doesn't let go of the memory it takes up while in-game - go on VE-building, goes up to around 1.5GB. quit and go to a singlenode test world, stays there - but loading that same map from a fresh start only takes up 0.8GB |
20:19 |
deltasquared |
(includes other processes running but the relative gap should be apparent) |
20:19 |
Krock |
roughly 300 MiB use in my singleplayer world |
20:20 |
twoelk |
deltasquared: are you saving rto local at the same time? |
20:20 |
twoelk |
-r |
20:22 |
* twoelk |
decides to go do some mining |
20:30 |
|
soloojos joined #minetest |
20:30 |
deltasquared |
twoelk: no I am not currently |
20:30 |
deltasquared |
... or did I leave that on, hold on |
20:31 |
deltasquared |
would that help or hinder in this sitation |
20:32 |
deltasquared |
(it had been left on, just gone and turned off) |
20:32 |
twoelk |
any difference in performance? |
20:34 |
deltasquared |
twoelk: still testing, it's not really performance that's the issue |
20:34 |
deltasquared |
the random crashes are :P |
20:34 |
twoelk |
yeah sloopy wording on my side |
20:36 |
deltasquared |
that does seem to have helpd a bit though |
20:36 |
twoelk |
my client sometimes freezes when writting to localdatabase and sometimes crashes if low on memory - might be related or not |
20:36 |
deltasquared |
OOM during DB flush... yeah I could see why that'd be a bit problematic |
20:37 |
deltasquared |
.... aaaand again. |
20:37 |
deltasquared |
it doesn't seem to like me moving around fast that's for sure |
20:40 |
GreenDimond |
arg |
20:40 |
GreenDimond |
why arent texture directions documented anywhere? |
20:40 |
deltasquared |
good question, I was going to draw up like a texture with arrows on so I could figure it out |
20:43 |
deltasquared |
hmm, does MT have any sort of minimum requirement specs list anywhere, I'm wondering if 4GB is considered pushing it |
20:43 |
twoelk |
some like that have been created multiple times, maybe they should be part of minimal for use in testing |
20:44 |
GreenDimond |
oh wait |
20:44 |
GreenDimond |
it is docd |
20:45 |
deltasquared |
GreenDimond: is it in lua_api.txt or elsewhere |
20:45 |
GreenDimond |
yes, api |
20:45 |
GreenDimond |
line 4499 |
20:45 |
deltasquared |
bladdy hell |
20:46 |
deltasquared |
GreenDimond: erm, can you give me a phrase to search for, line numbers tend not to be reliable in my experience |
20:47 |
paramat |
4GB is fine, reducing client mapblock limit should limit RAM use |
20:47 |
GreenDimond |
deltasquared: -Y |
20:47 |
deltasquared |
GreenDimond: ... hrm, I was hoping for something that would indicate facedir directions for each one, but ok |
20:48 |
deltasquared |
paramat: I did, I've set it all the way down at 256. still managing to crash in strange ways though |
20:51 |
paramat |
afaik by far the largest RAM use for a client is the mapblock meshes |
20:51 |
deltasquared |
that would figure |
20:52 |
deltasquared |
I'm just puzzled by these segfaults that are occuring without so much as a peep on stderr |
20:52 |
deltasquared |
I don't feel inclined to muck with a debug build of it at this time in the evening |
20:52 |
o11c |
what's the backtrace at least? |
20:53 |
paramat |
we don't have any client memory leak issues currently reported, afaik |
20:53 |
deltasquared |
o11c: sometimes it doesn't have any whatsoever, like the stack was mangled |
20:53 |
o11c |
run under valgrind? Might be too slow |
20:54 |
o11c |
-fsanitize=address is much faster but requires recompiling |
20:55 |
deltasquared |
o11c: like I said, I won't be trying anything like that this evening, I'm a bit tired now :P |
20:56 |
deltasquared |
relevant part of the log is this - https://ptpb.pw/XU5T.txt and it really is just that one line in the stack trace |
20:57 |
deltasquared |
..oh wait hold on I missed a bit before it |
20:58 |
deltasquared |
https://ptpb.pw/ouG6.txt there ya go |
20:58 |
deltasquared |
crash is happening inside mesa? welp |
21:00 |
deltasquared |
sometimes I wish I didn't have to recompile distro libs on arch just to get sane stack traces |
21:01 |
GreenDimond |
Krock: So, I got the texture to flip, but if I place on pane next to another, the texture flips. |
21:01 |
GreenDimond |
which makes it look weird |
21:02 |
|
troller joined #minetest |
21:04 |
Krock |
GreenDimond, then make it world-aligned |
21:04 |
GreenDimond |
Isn't that a 0.5.0 thing? |
21:04 |
Krock |
^ requires a frsh 0.5.0 client |
21:04 |
GreenDimond |
Yeah no can't do that |
21:06 |
|
RedSoxFan08 joined #minetest |
21:14 |
|
deltasquared joined #minetest |
21:15 |
o11c |
deltasquared: distros should have -dbg or -dbgsym packages |
21:17 |
|
RedSoxFan07 joined #minetest |
21:18 |
deltasquared |
o11c: actually thinking about it, I'm thinking of the wrong thing as you'd still see symbols if the stack was valid, just wouldn't be able to see source code in the debugger |
21:19 |
deltasquared |
... then again, maybe not if not exported. argh. |
21:19 |
deltasquared |
in any case, arch does *not* do sep. debug packages and it doesn't compile with -g or anything like that |
21:20 |
deltasquared |
nor does it do -dev packages... all those little header files included by default hurts FS find performance that's for sure |
21:20 |
sfan5 |
muh fs performance |
21:20 |
sfan5 |
maybe don't install arch if you care about such things |
21:20 |
deltasquared |
sfan5: it's never been an issue thus far... |
21:21 |
|
sovetskiy joined #minetest |
21:21 |
benrob0329 |
Void Linux FTW! |
21:21 |
sovetskiy |
minetest uses Lua v5.1. Right? |
21:21 |
GreenDimond |
Krock: Well it works :D so thanks :D |
21:22 |
Krock |
sovetskiy, 5.1, LuaJIT or anything newer |
21:22 |
Krock |
GreenDimond, ok, nice :) |
21:23 |
sfan5 |
Krock: incorrect |
21:23 |
sovetskiy |
so, there is no "continue" statement. right? |
21:23 |
Krock |
why would one want to use a lower version if the mods might not work with it? |
21:23 |
sfan5 |
highest supported is 5.1 |
21:24 |
Krock |
oh really? I didn't expect API changes on their side |
21:24 |
deltasquared |
sovetskiy: nope, there's no "continue" keyword |
21:24 |
deltasquared |
which annoys me quite a lot |
21:24 |
sovetskiy |
damn! |
21:24 |
sovetskiy |
continue statement is SO useful |
21:24 |
|
ensonic joined #minetest |
21:25 |
deltasquared |
I can't remember where it was I tried to use it, though I do recall having to be somewhat creative to work around it |
21:25 |
Krock |
sovetskiy, there's the trick to use do ... until false (or was it do ... while false?) and break inside |
21:25 |
sfan5 |
there's a few changes that would need backwards compat |
21:25 |
sfan5 |
shadowninja has made prs for 5.2 and 5.3 compat but they were rejected |
21:25 |
Krock |
oh great <.< |
21:26 |
Krock |
well, at least this guarantees that mods will work with LuaJIT |
21:27 |
deltasquared |
I for one would block allowing higher lua versions if it meant luaJIT wouldn't work, it's kinda useful |
21:27 |
sovetskiy |
do...until -- loop inside loop only the sake of termination of current iteration? Idiotic. |
21:29 |
Krock |
it's not about being helpful or not - it works, and actually saves some indents of if-checks |
21:29 |
Krock |
s/helpful/idiotic/ |
21:30 |
sovetskiy |
what about simple "goto" then? |
21:30 |
Krock |
that was added in a newer Lua version which is, what I just learnt, not supported yet |
21:30 |
|
RedSoxFan07 joined #minetest |
21:30 |
sovetskiy |
how long shoudld we wait? |
21:31 |
Krock |
depends whether Mike Pall is going to change his opinion on adapting newer Lua features in his JIT version or not |
21:36 |
sovetskiy |
because of lack of "continue" my code shifting right all the time |
21:36 |
orbea |
hey Wuzzy I checked out the mana, teletool and returnmirror mods, pretty cool. Would you be willing to make the returnmirror and magic teletool craftable even if hidden behind a configuration setting? |
21:37 |
Wuzzy |
no |
21:37 |
orbea |
okay... |
21:39 |
deltasquared |
hmm, /me suspects one misses the intent of a config variable if one asks for it to be bypassed |
21:39 |
deltasquared |
IOW moan at your server operator about it :P |
21:40 |
Krock |
sovetskiy, if there are more than two levels of indents, consider using the loop trick |
21:40 |
orbea |
that is me, I just wanted to know if I could get this fixed in the mod before considering the implications of forking... |
21:40 |
sovetskiy |
do you here link to some article explaining it in details? |
21:41 |
sovetskiy |
s/here/have |
21:44 |
|
guru joined #minetest |
21:44 |
Krock |
uh well.. classic stackoverflow answer: https://stackoverflow.com/questions/3524970/why-does-lua-have-no-continue-statement |
21:45 |
deltasquared |
orbea: well if you're the server owner, you mentioned the config setting, what's up with just using that |
21:46 |
orbea |
deltasquared: there isn't one, there is no recipe in the mod begin with |
21:46 |
orbea |
hence why I was asking it to be added |
21:46 |
orbea |
*mods |
21:47 |
deltasquared |
orbea: no need to fork, just make a mod which depends on it and define your own crafting recipe |
21:47 |
orbea |
actually good point... |
21:47 |
deltasquared |
I've done something similar with a local mod in my singleplayer world to adjust the difficulty. |
21:47 |
orbea |
thanks |
21:48 |
deltasquared |
namely, making travelnet elevators require the use of stainless steel, forcing me to advance somewhat in technic before I get easy teleportation |
21:48 |
orbea |
kind of silly this is needed, but w/e :) |
21:48 |
deltasquared |
*shrug* |
21:48 |
deltasquared |
can't speak for that |
21:48 |
orbea |
yea, it is what it is. |
21:49 |
deltasquared |
right, must dash, rude interruption time |
21:51 |
sovetskiy |
unconvenient. what if I want to really break out that loop? I need double break with temporary flag signaling it |
21:56 |
|
RedSoxFan07 joined #minetest |
22:03 |
|
RedSoxFan07 joined #minetest |
22:08 |
sovetskiy |
what global table or method can get me info about fuels? its names? burntimes? |
22:11 |
Krock |
well, there's minetest.get_all_craft_recipes(query item) |
22:13 |
Krock |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L2932 for reference |
22:15 |
|
troller joined #minetest |
22:21 |
sovetskiy |
no |
22:21 |
sovetskiy |
{ |
22:21 |
sovetskiy |
{ |
22:21 |
sovetskiy |
width = 1, |
22:21 |
sovetskiy |
type = "normal", |
22:21 |
sovetskiy |
items = { |
22:21 |
sovetskiy |
"default:coalblock" |
22:22 |
sovetskiy |
}, |
22:22 |
sovetskiy |
output = "default:coal_lump 9", |
22:22 |
sovetskiy |
method = "normal" |
22:22 |
sovetskiy |
} |
22:22 |
sovetskiy |
} |
22:22 |
sovetskiy |
it is for minetest.get_all_craft_recipes("default:coal_lump") |
22:22 |
sovetskiy |
there is nothing about its burntime |
22:25 |
|
Jousway joined #minetest |
22:32 |
|
Jousway joined #minetest |
23:07 |
|
EvergreenTree joined #minetest |
23:10 |
|
proller joined #minetest |
23:13 |
Wuzzy |
sovetskiy: sounds like a bug |
23:32 |
|
swift110 joined #minetest |
23:34 |
|
grumble joined #minetest |
23:34 |
|
Loquendero joined #minetest |