| Time |
Nick |
Message |
| 00:44 |
|
devmarth joined #minetest-dev |
| 00:48 |
Warr1024 |
VanessaE: in case you're interested, #2536 is now a thing. |
| 00:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2536 -- Anti-alias all 2D GUI Elements. by Warr1024 |
| 00:48 |
Warr1024 |
also, my PR number is 2 consecutive 2-digit perfect squares |
| 00:53 |
|
VanessaE joined #minetest-dev |
| 01:40 |
|
VanessaE joined #minetest-dev |
| 01:45 |
* est31 |
got #2500 |
| 01:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/2500 -- on_enter_node() and register_on_enter_node() methods |
| 01:46 |
est31 |
or no, sorry #2400 |
| 01:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/2400 -- Add /setpassword and /clearpassword logging by est31 |
| 01:57 |
|
Taoki joined #minetest-dev |
| 02:28 |
est31 |
man, 100 things... |
| 02:28 |
est31 |
minetest progresses quite fast |
| 02:28 |
est31 |
and time flies. |
| 02:28 |
est31 |
haven't I revoked its fly privilege? |
| 02:29 |
est31 |
perhaps its using a hacked client. |
| 02:29 |
est31 |
yes, that must be the reason. |
| 02:45 |
|
est31 joined #minetest-dev |
| 02:56 |
|
Zeno` joined #minetest-dev |
| 03:23 |
est31 |
Zeno`, can you have a look at #2531, #2535 and #2537 ? |
| 03:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2531 -- Fix cmake po detection bug by est31 |
| 03:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2535 -- Fix Android build on 32 bit by est31 |
| 03:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2537 -- Fix minetest.get_craft_recipe function by est31 |
| 03:23 |
est31 |
alot of fixing :) |
| 03:28 |
Zeno` |
How did 2537 creep in? |
| 03:29 |
hmmmm |
what's the difference between lua_newtable and lua_createtable? |
| 03:30 |
hmmmm |
hrmm... I wonder if anybody depends on genelement IDs being consecutive |
| 03:30 |
hmmmm |
give me one good reason why I shouldn't make them opaque handles instead |
| 03:31 |
Zeno` |
well 2537 should be merged immediately |
| 03:31 |
Zeno` |
the genelement handles? |
| 03:31 |
hmmmm |
yeah |
| 03:31 |
hmmmm |
the IDs returned by register_decoration and the like |
| 03:32 |
Zeno` |
hmm, not sure |
| 03:32 |
hmmmm |
for most things IDs can be used in place of names |
| 03:32 |
Zeno` |
for lua_createtable() you need to know the number of elements in the table beforehand judging from the Lua doc (referring to your previous question) |
| 03:33 |
hmmmm |
like for example let's say you're registering a decoration and you want it to occur in two biomes |
| 03:33 |
Zeno` |
But... people rely on them being consecutive? |
| 03:33 |
hmmmm |
you can either refer to the biomes by name |
| 03:33 |
hmmmm |
or by ID |
| 03:33 |
hmmmm |
the ID being the thing returned to your mod by register_biome() |
| 03:33 |
Zeno` |
I would never have assumed they would be consecutive but maybe people do, I dunno :3 |
| 03:33 |
hmmmm |
I want to change that |
| 03:33 |
hmmmm |
well, their fault if they do, it's undocumented behavior |
| 03:34 |
Zeno` |
Yeah, of course |
| 03:34 |
hmmmm |
you could always refer to a generation element by its name, if it's named |
| 03:34 |
hmmmm |
but oftentimes they aren't |
| 03:34 |
hmmmm |
for example, everybody names biomes, but nobody names ores |
| 03:34 |
Zeno` |
I can't think of a *good* reason where I would even contemplate relying on them being consecutive |
| 03:34 |
est31 |
Zeno`, doc sais that lua_newtable does the same as lua_createtable(L,0,0) |
| 03:34 |
est31 |
the middle param is the allocated size |
| 03:35 |
est31 |
as the table has one element, we allocate one |
| 03:35 |
Zeno` |
est31, so it's just a convenience thing? |
| 03:35 |
est31 |
yes |
| 03:35 |
hmmmm |
that's nice to know |
| 03:35 |
hmmmm |
I'm going to switch to lua_createtable for perlin noise map apis |
| 03:35 |
Zeno` |
well, it's also a performance thing if you know the number of elements I suppose |
| 03:35 |
est31 |
yes |
| 03:36 |
hmmmm |
thank you |
| 03:36 |
est31 |
np |
| 03:37 |
est31 |
and about how it sneaked in, read the issue for 2537, #2530. |
| 03:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/2530 -- Error when using minetest.get_craft_recipe(item) in a lua file |
| 03:39 |
Zeno` |
I'll merge it now if hmmmm agrees |
| 03:39 |
hmmmm |
do't you mean 2537? |
| 03:39 |
hmmmm |
2530 is an issue |
| 03:39 |
hmmmm |
and yes, +200 |
| 03:39 |
hmmmm |
LGTM |
| 03:41 |
Zeno` |
ok done. |
| 03:41 |
Zeno` |
also 2531 is good (I hated that particular file causing builds to fail) |
| 03:42 |
Zeno` |
agree, hmmmm? |
| 03:42 |
hmmmm |
yes |
| 03:43 |
hmmmm |
you realize I can't really give valid input, right? |
| 03:43 |
hmmmm |
those are the things that either work or don't, and i have no idea without testing it |
| 03:43 |
est31 |
nrzkt already +1ed it. |
| 03:43 |
Zeno` |
So he did... |
| 03:44 |
Zeno` |
anyway, those 2 are pushed |
| 03:44 |
est31 |
fine. |
| 03:46 |
WarrTab |
If you're in the mood for reviewing pr's, I just opened #2536 today... |
| 03:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/2536 -- Anti-alias all 2D GUI Elements. by Warr1024 |
| 03:47 |
Zeno` |
I've partially reviewed it :) |
| 03:47 |
Zeno` |
nice work |
| 03:47 |
hmmmm |
it looks fine to me so far |
| 03:47 |
WarrTab |
ah, thanks |
| 03:47 |
hmmmm |
WarrTab, the last thing you pushed has problems :/ |
| 03:47 |
WarrTab |
Oh, which? |
| 03:47 |
hmmmm |
angry people with pitchforks |
| 03:48 |
WarrTab |
It shouldn't even have any real effect without being enabled in config... |
| 03:48 |
hmmmm |
http://pastebin.ubuntu.com/10654682/ |
| 03:48 |
hmmmm |
it's enabled in the config by default |
| 03:48 |
hmmmm |
in any case, I told the guy to disable the setting, and that worked for him |
| 03:49 |
hmmmm |
I have no idea how I guessed the two things were interrelated but I turned out to be right |
| 03:49 |
WarrTab |
That's pretty weird, was it just the log msg, or was there more? |
| 03:49 |
hmmmm |
just the log message |
| 03:49 |
WarrTab |
Looks like only one angry person w/ pitchfork so far |
| 03:49 |
hmmmm |
well okay I exaggerated |
| 03:50 |
WarrTab |
I'm sure it's not gonna be something everyone wants to enable yet. I figure on-by-default probably requires a feature to "mature" a bit |
| 03:51 |
WarrTab |
It may take some time to learn how it interacts with more obscure mod features... |
| 03:51 |
hmmmm |
maybe you should change the defaults and push that? |
| 03:51 |
hmmmm |
on the other hand, it's getting a lot of exposure and testing! |
| 03:51 |
WarrTab |
ha, true |
| 03:51 |
hmmmm |
ElectronLibre is the guy to talk to about that |
| 03:52 |
WarrTab |
Maybe we should just put one checkbox on the settings gui for "enable experimental stuff" to get exposure |
| 03:52 |
hmmmm |
it would help to set debugging log level to info so you can gather more information like the filename it was split from with the garbage text |
| 03:52 |
hmmmm |
that's a really good idea actually |
| 03:52 |
est31 |
yea |
| 03:52 |
Zeno` |
est31, I don't know how to test #2535. I assume you've tested it on 64-bit and on the 32-bit f-droid build? |
| 03:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/2535 -- Fix Android build on 32 bit by est31 |
| 03:53 |
est31 |
I tested it on 64 bit, then there is nerzhul's CI which also tests it on 64 bit. I personally didn't test it on 32 bit, but f-droid people did. |
| 03:54 |
Zeno` |
well it *looks* fine :) |
| 03:54 |
est31 |
Zeno`, https://botbot.me/freenode/fdroid/2015-03-22/?msg=34774874&page=3 |
| 03:54 |
est31 |
begin of discussion: https://botbot.me/freenode/fdroid/2015-03-22/?msg=34774042&page=3 |
| 03:55 |
Zeno` |
well, I'm ok with it |
| 03:55 |
Zeno` |
I like the experimental stuff as well :) |
| 03:56 |
Zeno` |
s/stuff/idea |
| 03:57 |
Zeno` |
Ok, I'll merge that based on it being tested by krt and the automated builds |
| 03:58 |
Zeno` |
you ok with that reasoning, hmmmm? |
| 04:00 |
Zeno` |
WarrTab, do my code comments make sense or am I being vague again? heh |
| 04:00 |
WarrTab |
they make sense |
| 04:00 |
Zeno` |
weird |
| 04:00 |
WarrTab |
Actually, re: the s32 vs u32 thing... |
| 04:01 |
WarrTab |
It really would only make sense to use u32 for all coordinates |
| 04:01 |
WarrTab |
But rect<u32> then can't have negative width/height |
| 04:01 |
WarrTab |
Which would represent mirrored/flipped transforms |
| 04:02 |
Zeno` |
yeah, but once they are constrained it doesn't matter |
| 04:02 |
WarrTab |
And all my callers seem to want to use rect<s32> |
| 04:02 |
Zeno` |
convenience? |
| 04:03 |
Zeno` |
I don't know about the history of that |
| 04:03 |
WarrTab |
signed/unsigned disagreements are also the cause of a lot of bugs, esp things like buffer overflow vulns... |
| 04:03 |
Zeno` |
what was causing the upside down cuboids? |
| 04:03 |
WarrTab |
oh, 2 things |
| 04:04 |
WarrTab |
One was a quirk of how txr->img seems to alter the original |
| 04:04 |
WarrTab |
I didn't fix it, but avoided it, by avoiding repeated conversions using the cache |
| 04:05 |
Zeno` |
I wonder why it does that |
| 04:05 |
WarrTab |
On android, there's still the inversion issue from before |
| 04:05 |
Zeno` |
maybe a performance thing |
| 04:05 |
WarrTab |
The one I had caused was a 2d flip, i.e. after render |
| 04:05 |
WarrTab |
The one I see on android is a 3d flip, i.e. totally diff coordinate systems |
| 04:06 |
Zeno` |
oh. that's not confusing |
| 04:06 |
Zeno` |
:/ |
| 04:06 |
Zeno` |
unless it's endianess related |
| 04:06 |
Zeno` |
but that doesn't make sense |
| 04:06 |
WarrTab |
I suspect that when you convert an image to a txr, the video driver does some crazy stuff, like reverse row ordering s la .bmp, or even compression |
| 04:06 |
Zeno` |
possibly |
| 04:07 |
WarrTab |
But trying to pull back from txr to image, you get no help in manyncases |
| 04:07 |
WarrTab |
I resolved my android rendering woes by enabling the inventory image hack |
| 04:08 |
WarrTab |
Turns out autodetection for it dodn't pick my driver as problematic |
| 04:08 |
Zeno` |
hmm |
| 04:08 |
WarrTab |
RTT works on my android |
| 04:08 |
WarrTab |
But rtt bsck to image doesn't |
| 04:08 |
WarrTab |
Which messes up [inventorycube, whose output is an image |
| 04:09 |
WarrTab |
Oh, wait, the hack only fixes inventorycube if my scaling filter is ON |
| 04:09 |
WarrTab |
Because in that case I'm using the cached image, not txr->img |
| 04:09 |
WarrTab |
Never tested that bug with it off... |
| 04:10 |
WarrTab |
I should probably give android a regression pass w/ filter off... |
| 04:10 |
hmmmm |
Zeno`: sure |
| 04:10 |
hmmmm |
I thought screen coordinates for irrlicht are relative |
| 04:10 |
hmmmm |
that's why they're s32 |
| 04:11 |
hmmmm |
u32 is a dimension2d |
| 04:13 |
WarrTab |
I could try making sx and sy u32, and might just need to worry about the cast @ getPixel... |
| 04:14 |
WarrTab |
Either it's odd that getPixel takes s32, or it's just doing the implicit cast silently already. |
| 04:15 |
Zeno` |
yes it implicitly casts |
| 04:15 |
WarrTab |
I kind of wonder how slow getPixel/setPixel are; in my experience, they tend to be very slow, and have to check for all sorts of format conversions... |
| 04:19 |
WarrTab |
Btw, take a look at the loop in src/client/tile.cpp line 904. It's a very minor thing, but it seemed funny to me. |
| 04:19 |
WarrTab |
It's converting RGBA<-BGRA |
| 04:19 |
WarrTab |
It takes each u8 color component and swaps it with the other one |
| 04:20 |
WarrTab |
Including swapping G with G, and A with A |
| 04:20 |
WarrTab |
:-) |
| 04:22 |
Zeno` |
kind of quirky |
| 04:23 |
Zeno` |
I would have just put runptr += 4 at the end for a start |
| 04:23 |
WarrTab |
me too |
| 04:24 |
WarrTab |
So the body would be tmp = *runptr; *runptr = *(runptr + 2); *(runptr + 2) = tmp; runptr += 4; |
| 04:25 |
WarrTab |
It feels weird to me to say ptr += 4; I'm used to always having a * sizeof(something) there |
| 04:27 |
WarrTab |
I'll pull in those code review changes soon, maybe tomorrow. |
| 04:27 |
Zeno` |
well sizeof(unsigned char) aka sizeof(u8) is guaranteed to be 1 |
| 04:28 |
Zeno` |
but you wouldn't do that anyway |
| 04:28 |
WarrTab |
sizeof(u8) is more self-documenting, but I'm not a stickler for self-documenting code... |
| 04:28 |
Zeno` |
even if it was u16 *runptr; you'd still do runptr += 4 |
| 04:29 |
Zeno` |
because pointer arithmetic honours sizes |
| 04:29 |
WarrTab |
oh yeah, language quirl |
| 04:29 |
WarrTab |
S/.$/k/ |
| 04:29 |
WarrTab |
I actually always hated that |
| 04:30 |
WarrTab |
but when doing pointer walks, I seem to find myself walking with a pointer of s type different than the data elements |
| 04:32 |
Zeno` |
yes, but you might be crazy |
| 04:32 |
Zeno` |
hehe |
| 04:32 |
WarrTab |
I probably am. |
| 04:32 |
WarrTab |
No, wait, I actually have proof, come to think of it |
| 04:32 |
Zeno` |
the whole loop doesn't need to be written using pointer notation and in this case maybe [] notation would be better |
| 04:34 |
WarrTab |
https://gitlab.com/blindpass/gen2 <- proof of my crazy |
| 04:34 |
WarrTab |
Zeno`: IIRC pointer walks instead of array walks is a micro-optimization. |
| 04:35 |
WarrTab |
Pointer += 4 is faster than idx++, pointer = (idx * 4) |
| 04:36 |
WarrTab |
actually, the readme at https://gitlab.com/blindpass/android/blob/master/README might be better, though it hasn't been updated to latest version |
| 04:37 |
Zeno` |
using [] notation is equivalent |
| 04:37 |
Zeno` |
there's no optimisation (honest) |
| 04:38 |
WarrTab |
the whole "pointer walks are faster" actually predates most compiler optimizations... and a lot of cpu tech too |
| 04:39 |
Zeno` |
but in C the [] notation is simply shorthand for a pointer dereference |
| 04:39 |
WarrTab |
I'm thinking back in the 286 days |
| 04:39 |
Zeno` |
pre-ANSI? |
| 04:39 |
Zeno` |
I dunno about pre-ANSI C, but it's been like this since c89 |
| 04:40 |
WarrTab |
it's calculating the pointer that's theoretically slower |
| 04:40 |
WarrTab |
Though not slower in practice of your memory controller is the bottleneck anyway |
| 04:41 |
Zeno` |
No idea how... it produces the same ASM (and the asm is as I'd expect even for 286) |
| 04:41 |
Zeno` |
but I'll research it later since it might yield some interesting point of history :) |
| 04:42 |
hmmmm |
and xor eax, eax used to be faster too |
| 04:42 |
|
Hunterz joined #minetest-dev |
| 04:42 |
hmmmm |
stuff evolves |
| 04:42 |
WarrTab |
Reminds me of http://underhanded.xcott.com/?page_id=15 |
| 04:42 |
Zeno` |
yeah that's true |
| 04:43 |
Zeno` |
hang on, are you say incrementing the pointer by ONE might be faster? |
| 04:43 |
Zeno` |
(or might have historically been faster?) |
| 04:43 |
hmmmm |
lea edi, dword [ebx + ecx * 4] vs. add edi, 4 |
| 04:43 |
WarrTab |
No, saying that pointer += 4 would be faster than idx++ and using [] |
| 04:44 |
hmmmm |
I guess that is true in the strict sense of what happens |
| 04:44 |
WarrTab |
But knowing gcc, it probably already optimizes that for you |
| 04:44 |
hmmmm |
but the compiler might look into what it is you're actually doing and notice |
| 04:44 |
hmmmm |
"oh, this guy isn't actually using the counter "i" as he steps through the array" |
| 04:44 |
hmmmm |
"i can leverage this by advancing the pointer instead of incrementing the pointer and calculating the effective address |
| 04:45 |
hmmmm |
s/pointer/counter/ |
| 04:45 |
Zeno` |
a[0] actually, internally, has always been "translated" to *a |
| 04:45 |
WarrTab |
trying to micro-optimize like that could be bad, at best second-guessing the compiler, and at worst tripping it up |
| 04:45 |
Zeno` |
that's it! I'm installing Turbo C |
| 04:45 |
Zeno` |
first edition |
| 04:45 |
hmmmm |
Watcom C |
| 04:45 |
Zeno` |
Watcom is too advanced |
| 04:46 |
hmmmm |
watcom used to be teh shit |
| 04:46 |
hmmmm |
back in 1992 |
| 04:46 |
Zeno` |
it had better memory support |
| 04:46 |
WarrTab |
man, I was still doing basic back then |
| 04:46 |
Zeno` |
can't remember what it was called... (the tech) |
| 04:46 |
hmmmm |
I was 1 year old =] |
| 04:46 |
WarrTab |
Damn, you're pretty young |
| 04:47 |
WarrTab |
I was 11 |
| 04:48 |
Zeno` |
we might be taling about different things about the micro-optimisation |
| 04:48 |
Zeno` |
http://dpaste.com/2VCAEJ0 <--- those two snippets have always been exactly the same |
| 04:49 |
hmmmm |
yea |
| 04:49 |
Zeno` |
(apart from notational sugar) |
| 04:49 |
hmmmm |
what warrtab is talking about is different |
| 04:49 |
Zeno` |
I thought so... no wonder I was confused |
| 04:50 |
hmmmm |
for (int i = 0; i != ARRAYLEN(thing); i++) { something(thing[i]); } |
| 04:50 |
WarrTab |
Those snippets wouldn't be the same on 1980's technology, though ;-) |
| 04:50 |
hmmmm |
vs. for (FOO *foo = *thing; foo != thing + sizeof(thing); foo++) { something(foo); } |
| 04:51 |
WarrTab |
Though by today's standards they'd both be excruciating |
| 04:51 |
hmmmm |
the latter is, at least in theory, faster because it requires less instructions |
| 04:51 |
hmmmm |
though the compiler might look at the first snippet and decide you're not actually using the counter for anything other than array indexing and make it equivalent to the latter in the output |
| 04:52 |
WarrTab |
In practice, your processor is an order of magnitude faster than RAM, so if your data is large enough for cache misses, you won't notice a diff |
| 04:52 |
Zeno` |
I assert that they /were/ exactly the same in 1980 :P |
| 04:53 |
hmmmm |
yeah |
| 04:53 |
WarrTab |
If it's not larger than the cache, you won't notice the entire loop, probably |
| 04:53 |
hmmmm |
in the C language, 2[runptr] == *(2 + runptr) == *(runptr + 2) == runptr[2] |
| 04:53 |
Zeno` |
I think the optimisation would be doing runptr++ four times and four times only |
| 04:53 |
hmmmm |
-funroll-loops |
| 04:53 |
hmmmm |
fun fruit rollups |
| 04:53 |
Zeno` |
(back in dem olden days) |
| 04:54 |
WarrTab |
Loop unrolling is itself tricky |
| 04:54 |
Zeno` |
actually in the olden days you would have made that inline asm lol |
| 04:54 |
WarrTab |
fewer loop iterations, BUT uses more cache up, AND affects the branch predictor |
| 04:54 |
Zeno` |
not in the olden days |
| 04:55 |
* hmmmm |
hides |
| 04:55 |
Zeno` |
I'm going to convert all this to bit twiddling |
| 04:55 |
Zeno` |
that's how the pros do it |
| 04:55 |
WarrTab |
Oh, ugh :-) |
| 04:56 |
hmmmm |
guys |
| 04:56 |
WarrTab |
RGBA = ((BGRA & 0xff00ff00) ror 16) | (BGRA & 0xff00ff) |
| 04:56 |
hmmmm |
let's talk about schematic paths |
| 04:57 |
hmmmm |
erm, nevermind |
| 04:58 |
WarrTab |
Is there even an operator in c/c++ for binary barrel rotation? |
| 05:00 |
hmmmm |
nope |
| 05:00 |
WarrTab |
Boo |
| 05:00 |
hmmmm |
gcc has excellent recognition of the standard ROL() ROR() macros and converts them from their expansion into the instruction |
| 05:01 |
WarrTab |
ah, nice |
| 05:01 |
hmmmm |
okay I think what I'm going to do is try to detect if the schematic path is relative of absolute |
| 05:01 |
hmmmm |
if it's relative, I'll prepend the mod path |
| 05:02 |
hmmmm |
anybody have a problem with this?? |
| 05:02 |
Zeno` |
I've optimised it: http://dpaste.com/1DR6C6R can merge? |
| 05:02 |
Zeno` |
schematic paths |
| 05:02 |
Zeno` |
yeah, I think that's a good idea |
| 05:03 |
hmmmm |
the thing is.... do we know if minetest.get_modpath() always returns an absolute path? |
| 05:03 |
WarrTab |
I doubt it |
| 05:04 |
Zeno` |
This is what I started looking at the other day and that's just one of the questions I tried to answer to myself |
| 05:04 |
WarrTab |
I still run the thing on openbsd. It, and other sort-of-ported-to platforms may use rel paths with run_in_place |
| 05:05 |
hmmmm |
I think it is, IF running on a platform with path autodetection (i.e. the big four) |
| 05:05 |
hmmmm |
warrtab is right, my KERN_PROC_PATH hack only works on FreeBSD |
| 05:05 |
hmmmm |
I should fix this to work with the other 3 popular bsds |
| 05:05 |
hmmmm |
also I should fix it so it works on valgrind... |
| 05:06 |
WarrTab |
I doubt OpenBSD will ever willingly add an API to get the path of last exec |
| 05:06 |
WarrTab |
"What executable image am I running" is a perfectly sensible question to ask on a spawn-paradigm platform like windows... |
| 05:07 |
WarrTab |
Less-so on a fork-and-exec-or-maybe-overlay platform like unix |
| 05:07 |
hmmmm |
alright |
| 05:07 |
hmmmm |
it seems like there really is no way to find the full path on openbsd |
| 05:07 |
hmmmm |
that's stupid... |
| 05:08 |
WarrTab |
"the full path of what" is the key question |
| 05:08 |
hmmmm |
full path of the currently running executable |
| 05:08 |
WarrTab |
What you're really asking is "what was the path of my last exec() call" |
| 05:08 |
hmmmm |
hopefully absolute path |
| 05:09 |
hmmmm |
having an absolute path is absolutely necessay here otherwise my proposed solution just won't work |
| 05:09 |
hmmmm |
necessary* |
| 05:10 |
WarrTab |
I guess you could throw a hack in for the obscure platforms |
| 05:10 |
WarrTab |
Maybe a path prefixed with ./ or something to force relative interpretation...? |
| 05:10 |
Zeno` |
or maybe the full path is in argv[0]... who knows |
| 05:10 |
WarrTab |
Though I guess that's still backwards from what you want |
| 05:11 |
WarrTab |
Argv[0] could very well be an interpreter or launcher or hardlink or wrapper or any number of bizarre things |
| 05:11 |
hmmmm |
openbsd doesn't have procfs, right? |
| 05:11 |
hmmmm |
just checking |
| 05:11 |
WarrTab |
I think execve or something lets you pass anything you want as argv[0] |
| 05:12 |
Zeno` |
secret messages |
| 05:12 |
WarrTab |
Openbsd actually recently ripped procfs support out completely |
| 05:12 |
hmmmm |
awesome |
| 05:12 |
WarrTab |
You could add a cmdline option like --abspath |
| 05:12 |
hmmmm |
don't we have that?? |
| 05:12 |
hmmmm |
hrm |
| 05:13 |
WarrTab |
We could trust argv[0] under MOST circumstances and use --abspath to work around the rest |
| 05:13 |
WarrTab |
./minetest --abspath=`pwd` |
| 05:14 |
hmmmm |
you bring up an excellent point |
| 05:14 |
hmmmm |
why do we even care about the path of the executable |
| 05:14 |
WarrTab |
I think I might have used ./ as abs path in porting when I last played with BSD support |
| 05:14 |
hmmmm |
why aren't we using getcwd() |
| 05:14 |
WarrTab |
Yep |
| 05:14 |
WarrTab |
For run_in_place, makes the most sense |
| 05:14 |
hmmmm |
i don't know this is what celeron was doing and we all just went along with it and never performed any critical thinking |
| 05:15 |
WarrTab |
For non-run_in_place, those paths oughtta be compiled in |
| 05:16 |
WarrTab |
I think cwd == dir of executable is a reasonable assumption on most platforms |
| 05:16 |
hmmmm |
that would also fix the freebsd valgrind problem |
| 05:16 |
WarrTab |
Even on windows dbl-clicking an icon, runs the program by default from its own dir |
| 05:17 |
Zeno` |
does anyone use run_in_place? |
| 05:17 |
WarrTab |
I do |
| 05:17 |
hmmmm |
me :) |
| 05:17 |
Zeno` |
I dunno what it does |
| 05:17 |
hmmmm |
i think the majority of people use run_in_place |
| 05:17 |
WarrTab |
run-in-not-place is for root installs |
| 05:17 |
Zeno` |
I've never used it and I don't do "root installs" |
| 05:17 |
WarrTab |
Windows is ONLY run_in_place IIRC |
| 05:17 |
hmmmm |
yep |
| 05:17 |
Zeno` |
I have three different directories where minetest bin is actually |
| 05:18 |
Zeno` |
all of them in my home dir |
| 05:18 |
Zeno` |
and everything else in ~/.minetest/ |
| 05:18 |
Zeno` |
just works(TM) |
| 05:19 |
WarrTab |
I actually run_in_place, where _place just so happens to be ~/.minetest, with a rats' nest of symlinks :-) |
| 05:19 |
hmmmm |
here's the patch that added initializePaths: https://github.com/minetest/minetest/commit/6b6c2d37ea1f9075c4fbf0d7e2d52e527e1f86aa |
| 05:19 |
hmmmm |
we need to ask celeron what the reasoning behind this is before changing it |
| 05:19 |
hmmmm |
also we need to expect that changing it to the proper behavior will break things |
| 05:20 |
hmmmm |
celeron55: i am highlighing your nick |
| 05:23 |
Zeno` |
after looking at that function in porting (but the modern version) I wonder how my setup even works considering I don't use RUN_IN_PLACE |
| 05:23 |
hmmmm |
how minetest works is nothing short of a miracle |
| 05:23 |
WarrTab |
"use cwd" was how I originally fixed OpenBSD portability in https://github.com/minetest/minetest/commit/2636c92075196b4c2cd65327b1f839f1e8919b83 |
| 05:24 |
Zeno` |
oh // Get path to executable |
| 05:25 |
Zeno` |
so it seems on linux that it still gets the executable even if !defined RUN_IN_PLACE |
| 05:25 |
Zeno` |
I won't worry about it. Works, so *shrug*. Someone else can deal with that terrible function heh |
| 05:27 |
WarrTab |
The entire concept of "path to executable" is really a Windowsism, and even on that platform, as of Windows 8 at least, programs, program data, and config go in 3 different places now. |
| 05:28 |
WarrTab |
On unix, programs are generally meant to get data from compiled-in paths, cmdline, cwd, or ~/something... |
| 05:29 |
WarrTab |
It's actually kind of weird to have minetest exec in ~/.minetest/bin instead of ~/bin |
| 05:30 |
est31 |
what is ~/bin? |
| 05:30 |
WarrTab |
Except I'm not even sure if MT compiles on OpenBSD with RUN_IN_PLACE=0 w/o patches and hacks |
| 05:30 |
est31 |
on which os is it convention? |
| 05:30 |
hmmmm |
https://github.com/minetest/minetest/issues/2527#issuecomment-84811738 |
| 05:30 |
hmmmm |
lol proller |
| 05:31 |
est31 |
yea |
| 05:32 |
WarrTab |
est31 no idea on the convention, but where else do you put stuff to add to $PATH? |
| 05:33 |
est31 |
I don't have a user-wide path. but it is convention to have a ~/.$APPLNAME directory, mostly however for data |
| 05:33 |
WarrTab |
Btw, re: red sun, it seems there are still some places in code that are using images w/ specific pixel offsets that get thrown off... |
| 05:33 |
WarrTab |
Sifns lib was one, sun color is the other. |
| 05:34 |
WarrTab |
2 potential fixes I see so far: |
| 05:34 |
WarrTab |
1. Don't resize textures until they're bound to a mesh; could be complicated based on acces, though |
| 05:35 |
WarrTab |
2. Make the sun color thing relative to image size instead of absolute |
| 05:35 |
Zeno` |
I have minetest in ~/minetest-build-debug ~/minetest-build-release and ~/minetest-build-stable |
| 05:35 |
WarrTab |
est31 what's $APPLNAME? |
| 05:35 |
est31 |
the application's name |
| 05:35 |
* VanessaE |
peeks in |
| 05:35 |
est31 |
I have alot of ~/.$omething directories... |
| 05:36 |
Zeno` |
these aren't .skfjksjf dirs though |
| 05:36 |
WarrTab |
so you have to type out the path for everything? Or you have a lot of stuff in $PATH? |
| 05:36 |
VanessaE |
WarrTab: red sun....you know, I had noticed something was a little "off" about HDX's sun texture yesterday -- seemed too red. guess that explains it. |
| 05:36 |
Zeno` |
I type the full path |
| 05:36 |
VanessaE |
(I didn't think anything of it at the time) |
| 05:37 |
VanessaE |
(I assumed my tone map just needed adjusted) |
| 05:37 |
Zeno` |
(well I don't because I have scripts, but I effectively type the full path) |
| 05:37 |
est31 |
WarrTab, I do ctrl+R |
| 05:37 |
WarrTab |
vanessae: it needed not adjusted is the actual issue :-) |
| 05:37 |
Zeno` |
I'm bisecting it now |
| 05:37 |
VanessaE |
WarrTab: heh ok |
| 05:38 |
WarrTab |
zeno: it's the image scaling thing |
| 05:38 |
est31 |
yes its already bisected |
| 05:38 |
Zeno` |
oh it's adready been bisected? ok |
| 05:38 |
WarrTab |
As a short-term fix, we could set texture_min_size=1 in defaultsettimgs.cpp |
| 05:39 |
WarrTab |
Apparently our default of 16 as "effectively disabled by default" wasn't quite disabled enough |
| 05:39 |
WarrTab |
Friggin' 1px textures... |
| 05:40 |
WarrTab |
Might be just as quick to fix the tonemap code though |
| 05:40 |
WarrTab |
If anyone knows where it is... |
| 05:42 |
WarrTab |
Ah, got it |
| 05:42 |
WarrTab |
sky.cpp line 163 |
| 05:42 |
WarrTab |
That 511 needs to not be a literal |
| 05:42 |
WarrTab |
It should be texture height - 1, I guess |
| 05:43 |
WarrTab |
It's a 1-line fix; I'd do it myself, but not near a computer suitable for it |
| 05:45 |
WarrTab |
To be REALLY correct, offset should be calculated separately for sun/moon, incase the have different size tonemaps |
| 05:46 |
|
Warr1024 joined #minetest-dev |
| 05:46 |
WarrTab |
Meh, maybe I'll whip up a pr |
| 05:55 |
|
jin_xi joined #minetest-dev |
| 05:56 |
Warr1024 |
btw, didn't know you could pull specific texels from a texture... |
| 05:57 |
Warr1024 |
makes me wonder whether (1) sun/moon tonemaps don't work on android, or (2) we can use them to work around the texture->image issues we've been having with RTT |
| 06:04 |
Zeno` |
a) I imagine that u8 *texels = (u8 *)m_sun_tonemap->lock(ETLM_READ_ONLY); would be more efficient and b) why is the returned pointer not checked for NULL? |
| 06:05 |
VanessaE |
ok what is with the HORRIBLE lag while crafting stuff? |
| 06:06 |
VanessaE |
(in singleplayer) |
| 06:06 |
Zeno` |
it's been optimised |
| 06:06 |
VanessaE |
(I'm at f6f8250 at the moment) |
| 06:07 |
Zeno` |
i was joking, but I don't see the lag? |
| 06:09 |
VanessaE |
placing items in the craft grid results in them jumping back and forth between the grid and inventory |
| 06:09 |
VanessaE |
the lag is small but it's enough to be REALLY annoying |
| 06:09 |
* Zeno` |
looks again |
| 06:10 |
VanessaE |
it's like there's no inventory prediction anymore |
| 06:12 |
Zeno` |
inventory in the formspec or on the HUD? |
| 06:12 |
VanessaE |
in the formspec. |
| 06:12 |
Zeno` |
I don't see it and I'm using a debug build with no LuaJIT |
| 06:12 |
VanessaE |
moving items from inventory slots to the crafting grid. |
| 06:12 |
Zeno` |
(at HEAD) |
| 06:12 |
* Zeno` |
tries a dbuilder game |
| 06:13 |
VanessaE |
can you pull dreambuilder and see if it's just broken there? |
| 06:13 |
Zeno` |
I'm testing an old version of dreambuilder... taking ages to start up heh |
| 06:16 |
Zeno` |
I see it now with unified inventory (if that's what the mod is) |
| 06:16 |
* Zeno` |
tries release build |
| 06:18 |
Warr1024 |
are you testing on a server, or singleplayer? |
| 06:18 |
VanessaE |
singleplayer |
| 06:18 |
Zeno` |
singleplayer |
| 06:18 |
VanessaE |
ninja'd :) |
| 06:18 |
Zeno` |
so I was using the same as VanessaE |
| 06:18 |
Zeno` |
heh |
| 06:18 |
VanessaE |
Zeno`: how old is "old"? |
| 06:19 |
Zeno` |
ancient |
| 06:19 |
VanessaE |
just wondering, in case it's u_i that's broken |
| 06:19 |
Warr1024 |
ugh, my fix isn't working |
| 06:20 |
Zeno` |
ok, let me look... |
| 06:20 |
Zeno` |
VanessaE, 3f99e214d48a4eea12420a5ea97aa62c838c6e0b |
| 06:20 |
Zeno` |
Warr1024, I suppose you could just avoid upscaling 1px images |
| 06:20 |
VanessaE |
well that's not super old, but reasonably so. |
| 06:20 |
Warr1024 |
Hm, I guess that could work. |
| 06:21 |
Warr1024 |
I think that was proller's workaround |
| 06:21 |
Warr1024 |
since I suppose 1px images won't experience blurring anyway |
| 06:21 |
Zeno` |
I never look there (don't want to taint myself heh) |
| 06:21 |
Warr1024 |
ugh, seems like a cop-out to special-case it :-) |
| 06:22 |
Zeno` |
dunno if it's a cop-out |
| 06:22 |
Zeno` |
:P |
| 06:22 |
Zeno` |
probably an optimisation even |
| 06:22 |
Zeno` |
VanessaE, I notice the lag with LuaJIT and release build also |
| 06:23 |
VanessaE |
Zeno`: any chance this is a u_i bug? |
| 06:23 |
Zeno` |
VanessaE, I'd be guessing without trying to find the cause of it :) |
| 06:23 |
Zeno` |
But it never used to be like that |
| 06:23 |
Zeno` |
Well, I don't think it did... I'm sure I would have noticed something that annoying |
| 06:25 |
VanessaE |
it feels very much like using a chest on a laggy server |
| 06:25 |
VanessaE |
or a crafting table in Realtest, on a bad day |
| 06:25 |
Zeno` |
yes |
| 06:28 |
Warr1024 |
#2538 |
| 06:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/2538 -- Fix for sun/moon tonemaps: dont upscale 1px images. by Warr1024 |
| 06:30 |
Warr1024 |
someone should tell proller that there IS an "already fixed in freeminer" tag for issues: it's called him opening up a PR and sending the fix upstream :-) |
| 06:32 |
Warr1024 |
ooh, guiscaling actually anti-aliases the menu background too; I hadn't noticed that I had covered that too. |
| 06:33 |
Zeno` |
I don't like the extra parenthesis :P |
| 06:35 |
Warr1024 |
paranoia about compilers that ignore standards when it comes to order of ops |
| 06:36 |
Warr1024 |
and, frankly, novice devs who misread them |
| 06:36 |
Warr1024 |
The guy who taught me that feared the former, but I've learned to fear the latter more often. |
| 06:38 |
Warr1024 |
of course, you can fix any style issues you come across when you commit it, I suppose. |
| 06:38 |
Warr1024 |
As long as you don't end up introducing a bug I get blamed for :-P |
| 06:38 |
Zeno` |
https://gist.github.com/Zeno-/3e6e2ae6644e5c8c7e29 |
| 06:39 |
Zeno` |
Why? It's better to give you the fix so you get blamed for the bug isn't it? |
| 06:39 |
Zeno` |
:p |
| 06:39 |
Warr1024 |
composing 2 images together doesn't work very well when one of them is a high-res image from a texture pack, and the other is not texture-packed. |
| 06:40 |
Warr1024 |
*looks* okay. I take it it runs okay? |
| 06:40 |
Warr1024 |
Not a fan of your extra whitespace either :-) |
| 06:40 |
Zeno` |
Didn't test it |
| 06:41 |
Zeno` |
what whitespace? |
| 06:41 |
Warr1024 |
lines 14 and 15 |
| 06:41 |
Zeno` |
mistake :) |
| 06:41 |
Warr1024 |
I do like the early return style, though, thanks. |
| 06:41 |
Zeno` |
yw |
| 06:41 |
Zeno` |
haha :D |
| 06:42 |
Warr1024 |
I straight-ported my old code, and the old code couldn't do that. |
| 06:42 |
Warr1024 |
I get complaints about return/break/continue use occasionally |
| 06:42 |
Warr1024 |
flow control purists kind of hate them |
| 06:42 |
Zeno` |
oh fix that opening brace as well? |
| 06:42 |
Zeno` |
(for the start of the function) |
| 06:42 |
Warr1024 |
but I hate indenting to the point where shit is all crammed on the rightmost few columns.. |
| 06:43 |
Zeno` |
yeah, purists would say you don't need early returns, continue, break, goto, etc |
| 06:43 |
Zeno` |
but realists are a bit more... hmm, realistic? :) |
| 06:43 |
Zeno` |
of course you don't *Need* them, but they sure make the code cleaner (especially the indentation levels) |
| 06:44 |
est31 |
doublists are even more. |
| 06:44 |
Warr1024 |
goto I don't use, myself; not so much because of dogma, as I just (1) haven't had to, and (2) can't remember label syntax in C/C++. |
| 06:44 |
Zeno` |
goto use case is rare but there are valid cases |
| 06:44 |
est31 |
not realistic but doublistic |
| 06:44 |
|
Hunterz joined #minetest-dev |
| 06:44 |
Zeno` |
wtf is doublistic? lol |
| 06:45 |
Zeno` |
oh probably shouldn't use switch either... huge goto-like jump table... horrible |
| 06:45 |
est31 |
mhh you are right, reals are better than doubles |
| 06:45 |
Zeno` |
that has to be the worst joke I've ever head lmao :D |
| 06:45 |
est31 |
reals are really uncountable though. |
| 06:46 |
Zeno` |
that's why I don't use them |
| 06:46 |
Zeno` |
integers are all that's required |
| 06:46 |
est31 |
there are reals that no c program can output for any input. |
| 06:46 |
est31 |
input which has an end. |
| 06:47 |
Zeno` |
unreal |
| 06:48 |
Zeno` |
Warr1024, "The guy who taught me was paranoid about compilers that ignore standards when it comes to order of ops" |
| 06:48 |
Zeno` |
is he on medication now? |
| 06:49 |
Zeno` |
lol, I find that really funny (sorry) |
| 06:50 |
Warr1024 |
Zeno`: you get burned once, you learn to be careful |
| 06:50 |
Zeno` |
well he missed an op |
| 06:50 |
Warr1024 |
oh? |
| 06:50 |
Zeno` |
if (((dim.Width) <= 1 || ((dim.Height) <= 1)) |
| 06:50 |
Warr1024 |
cute |
| 06:51 |
Zeno` |
anyway it must have been a very bad compiler :( |
| 06:51 |
Warr1024 |
there are no shortage of those, you just don't hear much about them... |
| 06:51 |
jin_xi |
+1 for extra parens from both a lisper and user of many different languages all with subtly different rules for precedence |
| 06:51 |
Zeno` |
the *really* bad ones might even ignore precedence of parenthesis |
| 06:52 |
Warr1024 |
ha |
| 06:52 |
Warr1024 |
jin_xi: thanks, nice to be appreciated for a change ;-) |
| 06:52 |
Zeno` |
harsh crowd |
| 06:52 |
Warr1024 |
I also don't really bother to learn the intricacies of order of ops for any particular language |
| 06:53 |
Zeno` |
Me either |
| 06:53 |
Warr1024 |
the "my dear aunt sally" ones aren't so bad, but the bit twiddling ones can be weird. |
| 06:53 |
Warr1024 |
parens help me not have to worry about those. |
| 06:53 |
Zeno` |
I just trust the compiler to do what I meant |
| 06:53 |
Warr1024 |
some languages don't offer non-bitwise boolean ones |
| 06:53 |
Warr1024 |
lol |
| 06:54 |
Warr1024 |
no, compilers generally only compile what you type, not what you mean :-) |
| 06:54 |
Warr1024 |
#pragma you know what I'm sayin', right? |
| 06:54 |
Zeno` |
heh |
| 06:54 |
Zeno` |
So they don't guess? |
| 06:54 |
Zeno` |
stupid things |
| 06:55 |
Warr1024 |
actually, sometimes they do, and that can be problematic. |
| 06:55 |
Zeno` |
Well, guess is the wrong word. They should really look at the context and determine what I *really* meant to type but typed incorrectly and silently correct me |
| 06:55 |
Warr1024 |
if you're working on something sensitive enough, like driver code, then the compiler's optimizations based on its guess of what you intended can be wrong... |
| 06:56 |
Warr1024 |
When LibreSSL first forked from OpenSSL, there were a number of downstream projects to try to port it to other operating systems. |
| 06:56 |
Warr1024 |
but these had problems, such as leakage of sensitive informaion |
| 06:56 |
Zeno` |
you know my words in the last 10 minutes have been dripping with sarcasm, right? |
| 06:57 |
Warr1024 |
one of the culprits was the fact that compilers like to optimize away bzero before free |
| 06:57 |
Zeno` |
sometimes people don't realise when I'm being sarcastic... probably the nature of the medium we're communicating on |
| 06:57 |
Warr1024 |
Zeno`: was that before or after the mention of extra parens? |
| 06:57 |
Zeno` |
well, after that |
| 06:58 |
Warr1024 |
well, just because you were being facetious about compilers trying to "guess" what you mean doesn't mean that they don't actually do that :-) |
| 06:58 |
Zeno` |
oh, I do know :) |
| 06:59 |
Warr1024 |
what's the story on the PR, btw? Were you going to merge it, or kick back some code review comments, or pass it on for further review? |
| 06:59 |
Warr1024 |
it's a bugfix, but probably not ultra-critical |
| 06:59 |
Zeno` |
oh yeah.. forgot about that |
| 06:59 |
Warr1024 |
I mean, a red sun is damn creepy, but it's not exactly a segfault :-) |
| 07:00 |
Zeno` |
I suppose I can leave the extra indentation |
| 07:01 |
Warr1024 |
I don't mind any of the changes you had proposed |
| 07:02 |
Zeno` |
they make the PR less trivial |
| 07:02 |
Warr1024 |
though I suspect I'll probably over-parenthesize future diffs too... |
| 07:02 |
Zeno` |
and I'd then have to get approval from another dev :) |
| 07:02 |
Warr1024 |
just typing the space after if and for is damn hard to do :-) |
| 07:02 |
Warr1024 |
well, you can split the patch |
| 07:02 |
Zeno` |
So I left it as-is because it's obvious that it's a trivial fix |
| 07:02 |
Warr1024 |
submit the critical parts, and then do a style pass later |
| 07:03 |
Warr1024 |
eh, it's not really difficult to understand the code either way |
| 07:03 |
Zeno` |
correct |
| 07:04 |
Warr1024 |
awesome |
| 07:05 |
Warr1024 |
should we close 2527, or is there some level of confirmation of the fix necessar? |
| 07:05 |
Zeno` |
yeah I'm doing it now but got distracted :) |
| 07:06 |
Warr1024 |
awesome, only one more reported issue related to that upscale patch :-) |
| 07:06 |
Zeno` |
does github have an API? |
| 07:06 |
Zeno` |
would be nice to automate some of this |
| 07:06 |
Warr1024 |
yeah, I haven't messed with it much though. |
| 07:06 |
Warr1024 |
everybody who's anybody has an API :-) |
| 07:06 |
Zeno` |
true :) |
| 07:07 |
Zeno` |
Secure Connection Failed |
| 07:07 |
Zeno` |
ok well I give up |
| 07:07 |
Zeno` |
lol |
| 07:07 |
Zeno` |
github has been really bad for me for the last couple of days |
| 07:07 |
Zeno` |
pages not loading, things not being formatted, avatars displayed incorrectly, etc etc etc |
| 07:08 |
Warr1024 |
yeah, I guess I'm done for the night too. |
| 07:08 |
Zeno` |
I'd better cook dinner |
| 07:08 |
Warr1024 |
I think guiscaling could use a bit of time to gather some reviews and testing... |
| 07:08 |
Warr1024 |
later |
| 07:08 |
Warr1024 |
thanks for the quick fixes, btw. |
| 07:08 |
Zeno` |
bbl as well |
| 07:22 |
|
blaze joined #minetest-dev |
| 07:49 |
celeron55 |
hmmmm: the path detection code is indeed rather unconventional, but it has done its job of allowing users and developers to not care about CWD quite well |
| 07:49 |
celeron55 |
i don't remember what the original case was that made me add that |
| 07:51 |
hmmmm |
what would break if it were changed to only use cwd |
| 07:51 |
celeron55 |
oh that commit actually does two things |
| 07:52 |
celeron55 |
it adds RUN_IN_PLACE, AND implements it using a system that primarily uses the executable's path |
| 07:52 |
hmmmm |
i see |
| 07:52 |
hmmmm |
ahh |
| 07:52 |
celeron55 |
hmmmm: maybe not, but it would probably break many user's setups and some build systems that have weird stuff going on with CWD |
| 07:53 |
hmmmm |
so if somebody wanted to run minetest like projects/dev/minetest/bin/minetest it'd get the assets from the correct place |
| 07:53 |
hmmmm |
right this is the correct "spirit" of RUN_IN_PLACE.. it's running relative to where the executable is supposed to be |
| 07:53 |
celeron55 |
and it would start a fight of whether CWD should be in the root of minetest or in bin and what's the difference between a run-in-place and non-run-in-place versions regarding to that |
| 07:54 |
hmmmm |
the only problem is that on some platforms, getting the executable path is hard |
| 07:54 |
hmmmm |
it can't be done on OpenBSD, for example. simply can't |
| 07:54 |
celeron55 |
i'm not arguing that that's the only way to do it, but it has served us during the four years quite well if you ask me |
| 07:54 |
hmmmm |
on FreeBSD, my sysctl code actually breaks valgrind |
| 07:55 |
hmmmm |
and that's sort of a bummer |
| 07:57 |
hmmmm |
okay I think I know what to do |
| 07:58 |
celeron55 |
the code is ugly though |
| 07:58 |
celeron55 |
but that's not a problem with what the code does |
| 07:59 |
celeron55 |
(just a code-organizational issue) |
| 08:07 |
est31 |
hmmmm, what about /proc/curproc/file ? |
| 08:08 |
hmmmm |
procfs is not used by default on freebsd and netbsd; it doesn't exist on openbsd at all |
| 08:08 |
hmmmm |
you cannot rely on the existence of procfs |
| 08:08 |
est31 |
good to know. |
| 08:08 |
est31 |
there is no $0 trick? |
| 08:08 |
hmmmm |
nope. on openbsd they expect you to use the cwd for these sorts of situations |
| 08:08 |
hmmmm |
which obviously has problems |
| 08:09 |
est31 |
I always start my minetest from my desktop |
| 08:10 |
hmmmm |
god dammit l_mapgen.cpp is such a mess =] |
| 08:10 |
hmmmm |
was out all day and I wanted to get some serious stuff done |
| 08:10 |
hmmmm |
night all |
| 08:10 |
est31 |
bye |
| 08:12 |
est31 |
when its their philosophy, follow it. |
| 08:12 |
est31 |
just dont force all users to it. |
| 08:13 |
|
nrzkt joined #minetest-dev |
| 08:25 |
|
Calinou joined #minetest-dev |
| 08:37 |
|
SopaXorzTaker joined #minetest-dev |
| 08:50 |
|
kilbith joined #minetest-dev |
| 10:05 |
|
SopaXorzTaker joined #minetest-dev |
| 10:07 |
|
est31 joined #minetest-dev |
| 10:10 |
est31 |
finally, minetest is also available in the f-droid app store! https://f-droid.org/repository/browse/?fdfilter=mine&fdid=net.minetest.minetest |
| 10:15 |
|
rom1504 joined #minetest-dev |
| 10:24 |
est31 |
and the proper URL is https://f-droid.org/repository/browse/?fdid=net.minetest.minetest |
| 10:27 |
Calinou |
they have an IRC btw, #fdroid |
| 10:54 |
|
Player_2 joined #minetest-dev |
| 11:12 |
|
Zeno` joined #minetest-dev |
| 11:13 |
|
Calinou joined #minetest-dev |
| 11:27 |
|
FR^2 joined #minetest-dev |
| 11:27 |
|
MinetestForFun joined #minetest-dev |
| 11:34 |
|
Ritchie joined #minetest-dev |
| 11:36 |
|
SopaXorzTaker joined #minetest-dev |
| 12:22 |
|
Zeno` joined #minetest-dev |
| 12:57 |
Zeno` |
kinda quiet |
| 13:26 |
Zeno` |
nrzkt, are you awake? |
| 13:26 |
est31 |
https://github.com/minetest/minetest/pull/2540#issuecomment-84995376 |
| 13:26 |
est31 |
seems so |
| 13:27 |
|
MinetestForFun joined #minetest-dev |
| 13:29 |
Zeno` |
github is not working for me very well :/ |
| 13:30 |
est31 |
send them a mail, or complain to support |
| 13:30 |
est31 |
they are a corp |
| 13:30 |
est31 |
I have a nasty github issue too |
| 13:30 |
est31 |
but old one and I can live with |
| 13:31 |
Zeno` |
I have |
| 13:31 |
Zeno` |
:) |
| 13:31 |
Zeno` |
The web side of github is basically unusable for me atm |
| 13:32 |
est31 |
when did you ask them |
| 13:32 |
Zeno` |
about 20 minutes ago |
| 13:33 |
Zeno` |
it's been slowly getting worse for me over the last 5-7 days (on all 4 of my computers... browser doesn't matter) |
| 13:33 |
est31 |
I'm 100 percent sure its the alf. can you reproduce it with non-alf accounts? |
| 13:33 |
* est31 |
lost a bad joke again. where is it? |
| 13:34 |
Zeno` |
lol |
| 13:35 |
kilbith |
https://github.com/minetest/minetest/issues/2541 |
| 13:35 |
kilbith |
thanks for chasing the bug ^ |
| 13:39 |
Zeno` |
? |
| 13:41 |
nrzkt |
i looked at the code, the problem is serverside for me. It's not a network bug, the sent content is not right |
| 13:43 |
Zeno` |
I'm sorry, but are you serious? |
| 13:43 |
nrzkt |
the packet sending is a raw copy from asyncrunstep and the packet decoding is strictly exact, else everybody would have a bug. Then the only think possible is an object with wrong datas on server |
| 13:43 |
Zeno` |
The server doesn't send packets? |
| 13:43 |
nrzkt |
only thing* |
| 13:43 |
nrzkt |
hmm, why do you say that ? |
| 13:44 |
nrzkt |
the server send packets because the packet is handled and this exception is triggered |
| 13:44 |
Zeno` |
because you said "the problem is serverside for me" |
| 13:45 |
Zeno` |
I mean... it's the second time I've seen that bug report now |
| 13:45 |
kilbith |
it's obviously, unsurprisingly not a server bug (tm) ... |
| 13:45 |
nrzkt |
yes, the problem is on the datas written to the packet, but because the packet writing is trivial (pkt.putRawString(datas.c_str(), datas.size());) |
| 13:45 |
Zeno` |
there was a very similar one yesterday |
| 13:46 |
Zeno` |
Ok, let's put it this way. Why do the servers suddenly "have the wrong data"? |
| 13:47 |
nrzkt |
it's only into 1 world of this player, as he said in the pr |
| 13:47 |
nrzkt |
then the condition is not matched every time |
| 13:47 |
Zeno` |
Yesterday's bug report was from LazyJ as well? |
| 13:47 |
est31 |
yes |
| 13:47 |
nrzkt |
it's this report |
| 13:47 |
est31 |
the one you wanted to rebase |
| 13:48 |
Zeno` |
I wanted to rebase? |
| 13:48 |
est31 |
the sun problem |
| 13:48 |
est31 |
umm bisect |
| 13:49 |
Zeno` |
so it's now fixed? |
| 13:49 |
est31 |
I havent reproduced it |
| 13:50 |
Zeno` |
wtf does the sun problem have to do with something the server sends anyway? |
| 13:51 |
nrzkt |
est31 it's not related, the packet in this report isn't related to sun, it's ACTIVEOBJECT_REMOVE_ADD, sun is not an activeobject, right ? |
| 13:51 |
est31 |
sorry perhaps I got sth wrong |
| 13:51 |
* est31 |
needs sleep |
| 13:53 |
est31 |
bye |
| 13:53 |
|
err404 joined #minetest-dev |
| 13:54 |
Zeno` |
I might have a break as well. I'm very confused atm lol |
| 14:06 |
|
cd2 joined #minetest-dev |
| 14:15 |
|
PilzAdam joined #minetest-dev |
| 14:46 |
nrzkt |
PilzAdam: how signs_lib generate their names ? |
| 14:48 |
PilzAdam |
https://github.com/VanessaE/homedecor_modpack/blob/master/signs_lib/init.lua#L442 |
| 14:49 |
PilzAdam |
basically a huge [combine |
| 14:49 |
nrzkt |
is this a luaentitysao ? |
| 14:50 |
PilzAdam |
yes, the texture is set to an entity |
| 14:50 |
PilzAdam |
this is the only way to dynamically change textures |
| 14:51 |
nrzkt |
the exception is triggered because of this call server side: https://github.com/minetest/minetest/blob/master/src/server.cpp#L757 |
| 14:52 |
nrzkt |
which refers to this: https://github.com/minetest/minetest/blob/master/src/content_sao.cpp#L353 |
| 14:52 |
nrzkt |
this is the long string forger |
| 14:55 |
PilzAdam |
ObjectProperties::serialize uses writeU16(os, textures.size()); |
| 14:55 |
PilzAdam |
maybe the texture name contains more than 65000 chars? |
| 14:56 |
PilzAdam |
oh wait, that is the number of textures |
| 14:56 |
nrzkt |
yes |
| 14:57 |
PilzAdam |
serializeString properly checks the string the length, so that isn't the problem |
| 14:57 |
nrzkt |
yes, idem with long string |
| 14:58 |
PilzAdam |
do you have a way to reliably reproduce it? |
| 14:59 |
nrzkt |
at this moment no, because i don't have the user environment |
| 14:59 |
nrzkt |
if we cannot read the size on client side, it's because there is nothing to read |
| 15:03 |
nrzkt |
how can this be possible |
| 15:03 |
nrzkt |
the serializer and the deserialize are correct, i don't see a problem on it |
| 15:05 |
nrzkt |
the only place where we deserialize long strings are: deSerializeLongString |
| 15:05 |
nrzkt |
is: https://github.com/minetest/minetest/blob/master/src/content_cao.cpp#L646 |
| 15:06 |
nrzkt |
then the num_messages is incorrect, because we have read the previous datas in the CAO |
| 15:07 |
nrzkt |
https://github.com/minetest/minetest/blob/master/src/content_sao.cpp#L805 |
| 15:07 |
nrzkt |
it's written here, the message number and the message map |
| 15:08 |
nrzkt |
err: https://github.com/minetest/minetest/blob/master/src/content_sao.cpp#L367 , not the playerSAO |
| 15:11 |
|
Zeno` joined #minetest-dev |
| 15:17 |
nrzkt |
hmm... the "Malformed packet read" is triggered by NetworkPacket, we want to read outside of the packet size |
| 15:18 |
nrzkt |
this match the serialization error given by deSerializeLongString |
| 15:20 |
|
hmmmm joined #minetest-dev |
| 15:22 |
* VanessaE |
wanders in |
| 15:23 |
|
DFeniks joined #minetest-dev |
| 15:29 |
Zeno` |
It'd be nice if this could be reproduced somehow |
| 15:36 |
VanessaE |
signs_lib's string size is kinda limited - I've tested it (under LuaJIT) to be able to handle some 3 or 4K in a sign (even though the sign can theoretically only display about 1k, and that's if they're all 'i' or something) |
| 15:36 |
VanessaE |
so you can at least be confident that it's not running up against some serialization limit in Lua or so. |
| 15:36 |
nrzkt |
i don't think it's related to size our packet size and buffer size are correct |
| 15:37 |
VanessaE |
(that is, it's limited on input and on rendering to not go over that 3 or 4k, whatever it was) |
| 15:39 |
VanessaE |
by serialization limit I mean, just for example, the known bug in LuaJIT where it can't handle more than 64k. |
| 15:40 |
nrzkt |
in packets 16k or 4.2B , but generally 4.2B |
| 15:49 |
VanessaE |
Zeno`: about the crafting delay... could it be related to the get-all-recipes commits, since it only seems to happen under U_I and that mod uses those? |
| 15:50 |
Zeno` |
VanessaE, I suppose it could be yeah |
| 15:53 |
Zeno` |
strange, or not?, is that there is a possible memory leak in deSerializeLongString |
| 15:54 |
Zeno` |
caused by clientpackethandler.cpp line 822 |
| 15:57 |
nrzkt |
822 ? are you sure ? it's not the same packet |
| 15:57 |
nrzkt |
https://github.com/minetest/minetest/blob/master/src/network/clientpackethandler.cpp#L822 |
| 16:01 |
Zeno` |
as I said, it's probably a coincidence but that is where the possible memory leak is occurring |
| 16:01 |
Zeno` |
wtf |
| 16:02 |
* Zeno` |
checks that he's at HEAD |
| 16:02 |
Zeno` |
line 815 |
| 16:04 |
|
Warr1024 joined #minetest-dev |
| 16:06 |
nrzkt |
you are not on the right packet zeno |
| 16:06 |
nrzkt |
it's not this packet as the backtrace said it's ACTIVEOBJECT_REMOVE_ADD |
| 16:06 |
nrzkt |
https://github.com/minetest/minetest/blob/master/src/network/clientpackethandler.cpp#L365 |
| 16:07 |
Zeno` |
I am saying that there is a possible memory leak caused by line 815 of clientpackethandler.cpp |
| 16:07 |
Zeno` |
Well, I'm not saying it, I'm just reporting what valgrind is telling me |
| 16:08 |
Zeno` |
and either it's a coincidence or not :) |
| 16:08 |
nrzkt |
why ? std::string is not a pointer, and is not a pointer too |
| 16:08 |
Zeno` |
it's the Buffer I imagine |
| 16:09 |
nrzkt |
the buf[4] ? |
| 16:09 |
Zeno` |
onl line 124 of serialize.cpp |
| 16:10 |
Zeno` |
I'm not saying this *is* an error |
| 16:10 |
Zeno` |
I saying that valgrind reports it |
| 16:12 |
|
SopaXorzTaker joined #minetest-dev |
| 16:12 |
nrzkt |
very strange why are we using Buffer<char> there ? instead of writing directly to std::string ? |
| 16:12 |
Zeno` |
no idea |
| 16:14 |
nrzkt |
it's useful as i see in my first test |
| 16:15 |
Zeno` |
I'll run valgrind again |
| 16:17 |
nrzkt |
Zeno` can you review https://github.com/nerzhul/minetest/commit/7ad167787eef6783daccfe6680a06a03905eb74d please ? I improve a little bit the interaction between Connection senders with the given packet by removing the oldForgePacket copy, replacing it by a reference |
| 16:17 |
nrzkt |
this will improve a little bit more our network stack performance |
| 16:26 |
Zeno` |
I'm more interested in fixing (potential) bugs than performance atm :) |
| 16:27 |
nrzkt |
i agree with you, i only find this useful improvement when i look at the network stack today :) |
| 16:27 |
VanessaE |
maybe a bug freeze needs to be declared? |
| 16:28 |
VanessaE |
no performance changes, no features, strictly only bug fixes |
| 16:28 |
Zeno` |
Not much point in optimising something that doesn't work lol (if there is a bug) |
| 16:28 |
VanessaE |
I think we need a fairly long period with only this alloed. |
| 16:28 |
VanessaE |
allowed* |
| 16:29 |
Zeno` |
To be clear I'm not saying the bugs are network related; but there *are* bugs |
| 16:29 |
nrzkt |
VanessaE, 0.4.12 is young. 1 month too early, 1 or 2 months more can be useful, bugtracking must be done in parallel of the devel |
| 16:29 |
VanessaE |
and then at the end of said freeze, make a new release. |
| 16:29 |
VanessaE |
nrzkt: so? 0.4.12 is a pretty nasty release (not as bad as 0.4.11, but bad) |
| 16:29 |
Zeno` |
they may or may not be network related; either way they need to be fixed before worrying about optimisation IMO |
| 16:29 |
nrzkt |
no problem :p |
| 16:30 |
Zeno` |
hey 0.4.11 was very fast |
| 16:30 |
VanessaE |
Zeno`: fast at crashing? ;) |
| 16:30 |
Zeno` |
50x faster than 0.4.10 |
| 16:31 |
Zeno` |
no :P |
| 16:31 |
Zeno` |
but there were some major hiccups yeah |
| 16:31 |
VanessaE |
but anyway I'm saying zero new features, not even the most trivial. no performance tuning, nothing like that. All efforts directed at fixing bugs, regardless of who made them, how they got started, or how big or trivial they are. |
| 16:31 |
VanessaE |
and keep at it until enough are declared fixed that it's worth a new release. |
| 16:32 |
nrzkt |
we don't have really new features on this devel version |
| 16:32 |
VanessaE |
constant development is useless if it results in buggy code |
| 16:32 |
Zeno` |
Does there need to be a "feature freeze" for this to happen though? It's common sense to fix bugs before optimising |
| 16:32 |
kilbith |
Zeno`, "faster" is relative... |
| 16:32 |
Zeno` |
kilbith, no... I have objective tests |
| 16:32 |
kilbith |
on your i7, maybe yeah |
| 16:32 |
VanessaE |
kilbith: yeah -- one function is 5x faster, another is 3x, another is 10x... that's already 18x. ;) |
| 16:33 |
kilbith |
not the same output on my celeron |
| 16:33 |
Zeno` |
no; CPU independent |
| 16:33 |
Zeno` |
my profiling methodology doesn't care about cores or how fast the CPU is |
| 16:34 |
Zeno` |
it's just "self cost (relative)" |
| 16:34 |
Zeno` |
no more, no less, and there cannot be argument :P |
| 16:34 |
kilbith |
the announced +20 FPS or +30 FPS on each of earlier commits was not noticable at all for me |
| 16:34 |
kilbith |
your commits* |
| 16:34 |
Zeno` |
FPS is a bogus measurement |
| 16:35 |
kilbith |
this is what you claimed in the PRs |
| 16:35 |
Zeno` |
I really quoted FPS gains? |
| 16:35 |
kilbith |
yep |
| 16:35 |
Zeno` |
If so I was wrong. |
| 16:35 |
VanessaE |
kilbith: RAM performance will kill those FPS improvements believe it or not |
| 16:35 |
VanessaE |
because so much of Minetest is CPU-bound instead of being handled by the graphics device |
| 16:35 |
Zeno` |
I normally only ever quote cycle percentage relative percentages |
| 16:36 |
VanessaE |
which in turn makes it depend on RAM and bus performance as well |
| 16:36 |
kilbith |
but there was certainly an overall optimizing, i observe +10FPS between .10 and .11 |
| 16:36 |
Zeno` |
maybe at the start I got carried away, it's so long ago I can't remember. But, yes, FPS is not a valid measurement |
| 16:38 |
Zeno` |
I can't imagine myself quoting FPS improvements and not qualifying the statement with "on my machine" |
| 16:38 |
Zeno` |
but who knows... I am crazy after all |
| 16:38 |
kilbith |
in *some* or your PRs |
| 16:38 |
kilbith |
but anyways, doesn't matter now |
| 16:38 |
kilbith |
*of |
| 16:53 |
|
SopaXorzTaker joined #minetest-dev |
| 16:55 |
Zeno` |
nrzkt: http://dpaste.com/3ZQS615 |
| 16:55 |
Zeno` |
may or may not be relevant... it could be just a coincidence as I mentioned |
| 16:56 |
nrzkt |
955 blocks ? it's huge |
| 16:56 |
nrzkt |
This can explain some memory leaks on server, if the deserializeLongString has memory problems :( |
| 16:57 |
Zeno` |
oh, those are particles |
| 16:57 |
Zeno` |
should just disable that crap |
| 16:57 |
nrzkt |
i go back home, see you ! |
| 16:58 |
Zeno` |
it's not the same possible leak as I got before |
| 16:58 |
Zeno` |
oh, he's gone |
| 16:58 |
VanessaE |
he'll be back |
| 16:58 |
Zeno` |
3AM here |
| 16:58 |
Zeno` |
I think I must rest :) |
| 17:00 |
|
roniz joined #minetest-dev |
| 17:00 |
Zeno` |
http://dpaste.com/1R891VG |
| 17:03 |
|
Hunterz joined #minetest-dev |
| 17:05 |
|
jin_xi joined #minetest-dev |
| 17:14 |
|
Wayward_One joined #minetest-dev |
| 17:26 |
|
Jordach joined #minetest-dev |
| 17:29 |
|
MinetestForFun joined #minetest-dev |
| 17:38 |
|
Tablet_One joined #minetest-dev |
| 17:39 |
|
Tablet_Two joined #minetest-dev |
| 17:39 |
|
Krock joined #minetest-dev |
| 17:41 |
|
ElectronLibre joined #minetest-dev |
| 17:51 |
|
Tablet_One joined #minetest-dev |
| 17:56 |
|
paramat joined #minetest-dev |
| 18:01 |
paramat |
hi hmmmm please could you approve my generate_ores/decos PR? #2533 |
| 18:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/2533 -- lua_api/l_mapgen: Fix volume of minetest.generate_ores/decorations to mapchunk volume by paramat |
| 18:31 |
|
roniz_ joined #minetest-dev |
| 18:34 |
|
rubenwardy joined #minetest-dev |
| 18:40 |
|
est31 joined #minetest-dev |
| 18:59 |
|
shadowzone joined #minetest-dev |
| 19:04 |
|
misprint joined #minetest-dev |
| 19:04 |
|
ekem joined #minetest-dev |
| 19:10 |
|
shadowzone joined #minetest-dev |
| 19:30 |
|
Tesseract joined #minetest-dev |
| 19:38 |
|
FR^2 joined #minetest-dev |
| 19:40 |
|
paramat left #minetest-dev |
| 19:46 |
|
hmmmm joined #minetest-dev |
| 19:55 |
|
MinetestForFun joined #minetest-dev |
| 20:04 |
|
shadowzone joined #minetest-dev |
| 20:06 |
|
casimir joined #minetest-dev |
| 20:08 |
casimir |
Greetings. In just updated my minetest after a while. And I'm mildly shocked. Why do no-fancy leaves look that ugly? Why did it crash when I wanted to craft something, and why do I have damage-flash and sound when damage is turned of? What is happening to this game? |
| 20:10 |
hmmmm |
do you have anisotropic, bilinear, or trilinear filtering enabled? |
| 20:11 |
casimir |
No. It has nothing to do with this. |
| 20:12 |
hmmmm |
you're sure you don't have them enabled? |
| 20:12 |
hmmmm |
you shouldn't notice any 'ugliness' with leaves in that case |
| 20:12 |
hmmmm |
could you take a screenshot of what you mean? |
| 20:12 |
casimir |
I'm sure. Screenshot incoming. |
| 20:13 |
hmmmm |
are you using a custom texture pack |
| 20:14 |
casimir |
http://screenshot.ru/upload/images/2015/03/23/screenshot_12123900148dad8.png |
| 20:15 |
hmmmm |
could you give a screenshot of the same scene with texture_clean_transparent = false? |
| 20:15 |
hmmmm |
also what video card do you have? |
| 20:17 |
casimir |
Ok, with this setting they look how they are supposed to. Is it new? |
| 20:17 |
est31 |
VanessaE, you there? |
| 20:17 |
hmmmm |
yeah it's new |
| 20:17 |
hmmmm |
you weren't supposed to see any difference unless you had some kind of filtering enabled |
| 20:18 |
hmmmm |
also can you give a backtrace of the crafting crash? |
| 20:18 |
hmmmm |
as far as the last thing you mentioned: i saw you are using 0.5.0-dev, not the master branch |
| 20:18 |
hmmmm |
this is fixed in the master branch |
| 20:19 |
kilbith |
casimir, no-fancy leaves disable the alpha channel in the texture, now you no longer see the odd black background on them |
| 20:20 |
est31 |
VanessaE, I have bisected the issue you had concerns about, and it is 1b2f64473ed4f222d3b7f02df853730d4382105e. |
| 20:20 |
est31 |
(the move stuff from craft field to inventory and back one earlier today) |
| 20:21 |
casimir |
thank you hmmmm |
| 20:21 |
est31 |
s/it is/its caused by/ |
| 20:22 |
casimir |
kilbith, I use a dark green background for that reason, and that looks much better. |
| 20:23 |
kilbith |
well, now instead of having the patterns + the plain background on them, the leaves are just mixed |
| 20:23 |
casimir |
About the crash, I have nothing in my logs. |
| 20:23 |
|
MinetestForFun_ joined #minetest-dev |
| 20:28 |
|
shadowzone joined #minetest-dev |
| 20:35 |
est31 |
VanessaE, see #2544 |
| 20:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/2544 -- Moving items into crafing grid and back got glitchy (regression) on dreambuilder |
| 20:38 |
Warr1024 |
we probably never tested some of the filtering with non-fancy leaves because it doesn't really seem to make much sense to have fancy everything EXCEPT leaves... |
| 20:38 |
est31 |
btw the optimisation commits that were merged recently are only about the other direction: output -> input |
| 20:38 |
Warr1024 |
how are fancy leaves implemented? Are they part of the engine, or part of _game? |
| 20:39 |
Warr1024 |
seems like it would have been better to actually use a separate texture for leaves when non-fancy... |
| 20:40 |
est31 |
my suspicion on 2544 is though that it only exposes a deeper issue. I had similar problems with pipeworks sorttube buttons already. there is even a feature request issue by me... |
| 20:41 |
|
Ritchie joined #minetest-dev |
| 20:45 |
|
Robert_Zenz joined #minetest-dev |
| 20:54 |
|
Hunterz joined #minetest-dev |
| 20:59 |
|
Hunterz joined #minetest-dev |
| 20:59 |
|
paramat joined #minetest-dev |
| 21:00 |
|
Hunterz left #minetest-dev |
| 21:02 |
paramat |
damage flash when falling or underwater, when damage is disabled, is not fixed yet |
| 21:03 |
paramat |
anyone know why my fork of master often says 0.5dev in the corner of the screen? i only use master branch |
| 21:04 |
paramat |
version detection seems buggy |
| 21:07 |
hmmmm |
is casmir using your fork??? |
| 21:08 |
paramat |
nope |
| 21:08 |
hmmmm |
hmm |
| 21:08 |
hmmmm |
anyway, about 2533 |
| 21:08 |
paramat |
i suspect casimir's screenshot is actually master branch, but displays 0.5dev on the screen as mine does |
| 21:09 |
hmmmm |
there definitely is value in keeping area parameters for generate_decorations and so on |
| 21:09 |
hmmmm |
so when you added it, people had to change their code if they used it already, right? |
| 21:09 |
|
shadowzone joined #minetest-dev |
| 21:09 |
hmmmm |
changing it back would be even worse now |
| 21:09 |
paramat |
yes |
| 21:09 |
hmmmm |
why not make it an optional parameter |
| 21:10 |
hmmmm |
i'm still not sure what would make the most sense in terms of "do things inside a voxelmanip" apis |
| 21:10 |
hmmmm |
it's very likely that whenever somebody is going to a). calculate lighting, b). update liquids, c). place ores and decorations they're probably doing it from the context of a mapgen voxelmanip |
| 21:11 |
paramat |
i only know of one modder using generate_ores/decos, changing back would make their original code work, so better for them |
| 21:11 |
hmmmm |
hrmmm |
| 21:11 |
paramat |
but with minp, maxp this time as it should be |
| 21:12 |
hmmmm |
i think we should make the two pmin/pmax parameters optional |
| 21:12 |
hmmmm |
what about you? |
| 21:12 |
hmmmm |
and getBlockSeed should use pmin as its position |
| 21:12 |
paramat |
..and default to minp/maxp |
| 21:12 |
hmmmm |
right |
| 21:13 |
hmmmm |
well minp/max would default to the inner edge of a mapgen voxelmanip |
| 21:13 |
hmmmm |
but this way if somebody has a voxelmanip that isn't from the mapgen, they're able to make it work |
| 21:13 |
paramat |
i'm sorta neutral but can't see a use for p1/p2 |
| 21:13 |
hmmmm |
well like i just said |
| 21:13 |
hmmmm |
if somebody is decorating from within a non-mapgen voxelmanip |
| 21:13 |
hmmmm |
then having a p1/p2 would be absolutely necessary |
| 21:13 |
paramat |
ah |
| 21:14 |
paramat |
okay i'll make it optional p1/p2 |
| 21:14 |
hmmmm |
you might be wondering why anybody would generate ores and decorations in a non-mapgen voxelmanip |
| 21:14 |
hmmmm |
i am too, but you never know until it happens |
| 21:14 |
paramat |
yeah |
| 21:14 |
hmmmm |
things get used in very interesting and innovative ways |
| 21:15 |
paramat |
and these optional p1/p2 should be checked for validity and sorted |
| 21:15 |
hmmmm |
heh I think I just thought of a potential use for modifying hud in an on_generate callback |
| 21:15 |
hmmmm |
well |
| 21:15 |
hmmmm |
we'll change all the push_v3s16s to check_v3s16s in a different commit |
| 21:16 |
paramat |
yeah, as i don't know how to check validity |
| 21:16 |
paramat |
i'll just sort |
| 21:16 |
paramat |
#2543 |
| 21:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/2543 -- Mgv6: Use heightmap in placeTreesAndJungleGrass() by paramat |
| 21:17 |
hmmmm |
v3s16 pmin = lua_istable(L, 2) ? read_v3s16(L, 2) : mg.vm->m_area.MinEdge + v3s16(1,1,1) * MAP_BLOCKSIZE; |
| 21:17 |
hmmmm |
like that |
| 21:17 |
paramat |
ah okay |
| 21:18 |
hmmmm |
2543 looks good |
| 21:19 |
paramat |
oh and blockseed should be either p1 or default minp? |
| 21:19 |
hmmmm |
just make it minp |
| 21:19 |
hmmmm |
erm, p1 after sorting |
| 21:19 |
hmmmm |
it should be "the minimum coordinate that generation is going to happen at" |
| 21:20 |
paramat |
ah okay |
| 21:22 |
|
roniz joined #minetest-dev |
| 21:22 |
|
DFeniks joined #minetest-dev |
| 21:26 |
VanessaE |
est31: I am here now. I see the issue you filed. |
| 21:26 |
* VanessaE |
sighs |
| 21:27 |
est31 |
as I said it might have only exposed an already existing issue better I'm not sure. |
| 21:27 |
VanessaE |
possible |
| 21:30 |
paramat |
hmmmmm when you left c55 made me mapgen manager, but i said 'only while hmmmmm is gone', and your name remains on the wiki. i'm not too bothered either way but would it be useful to share the position such that i can reduce your workload by doing the simpler stuff? not sure it makes much difference anyway as i need your approval for PRs |
| 21:30 |
VanessaE |
that needs added as a line item to #2524 then |
| 21:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/2524 -- Issues with new network code |
| 21:31 |
hmmmm |
it doesn't matter |
| 21:31 |
VanessaE |
or at least referenced. |
| 21:31 |
hmmmm |
what matters is the code |
| 21:39 |
jin_xi |
non mapgen vmanip is still necessary if you want to do anything fancy, ie lua generated, unless you do the whole mapgen in lua |
| 21:44 |
paramat |
yep |
| 21:48 |
VanessaE |
est31: come to think of it, even *placing* an object seems kinda laggy now. |
| 21:48 |
VanessaE |
I don't recall e.g. pipeworks pipes having a visible lag between placement and the autorouter kicking in. |
| 21:50 |
est31 |
there is such a lag |
| 21:50 |
est31 |
I had it for technic cables on VE-S enough times |
| 21:51 |
est31 |
ofc only when the server is under load too |
| 21:51 |
VanessaE |
yeah but in singleplayer, in a test world that's totally idle? |
| 21:51 |
paramat |
now pushing 2543, will notify when done |
| 21:53 |
est31 |
is that the same issue btw? |
| 21:53 |
|
ElectronLibre left #minetest-dev |
| 21:53 |
est31 |
could you confirm that the commit from my report introduces the placing lag? |
| 21:56 |
VanessaE |
sure, lemme check |
| 22:00 |
paramat |
push complete |
| 22:00 |
VanessaE |
I've rolled back to 038d3a31 (one commit before 1b2f644), and am not seeing nearly as much placement delay or glitchiness now. |
| 22:00 |
VanessaE |
s/glitchiness/crafting grid glitchiness/ |
| 22:00 |
VanessaE |
so that should be enough to confirm your report |
| 22:04 |
VanessaE |
added my comments to 2544 |
| 22:04 |
hmmmm |
well |
| 22:04 |
hmmmm |
it seems to be a pretty big problem |
| 22:05 |
hmmmm |
i think maybe the offending commit should be reverted until it's solved |
| 22:05 |
hmmmm |
as for the clean_transparent_textures, we can solve that problem by setting it to disabled by default |
| 22:06 |
hmmmm |
i tested these commits too and they seemed okay at the time :( |
| 22:50 |
|
devmarth joined #minetest-dev |
| 22:55 |
|
paramat left #minetest-dev |
| 23:33 |
|
devmarth joined #minetest-dev |
