Time |
Nick |
Message |
00:13 |
|
OldCoder joined #minetest-dev |
00:19 |
VanessaE |
damn it. |
00:19 |
* VanessaE |
kicks HLuaBot |
00:21 |
* VanessaE |
looks around and discretely sweeps the scattered bolts under the nearest table |
00:28 |
ShadowNinja |
https://github.com/minetest/minetest/pull/1606 |
00:30 |
VanessaE |
"Use require() or anything in the package library (require() and some package functions can load C modules, the rest are only useful if you have access to the other functions)." <--- how will this affect the IRC mod? |
00:36 |
VanessaE |
"This isn't quite ready yet, you can still load bytecode if init.lua is a bytecode file" <--- Is there any legit use case for bytecode files in Minetest? |
00:37 |
|
HLuaBot joined #minetest-dev |
00:37 |
ShadowNinja |
VanessaE: Hiding the source code. |
00:37 |
VanessaE |
besides that. |
00:37 |
VanessaE |
mauvebic is not a legit use case :P |
00:38 |
ShadowNinja |
VanessaE: Super-optimizing things (SoniEx does that). |
00:38 |
VanessaE |
ehm |
00:39 |
ShadowNinja |
You can do things like foo[1]:bar() in bytecode. |
00:39 |
VanessaE |
interesting. |
00:40 |
VanessaE |
frankly I'm not one to suppose closed-source at all but that's not what your pull is about, so better to approach that some other time. |
00:41 |
VanessaE |
s/suppose/support/ |
01:00 |
|
Cylus_ joined #minetest-dev |
01:05 |
|
SoniEx2 joined #minetest-dev |
01:12 |
|
Miner_48er joined #minetest-dev |
02:02 |
|
paramat left #minetest-dev |
02:35 |
|
AnotherBrick joined #minetest-dev |
02:36 |
|
CraigyDavi joined #minetest-dev |
03:06 |
|
OldCoder joined #minetest-dev |
03:28 |
|
sol_invictus joined #minetest-dev |
03:37 |
zat |
Simple deco_types DON'T respect biomes option!!!!!!!!!!!!!!!!!!!! |
03:44 |
gentoobro |
with mapgen v7? |
03:45 |
gentoobro |
they work for me, but there was some strange behavior i found dealing with decorations that were buildable-to combined with 'falling' mg7 dust nodes |
03:45 |
gentoobro |
basically, a dusting of snow or sand would "squash" my grass |
03:46 |
zat |
yes they work you are right lol |
03:46 |
zat |
uh |
03:46 |
zat |
schematics are the real buggy ones |
03:47 |
gentoobro |
i haven't experimented much with those; my plan is to use special placeholder nodes and a one-time abm |
03:47 |
gentoobro |
kind of like moretrees |
03:51 |
zat |
gentoobro: I am doing that right now |
03:57 |
|
zat joined #minetest-dev |
04:07 |
gentoobro |
how's it working out for you? |
04:16 |
|
kaeza joined #minetest-dev |
04:21 |
zat |
gentoobro: horrible |
04:40 |
gentoobro |
:( |
04:51 |
zat |
really, its a ugly hack |
04:55 |
gentoobro |
schematics in general, or this application of them? |
05:03 |
zat |
using normal decos with abms |
05:06 |
|
Zeno` joined #minetest-dev |
05:26 |
|
nore joined #minetest-dev |
07:10 |
|
Hunterz joined #minetest-dev |
07:11 |
|
CraigyDavi joined #minetest-dev |
07:44 |
|
PenguinDad joined #minetest-dev |
07:48 |
|
psedlak joined #minetest-dev |
07:56 |
|
Krock joined #minetest-dev |
08:11 |
|
Megaf joined #minetest-dev |
08:26 |
Zeno` |
what is legacy_mineral? In minetest.register_node() |
08:26 |
Zeno` |
e.g. https://github.com/minetest/minetest_game/blob/master/mods/default/nodes.lua |
08:31 |
Krock |
legacy is to support older worlds |
08:38 |
Zeno` |
So, I guess it doesn't harm if it's left there (will just be ignored) |
08:38 |
Zeno` |
Thanks |
08:48 |
|
Taoki[mobile] joined #minetest-dev |
09:12 |
|
CraigyDavi` joined #minetest-dev |
09:18 |
|
casimir joined #minetest-dev |
09:25 |
Zeno` |
so much fun |
09:39 |
Zeno` |
geez |
09:39 |
Zeno` |
Why didn't he just implement the SIMPLE solution where on_generated callbacks can be ordered? |
09:40 |
Zeno` |
That SOLVED the problem |
09:40 |
Zeno` |
Now there is some problem that nobody seems to even be aware of (well, very few people) |
09:41 |
Zeno` |
I suppose the modern trend is to do it the hard way |
09:41 |
Zeno` |
no K.I.S.S |
09:42 |
Zeno` |
just add crap until it doesn't work hehe |
09:42 |
Zeno` |
obvious solution is obviously no good |
09:49 |
Zeno` |
who peer-reviewed and approved f3eefeb7948b8b8d1a98f2f89baa39abc807f72d, 9e4e7072da8f565eef37da7558053a436b9cbba3 and 3fa4f782d90dac0d800251a9ab0f0afb9d32560c |
09:49 |
Zeno` |
I can't see a pull request |
09:49 |
Zeno` |
I thought 2 core devs had to approve pull requests |
09:52 |
|
T4im joined #minetest-dev |
09:52 |
|
CWz joined #minetest-dev |
10:26 |
|
Benja joined #minetest-dev |
10:31 |
|
Amaz joined #minetest-dev |
11:21 |
|
ImQ009 joined #minetest-dev |
11:38 |
|
OldCoder joined #minetest-dev |
11:41 |
Zeno` |
who peer-reviewed and approved f3eefeb7948b8b8d1a98f2f89baa39abc807f72d, 9e4e7072da8f565eef37da7558053a436b9cbba3 and 3fa4f782d90dac0d800251a9ab0f0afb9d32560c <--- Can these commits be taken out of master? |
11:45 |
Krock |
*reverted |
12:27 |
|
PilzAdam joined #minetest-dev |
12:40 |
sol_invictus |
can anyone give me a hint on why /clearobjects causing pos over limit exception when generation limit is lower than 31000? |
12:41 |
sol_invictus |
I was thinking the cause is the *blocks* over the limit being processed, but it's not |
13:20 |
|
AnotherBrick joined #minetest-dev |
14:00 |
RealBadAngel |
Zeno`, why do you want those commits to be reverted? |
14:10 |
|
proller joined #minetest-dev |
14:36 |
|
NakedFury joined #minetest-dev |
14:38 |
VanessaE |
RealBadAngel: because they broke something about the way vmanips behave, in that they are now causing server crashes |
14:39 |
VanessaE |
ERROR: An unhandled exception occurred: caught (...) |
14:39 |
VanessaE |
[C]: in function 'get_data' |
14:39 |
VanessaE |
stuff like that, unless he's found a new bug, that is. |
14:41 |
casimir |
It's #1607 |
14:43 |
VanessaE |
ok then it's two bugs. |
14:44 |
|
proller joined #minetest-dev |
14:44 |
Krock |
RealBadAngel, one (or more) (or all together) caused a new bug which destroys by-lua-generated terrain |
14:45 |
Krock |
nyan cats are not affected. only VM stuff |
14:54 |
VanessaE |
nice. |
14:55 |
VanessaE |
zeno and I discussed this earlier (in /msg) as well |
14:55 |
VanessaE |
so the crash is something new, related or not idk.. |
15:02 |
|
khonkhortisan joined #minetest-dev |
15:03 |
|
Anchakor_ joined #minetest-dev |
15:33 |
|
sapier joined #minetest-dev |
15:34 |
sapier |
Hello do we have more information about that malformed packet crash? because according to the dump crash happens in send thread not in receive thread? |
15:35 |
VanessaE |
sapier: look closer - there were two crashes - one in the send thread and one in the receive thread. |
15:35 |
VanessaE |
at separate times, on separate servers. |
15:35 |
sapier |
ah |
15:36 |
VanessaE |
I can't confirm if the malformed packets were the cause; all I got from it was that dmesg dump after the fact. |
15:36 |
sapier |
I've already found something wrong if a packet with size 0 is received but I'm not sure how this is supposed to cause a crash |
15:44 |
sapier |
I've pushed the fix, yet I don't really believe this was reason for it |
15:44 |
|
Krock joined #minetest-dev |
15:51 |
sapier |
hmm I don't see any way a empty packet could cause a crash :-( VanessaE if it's still happening can you try to find out what has to happen and how to reproduce? |
15:51 |
VanessaE |
sapier: it's totally random |
15:51 |
VanessaE |
seems like every time that happens, I'm asleep or afk |
15:52 |
VanessaE |
and it may not be network related at all - only reason I highlighted you was that both crashes were preceded by those malformed packets. |
15:53 |
VanessaE |
I had one crash the other day out of the blue that was a sudden, extremely high memory usage (as in, tried to allocate tens of GB all at once) |
15:53 |
VanessaE |
OOM killer caught it |
15:54 |
sapier |
what's size of textures on that server? |
15:54 |
VanessaE |
they're just normal defaults. |
15:54 |
VanessaE |
most are 16px |
15:54 |
VanessaE |
a couple dozen 64px inventory images, that's about it |
15:55 |
sapier |
ok so our known attack most likely wont work |
15:55 |
VanessaE |
(used for stuff where the client can't render the model correctly, that sorta thing) |
15:56 |
VanessaE |
heh, no |
15:56 |
VanessaE |
this was just...a couple guys were digging some stone, probably deep mining or something (I didn't note the coords) and then BAM, the server mem usage shot right off the top of the chart, ran off into swap for a few hundred megs, and the OOM killer nailed it. |
15:57 |
sapier |
that's fit, some memory corruption happening prior allocating memory |
16:02 |
sapier |
question is who does it. Happening in send/receive thread is actually quite logic as those do frequent memory allocations. |
16:06 |
|
hmmmm joined #minetest-dev |
16:09 |
sol_invictus |
I confirm these crashes, had another one today |
16:09 |
sol_invictus |
should I provide the log? |
16:13 |
sapier |
of course, that bug most likely will be hard to track down any piece of information could provide the hint we need |
16:15 |
VanessaE |
hmmmm: you need to address #1607 right away. |
16:15 |
VanessaE |
major regression |
16:15 |
VanessaE |
sol_invictus: I don't suppose you got a gdp backtrace of it? :) |
16:15 |
VanessaE |
gdb* |
16:16 |
sol_invictus |
VanessaE: am I supposed to run the server with gdb? xD |
16:16 |
VanessaE |
sapier: see? ;) |
16:17 |
sapier |
if you can run your server within gdb and reproduce it that could help yes |
16:17 |
sapier |
but if you can reproduce it explaining how to reproduce it would be even better ;-) as there are plenty of ways to use gdb which are quite hard to explain |
16:19 |
sol_invictus |
I wish I knew how to reproduce it |
16:19 |
sapier |
me too ;-) |
16:19 |
sol_invictus |
would higher debug level help tracking it down? |
16:20 |
sapier |
possible but it's still pure luck |
16:20 |
sol_invictus |
maybe I should compile debug version? |
16:20 |
sapier |
right now I guess chances someone finds this bug by accident are as good as us looking for it |
16:20 |
sapier |
yes if you intend to run it in gdb you should do that |
16:21 |
sol_invictus |
okay, will try that when I'm done with some other stuff |
16:23 |
sol_invictus |
sapier: what exactly logstream is? |
16:23 |
sapier |
right now a stream you don't get |
16:23 |
sapier |
I just changed it to errorstream and pushed |
16:23 |
sapier |
uncought exceptions are errors for sure |
16:26 |
|
Sokomine joined #minetest-dev |
16:31 |
sol_invictus |
ok, I hope next time I will get more detiled output |
16:35 |
sol_invictus |
q |
16:35 |
|
sol_invictus left #minetest-dev |
16:39 |
|
sapier left #minetest-dev |
16:43 |
|
sol_invictus joined #minetest-dev |
16:44 |
sol_invictus |
so, anyone can help me on this clearobjects problem? |
16:49 |
VanessaE |
[09-06 08:41] <sol_invictus> can anyone give me a hint on why /clearobjects causing pos over limit exception when generation limit is lower than 31000? |
16:49 |
VanessaE |
wat |
16:50 |
VanessaE |
ok that's just wrong. |
16:50 |
VanessaE |
that should NEVER happen |
16:50 |
VanessaE |
wtf is causing the mapgen to create blocks outside the normal limits? |
16:59 |
sol_invictus |
maybe I explained wrong |
16:59 |
sol_invictus |
I have set #define MAP_GENERATION_LIMIT (15000) |
17:00 |
sol_invictus |
tried to run /clearobjects |
17:00 |
sol_invictus |
got pos over limit |
17:00 |
sol_invictus |
uncaught exception |
17:01 |
sol_invictus |
VanessaE: maybe there is a way to run clearobjects on a particular area, not all loadable blocks? |
17:01 |
VanessaE |
well you can use worldedit to clear selected areas |
17:01 |
VanessaE |
but otherwise that's a bug :) |
17:02 |
sol_invictus |
I tried, but it fails when you select a huge area |
17:02 |
sol_invictus |
even crashes the server iirc |
17:02 |
sol_invictus |
okay, if it's a bug, I shoulld run it with gdb and reproduce it? |
17:03 |
|
zat joined #minetest-dev |
17:03 |
sol_invictus |
because output is not clear in that case either |
17:03 |
Krock |
sol_invictus, where's that mapgen limit defined? |
17:04 |
sol_invictus |
constants.h |
17:04 |
Krock |
kty |
17:13 |
Krock |
This leads me to the following feature request: https://github.com/minetest/minetest/issues/1608 |
17:19 |
sol_invictus |
yeah, that's a surprise it's still not there |
17:20 |
Krock |
possibly because it's a define, so minetest-wide |
17:20 |
sol_invictus |
btw Krock, remote media takes longer than expected, we need to harden our servers first |
17:21 |
sol_invictus |
there is no conf setting as well |
17:22 |
sol_invictus |
which is super easy |
17:30 |
sfan5 |
remote_media takes longer? |
17:31 |
sol_invictus |
adding remote_media takes longer* |
17:36 |
|
davexunit joined #minetest-dev |
17:37 |
davexunit |
hello all. I'm currently working on packaging minetest for the GNU system distribution. |
17:38 |
davexunit |
in order to make minetest's modular subgames work well in the system, I have created a patch that adds support for a MINETEST_SUBGAME_PATH environment variable: https://github.com/minetest/minetest/pull/1609 |
18:02 |
|
SoniEx2 left #minetest-dev |
18:17 |
RealBadAngel |
https://www.youtube.com/watch?v=znvySoFWum8&feature=youtu.be |
18:17 |
RealBadAngel |
preview of node highlighting |
18:19 |
davexunit |
RealBadAngel: neat :) |
18:27 |
|
f-a joined #minetest-dev |
18:27 |
f-a |
just downloaded compiled minetest, good job guys |
18:36 |
|
garfonzo joined #minetest-dev |
18:40 |
sfan5 |
uh, thanks |
18:46 |
sol_invictus |
RealBadAngel: that's awesome, but in my opinion it could blink a bit slower |
18:46 |
VanessaE |
agreed. |
18:46 |
RealBadAngel |
im trying now to fine tune it |
18:47 |
RealBadAngel |
it should also be not as bright at night |
18:50 |
Krock |
RealBadAngel, looks good. I hope it won't depend on shaders |
18:51 |
RealBadAngel |
Krock, its not shaders feature |
18:51 |
Krock |
god |
18:51 |
Krock |
+o |
18:51 |
Krock |
well, at night it looks to bright |
18:52 |
VanessaE |
[09-06 14:48] <RealBadAngel> it should also be not as bright at night |
18:52 |
Krock |
k. |
18:52 |
Krock |
VanessaE ninja'd me once more again |
18:53 |
sol_invictus |
someone on forum said me that kaeza was working on head animations, anyone has details on that? |
18:54 |
Krock |
I've read it on the IRC |
18:54 |
sol_invictus |
is it ever going to be implemented? (: |
18:54 |
sol_invictus |
that feels so frustrating, you can't even nod to someone |
18:54 |
* VanessaE |
pokes Taoki[laptop] |
18:54 |
Taoki[laptop] |
hi |
18:55 |
VanessaE |
Taoki[laptop]: I think that ^^^ is your department? :) |
18:55 |
Krock |
^^^^ |
18:55 |
Taoki[laptop] |
sol_invictus: I wanted to do head animations too, but there's a problem: Irrlicht breaks models when you try to animate bones directly |
18:56 |
Taoki[laptop] |
The Lua function in Minetest to allow that already exists. But if you use it, the model will simply break and stop animating and get flipped and stuff. It's an Irr problem, and I'm hoping it will get fixed |
18:56 |
VanessaE |
sol_invictus: what I find frustrating is simply others not being able to see that you're looking up or down at something |
18:56 |
Taoki[laptop] |
i don't know if it happens with both b3d and x models. I only tried with x |
18:56 |
VanessaE |
Taoki[laptop]: have you looked into it recently? surely by now this has been fixed. |
18:56 |
VanessaE |
and if it doesn't happen with b3d then ditch that crusty .x format finally |
18:56 |
RealBadAngel |
i remember seeing animation with player head movement? |
18:57 |
Taoki[laptop] |
VanessaE: I need to check again against latest irrlicht (1.8). I don't have a b3d exporter howeveer |
18:57 |
VanessaE |
RealBadAngel: kaeza did it by sending tons of events over the network from the server --> client |
18:57 |
sol_invictus |
Taoki: ah, I'm using enchanced model with bending limbs and sometimes I see players disassembled :D |
18:57 |
Taoki[laptop] |
sol_invictus: Yeah, that's the bug |
18:57 |
sol_invictus |
it doesn't happen often |
18:57 |
VanessaE |
sol_invictus, Taoki[laptop] I use that knees/elbows model and I don't see that bug. |
18:58 |
VanessaE |
however wield3d doesn't work right - the item doesn't stay attached to the player's hand |
18:58 |
VanessaE |
(it floats around, the faster you move, the further away it floats until you stop moving) |
18:58 |
sol_invictus |
lol |
18:58 |
Krock |
VanessaE, that's a movement speed fail |
18:59 |
Taoki[laptop] |
VanessaE: The attachment system also uses Irrlicht's builtin functions for object-to-object attachment. So the problem is again Irrlicht most likely |
18:59 |
Taoki[laptop] |
I'm not an Irr dev myself, so I can't do much there |
18:59 |
sol_invictus |
btw, when I got my lag ~.2s I stopped seeing movement lags on carts |
18:59 |
VanessaE |
Taoki[laptop]: this needs addressed. I'm sure irrlicht is not the problem here, otherwise it basically couldn't be used with anything. |
19:00 |
Taoki[laptop] |
possibly |
19:00 |
VanessaE |
if kaeza could do it over the network from server-->client, then it can be done entirely in-client too |
19:01 |
VanessaE |
idk how he did it though, probably by modifying the model in realtime |
19:02 |
|
OldCoder joined #minetest-dev |
19:04 |
sol_invictus |
I'm wondering, why is irrlicht causing so many problems everywhere? |
19:04 |
sol_invictus |
was it the only choice? |
19:04 |
Krock |
yeah. why not making our own 3d graphics processing library? |
19:04 |
* Krock |
headdesks |
19:05 |
sol_invictus |
I didn't say that |
19:05 |
sol_invictus |
just curious if it's the only available |
19:05 |
VanessaE |
in some cases, irrlicht is simply being underutilized |
19:05 |
VanessaE |
e.g. minetest code being used to do something irrlicht could do better with just a little bit of preprocessing |
19:06 |
VanessaE |
in some cases, features not being used at all |
19:07 |
sol_invictus |
hmm, quite likely |
19:09 |
VanessaE |
Taoki[laptop]: what splitting the head from the body and attaching it as a separate mesh? |
19:10 |
VanessaE |
do some magic with the texture file to map it properly, etc. |
19:10 |
Taoki[laptop] |
VanessaE: Slightly more doable. But then it would also have that lag problem, and overall be more complex than needed |
19:10 |
VanessaE |
sure, it'd have that movement lag problem, but THAT problem needs addressed too by the sound of it |
19:11 |
VanessaE |
s/what/what about/ |
19:13 |
VanessaE |
oh well, just trying to spur development a bit :) |
19:17 |
|
sol_invictus joined #minetest-dev |
19:25 |
sol_invictus |
screenshot from lua - is it possible? |
19:26 |
Krock |
afaik no |
19:27 |
Krock |
use F12 instead |
19:28 |
sol_invictus |
ik about F12, it not what I want ): |
19:28 |
sol_invictus |
it's not* |
19:29 |
|
mrtux joined #minetest-dev |
19:29 |
|
hintss joined #minetest-dev |
19:31 |
kahrl |
sol_invictus: lua is only run on the server |
19:33 |
sol_invictus |
I see. that means there is no way you can get a screenshot from client to server (e.g. /screenshot command) without patching the client, right? |
19:33 |
RealBadAngel |
kahrl, https://www.youtube.com/watch?v=znvySoFWum8&feature=youtu.be |
19:34 |
kahrl |
RealBadAngel: saw it, good work! |
19:34 |
kahrl |
IMHO it shouldn't blink though |
19:34 |
T4im |
sol: other engines only can do that usually because the client runs the game code virtualised clientside as well, unless the client can do it nativly |
19:35 |
RealBadAngel |
kahrl, blinkin makes it work for all kind of textures, bright or not |
19:35 |
kahrl |
hmm |
19:36 |
sol_invictus |
T4im: got it |
19:37 |
kahrl |
RealBadAngel: you still have the selection box so that shouldn't be a big deal |
19:38 |
RealBadAngel |
im still playing with the effect, trying to make it look even more nice |
19:40 |
sol_invictus |
I think bliking just needs to be smoother, so it's not that eye-dragging and it would be fine |
19:46 |
|
sol_invictus joined #minetest-dev |
19:54 |
|
mrtux joined #minetest-dev |
20:03 |
|
Megaf joined #minetest-dev |
20:06 |
|
f-a left #minetest-dev |
20:09 |
|
Megaf joined #minetest-dev |
20:18 |
|
sfan5 joined #minetest-dev |
20:30 |
|
sfan5 joined #minetest-dev |
21:00 |
Krock |
how about merging https://github.com/minetest/minetest/pull/1605 ? |
21:53 |
|
paramat joined #minetest-dev |
22:06 |
|
mrtux joined #minetest-dev |
22:10 |
|
ImQ009 joined #minetest-dev |
23:35 |
|
paramat left #minetest-dev |