| Time |
Nick |
Message |
| 00:01 |
Warr1024 |
hmmmm: I thought about making "smart" defaults, but wasn't sure if the feature was mature enough... |
| 00:02 |
VanessaE |
Warr1024: regarding the scaling, I'd personally have chosen 64px as the "sane default" also |
| 00:03 |
VanessaE |
(though I'll still turn it up for my own box) |
| 00:04 |
Warr1024 |
I guess it could be ok to set min_size to 1 and clean_trans to off, but set them to 64 and true if anything besides mips are enabled. |
| 00:05 |
est31 |
what is the problem now? |
| 00:06 |
VanessaE |
est31: no problem, per se. just a matter of the game choosing sane defaults |
| 00:06 |
VanessaE |
Warr1024: good idea. |
| 00:06 |
Warr1024 |
The whole "aniso implies linear" seems to be more common than not in my experience |
| 00:06 |
VanessaE |
does setting it to 1 in fact actually "skip" the prescaling code? |
| 00:06 |
VanessaE |
(if not, it should) |
| 00:07 |
Warr1024 |
not explicitly, but it's a short path in practice anyway |
| 00:07 |
VanessaE |
also I noticed where you were pulling from the settings in multiple places, instead of doing it just once and referencing the result |
| 00:07 |
VanessaE |
you may want to fix that |
| 00:08 |
Warr1024 |
it should be only once per image, but I wasn't sure the convention for doing it once per game |
| 00:09 |
Warr1024 |
zeno mentioned that too, but said it'd br easy enough to fix later... |
| 00:09 |
VanessaE |
yeah. there's a push to just do *all* of the settings in some kind of once-at-the-start construct, but idk what the final decision is on that |
| 00:10 |
VanessaE |
(well all of those which can be done only at the start anyway) |
| 00:11 |
Warr1024 |
might not be too bad to have a few caches by type of the already-parsed values, and invalidate them upon setting one |
| 00:12 |
Warr1024 |
would be a nice encapsulation too... |
| 00:17 |
est31 |
hmmmm, can you close #2449 please? Commit at latest head fixes that. |
| 00:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/2449 -- Eating not updating hud |
| 00:24 |
|
shadowzone joined #minetest-dev |
| 00:30 |
|
prozacgod joined #minetest-dev |
| 00:31 |
WarrTab |
Progress on the gui scaling |
| 00:31 |
WarrTab |
It now kinda works a little on android |
| 00:31 |
WarrTab |
Rtt's don't work |
| 00:32 |
WarrTab |
Though inventorycube was always broken, but now rtt's are too... |
| 00:32 |
WarrTab |
But all 2d stuff seems to be good... |
| 00:32 |
VanessaE |
sapier ended up having to resort to a really nasty hack with RTT: |
| 00:32 |
VanessaE |
exploit the screenshot function. |
| 00:33 |
VanessaE |
at least at one point he did |
| 00:33 |
WarrTab |
I think it's still quite hacky |
| 00:33 |
WarrTab |
I wonder how inventorycube differs |
| 00:33 |
VanessaE |
I forget why he did that, though |
| 00:34 |
WarrTab |
And why it never worked |
| 00:34 |
WarrTab |
I think fixing gui scaling might involve fixing rtt on android |
| 00:35 |
WarrTab |
I might try just writing a really simple naive renderer to prove its doable... |
| 00:47 |
WarrTab |
Oh god why does ^[inventorycube not use the rtt code above that at least has working hacks, even if they're hacks? |
| 00:47 |
VanessaE |
why is anything still *using* ^[inventorycube at all? |
| 00:48 |
WarrTab |
I used it |
| 00:48 |
VanessaE |
you shouldn't need it at all anymorpe |
| 00:48 |
VanessaE |
anymore* |
| 00:48 |
WarrTab |
I wanted a craftitem that looked like a node, bit wasn't |
| 00:48 |
VanessaE |
ah |
| 00:48 |
VanessaE |
well I guess for that, it's useful |
| 00:49 |
WarrTab |
also if you want yo overlay some 2d over a fake-3d node |
| 00:49 |
VanessaE |
but for example default glass still uses it for no reason |
| 00:49 |
WarrTab |
Though it won't work with nodebox |
| 00:49 |
VanessaE |
inventory_image = minetest.inventorycube("default_glass.png"), |
| 00:49 |
WarrTab |
Or really most drawtypes |
| 00:50 |
WarrTab |
no, that inventorycube on glass actually DOES have an effect... |
| 00:50 |
WarrTab |
...it pisses off android users :-) |
| 00:50 |
VanessaE |
HAHA |
| 00:51 |
WarrTab |
In principle I should be able to make inventorycube work on android, though, by refaccing and reusing the hacked-but-working code above |
| 00:52 |
WarrTab |
When sapier tested this, he must have ised bars in his windows instead of glass :-) |
| 00:53 |
WarrTab |
I suspect that the issue with the rest of shit might be memory aliasing... |
| 00:56 |
VanessaE |
lol |
| 01:06 |
WarrTab |
Or use-after-free, maybe |
| 01:06 |
WarrTab |
The irrlicht refcounting stuff is a bit arcane |
| 01:29 |
|
WarrTab joined #minetest-dev |
| 01:32 |
|
zat joined #minetest-dev |
| 01:46 |
|
Taoki joined #minetest-dev |
| 01:48 |
WarrTab |
Ok, I'm tempted to just say "doesn't work on android for now" and leave it at that... |
| 01:49 |
WarrTab |
Basically, I don't know if the bug in guiscaling on android can be fixed without fixing the other bugs anyway |
| 01:50 |
WarrTab |
Fixing rtt and inventorycube on android might be beyond me |
| 01:51 |
WarrTab |
Or at least I'll need to make incremental builds for android work for me |
| 01:53 |
WarrTab |
Maybe if I ger it working well enough for desktop, one of the android experts in here can help me figure out the android issues |
| 02:23 |
|
crazyR joined #minetest-dev |
| 02:23 |
|
crazyR joined #minetest-dev |
| 03:02 |
|
Tablet_One joined #minetest-dev |
| 03:32 |
|
Tablet_One joined #minetest-dev |
| 03:45 |
|
Zeno` joined #minetest-dev |
| 04:02 |
hmmmm |
https://github.com/kwolekr/minetest/commit/2267313eb0343ffa6a7586aab93afad1b00358c5 |
| 04:19 |
Zeno` |
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/rand_r.c;h=1098ffb7451b3f4ea042cac83f14a47470db21ce;hb=HEAD |
| 04:19 |
hmmmm |
? |
| 04:19 |
Zeno` |
The example in K&R actually seems to be that used by ANSI-C :-o |
| 04:19 |
Zeno` |
(that's the re-entrant version) |
| 04:20 |
hmmmm |
what why... |
| 04:20 |
hmmmm |
there are so many BETTER random algos out there |
| 04:20 |
Zeno` |
I suppose so that rand() is consistent across platforms :/ |
| 04:21 |
Zeno` |
I never realised rand() was so bad |
| 04:21 |
hmmmm |
well |
| 04:22 |
hmmmm |
I took the bottom 8 bits of that rand's output for each byte printed to stdout when I tested it using dieharder |
| 04:22 |
hmmmm |
and it failed over half the tests |
| 04:22 |
hmmmm |
imagine if i used all 15 bits of enthropy |
| 04:24 |
Zeno` |
yeah. BSD uses the same |
| 04:24 |
hmmmm |
*freebsd*? |
| 04:25 |
hmmmm |
I tested my libc's rand too and it passed everything |
| 04:25 |
Zeno` |
weird |
| 04:25 |
hmmmm |
the way glibc and bsd libc use it must make a huge difference |
| 04:25 |
Zeno` |
must do |
| 04:25 |
Zeno` |
anyway your fork looks good |
| 04:26 |
hmmmm |
now all I need to do is convince modders to use PcgRandom instead |
| 04:26 |
Zeno` |
http://svnweb.freebsd.org/base/head/lib/libc/stdlib/rand.c?view=markup |
| 04:26 |
Zeno` |
there is an #ifdef |
| 04:27 |
hmmmm |
yeah |
| 04:27 |
hmmmm |
oh yeah I remember looking at this when I was doing tests initially |
| 04:27 |
hmmmm |
Zeno`, you should try running glibc rand() in dieharder since you use linux :-) |
| 04:28 |
Zeno` |
i think I might :) |
| 04:28 |
hmmmm |
#include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { srand(time(NULL)); while (1) putc(rand() & 0xFF); } |
| 04:28 |
hmmmm |
then ./yourprog | dieharder -a -d 200 |
| 04:29 |
hmmmm |
or, well, maybe you should use more than the bottom 8 bits, but you get the idea |
| 04:29 |
Zeno` |
grrr... is there a non-svn link to download dieharder? |
| 04:30 |
Zeno` |
meh, I have svn installed anyway |
| 04:30 |
hmmmm |
no idea.. i got it from pkg |
| 04:31 |
Zeno` |
oh |
| 04:31 |
Zeno` |
I can as well :) |
| 04:31 |
Zeno` |
didn't expect it to be there |
| 04:33 |
Zeno` |
I will use putchar instead of putc |
| 04:34 |
Zeno` |
seems to take a while to run |
| 04:34 |
hmmmm |
oh yeah it does |
| 04:34 |
hmmmm |
about 40 minutes on my xeon e3-1230v2 |
| 04:35 |
Zeno` |
everything passed so far |
| 04:35 |
hmmmm |
btw read http://www.pcg-random.org/pdf/toms-oneill-pcg-family-v1.02.pdf if you're interested |
| 04:35 |
Zeno` |
wait a sec... is this working? |
| 04:36 |
Zeno` |
I'll dpaste |
| 04:36 |
Zeno` |
http://dpaste.com/39F1J18 |
| 04:36 |
Zeno` |
why is it using mersene twister? |
| 04:37 |
hmmmm |
did i give you the wrong command line params? uh oh |
| 04:37 |
* hmmmm |
checks |
| 04:37 |
hmmmm |
yes i did. should be -a -g 200 :( sorry |
| 04:37 |
Zeno` |
ok restarting :) |
| 04:38 |
Zeno` |
MT is doing well though |
| 04:38 |
hmmmm |
ahh I said -d |
| 04:38 |
hmmmm |
yeah of course |
| 04:38 |
hmmmm |
personally, when i tried it, it only got two "weak" ratings |
| 04:39 |
Zeno` |
only had one weak when i stopped it: sts_serial| 15| 100000| 100|0.99649720| WEAK (obviously would be the same as your result) |
| 04:39 |
Zeno` |
I'm guessing glibc must do something different as well because they're all passing for now |
| 04:39 |
* Zeno` |
downloads glibc source so he can look more closely |
| 04:40 |
hmmmm |
i doubt it changed from the link you pasted |
| 04:40 |
hmmmm |
how are you printing it to stdout? |
| 04:40 |
Zeno` |
putchar |
| 04:40 |
Zeno` |
int main(int argc, char *argv[]) { srand(time(NULL)); while (1) putchar(rand() & 0xFF); } |
| 04:40 |
hmmmm |
oh okay |
| 04:40 |
hmmmm |
so you're only using the low 8 bits too |
| 04:41 |
Zeno` |
perhaps fedora uses a modified glibc (wouldn't surprise me, lol) |
| 04:41 |
hmmmm |
unless i'm misunderstanding something, the only difference between the glibc and the minetest rand is that glibc is skipping 2 numbers per call |
| 04:41 |
hmmmm |
or maybe that RNG is a lot stronger than we thought, and minetest just implemented it in a weak manner |
| 04:45 |
hmmmm |
shoot =] |
| 04:45 |
hmmmm |
I just noticed a problem I introduced when cleaning up PseudoRandom |
| 04:45 |
Zeno` |
maybe |
| 04:46 |
Zeno` |
it's doing the rgb tests now and only one failure |
| 04:49 |
hmmmm |
https://github.com/kwolekr/minetest/commit/3993093f51544d4eb44efb57c973e29107ea2f7a |
| 04:49 |
hmmmm |
I keep using uintXX_t instead of uXX |
| 04:51 |
Zeno` |
wtf are these rgb_lagged_sum tests doing |
| 04:51 |
Zeno` |
they take longer than the rest combined |
| 04:55 |
hmmmm |
I think it's trying to correlate X length bitstrings with the rest of the output |
| 04:56 |
Zeno` |
unless something else is "weak" from this point on everything but one passed |
| 04:57 |
* Zeno` |
wonders if glibc uses something different... it must |
| 04:57 |
Zeno` |
after this I'll copy paste some algorithms |
| 04:58 |
hmmmm |
yeah, minetest's rendition had almost half of the results as failures |
| 04:58 |
Zeno` |
second failure |
| 04:58 |
hmmmm |
and as far as i can tell there's no functional difference between the two aside from glibc skipping two randoms |
| 04:59 |
Zeno` |
http://dpaste.com/1SQ794C |
| 05:00 |
Zeno` |
This is annoying. Now I have to find out what rand() is using :( |
| 05:02 |
Zeno` |
err |
| 05:02 |
Zeno` |
https://github.com/lattera/glibc/blob/master/stdlib/random_r.c |
| 05:02 |
Zeno` |
https://github.com/lattera/glibc/blob/master/stdlib/random_r.c#L371 |
| 05:02 |
Zeno` |
I wonder how it chooses what "type" to use |
| 05:03 |
hmmmm |
well it looks like you were testing "our fancy trinomial stuff" |
| 05:04 |
Zeno` |
yes I think so :D |
| 05:08 |
Zeno` |
god I hate the GNU brace style |
| 05:18 |
Zeno` |
lol |
| 05:18 |
Zeno` |
I am getting much better results now |
| 05:19 |
Zeno` |
http://dpaste.com/0NADT7P |
| 05:19 |
Zeno` |
(src included). Nothing passed so far. This is great |
| 05:22 |
|
JeDaYoshi joined #minetest-dev |
| 05:27 |
|
prozacgod joined #minetest-dev |
| 05:27 |
|
book` joined #minetest-dev |
| 06:11 |
hmmmm |
argh |
| 06:12 |
hmmmm |
dammit, paramat, why didn't you make generate_ores/decorations have p1 p2 be optional |
| 06:16 |
|
Tablet_One joined #minetest-dev |
| 06:18 |
|
Megaf_ joined #minetest-dev |
| 06:25 |
Zeno` |
https://github.com/kwolekr/minetest/commit/3993093f51544d4eb44efb57c973e29107ea2f7a#diff-394cf121b2cc4085d04fc6487fdfadbfR109 |
| 06:25 |
Zeno` |
Please put semicolon on next line :) |
| 06:26 |
Zeno` |
hmmmm ^^ |
| 06:26 |
hmmmm |
okay |
| 06:34 |
Zeno` |
hmmmm, what is randNormalDist() ? |
| 06:34 |
|
Tablet_One joined #minetest-dev |
| 06:34 |
hmmmm |
hey i thought you reviewed it already |
| 06:34 |
Zeno` |
and why is accum u32? |
| 06:34 |
Zeno` |
I am re-reviewing :) |
| 06:35 |
hmmmm |
good catch |
| 06:35 |
hmmmm |
i had an internal debate on what datatypes i should be using |
| 06:35 |
hmmmm |
i must've changed my mind 50 times over |
| 06:35 |
hmmmm |
"naw, let the caller adjust the range if they want something negative" |
| 06:35 |
hmmmm |
"naw, let's be consistent with PseudoRandom" |
| 06:36 |
hmmmm |
"yeah, but this interface is imposed on the lua api too |
| 06:38 |
Zeno` |
lol |
| 06:39 |
Zeno` |
*sigh* /me writes types.h so he can extract the code and test it outside of minetest |
| 06:39 |
Zeno` |
I was re-reviewing because I read some articles about the method you're using btw ;) |
| 06:39 |
hmmmm |
use uint32_t instead, i dare ya |
| 06:39 |
Zeno` |
it's pretty interesting |
| 06:40 |
hmmmm |
watch the reports about "it doesn't compile on debian Slow Snail v7.0 |
| 06:40 |
Zeno` |
it doesn't have stdint.h? |
| 06:41 |
hmmmm |
the stdint.h include doesn't propogate its way to where it's being used *on their system* |
| 06:41 |
Zeno` |
their system must be broken |
| 06:41 |
hmmmm |
due to some very specific combination of platform and standard header versions |
| 06:41 |
Zeno` |
next! |
| 06:41 |
hmmmm |
also: windows. |
| 06:42 |
Zeno` |
broken |
| 06:42 |
|
prozacgod joined #minetest-dev |
| 06:43 |
Zeno` |
seems I already have a types.h |
| 06:43 |
hmmmm |
#include <irrlicht/irrTypes.h> |
| 06:44 |
Zeno` |
http://dpaste.com/3A7WKXF |
| 06:44 |
Zeno` |
broken on windows and debian |
| 06:46 |
hmmmm |
whoops. I see a bug |
| 06:47 |
hmmmm |
great job, you were supposed to review my code! |
| 06:47 |
Zeno` |
I found one bug |
| 06:47 |
Zeno` |
umm, why is github not letting me look at the raw file :/ |
| 06:48 |
hmmmm |
didn't update len if out is unaligned in PcgRandom::bytes() |
| 06:48 |
hmmmm |
ooops. |
| 06:54 |
|
Tablet_One joined #minetest-dev |
| 06:58 |
Zeno` |
hmm |
| 06:59 |
Zeno` |
hmmmm, is it updated now? |
| 06:59 |
hmmmm |
https://github.com/minetest/minetest/commit/761b127060b924a43a79c72d5488dbe9c186acc0 |
| 07:03 |
|
Hunterz joined #minetest-dev |
| 07:04 |
Zeno` |
nope it's no goof |
| 07:04 |
Zeno` |
good* |
| 07:04 |
Zeno` |
diehard_operm5| 0| 1000000| 100|0.99994079| WEAK |
| 07:04 |
hmmmm |
all prngs get at least 4 weaks |
| 07:04 |
Zeno` |
ok I'll let it have a few |
| 07:05 |
hmmmm |
the point is that it's a massive improvement over minetest's original algorithm that were half failures |
| 07:05 |
Zeno` |
of course ;) |
| 07:06 |
Zeno` |
Is it fast enough? |
| 07:07 |
hmmmm |
i dunno it's just a bunch of bitshifts |
| 07:07 |
hmmmm |
it should be okay |
| 07:07 |
Zeno` |
nevermind, starting test again (forgot -O2) |
| 07:08 |
Zeno` |
yeah it's fast |
| 07:08 |
hmmmm |
F... i see another bug |
| 07:09 |
hmmmm |
dammit zeno i thought you reviewed my stuff!!! |
| 07:10 |
hmmmm |
heh, can you find it? it's in PcgRandom::bytes() again |
| 07:11 |
Zeno` |
I didn't know the algorithm in first review! :P |
| 07:11 |
hmmmm |
well this doesn't have to do with the algorithm itself, just how i blit data |
| 07:12 |
Zeno` |
r = next()? |
| 07:13 |
Zeno` |
nope I can't see it |
| 07:14 |
hmmmm |
endianness |
| 07:14 |
Zeno` |
ok, yes :) |
| 07:14 |
hmmmm |
i can see the PR, "help, on android all my maps are different!" |
| 07:15 |
hmmmm |
"there's a cave always at (x, y, z) using seed = 123 when I play on android, but it's different on PC!" |
| 07:15 |
Zeno` |
feature? |
| 07:16 |
hmmmm |
oh no no |
| 07:16 |
hmmmm |
i keep forgetting, minetest PR == Pull Request, work PR == Problem Report |
| 07:17 |
Zeno` |
haha |
| 07:17 |
|
selat joined #minetest-dev |
| 07:17 |
hmmmm |
well I suppose we love adding problem reports here at minetest inc. |
| 07:17 |
VanessaE |
well with minetest, doesn't the former lead to the latter anyway? :P |
| 07:17 |
Zeno` |
true, true |
| 07:18 |
hmmmm |
VanessaE: yeah it does |
| 07:18 |
|
Tablet_One joined #minetest-dev |
| 07:19 |
hmmmm |
oh. yeah. |
| 07:19 |
hmmmm |
VanessaE: you should switch from PseudoRandom to PcgRandom in your mods |
| 07:20 |
VanessaE |
that would be plants_lib, only place I use random numbers. ok, will do. |
| 07:20 |
hmmmm |
also take a look at PcgRandom.rand_normal_dist(). in laymans terms, you won't have an equal number of cacti that have height of 1, height of 2, etc. |
| 07:21 |
VanessaE |
are you employing that algo in things like the spawn_tree() call also? |
| 07:21 |
hmmmm |
you'd have by far the most of them "in between" min and max, and as the values get more extreme, they occur rarer |
| 07:21 |
hmmmm |
not yet, still need to do that |
| 07:21 |
VanessaE |
ok |
| 07:22 |
VanessaE |
actually you know what, I actually use math.random() everywhere, not even PseudoRandom. |
| 07:22 |
hmmmm |
oh, that's totally uniform then |
| 07:23 |
hmmmm |
well, you can do the same thing that rand_normal_dist does internally to get the same kind of bell-curved distribution of random samples |
| 07:25 |
Zeno` |
this is much faster than math.rand() (well, excluding the rand_normal_dist()) |
| 07:25 |
Zeno` |
heaps faster |
| 07:25 |
VanessaE |
sounds like a good idea to switch then. |
| 07:25 |
Zeno` |
that means a lot |
| 07:25 |
hmmmm |
scratches head |
| 07:25 |
VanessaE |
(I've no real need for uniform distribution) |
| 07:26 |
hmmmm |
math.random() is that slow??? |
| 07:26 |
Zeno` |
it's not *that* slow, but compared to this it is |
| 07:26 |
hmmmm |
that's incredible. i never would have expected that |
| 07:26 |
Zeno` |
must be those fancy trinomials |
| 07:26 |
hmmmm |
lol |
| 07:29 |
Zeno` |
rand() calls three libc functions: rand, random and random_r with a summed cost of 50.5% |
| 07:30 |
Zeno` |
PcgRandom::next() costs 20.6% |
| 07:31 |
Zeno` |
(these are self costs) |
| 07:31 |
hmmmm |
heh you certainly do love your callgrind |
| 07:31 |
Zeno` |
which in this case is the same as inclusive anyway |
| 07:31 |
Zeno` |
well, I had to check! |
| 07:31 |
Zeno` |
can't have slow crap being added |
| 07:31 |
Zeno` |
heh |
| 07:32 |
* Zeno` |
will give it a tick of approval |
| 07:32 |
Zeno` |
it's like a stamp of zenoness |
| 07:33 |
hmmmm |
you know i actually put PseudoRandom into its own executable and, lo and behold, even after -O3 on the most current gcc and clang available to me, it will not inline |
| 07:33 |
Zeno` |
VanessaE, I'm talking about rand() because Lua uses standard C's rand() C-side |
| 07:33 |
hmmmm |
i tried even using the inline keyword and it simply won't take the hint |
| 07:33 |
Zeno` |
I dunno if it needs any inlining :P |
| 07:34 |
Zeno` |
C-side, by the C-shore |
| 07:34 |
hmmmm |
yeah.. that was part of the internal debate |
| 07:34 |
hmmmm |
should PcgRandom be a derived class of PseudoRandom |
| 07:34 |
hmmmm |
"but wait, then I'd have to either change PseudoRandom's output or truncate PcgRandom's output" |
| 07:34 |
hmmmm |
"but it's so much neater!" |
| 07:35 |
Zeno` |
The only thing I might potentially worry about is the 64-bit operations but I had a huge debate with someone over this when I was doing my mersene twister and it wasn't really resolved |
| 07:35 |
Zeno` |
worry about performance wise* |
| 07:35 |
Zeno` |
but *shrug*; I doubt it matters |
| 07:36 |
hmmmm |
most of the world is on 64 bit by now i think |
| 07:36 |
Zeno` |
well, my watch isn't! |
| 07:36 |
Zeno` |
actually my watch is analogue |
| 07:36 |
Zeno` |
probably won't affect my watch |
| 07:37 |
hmmmm |
the first time I installed a 64 bit operating system |
| 07:37 |
hmmmm |
i though, phew, i have arrived into the future! |
| 07:37 |
VanessaE |
...and then you had to install win32codecs or flash plugin. :) |
| 07:37 |
hmmmm |
wine was the big killer for me |
| 07:37 |
Zeno` |
fedora doesn't even install 32-bit compat libs by default anymore |
| 07:37 |
hmmmm |
i somehow got it working |
| 07:38 |
VanessaE |
(those fucking things kept me from going 64bit for the longest time, until distro maintainers figures out the whole multiarch thing) |
| 07:38 |
Zeno` |
VanessaE, there's no 64-bit flash plugin? |
| 07:38 |
hmmmm |
FreeBSD 32 bit Linuxulator works fine :) i don't think i ever had a flash problem with 64 bit |
| 07:38 |
VanessaE |
Zeno`: not sure, but there wasn't back then |
| 07:38 |
Zeno` |
oh back then... yeah |
| 07:40 |
* Zeno` |
hopes this new PRNG doesn't affect his framerate when playing on his Eee PC |
| 07:40 |
Zeno` |
it's already only 1fps; could make it unplayable |
| 07:40 |
|
leat joined #minetest-dev |
| 07:40 |
hmmmm |
don't get why people try to play minetest on these super low-end machines |
| 07:40 |
VanessaE |
Zeno`: oh that reminds me, Warr* mentioned that his guiscaling patches may have caused a framerate drop because of the compositing workaround e.g. signs. can you confirm that? |
| 07:41 |
hmmmm |
they probably think it works in theory |
| 07:41 |
VanessaE |
(I can't be sure) |
| 07:41 |
hmmmm |
why would that cause a framerate drop? it's only applied during texture loading, isn't it? |
| 07:42 |
VanessaE |
hmmmm: because part of it has to be deferred until after all of the compositing stuff has been done (e.g. ^[combine and the like). |
| 07:42 |
hmmmm |
surely the result would become cached |
| 07:42 |
hmmmm |
i hope |
| 07:42 |
VanessaE |
idk what effect that has in the end, if any |
| 07:42 |
VanessaE |
I don't think so |
| 07:42 |
hmmmm |
sweet |
| 07:42 |
VanessaE |
if RBA were here he'd know the answer to that |
| 07:43 |
VanessaE |
his theory is that the client burns through all of the compositing commands in realtime, every frame, and doesn't cache/reuse the results |
| 07:43 |
VanessaE |
and that *that* is why lots of signs_lib signs will kill FPS (e.g. VE-S spawn area) |
| 07:44 |
hmmmm |
i sort of accepted a long time ago that i'm never going to get a decent play experience on multiplayer |
| 07:47 |
VanessaE |
I think Warr's observed lower FPS (if legit) is probably just the result of having higher resolution textures everywhere including the signs' entities, probably nothing to do with where the scaling is in the compositing chain |
| 07:48 |
Zeno` |
VanessaE, I'll look later |
| 07:48 |
Zeno` |
right now I am heading off to do stuff outside (*gasp*) |
| 07:48 |
Zeno` |
sleep well |
| 07:49 |
hmmmm |
night |
| 07:49 |
hmmmm |
i should get going tooo |
| 07:49 |
hmmmm |
night vaness |
| 07:49 |
hmmmm |
a |
| 07:49 |
VanessaE |
night |
| 07:49 |
VanessaE |
I'm off also |
| 07:49 |
hmmmm |
need to make my new bedtime be 3 am instead of 4 |
| 07:49 |
hmmmm |
hard to break the habit though, nawmean? |
| 07:49 |
VanessaE |
yup |
| 07:49 |
VanessaE |
but if you did that, |
| 07:50 |
VanessaE |
we wouldn't have had this chat ;) |
| 07:50 |
hmmmm |
:D |
| 07:50 |
VanessaE |
anyway, night |
| 07:50 |
hmmmm |
night |
| 07:52 |
|
nore joined #minetest-dev |
| 07:58 |
|
leat joined #minetest-dev |
| 08:50 |
|
MinetestForFun joined #minetest-dev |
| 08:52 |
|
nrzkt joined #minetest-dev |
| 08:53 |
|
Krock joined #minetest-dev |
| 08:53 |
nrzkt |
new stats: 185 installations on playstore :) |
| 08:55 |
|
kilbith joined #minetest-dev |
| 08:59 |
|
blaze joined #minetest-dev |
| 09:01 |
|
Calinou joined #minetest-dev |
| 09:01 |
|
Anchakor_ joined #minetest-dev |
| 09:05 |
|
jin_xi joined #minetest-dev |
| 09:15 |
|
leat joined #minetest-dev |
| 09:23 |
nrzkt |
can somes help me to find a function name for #2525 ? :) |
| 09:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2525 -- Some builtin cleanup since recent changes by nerzhul |
| 09:39 |
nrzkt |
VanessaE ? |
| 09:39 |
VanessaE |
hm? |
| 09:39 |
nrzkt |
i looked at the spawnpoint bug you mentionned, and i think it's older clients only |
| 09:40 |
nrzkt |
because the 0.4.10-12 clients use the spawnpoint given by the server, but not older clients |
| 09:41 |
VanessaE |
ohh |
| 09:41 |
nrzkt |
but i think we can "cheat" and force the position after _init to restore the function for older clients, but i need to test if this doesn't glitch the client |
| 09:41 |
|
Zeno` joined #minetest-dev |
| 09:42 |
nrzkt |
for < 0.4.10 haven't checked, but look at this as a proof: https://github.com/minetest/minetest/blob/master/src/network/clientpackethandler.cpp#L106 |
| 09:43 |
nrzkt |
pktSize > 7 on the recent clients, but not olders which ignore this param and following too |
| 09:43 |
VanessaE |
well it happens with current HEAD also |
| 09:43 |
VanessaE |
(client) |
| 09:43 |
nrzkt |
oh ? okay, then, i need to find the real issue. Is this random or can i reproduce it easily ? |
| 09:44 |
VanessaE |
it's random-ish. try joining my creative server. it will take several tries because of the ghost entity delete bug causing you to time out. you'll eventually find yourself spawned at 0,0,0 |
| 09:44 |
VanessaE |
(that bug is not your fault) |
| 09:44 |
|
leat joined #minetest-dev |
| 09:44 |
nrzkt |
strange, the static_spawnpoint param is only used un builtin lua, not in core itself |
| 09:45 |
nrzkt |
then it's not a bug with network but with core |
| 09:45 |
nrzkt |
core-lua |
| 09:45 |
VanessaE |
(you'll know it's 0,0,0 because there will be a sign on a gold block saying something about "an 'original'" something. |
| 09:45 |
VanessaE |
) |
| 09:47 |
Zeno` |
why is it 7? |
| 09:47 |
nrzkt |
https://github.com/minetest/minetest/blob/master/builtin/game/static_spawn.lua |
| 09:47 |
nrzkt |
it's handled here |
| 09:48 |
nrzkt |
it's correct for me, i look at the register_on_newplayer in core |
| 09:48 |
nrzkt |
register_on_newplayer doesn't exist in core ? |
| 09:49 |
VanessaE |
it isn't limited to new players actually |
| 09:49 |
nrzkt |
we have an api but no call, i look at this, how can this be working |
| 09:49 |
VanessaE |
regular players get teleported there too |
| 09:49 |
VanessaE |
idk why I said new players before, that was a mistake. |
| 09:50 |
nrzkt |
in stable-0.4 register_on_newplayer isn't in core too |
| 09:50 |
nrzkt |
how can this be working |
| 09:56 |
Zeno` |
looks like it's a Lua callback |
| 09:56 |
nrzkt |
yes, but this callback doesn't exist in core |
| 09:56 |
nrzkt |
neither in master nor in stable-0.4 |
| 09:56 |
Zeno` |
doesn't have to... it's registered |
| 09:56 |
Zeno` |
so the C++ calls the registered function on server step |
| 09:57 |
Zeno` |
registered Lua function* |
| 09:57 |
nrzkt |
but where does the core call it ? |
| 09:58 |
Zeno` |
builtin/game/register.lua:core.registered_on_newplayers, core.register_on_newplayer = make_registration() |
| 09:58 |
nrzkt |
oh i understand now :) |
| 09:58 |
nrzkt |
registered_on_newplayers :) |
| 10:00 |
|
leat joined #minetest-dev |
| 10:01 |
nrzkt |
then the problem is on player creation/load |
| 10:01 |
nrzkt |
because position is correctly sent to client, then the position isn't correctly collected |
| 10:01 |
nrzkt |
it's not the network |
| 10:01 |
Zeno` |
seems like a strange way to do it, but I don't know much about Lua |
| 10:02 |
kilbith |
you're too old :P |
| 10:02 |
Zeno` |
haha :P |
| 10:02 |
Zeno` |
thanks gcu |
| 10:02 |
Zeno` |
err, I mean kilbith |
| 10:02 |
nrzkt |
the problem is here i think: Server::emergePlayer |
| 10:04 |
nrzkt |
i think we must rework the player handling on server, we have two way to manage them it's not good and can cause problems in handling. We can manage them by name or by peer_id |
| 10:04 |
Zeno` |
add infostream << "Client: received player pos" << ......... |
| 10:04 |
nrzkt |
findSpawnPos |
| 10:04 |
Zeno` |
so that we can get more detailed information |
| 10:04 |
nrzkt |
just lol :p |
| 10:04 |
nrzkt |
/ Try to find a good place a few times |
| 10:04 |
nrzkt |
for(s32 i=0; i<1000; i++) |
| 10:05 |
nrzkt |
after 1000 attemps, the nodepos is set to 0,0,0 |
| 10:05 |
nrzkt |
i think the problem is here :) |
| 10:05 |
nrzkt |
the static_spawnpoint is not used here |
| 10:06 |
nrzkt |
it's why the problem is so random |
| 10:06 |
nrzkt |
this function is called by emergePlayer when create a player |
| 10:06 |
Zeno` |
I don't get it |
| 10:06 |
nrzkt |
and also on respawn |
| 10:07 |
nrzkt |
server.cpp L3183 |
| 10:07 |
Zeno` |
how was it ever working in that case? |
| 10:07 |
nrzkt |
since a long long time |
| 10:07 |
nrzkt |
the bug is present since many months as users reports |
| 10:10 |
nrzkt |
then, i will fix the problem with this function and show you a patch Zeno` |
| 10:11 |
Zeno` |
It's not a race condition is it? |
| 10:12 |
nrzkt |
it's not a concurrence problem, no |
| 10:13 |
nrzkt |
in fact there are two cases on which this function is called and can setp layer to 0,0,0: if he's a new player and we don't find a random place or if player respawn but we don't find a lua call which permit to replace the player |
| 10:20 |
|
fz72 joined #minetest-dev |
| 10:24 |
fz72 |
Something related to spawnpoint. Is it possible to set a static spawnpoint per world? I thought of implement an option for this in world.mt |
| 10:25 |
Zeno` |
errr. you can have different minetest.conf for every world |
| 10:25 |
nrzkt |
i think it's possible if we can do it with enable_damage |
| 10:26 |
nrzkt |
yes, but some settings are set to world.mt now :) |
| 10:26 |
nrzkt |
it's useful for regular clients |
| 10:30 |
|
leat joined #minetest-dev |
| 10:30 |
|
neoascetic joined #minetest-dev |
| 10:30 |
nrzkt |
Zeno`: okay for https://github.com/nerzhul/minetest/commit/0e446b4b371b6c0a6744076887c1f0d202d76c09 ? |
| 10:33 |
nrzkt |
or nore, or kahrl or anybody eslse |
| 10:33 |
nrzkt |
this commit set the spawnPoint to static_spawnpoint. If the server doesn't find a proper spawnpoint for players after 1000 loop occurences we return static_spawnpoint instead of 0,0,0 |
| 10:34 |
Zeno` |
not really; why does it have to do the loop if it's already know? |
| 10:34 |
nrzkt |
because the server spawn you randomly |
| 10:34 |
Zeno` |
so it ignores static_spawnpoint? |
| 10:34 |
nrzkt |
if you die on non creative servers you spawn at different points |
| 10:34 |
nrzkt |
yes, it was always like this. Mods can override this |
| 10:35 |
fz72 |
I'm voting for more world specific configs. For example you change freemove or fastmove for all worlds and not only for the actual world. |
| 10:35 |
Zeno` |
err, https://github.com/nerzhul/minetest/blob/0e446b4b371b6c0a6744076887c1f0d202d76c09/src/server.cpp#L3191 <-- what does that actually achieve then? |
| 10:36 |
nrzkt |
we look if static_spawnpoint is set and transform the V3F to V3S16 because we cannot read V3S16 into the config and static_spawnpoint is a V3F |
| 10:37 |
nrzkt |
if no static_spawnpoint set, then the 0,0,0 stays, because nobody tells us what is the spawnpoint :) |
| 10:39 |
nrzkt |
it's the correct answer to you question ? |
| 10:40 |
Zeno` |
well not really; I'm not sure how this makes a difference because of https://github.com/nerzhul/minetest/blob/0e446b4b371b6c0a6744076887c1f0d202d76c09/src/server.cpp#L3215 |
| 10:40 |
nrzkt |
this is not the problem |
| 10:41 |
Zeno` |
well it is because the value you set earlier for nodepos is overwritten for every iteration of the loop isn't it? (well, those when the two continues were not triggered) |
| 10:41 |
nrzkt |
you are right... |
| 10:42 |
nrzkt |
then maybe we need to set the test at the end of the function |
| 10:42 |
nrzkt |
i don't see any other spawn check in the code it's the only place where we spawn player |
| 10:43 |
|
leat joined #minetest-dev |
| 10:44 |
nrzkt |
hmmm Zeno |
| 10:44 |
nrzkt |
if we match every continue that can happen |
| 10:44 |
|
MinetestForFun joined #minetest-dev |
| 10:44 |
nrzkt |
then the fix is correct |
| 10:45 |
nrzkt |
the problem can happen in rare cases, if the 1000 loop occurences match the underwater and high places |
| 10:45 |
nrzkt |
nodepos is not overwritten in that case |
| 10:47 |
Zeno` |
well yeah |
| 10:47 |
Zeno` |
I guess I just don't understand that whole function |
| 10:47 |
Zeno` |
I don't mean the code |
| 10:47 |
nrzkt |
but the behaviour of static_spawnpoint is not to respawn on spawnpoint when a player is created ? |
| 10:48 |
nrzkt |
and when player die ? |
| 10:48 |
Zeno` |
well that's what I mean... isn't a new player always supposed to go to static_spawnpoint? |
| 10:48 |
nrzkt |
https://forum.minetest.net/viewtopic.php?pid=93479 |
| 10:49 |
nrzkt |
PilzAdam uses a mod, but we have the function in core too |
| 10:49 |
Zeno` |
# If this is set, players will always (re)spawn at the given position |
| 10:49 |
Zeno` |
#static_spawnpoint = 0, 10, 0 |
| 10:49 |
nrzkt |
and if the mod sets the spawnpoint this function is not matched. |
| 10:50 |
nrzkt |
right, then i think we must change the code, no ? |
| 10:50 |
nrzkt |
it's a bug on the parameter, we doesn't respect its behaviour |
| 10:50 |
Zeno` |
but your change will not behave like that |
| 10:50 |
nrzkt |
no, right, but older code no |
| 10:51 |
Zeno` |
your change will put the player at static spawnpoint only if none of the random ones are ok |
| 10:51 |
nrzkt |
right |
| 10:51 |
nrzkt |
like the previous code do, i only fix the 0,0,0 problem here |
| 10:51 |
Zeno` |
Well I officially don't understand :) |
| 10:53 |
Zeno` |
i.e. why send to a random location if static spawnpoint is set? |
| 10:53 |
nrzkt |
because we don't do what we should do ? :p |
| 10:54 |
nrzkt |
https://github.com/nerzhul/minetest/commit/3ed403a7a4b6c09347c323cd816da1b1e1919886 |
| 10:54 |
nrzkt |
i changed the code to respect static_spawnpoint function |
| 10:55 |
Zeno` |
well, that makes more sense to me |
| 10:55 |
nrzkt |
VanessaE, fz72, kilbith, other guys does this make sense for you ? |
| 10:56 |
Zeno` |
why is the other return intToFloat(nodepos, BS); ? |
| 10:56 |
Zeno` |
oh I see |
| 10:56 |
nrzkt |
because pos = pos * BS |
| 10:57 |
nrzkt |
and the function also do the conversion |
| 10:57 |
Zeno` |
yeah |
| 10:58 |
Zeno` |
I can't agree to the change because I don't know enough about what's going on here, but at least it makes sense now :) |
| 10:58 |
|
SopaXorzTaker joined #minetest-dev |
| 10:59 |
nrzkt |
i do a PR, then |
| 10:59 |
Zeno` |
probably best. I actually don't even know the issue number you're fixing :D |
| 10:59 |
Zeno` |
although I read the logs so I know generally what you're doing |
| 10:59 |
Zeno` |
hehe |
| 10:59 |
nrzkt |
:) |
| 11:03 |
nrzkt |
Zeno` can you review #2525 |
| 11:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/2525 -- Some builtin cleanup since recent changes by nerzhul |
| 11:03 |
nrzkt |
the fix we talked about is #2526 |
| 11:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/2526 -- findSpawnPos must use the static_spawnpoint to set the player position by nerzhul |
| 11:08 |
Zeno` |
The thing I don't get is why static_spawnpoint has worked in the past without this fix |
| 11:08 |
|
leat joined #minetest-dev |
| 11:09 |
nrzkt |
maybe because everybody uses mods ? |
| 11:11 |
Zeno` |
but it's part of builtin |
| 11:11 |
Zeno` |
isn't it? |
| 11:12 |
nrzkt |
yes: look at void Server::RespawnPlayer(u16 peer_id) => bool repositioned = m_script->on_respawnplayer(playersao); is prior to this function |
| 11:15 |
nrzkt |
i will push a little cleanup on network code, an unused function and i make oldForgePacket more atomic, using Buffer instead of SharedBuffer, it's a first step |
| 11:17 |
Zeno` |
the code is all over the place :/ |
| 11:17 |
nrzkt |
:p |
| 11:21 |
Zeno` |
server.cpp line 3335 |
| 11:21 |
Zeno` |
that *should* handle the static spawnpoint |
| 11:21 |
nrzkt |
in the dedicated_server_loop ? |
| 11:22 |
Zeno` |
in emergePlayer() |
| 11:22 |
nrzkt |
it's already done, we call findSpawnPos for new players |
| 11:22 |
nrzkt |
the spawn point is for new or dead players, not connecting players |
| 11:22 |
Zeno` |
yeah and then it's run/reset again |
| 11:23 |
Zeno` |
I can't even trace this code, lol |
| 11:23 |
* Zeno` |
gives up |
| 11:23 |
nrzkt |
we call on_newplayer there... this function call lua which looks at the static_spawnpoint if i remember, then the Lua code has problems ? |
| 11:24 |
Zeno` |
not 100% sure |
| 11:24 |
Zeno` |
it calls the registered_on_newplayers Lua function |
| 11:26 |
|
Calinou joined #minetest-dev |
| 11:29 |
|
leat joined #minetest-dev |
| 11:31 |
|
rubenwardy joined #minetest-dev |
| 11:33 |
Zeno` |
well, I have a headache now so I think I must lie down for a bit. bbl |
| 11:41 |
|
leat joined #minetest-dev |
| 11:43 |
|
ElectronLibre joined #minetest-dev |
| 11:44 |
|
err404 joined #minetest-dev |
| 11:44 |
|
MinetestForFun_ joined #minetest-dev |
| 11:57 |
|
Jordach joined #minetest-dev |
| 12:04 |
Calinou |
can the Calinou server either be renamed or banned from the list? |
| 12:04 |
Calinou |
it's not started by me |
| 12:06 |
|
ElectronLibre joined #minetest-dev |
| 12:15 |
|
Dartmouth joined #minetest-dev |
| 12:15 |
Calinou |
nevermind |
| 12:28 |
fz72 |
maybe all settings that are changed and are world related should be saved in the world specific minetest.conf |
| 12:39 |
|
OldCoder joined #minetest-dev |
| 12:42 |
|
fz72 joined #minetest-dev |
| 12:46 |
|
ElectronLibre joined #minetest-dev |
| 12:47 |
|
leat joined #minetest-dev |
| 12:55 |
|
SopaXorzTaker joined #minetest-dev |
| 12:56 |
|
roniz joined #minetest-dev |
| 13:06 |
nrzkt |
somes have already experience view range problems on specific accounts ? |
| 13:08 |
Krock |
view range problems like...? |
| 13:09 |
nrzkt |
my wife has a problem, she view at 30m range with her account but if she use another account she doesn't have problem. Only her account is affecter, also after a server reboot... |
| 13:15 |
Calinou |
force a specific view range |
| 13:15 |
Calinou |
viewing_range_nodes_min = 100 |
| 13:17 |
nrzkt |
client side, right ? |
| 13:18 |
nrzkt |
but it's very strange this occurs only on my server with her account, not other accounts, is there any cache somewhere for this ? |
| 13:23 |
Calinou |
yes, viewing range is client-side |
| 13:23 |
Calinou |
there is no cache |
| 13:23 |
Calinou |
the autotuner bases itself on framerate, compared to wanted_fps (default: 30) |
| 13:28 |
nrzkt |
i see |
| 13:40 |
|
Zeno` joined #minetest-dev |
| 13:57 |
|
TheWolf joined #minetest-dev |
| 13:58 |
|
hmmmm joined #minetest-dev |
| 14:05 |
Zeno` |
Any comments on #2402? |
| 14:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2402 -- Clean up and tweak build system by ShadowNinja |
| 14:06 |
nrzkt |
no new comment for me |
| 14:09 |
Zeno` |
any reason why it hasn't been merged? |
| 14:10 |
nrzkt |
last comments 5 days ago, no new discussion about it |
| 14:13 |
|
Calinou joined #minetest-dev |
| 14:18 |
hmmmm |
i wonder why proller is mad about this |
| 14:20 |
Zeno` |
lmao... github has gone mad |
| 14:21 |
hmmmm |
>:-(!! |
| 14:21 |
Zeno` |
they must have hired a junior |
| 14:22 |
Zeno` |
anyway referring to your comment, hmmmm, I find the #else inline with the rest of the code kind of makes it hard to read |
| 14:22 |
Zeno` |
s/inline/in line |
| 14:22 |
hmmmm |
if you want to change it, we can make a decision to change it from here on |
| 14:22 |
Zeno` |
It should be discussed |
| 14:23 |
hmmmm |
sure.. it's just that i don't have enough of an opinion to care |
| 14:23 |
Zeno` |
:D |
| 14:23 |
hmmmm |
it's the standard that # is the first character of the line, so we should be standards compliant |
| 14:23 |
hmmmm |
anybody have a rebuttal? :/ |
| 14:23 |
Zeno` |
it's pre-89 "standard" |
| 14:23 |
Zeno` |
but many, many, many, people still follow it |
| 14:24 |
hmmmm |
don't think it was ever changed. |
| 14:24 |
hmmmm |
lemme check |
| 14:24 |
Zeno` |
I think it has but I think that the pre-ANSI requirement made more sense |
| 14:25 |
Zeno` |
so, I'd vote for adding it as a style guideline for sure |
| 14:25 |
hmmmm |
yeah, you're right |
| 14:25 |
hmmmm |
that rule is outdated and clearly not the case these days |
| 14:26 |
hmmmm |
A preprocessing directive consists of a sequence of preprocessing tokens that begins with a # preprocessing token that (at the start of translation phase 4) is either the first character in the source file (optionally after white space containing no new-line characters) or that follows white space containing at least one new-line character, and is ended by the next new-line character. 140) |
| 14:28 |
hmmmm |
ugh when is this ever gonna get fixed https://github.com/minetest/minetest/commit/61f2d0ca3417b2a18a60015bf5423629d81bb754#diff-4f2cf5d1d78044ecd5922286ee4d371bL2917 |
| 14:29 |
Zeno` |
yep. I really only CC'd you because I thought we were talking about it the other day (but it may have been someone else I was talking to) |
| 14:29 |
hmmmm |
we were |
| 14:32 |
|
ElectronLibre joined #minetest-dev |
| 14:54 |
|
OldCoder joined #minetest-dev |
| 14:55 |
nrzkt |
hmmmm can you look at #2526, we talk about the static_spawnpoint feature |
| 14:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/2526 -- findSpawnPos must use the static_spawnpoint to set the player position by nerzhul |
| 15:02 |
nrzkt |
do you agree with reverting 467fc0ddc912ae38c3bf9fcb99e0b66d7478eec0 ? |
| 15:22 |
|
OldCoder joined #minetest-dev |
| 15:28 |
Zeno` |
heh, paramat reopened a PR and just about when I was about to close it again he re-closed it |
| 15:31 |
Zeno` |
unrelated, but I am very wary of 2526 (sorry nrzkt) |
| 15:32 |
Zeno` |
It really doesn't seem to be the root cause of the issue |
| 15:32 |
Zeno` |
what issue does it address anyway? |
| 15:33 |
nrzkt |
you may be right because lua code is correct |
| 15:38 |
|
err404 joined #minetest-dev |
| 15:59 |
|
est31 joined #minetest-dev |
| 16:00 |
Zeno` |
nrzkt? |
| 16:00 |
nrzkt |
yes ? |
| 16:00 |
Zeno` |
what is the issue/bug report that 2526 is trying to fix? |
| 16:01 |
nrzkt |
new players and respawning players which are teleported to 0,0,0 instead of static_spawnpoint |
| 16:01 |
Zeno` |
link? |
| 16:01 |
est31 |
#2526 |
| 16:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/2526 -- findSpawnPos should use the static_spawnpoint to set the player position by nerzhul |
| 16:01 |
nrzkt |
read at IRC logs, nobody made issue |
| 16:01 |
nrzkt |
or talk with vanessaE |
| 16:01 |
Zeno` |
ok, if there is not issue it's unconfirmed I think |
| 16:01 |
Zeno` |
VanessaE, please open an issue |
| 16:02 |
nrzkt |
i can confirm the issue, i had the issue on my server sometimes |
| 16:02 |
Zeno` |
I'd rather something more than "this sometimes happens" :) |
| 16:02 |
|
selat joined #minetest-dev |
| 16:02 |
nrzkt |
it's not reproducable, sometimes that arrives, sometimes not |
| 16:03 |
nrzkt |
create many players on your server, you'll se the issue if you are lucky , but i see this issue 5 times, players are at 0,0,0 instead of spawn, and i also get this issue 1 time |
| 16:03 |
Zeno` |
ok, but without more data it's impossible to tell if the PR is even addressing the right thing |
| 16:03 |
Zeno` |
add some more infostream output :P |
| 16:04 |
Zeno` |
I, personally, would like to know *where*/*how* they are ending up at 0,0,0 |
| 16:05 |
Zeno` |
instead of tracing, because this is kind of complex with Lua involved |
| 16:05 |
nrzkt |
the only location where 0,0,0 is possible is the code i mentionned, we already review the Lua code |
| 16:06 |
Zeno` |
is the Lua code actually being called? |
| 16:06 |
Zeno` |
is the new position being reset by "anti cheat"? |
| 16:06 |
nrzkt |
yes, because static_spawnpoint works many times, but not every time |
| 16:06 |
nrzkt |
no |
| 16:06 |
Zeno` |
but I see no proof of this :( |
| 16:07 |
Zeno` |
I have never seen it on my server, as an example |
| 16:07 |
Zeno` |
So I think we need more data |
| 16:09 |
Zeno` |
I don't really like the PR because: a) it reads static_spawnpoint directly (my server has more than one static spawnpoints); b) I can't see why the Lua is failing; and c) I can't see proof |
| 16:09 |
Zeno` |
So it warrants more investigation IMO |
| 16:10 |
|
Player_2 joined #minetest-dev |
| 16:24 |
|
Warr1024 joined #minetest-dev |
| 16:24 |
Warr1024 |
I figured out why RTT works on android but [inventorycube doesn't |
| 16:24 |
Warr1024 |
at least, I'm pretty sure the theory is sound. |
| 16:25 |
Warr1024 |
normal node images are RTT, which is actually done as render to image, then image to texture |
| 16:25 |
Warr1024 |
but the inventorycube needs an image as output, not a texture, so it tries to grab it back from the video adapter |
| 16:25 |
Warr1024 |
that's the main variable. |
| 16:26 |
Warr1024 |
so what it's doing is render->image->texture->image, which can be short-circuited |
| 16:26 |
Warr1024 |
the complicated part is that I think desktop might actually use render->texture, so it needs to keep the render->texture->image process. |
| 16:33 |
nrzkt |
no |
| 16:33 |
nrzkt |
oops :) not for you |
| 16:48 |
ShadowNinja |
Zeno`: It isn't merged because I waited and then got busy. |
| 16:50 |
est31 |
merged |
| 16:50 |
est31 |
ow |
| 16:50 |
* est31 |
forgot the ctrl-f |
| 16:51 |
est31 |
regarding #2402 |
| 16:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/2402 -- Clean up and tweak build system by ShadowNinja |
| 16:52 |
est31 |
nrzkt, do you know how the build system behaves on BSD when you enable freetype |
| 16:52 |
est31 |
does it fail by default, or only show a warning? |
| 16:54 |
nrzkt |
if i remember i have a fail |
| 16:54 |
nrzkt |
but i can't remember if it's freetype or gettext |
| 16:54 |
est31 |
there is #2403, which points to freetype errors on BSD |
| 16:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/2403 -- Fix freetype detection by AMDmi3 |
| 16:54 |
nrzkt |
in fact no, i haven't any error |
| 16:55 |
nrzkt |
jenkins works then it's good |
| 16:55 |
est31 |
yes |
| 16:55 |
nrzkt |
cmake . -DENABLE_GETTEXT=1 -DENABLE_FREETYPE=1 -DENABLE_LEVELDB=1 -DENABLE_REDIS=1 -DCMAKE_BUILD_TYPE=Debug |
| 16:55 |
est31 |
thats good |
| 16:55 |
est31 |
so then it works |
| 17:02 |
nrzkt |
reverting 467fc0ddc912ae38c3bf9fcb99e0b66d7478eec0 as discussed with ShadowNinja |
| 17:03 |
est31 |
can you give me a link? |
| 17:04 |
est31 |
https://github.com/minetest/commit/467fc0ddc912ae38c3bf9fcb99e0b66d7478eec0 |
| 17:04 |
est31 |
404 4 me |
| 17:04 |
|
DFeniks joined #minetest-dev |
| 17:04 |
nrzkt |
the apply_damage lua call. reverted. |
| 17:05 |
est31 |
ah yes seen |
| 17:28 |
|
Krock joined #minetest-dev |
| 17:40 |
|
OldCoder joined #minetest-dev |
| 17:41 |
|
Tablet_One joined #minetest-dev |
| 17:41 |
|
paramat joined #minetest-dev |
| 17:45 |
paramat |
hmmmm, saw your comment, i'll fix 'generate ores/decorations'. i'll make p1, p2 optional and default to chunk minp/maxp. but then, would we ever need positions other than chunk minp/maxp? |
| 17:50 |
paramat |
i'll push #2519 in an hour or so |
| 17:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/2519 -- Mgv7: 1 up , 1 down overgeneration for chunk border continuity by paramat |
| 17:50 |
hmmmm |
hmm I don't know |
| 17:51 |
hmmmm |
maybe they'd like to only generate ores within a certain area |
| 17:51 |
hmmmm |
like from (-100, -100, -100) -> (100, 100, 100) |
| 17:51 |
hmmmm |
you know what.. speaking from past experiences, it's probably a bad idea to give the option to the user at all unless somebody specifically requests it |
| 17:52 |
hmmmm |
every time i give a p1, p2 parameter in an api, people mess it up and they get black shadows across most of their map |
| 17:52 |
paramat |
yeah okay i'd prefer to fix it to minp/maxp, will do |
| 17:53 |
hmmmm |
in any case there is one more problem with your changes: |
| 17:54 |
hmmmm |
you don't sort pmin/pmax input. this could cause a crash if somebody enters messed up parameters |
| 17:54 |
paramat |
ah okay, i know how to sort |
| 17:55 |
hmmmm |
also, debatable, but you take getBlockSeed of vm->m_area.MinEdge... is that *correct*? |
| 17:55 |
hmmmm |
I'm not sure myself it matters that much and it's hard to come up with a clean solution |
| 17:55 |
hmmmm |
also you don't check for pmin/pmax validity before passing them along to the api |
| 17:56 |
hmmmm |
so that way core.generate_ores(vm, "foobar") would do something strange |
| 17:56 |
paramat |
the blockseed thing was there already i left it as it is =) |
| 17:57 |
hmmmm |
yes, but before it was assumed the minedge was always going to be thing passed to placeAllOres |
| 17:57 |
paramat |
okay so in future i'll sort p1/p2 and check validity |
| 17:58 |
paramat |
ah i see |
| 17:58 |
paramat |
it should be chunk minp instead? |
| 17:58 |
hmmmm |
well wait, how do I do error checking in other similar functions |
| 17:58 |
hmmmm |
hmm I don't |
| 17:58 |
VanessaE |
nrzkt: the player being spawned at 0,0,0 also happens with old players joining a world they've been to before. It's not limited to new players or to respawn on death. |
| 17:59 |
paramat |
lol |
| 17:59 |
hmmmm |
paramat: hold up |
| 17:59 |
hmmmm |
we should fix all areas where it's assumed the pos parameters will be both present and valid |
| 17:59 |
paramat |
anyway, it's good to actually have you around to point out my mistakes |
| 18:00 |
nrzkt |
VanessaE: noted |
| 18:00 |
hmmmm |
we should use check_v3s16() everywhere those parameters aren't optional instead of read_v3s16() |
| 18:01 |
hmmmm |
yeah, sorry, I don't know why I used read_v3s16() |
| 18:01 |
hmmmm |
this might break some peoples' mods but that's fine because they were relying on undefined behavior |
| 18:01 |
hmmmm |
i have no sympathy for people who rely on UB |
| 18:02 |
paramat |
okay for now though i should just edit generate ores/decos to be fixed to minp/maxp and get blockseed at minp? |
| 18:02 |
hmmmm |
yes and yes |
| 18:03 |
paramat |
okay |
| 18:03 |
hmmmm |
and then I suppose the switch from push_v3s16 -> check_v3s16 should come in a separate commit |
| 18:03 |
hmmmm |
as for the overgeneration |
| 18:03 |
hmmmm |
i still have my doubts whether this is the best way to accomplish this fix, but it works for now |
| 18:04 |
hmmmm |
still trying to come up with a way to fix this entire class of bugs |
| 18:04 |
paramat |
thanks |
| 18:04 |
paramat |
overgen is actually simple, lightweight and elegant, not ugly ;P |
| 18:05 |
hmmmm |
it's not realistic to assume we can make all features defined by point-polled values |
| 18:05 |
paramat |
but that comes from tackling it for years in lua mapgen |
| 18:05 |
paramat |
for example all my road and path-generating mapgens rely on horizontal overgen |
| 18:06 |
paramat |
there's no simpler way to do it |
| 18:06 |
hmmmm |
perhaps we could have like certain blocks generating having a prerequisite block |
| 18:06 |
hmmmm |
and then the prerequisite block is generated first |
| 18:06 |
hmmmm |
i don't know |
| 18:07 |
hmmmm |
the emergethread queue is messed up the way it is |
| 18:07 |
paramat |
the alternatives to overgen always seem complex and too theoretical to me |
| 18:07 |
hmmmm |
perhaps |
| 18:08 |
hmmmm |
but overgen only solves the issue of soil layering |
| 18:08 |
paramat |
.. and trees, dust, path generation etc |
| 18:08 |
hmmmm |
i want to have one solution that solves every situation where we have "oh gosh, I need to know what's up there in order to know if I should generate what's down here" |
| 18:09 |
paramat |
(see my lua mapgens) |
| 18:09 |
hmmmm |
hmm |
| 18:09 |
hmmmm |
how does overgen solve tree generation? |
| 18:09 |
hmmmm |
and yeah dust is the same category as dust |
| 18:09 |
hmmmm |
erm, as soil |
| 18:09 |
paramat |
allowing trees to grow into the chunk above |
| 18:10 |
paramat |
anyway back soon.. |
| 18:11 |
|
Tablet_Two joined #minetest-dev |
| 18:12 |
|
Tablet_Two joined #minetest-dev |
| 18:15 |
|
ElectronLibre joined #minetest-dev |
| 18:45 |
nrzkt |
on stable-0.4 and master i can experience this issue on my server void Game::processClientEvents(CameraOrientation*, float*): An engine assumption 'new_id == id' failed. |
| 18:47 |
nrzkt |
assert is trigger by hunger mod by blockmen, the triggered event is: else if (event.type == CE_HUDADD) |
| 18:47 |
nrzkt |
but that doesn't happen everytime |
| 18:47 |
hmmmm |
known issue: https://github.com/minetest/minetest/issues/2484 |
| 18:48 |
nrzkt |
right, who work on Hud ? |
| 18:48 |
hmmmm |
i don't think anybody does at the moment |
| 18:49 |
hmmmm |
blue42u created the remote hud commands, i created the Hud class and maintained it for a little bit |
| 18:49 |
hmmmm |
it's basically anybody at this point, though |
| 18:49 |
nrzkt |
if you want to reproduce it happen often with https://github.com/BlockMen/hud |
| 18:50 |
nrzkt |
i have added this mod to my server today, sometimes trigger some nil Lua exception and 1/3 login => client crash |
| 18:50 |
hmmmm |
well we don't know what the cause of the desynchronization is |
| 18:50 |
nrzkt |
if you connects to my server you can reproduce sometimes the issue |
| 18:50 |
hmmmm |
but a server should not be able to cause a client to crash like that |
| 18:50 |
hmmmm |
it should print to errorstream and recover |
| 18:51 |
nrzkt |
sanity_check(new_id == id); is the cause, but at this moment we have done u32 new_id = player->addHud(e); |
| 18:51 |
nrzkt |
what is the impact of the id modification on the client ? is this really important ? |
| 18:52 |
hmmmm |
it's just a sanity check |
| 18:52 |
hmmmm |
that's an indication the client and server aren't in sync |
| 18:52 |
nrzkt |
but it crash my client with an assert |
| 18:52 |
hmmmm |
so any time the server tries to modify some hud stat, it'll modify the incorrect one |
| 18:52 |
hmmmm |
right, so print to the errorstream instead of assert |
| 18:53 |
hmmmm |
with regard to #2526: respecting the static_spawnpoint setting is a correct and good thing, but it's definitely not the source of the bug you're trying to fix |
| 18:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/2526 -- findSpawnPos should use the static_spawnpoint to set the player position by nerzhul |
| 18:54 |
nrzkt |
right, if you want to merge this PR why not, if you have comments and you find the real bug we can add it to PR |
| 18:54 |
hmmmm |
before you do merge it though, how was it expected that static_spawnpoint would work when it added? |
| 18:55 |
hmmmm |
i am not familiar with this code so I'm just guessing |
| 18:55 |
hmmmm |
but there might be some kind of on_respawn() callback where the player is teleported |
| 18:55 |
hmmmm |
if that's the case, then 2526 shouldn't be merged at all and rather the above thing should be fixed |
| 18:55 |
nrzkt |
in fact the code is in Lua also, but sometimes it's not called and the findSpawnPos function is called |
| 18:56 |
hmmmm |
that's not a good thing |
| 18:56 |
nrzkt |
it's how i understand the thing |
| 18:56 |
hmmmm |
unless I'm mistaken, the fact that the lua callback isn't being triggered for whatever reason is the root cause of the bug |
| 18:57 |
nrzkt |
but Zeno` does more investigation than me. findSpawnPos shouldn't return 0,0,0 it should return static_spawnpoint instead because it's the function goal |
| 18:57 |
hmmmm |
why do you multiply nodeposf by BS |
| 18:57 |
nrzkt |
for the Hud problem i suspect a non locked variable |
| 18:57 |
nrzkt |
because the function return nodepos*BS |
| 18:57 |
hmmmm |
....why..... |
| 18:58 |
hmmmm |
i can see it returns that, but why does it return that |
| 18:58 |
nrzkt |
i don't know, i respect the way and do same thing :p |
| 18:58 |
hmmmm |
do you realize what "BS" is for? |
| 18:58 |
nrzkt |
BS = 10 |
| 18:58 |
hmmmm |
it's for translating player coordinates to 3d space coordinates in irrlicht |
| 18:58 |
nrzkt |
okay |
| 18:59 |
hmmmm |
so i see it returns intToFloat(nodepos, BS); at the bottom |
| 18:59 |
hmmmm |
that might be wrong |
| 19:00 |
nrzkt |
ok i'm pretty sure that the problem is we don't have lock on hud |
| 19:01 |
hmmmm |
alright I just checked it out a bit more, multiplying by BS is correct |
| 19:02 |
hmmmm |
but when you're making some kind of modification to existing code, you should try to figure out why it does what it does |
| 19:02 |
nrzkt |
EmergeThread can modify hud (at player load, it's the only case where it modify the hud for a player) for a player and serverthread can do it too |
| 19:03 |
nrzkt |
maybe, but i tested the change and it worked like i want, i'm not very familiar with mapgen and i already see this BS many times in other parts, then i thought it was normal :p |
| 19:03 |
hmmmm |
why would anybody modify it in both |
| 19:03 |
hmmmm |
that's horrible |
| 19:03 |
hmmmm |
BS is only normal when you're talking about player/item coordinates |
| 19:04 |
hmmmm |
for map coordinates, it's never multiplied by BS |
| 19:04 |
hmmmm |
anyway, good theory, but does blockmen's code modify hud in an on_generate callback? |
| 19:05 |
hmmmm |
I don't see any |
| 19:05 |
|
Ritchie joined #minetest-dev |
| 19:06 |
nrzkt |
in the mod you mean ? no |
| 19:06 |
nrzkt |
but it's possible to modify the vector from 2 threads at same time, i will add a PR to add a mutex to protect the hud |
| 19:06 |
hmmmm |
okay |
| 19:07 |
hmmmm |
that is needed, even though it's very odd for anybody to modify hud in an on_generate callback |
| 19:12 |
nrzkt |
hmmmm: can you review #2529 please |
| 19:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/2529 -- Protect Player::hud from concurrent modifications by nerzhul |
| 19:14 |
hmmmm |
the lock in maxHudId shouldn't be there |
| 19:14 |
hmmmm |
hrmm i wonder what calls that |
| 19:16 |
hmmmm |
nrzkt: remove the lock from maxHudId and instead add a lock in Hud::drawLuaElements |
| 19:16 |
|
Dartmouth joined #minetest-dev |
| 19:16 |
nrzkt |
Hud::drawLuaElements |
| 19:16 |
hmmmm |
er wait |
| 19:16 |
hmmmm |
that's not needed because that's the client |
| 19:16 |
hmmmm |
so just remove the lock from that function |
| 19:16 |
nrzkt |
right |
| 19:16 |
hmmmm |
otherwise, approved |
| 19:17 |
nrzkt |
do you agree for a merge ? |
| 19:17 |
nrzkt |
it's updated on github, if you're okay for a merge i can do it |
| 19:19 |
nrzkt |
i wait for the builds to be sure :) |
| 19:26 |
paramat |
okay while you're waiting i'll push 2519 now |
| 19:26 |
nrzkt |
i need to fix the compilation issue before, but the design is here :) |
| 19:32 |
nrzkt |
okay this is fixed :) |
| 19:33 |
ElectronLibre |
I got this on a server compiled with yesterday's afternoon's HEAD, with clients HEAD and 0.4.12-release : http://pastebin.ubuntu.com/10654682/ . Have this been reported? |
| 19:36 |
hmmmm |
nrzkt, yes, i do |
| 19:36 |
Krock |
ElectronLibre, interesting error :3 |
| 19:36 |
hmmmm |
ouch |
| 19:37 |
hmmmm |
ElectronLibre, change texture_clean_transparent = false for now |
| 19:37 |
ElectronLibre |
Client or server side? |
| 19:37 |
hmmmm |
client |
| 19:37 |
ElectronLibre |
Good. |
| 19:37 |
ElectronLibre |
Thank you. |
| 19:37 |
hmmmm |
np |
| 19:37 |
nrzkt |
hmmmm: what did you want to do ? sorry i missed a thing :p |
| 19:38 |
hmmmm |
nrzkt: approve for merge |
| 19:38 |
nrzkt |
okay, i do it |
| 19:38 |
paramat |
wait |
| 19:38 |
paramat |
5 mins |
| 19:38 |
hmmmm |
when I say "approved", or "LGTM", or something similar, then yes I signed off on the commit |
| 19:38 |
hmmmm |
paramat, ?? |
| 19:38 |
paramat |
im pushing 2519 |
| 19:38 |
nrzkt |
okay, i'm waiting for u |
| 19:38 |
hmmmm |
oh |
| 19:39 |
hmmmm |
lazy guy doesn't want to pull and rebase |
| 19:41 |
paramat |
okay done |
| 19:41 |
hmmmm |
ElectronLibre: did that config setting work for you?? |
| 19:42 |
ElectronLibre |
I'm connecting again right now. |
| 19:43 |
paramat |
pushing takes me 10-15mins because i clone, wget, git am, compile and test the mapgens |
| 19:44 |
paramat |
i teleported to a mountainous location to test overgen |
| 19:48 |
nrzkt |
okay, pushing now |
| 19:54 |
paramat |
i wonder if it's expected of me to compile and test mapgens during a push? |
| 19:55 |
hmmmm |
i don't know |
| 19:55 |
hmmmm |
whenever i make a modification to the mapgen I aimlessly wander around a map for a while |
| 19:55 |
ElectronLibre |
hmmmm, the configuration you gave me fixed the issue. |
| 19:55 |
hmmmm |
ElectronLibre: awesome, thanks! |
| 19:57 |
paramat |
then after a push i update, compile and test everything again *=/ |
| 19:58 |
paramat |
pushing still makes me really anxious |
| 19:59 |
|
OldCoder joined #minetest-dev |
| 20:02 |
|
Calinou joined #minetest-dev |
| 20:05 |
est31 |
nrzkt, can you review #2531 ? |
| 20:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2531 -- Fix cmake po detection bug by est31 |
| 20:07 |
nrzkt |
i agree, this is a pain :p |
| 20:08 |
|
paramat left #minetest-dev |
| 20:09 |
est31 |
at other places, timestamp should be tolerated |
| 20:09 |
Krock |
Finally a cleanup in the cmake variables :) Well done, ShadowNinja! |
| 20:10 |
|
Megal joined #minetest-dev |
| 20:14 |
nrzkt |
why are we copying the loaded player into the remote player instead of loading directly to the remoteplayer ? Somes can look at ServerEnvironment::loadPlayer ? |
| 20:21 |
ElectronLibre |
Latest build freezes on full grey world, no HUD, minetest process frozen, any idea? :/ |
| 20:22 |
nrzkt |
server or client ? |
| 20:22 |
nrzkt |
or twice ? |
| 20:22 |
ElectronLibre |
Server frozen, have to kill minetest. |
| 20:22 |
nrzkt |
the lock has problems ? can you check if the process is stucked in lock state ? |
| 20:22 |
ElectronLibre |
Client frozen, on grey screen with no HUD, just hotbar loaded, no world loaded. Someone else just compiled and reported it. |
| 20:23 |
ElectronLibre |
How can I check if it is in lock state? |
| 20:23 |
nrzkt |
ps ax|grep minetest |
| 20:23 |
ElectronLibre |
Ok. |
| 20:24 |
nrzkt |
it's always the case or only one time ? |
| 20:24 |
ElectronLibre |
Always. |
| 20:24 |
nrzkt |
have you got some HUD mods ? |
| 20:24 |
ElectronLibre |
Yes. |
| 20:24 |
nrzkt |
wait a minute i recheck 0e5e49736c0a5fa29bca257bafc02d7c7a7171c9 |
| 20:24 |
ElectronLibre |
HUD mod by blockmen, the one you were applying a fix for right now. |
| 20:25 |
nrzkt |
okay i see, i install it on my devel env |
| 20:27 |
nrzkt |
deadlock, right, i check the issue |
| 20:30 |
nrzkt |
oh... i seee |
| 20:30 |
nrzkt |
u32 getFreeHudID() wait the addHud lock but it's already locked... |
| 20:31 |
nrzkt |
misfollowed the code path for getFreeHudID, will be fixed soon |
| 20:32 |
nrzkt |
i push the fix now. |
| 20:32 |
ElectronLibre |
I will test it. |
| 20:33 |
nrzkt |
i tested it with hud by blockmen. worked for me now |
| 20:33 |
nrzkt |
you can test |
| 20:41 |
|
OldCoder joined #minetest-dev |
| 20:54 |
|
sofar joined #minetest-dev |
| 20:54 |
ElectronLibre |
No more problems nrzkt. |
| 20:58 |
nrzkt |
normal :) |
| 21:06 |
|
paramat joined #minetest-dev |
| 21:22 |
paramat |
okay hmmmm here's my initial code, needs checking #2533 |
| 21:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/2533 -- lua_api/l_mapgen: Fix volume of minetest.generate_ores/decorations to mapchunk volume by paramat |
| 21:32 |
|
OldCoder joined #minetest-dev |
| 21:46 |
|
DFeniks joined #minetest-dev |
| 21:51 |
|
ElectronLibre left #minetest-dev |
| 22:34 |
|
Wayward_One joined #minetest-dev |
| 22:40 |
|
paramat left #minetest-dev |
| 22:51 |
|
err404 joined #minetest-dev |
| 22:52 |
WarrTab |
Ugh, so apparently my android device supports rtt correctly, and was NOT using the rtt screenshot hack... |
| 22:53 |
WarrTab |
...but it does NOT support texture->image capture correctly. |
| 23:37 |
|
crazyR joined #minetest-dev |
