| Time |
Nick |
Message |
| 00:00 |
hmmmm |
well I guess that's just reversing it |
| 00:00 |
hmmmm |
but it'd unify the interface i believe |
| 00:00 |
hmmmm |
because right now the game loop needs to know about every event producer, and every event producer has to maintain their own event queue |
| 00:02 |
VanessaE |
having a single unified event queue would make more sense to me. |
| 00:05 |
hmmmm |
wow |
| 00:05 |
VanessaE |
? |
| 00:05 |
hmmmm |
the more i think about this, the more we can theoretically remove envlock from scripts =] |
| 00:05 |
VanessaE |
uh oh. |
| 00:05 |
hmmmm |
the more I realize* |
| 00:06 |
VanessaE |
est31: batten down the hatches. hmmmm is getting ideas again :) |
| 00:06 |
est31 |
lol |
| 00:07 |
* sofar |
handwaves a multi-threaded server |
| 00:08 |
hmmmm |
well |
| 00:08 |
hmmmm |
not so fast |
| 00:08 |
hmmmm |
this has major implications to the design of mapgens |
| 00:08 |
sofar |
can't mapgen be parallelized? |
| 00:08 |
est31 |
isnt it? |
| 00:09 |
hmmmm |
also i have many other things to work on :/ |
| 00:09 |
hmmmm |
I don't know what to do first |
| 00:09 |
sofar |
Given the slow speed, and my 11 cores sitting idle, I doubt it is |
| 00:09 |
VanessaE |
hmmmm: what's your TODO list so far? |
| 00:09 |
hmmmm |
hahahahaha |
| 00:09 |
hmmmm |
you really wanna know |
| 00:09 |
VanessaE |
sure, what the hell :) |
| 00:09 |
sofar |
VanessaE: his SO? |
| 00:10 |
VanessaE |
sofar: well of course his SO is on his TODO list, but I'd figure that's a perpetual entry :P |
| 00:11 |
VanessaE |
hmmmm: what I was really saying was, maybe just go after whatever's easiest at this point, or let one of us pick it for you if you're brave >:-) |
| 00:11 |
est31 |
I'd like to add better authentication and encryption support from the protocol side (where currently only nothing is encrypted yet, only that the server can send the key in the init packet) in one step, but I'm not sure whether others want it too. |
| 00:12 |
hmmmm |
http://fpaste.org/207442/82791341/ |
| 00:13 |
sofar |
nice list |
| 00:13 |
VanessaE |
est31: it's my understanding that other modern games dispense with the whole username/password thing entirely, aiming for just in-game name with some kind of server-generated crypto key for ident. |
| 00:13 |
hmmmm |
and then |
| 00:13 |
hmmmm |
client side modding |
| 00:13 |
hmmmm |
mapgen v8 |
| 00:13 |
hmmmm |
and now this ^_^ woot |
| 00:13 |
hmmmm |
minetest can easily be a full time job |
| 00:14 |
VanessaE |
hmmmm: "OGL lightmaps" <--- as in multi colors? |
| 00:14 |
hmmmm |
yeah |
| 00:14 |
hmmmm |
oh yeah also! |
| 00:14 |
hmmmm |
fix transparency Z-sorting |
| 00:14 |
VanessaE |
oh G*d yeah |
| 00:15 |
hmmmm |
that requires a lot of coding |
| 00:15 |
VanessaE |
if I had to pick from that pasted list + these last few things, honestly it would be z-sorting and lights roughly equally. |
| 00:15 |
VanessaE |
howEVER... |
| 00:16 |
hmmmm |
lol |
| 00:16 |
VanessaE |
"implement DecoLSystem" looks like it might amoung the low-hanging-fruit category |
| 00:16 |
hmmmm |
actually not quite |
| 00:16 |
hmmmm |
a prerequisite to that is fix the horror known as treegen.cpp |
| 00:16 |
VanessaE |
heh |
| 00:17 |
VanessaE |
well I meant since code already exists to generate the trees, and to place the spawner objects, all that's needed is some glue to turn one into the other (instead of the usual ABMs) |
| 00:17 |
|
paramat joined #minetest-dev |
| 00:17 |
|
cvtsx1 joined #minetest-dev |
| 00:17 |
hmmmm |
i'd rather do things right |
| 00:17 |
VanessaE |
I know. |
| 00:18 |
hmmmm |
this list makes me want to drink |
| 00:18 |
VanessaE |
heh |
| 00:24 |
|
Taoki joined #minetest-dev |
| 00:25 |
|
est joined #minetest-dev |
| 00:25 |
paramat |
i added water and lava to this PR and will push soon game#484 |
| 00:25 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/484 -- Default/nodes: Make water, lava and ice is_ground_content = false by paramat |
| 00:31 |
VanessaE |
hmmmm: btw, |
| 00:31 |
VanessaE |
there is something new to add to your TODO, and I have no fucking idea how it could be solved :P |
| 00:31 |
hmmmm |
thanks |
| 00:32 |
paramat |
lol |
| 00:32 |
VanessaE |
today while I was worldediting some land that was already flat, I kept running into parts of the air above the region that was not already loaded, or which kept getting UNloaded after some time (it was a huge area). long story short: black shadows on my work space at the bottom of the stack. |
| 00:33 |
VanessaE |
(worldediting e.g just some routine stuff on the top layer of the work area) |
| 00:33 |
VanessaE |
the sunlight propagating code was tripping me up. |
| 00:37 |
paramat |
that might be related to the black shadows sometimes i get when growing large numbers of tree saplings, that code also uses non-mapgen voxelmanip and update_map |
| 00:37 |
hmmmm |
that has nothing to do with my sunlight propogation code |
| 00:37 |
hmmmm |
that's all Map::updateLighting |
| 00:37 |
hmmmm |
blame it on celeron |
| 00:38 |
VanessaE |
oh? |
| 00:38 |
VanessaE |
wait, mine or paramat's? |
| 00:38 |
paramat |
perhaps both |
| 00:38 |
paramat |
worldedit uses update_map |
| 00:40 |
paramat |
now pushing to game.. |
| 00:40 |
VanessaE |
I assumed it was the sunlight propagation code because I could fix the shadows extending my selection to include a much taller area than I was otherwise working on, say 5-10 mapblocks higher, and then just doing, //replace air air |
| 00:46 |
paramat |
done |
| 00:47 |
|
Zeno` joined #minetest-dev |
| 00:49 |
hmmmm |
hmrm |
| 00:49 |
hmmmm |
ShadowNinja, the mailing list password doesn't work for the Administrator Authentication |
| 00:49 |
hmmmm |
it wants my mail to be moderator approved first |
| 00:50 |
est |
hi Zeno`! |
| 00:50 |
est |
do you feel better? |
| 00:50 |
hmmmm |
er nevermind |
| 00:51 |
hmmmm |
http://lists.minetest.net/archives/minetest-dev/2015-April/000001.html |
| 00:51 |
hmmmm |
=] |
| 00:51 |
est |
http://pastie.org/10075588 |
| 00:51 |
est |
^ what I think auth protocol should look like |
| 00:51 |
hmmmm |
est: post it to the mailing list |
| 00:51 |
hmmmm |
not here |
| 00:52 |
paramat |
lots of testys =) |
| 00:52 |
hmmmm |
it's like "heeeere kitty kitty kitty" |
| 00:53 |
hmmmm |
"heeeere minetesty-testy-testy" |
| 00:53 |
Zeno` |
est, hi. Getting there. complications with flu == bronchitis == feel crap |
| 00:53 |
hmmmm |
that sucks man |
| 00:53 |
est |
:( |
| 00:53 |
Zeno` |
kinda ruined easter weekend but feeling better now so life moves on :) |
| 00:53 |
est |
bronchitis is pretty bad |
| 00:54 |
hmmmm |
hey Zeno`, don't feel bad, the whole weekend I had to struggle with getting gcc to work on FreeBSD |
| 00:54 |
hmmmm |
and i ultimately was defeated |
| 00:56 |
Zeno` |
really? |
| 00:56 |
Zeno` |
Last time I used freebsd gcc was a breeze; that's pretty weird |
| 00:57 |
Zeno` |
although it has been 2 years since fbsd |
| 00:57 |
hmmmm |
http://stackoverflow.com/questions/29461123/segfault-on-startup-of-application-compiled-with-g49-on-freebsd-10-x |
| 00:57 |
hmmmm |
I never post on forums |
| 00:57 |
hmmmm |
this is my first time I had ever posted on a forum like this |
| 00:57 |
hmmmm |
that's how desperatei am |
| 00:58 |
Zeno` |
different ABI? |
| 00:58 |
Zeno` |
64 vs. 32? |
| 00:58 |
hmmmm |
clang and gcc should have a compatible abi |
| 00:59 |
hmmmm |
the only real guess is that there's some problem with libcxxrt.so being used in place of libsupc++.so but that's BS because all the addresses in the backtrace happen inside of libstdc++ |
| 00:59 |
Zeno` |
hope you get an answer |
| 00:59 |
hmmmm |
=] |
| 00:59 |
Zeno` |
that seems pretty wrong |
| 01:00 |
hmmmm |
now I remember why I wanted to switch to Linux |
| 01:00 |
est |
so its sent |
| 01:01 |
Zeno` |
Ok with me changing client.cpp line 1711 to strftime(timetstamp_c, sizeof(timetstamp_c), "%Y%m%d_%H%M%S", tm); ? |
| 01:01 |
hmmmm |
sure why not |
| 01:01 |
Zeno` |
to fix the high priority bug #2603 |
| 01:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/2603 -- Crash caused by taking a screenshot |
| 01:01 |
est |
so no serials anymore? |
| 01:02 |
Zeno` |
the serial is added after that |
| 01:02 |
Zeno` |
(and only if necessary) |
| 01:02 |
est |
ok then |
| 01:02 |
Zeno` |
phew, I'm glad to close this one and avert disaster |
| 01:02 |
est |
lol |
| 01:03 |
est |
yea perhaps a bit too exagerated... |
| 01:03 |
Zeno` |
It *is* a bit strange that it crashed though |
| 01:04 |
est |
hmmmm, can you approve my email, or do I simply have to wait now? |
| 01:05 |
hmmmm |
no idea |
| 01:05 |
hmmmm |
There are no pending requests. Click here to reload this page. |
| 01:06 |
est |
perhaps it doesnt like because I havent set a subject |
| 01:06 |
hmmmm |
well, try that |
| 01:06 |
Zeno` |
approve your email? |
| 01:06 |
Zeno` |
I sent an email to my mum this morning without approval :( |
| 01:07 |
hmmmm |
aha now i got it |
| 01:08 |
Zeno` |
you got the email I sent my mum? |
| 01:08 |
Zeno` |
you... are my mum? |
| 01:08 |
est |
haha "modern" |
| 01:08 |
Zeno` |
lol, sorry... must be the medicine |
| 01:08 |
hmmmm |
you are being 1 cheeky kunt m8, i sware i am going 2 wreck you, i sware on me mum |
| 01:09 |
VanessaE |
hmmmm: ow. that hurt to read. |
| 01:09 |
hmmmm |
"i sware on me mum" is a meme lol |
| 01:10 |
hmmmm |
read it with an scottish accent |
| 01:10 |
* Zeno` |
goes to the pet shop to buy a scotch terrier so he can get it to read the comment aloud |
| 01:11 |
hmmmm |
http://lists.minetest.net/archives/minetest-dev/2015-April/000002.html |
| 01:11 |
hmmmm |
:D |
| 01:11 |
hmmmm |
we have mailing list liftoff |
| 01:11 |
est |
fine |
| 01:11 |
VanessaE |
hmmmm: actually I can'y help but read that with a british accent :) |
| 01:11 |
VanessaE |
can't* |
| 01:12 |
Zeno` |
is this one of those mailing lists that reminds me of my password once a month? |
| 01:12 |
hmmmm |
nope |
| 01:12 |
est |
I think yes |
| 01:12 |
Zeno` |
the stupid freetype mailing listed reminds me of my password :/ |
| 01:12 |
Zeno` |
list* |
| 01:12 |
hmmmm |
it's going to get disabled if it does |
| 01:13 |
Zeno` |
there was once a guy who replied to the reminder telling them to stop that shit (which had his email in it of course) and of course it went to the entire list |
| 01:13 |
Zeno` |
email and password in it |
| 01:13 |
est |
http://pastie.org/10075614 |
| 01:13 |
est |
this is the welcome email |
| 01:14 |
hmmmm |
lol |
| 01:14 |
est |
and no dont try, I have replaced the password |
| 01:14 |
hmmmm |
yes, disable it |
| 01:14 |
hmmmm |
we prefer |
| 01:14 |
hmmmm |
@ ShadowNinja reminder to disable monthly password resets |
| 01:15 |
hmmmm |
i bash ye fookin head in |
| 01:16 |
* paramat |
wonders when #2501 will be attended to, considers bisecting |
| 01:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/2501 -- creative & damage disabled: tnt deals damage and kils player |
| 01:16 |
paramat |
lol hmmmmm you sound so british |
| 01:17 |
Zeno` |
jolly good show; I'll sign up when I'm sure it doesn't store my password plain text and remind me of it every so often |
| 01:18 |
est |
just use a random string for the password |
| 01:19 |
est |
then wait for the remainder |
| 01:19 |
Zeno` |
haha |
| 01:19 |
Zeno` |
goo show! |
| 01:19 |
Zeno` |
goo goo |
| 01:20 |
Zeno` |
I think I've subscribed |
| 01:20 |
Zeno` |
I see a picture of RMS... wait, that's a GNU |
| 01:22 |
Zeno` |
est, https://github.com/minetest/minetest/commit/ed3ebd633d23184c65128fae72f2b6c10c932e73#commitcomment-10577203 |
| 01:22 |
ShadowNinja |
est: It should be whitelisted now, but everything not whitelisted is greylisted. There's a default whitelist that includes a lot of domains, but not yandex. |
| 01:22 |
est |
ok |
| 01:22 |
ShadowNinja |
hmmmm: It should just be a monthly reminder. |
| 01:22 |
Zeno` |
est, nerzhul put the return in the wrong place |
| 01:23 |
est |
why |
| 01:23 |
est |
is clang still not happy? |
| 01:23 |
Zeno` |
ShadowNinja, but those monthly reminders send your passwords as plain text? so they're stored plain text? |
| 01:23 |
Zeno` |
est, style |
| 01:23 |
hmmmm |
that's not dangerous or anything, naw |
| 01:23 |
Zeno` |
clang would be happy if the return was at the end of the function where it should be |
| 01:23 |
ShadowNinja |
Zeno`: Yep. I know, bad security. It does warn you about that though. |
| 01:24 |
paramat |
also 'override day nght ratio' is broken, seems to be related to network commits, another one to bisect |
| 01:24 |
hmmmm |
the asserts() get removed when compiled for release, so in the case where it did get an illegal hash type, it'd return randomish junk |
| 01:24 |
Zeno` |
ShadowNinja, well I'm glad it will remind me really because I've forgotten what I used already lol |
| 01:25 |
est |
they do get removed?? |
| 01:25 |
est |
I have thought minetest has custom asserts that dont |
| 01:25 |
Zeno` |
hmmmm, nah, it'd drop through to the end of the function which *should* be return 0; |
| 01:25 |
est |
Zeno` has said something along those lines |
| 01:25 |
Zeno` |
est, no, asserts go away in release builds |
| 01:25 |
Zeno` |
man assert <--- that is how it behaves (and how it should always have behaved)\ |
| 01:25 |
est |
damn thats bad |
| 01:26 |
est |
so what to do |
| 01:26 |
est |
exit(0)? |
| 01:26 |
Zeno` |
you can use FAIL_IF(... |
| 01:26 |
est |
? |
| 01:26 |
Zeno` |
using assert for lazy error checking is silly |
| 01:27 |
Zeno` |
umm I think it's in debug.h |
| 01:27 |
est |
either way its a pre condition |
| 01:27 |
Zeno` |
#define FATAL_ERROR_IF(expr, msg) \ |
| 01:27 |
Zeno` |
that's correct, so it should never happen... EVER |
| 01:27 |
est |
so I cant guarantee for anything if that code is called that way |
| 01:28 |
Zeno` |
so putting the return 0 at the end of the function so all code paths at least return 0 is the preferred style (I would think) |
| 01:28 |
est |
so then its fine? |
| 01:28 |
Zeno` |
if it's truly a pre-condition then you know the condition before the function is even called |
| 01:29 |
est |
so pre-conditions are things that you assume that are fulfilled when you are inside some function? |
| 01:29 |
Zeno` |
not assume, know |
| 01:30 |
Zeno` |
you assert that such-and-such is always true and if it's false then the laws of the universe have changed |
| 01:30 |
hmmmm |
or there was a soft memory error |
| 01:31 |
hmmmm |
the laws of the universe allows for cosmic rays corrupting electronics |
| 01:31 |
est |
hm, then perhaps I've got it wrong, but still I do know that I dont call that method in another way |
| 01:32 |
est |
so the condition is always fulfilled |
| 01:32 |
Zeno` |
a = 10; a few hundred lines later if you have never changed assert(a == 10); <--- I doubt many people would want that assert to persist in release builds to account for cosmic rays |
| 01:32 |
|
err404 joined #minetest-dev |
| 01:32 |
est |
I've mostly added it so that when people change code, they will notice that the asserts break, and they dont have to debug a long time |
| 01:32 |
Zeno` |
yeah, so you've used assert correctly |
| 01:33 |
Zeno` |
that's what they're meant for |
| 01:33 |
est |
fine then |
| 01:33 |
Zeno` |
:) |
| 01:33 |
Zeno` |
it's only the position of the return value that I consider bad style, but perhaps that's a personal preference |
| 01:33 |
Zeno` |
s/value/statement |
| 01:34 |
est |
I guess I should also have avoided the if construct, and used assert(expression) directly |
| 01:34 |
est |
but thats also style |
| 01:34 |
est |
when I have time, I guess I will refactor that whole file |
| 01:34 |
est |
lots of duplicate code |
| 01:37 |
Zeno` |
hmm |
| 01:37 |
Zeno` |
it's not toooo bad |
| 01:38 |
Zeno` |
I looked at it yesterday while still in a delirium and it even then it looked good :) |
| 01:38 |
est |
lol |
| 01:39 |
est |
there is higher prio stuff to do first, either way |
| 01:39 |
est |
like auth |
| 01:41 |
Zeno` |
est, I see what you mean now... I would, too, have written it like: http://dpaste.com/3Y83XNX |
| 01:41 |
Zeno` |
with proper formatting of course lol |
| 01:42 |
est |
yes |
| 01:43 |
est |
ok going oflline now, awaiting response for my email. |
| 01:44 |
paramat |
#2607 |
| 01:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/2607 -- player:override_day_night_ratio() now results in a dark landscape |
| 01:45 |
Zeno` |
email? |
| 01:45 |
Zeno` |
paramat, *sigh* |
| 01:45 |
Zeno` |
paramat, can you bisect it? :) |
| 01:46 |
paramat |
yes i will |
| 01:47 |
|
est31 joined #minetest-dev |
| 01:47 |
ShadowNinja |
Zeno`: I think he means http://lists.minetest.net/archives/minetest-dev/2015-April/000002.html |
| 01:47 |
est31 |
yes |
| 01:48 |
Zeno` |
oh |
| 01:48 |
est31 |
initial goal for the auth change should be adjusting the init packets |
| 01:48 |
est31 |
I'm offline but will read chat |
| 01:48 |
* Zeno` |
reads |
| 01:50 |
Zeno` |
ShadowNinja, did I join the mailing list correctly? |
| 01:50 |
* Zeno` |
hopes he put in the correct email address |
| 01:51 |
|
paramat left #minetest-dev |
| 02:12 |
Zeno` |
lol |
| 02:12 |
Zeno` |
http://stackoverflow.com/questions/25726331/strftime-f-does-not-work-on-windows |
| 02:13 |
Zeno` |
not a filename bug at all |
| 02:13 |
Zeno` |
a secret MS developer let me know |
| 02:15 |
Zeno` |
I guess we should stick to c89 for c functions |
| 02:55 |
hmmmm |
hrmm |
| 02:55 |
hmmmm |
sorta wondering what i should do for the schematic filename thing |
| 02:56 |
hmmmm |
i can get the current mod path easily enough - but modifying the filename inside the API modifies the shadow lookup table in lua |
| 02:56 |
hmmmm |
err doesn't modify* |
| 03:11 |
Zeno` |
that's a problem |
| 03:12 |
ShadowNinja |
Zeno`: Seems not. Check your email for a confirmation message. Could be in spam. |
| 03:13 |
Zeno` |
ok |
| 03:13 |
hmmmm |
i think this is a larger problem |
| 03:13 |
hmmmm |
am I obligated to fix up lua-land shadow tables from within C++? |
| 03:14 |
hmmmm |
do I instead duplicate the logic in lua? |
| 03:14 |
Zeno` |
well, it's not in junk. I'll look after lunch. bbs |
| 03:14 |
hmmmm |
later |
| 03:16 |
hmmmm |
hehe |
| 03:16 |
hmmmm |
I wonder how much would break if we changed the memory layout of a MapBlock to be y-x-z instead of x-y-z |
| 03:28 |
ShadowNinja |
hmmmm: Map and protocol for a start, without copies and conversions. |
| 03:28 |
hmmmm |
trudat |
| 03:33 |
hmmmm |
what, you wouldn't like sideways minetest? |
| 03:34 |
ShadowNinja |
Well, it would be interesting... ;-) |
| 03:55 |
sofar |
why would the protocol change? you could keep it the same ... swapping a few bytes sent over the wire shouldn't be too expensive? |
| 04:42 |
hmmmm |
well it would change the protocol version |
| 04:42 |
hmmmm |
it's not changing the actual protocol of the game |
| 04:43 |
hmmmm |
after thinking long and hard about it, i believe it's safe to say my mapblock transaction idea is crap because everyone's a reader |
| 04:43 |
hmmmm |
and everyone's a writer |
| 04:43 |
hmmmm |
why would anybody be reading mapnodes unless they intend to write to the map |
| 04:51 |
VanessaE |
hmmmm: plants_lib. |
| 04:52 |
VanessaE |
it reads the map, but it doesn't necessarily *write* the map right away. |
| 04:52 |
VanessaE |
that's not to say that it invalidates your "my idea is crap" self-deprecation ;) but don't assume everyone's a automatically a writer if they're a reader. |
| 04:54 |
hmmmm |
would you take an api that lets you read and then when you go to do those writes it turns out that region of the map changed since when you read it |
| 04:54 |
VanessaE |
also mob mods. they don't write the map at all int he usual sense. they just spawn some entities. |
| 04:54 |
hmmmm |
probably not |
| 04:54 |
VanessaE |
oh of course not. |
| 04:55 |
VanessaE |
in fact you'll surely recall the tsuris we had before when exactly that was the case when mixing mapgen mods that uses set_node() with those which used vmanips. |
| 04:55 |
hmmmm |
well that was different |
| 04:55 |
hmmmm |
but yeah, people will get into a shitstorm if the data isn't exactly consistent with what they expect |
| 04:56 |
hmmmm |
by that i mean: act as if it were single-threaded |
| 04:56 |
VanessaE |
*nod* |
| 04:57 |
hmmmm |
so like i asid |
| 04:57 |
hmmmm |
the transaction idea only really helps if you have a lot of readers |
| 04:58 |
VanessaE |
which won't really be the case in practice |
| 04:58 |
hmmmm |
correct. |
| 04:58 |
hmmmm |
you're a writer if you are ever going to do any write ever, contingent on the state of the data you have in front of you |
| 04:59 |
hmmmm |
one really simple mechanism i could add that would help a bit is if i had a callback when a lock isn't being held anymore |
| 05:01 |
VanessaE |
might work so long as the callback doesn't come with too much overhead |
| 05:01 |
hmmmm |
probably not |
| 05:04 |
hmmmm |
dammit vanessa when are you going to become a core dev |
| 05:04 |
VanessaE |
when I actually understand C++ enough :) |
| 05:05 |
hmmmm |
that's never going to happen if you don't try |
| 05:05 |
VanessaE |
oh I do try actually. a goodly portion of the PR's that come across, I read through the code trying to learn. |
| 05:05 |
hmmmm |
ya gotta write |
| 05:05 |
VanessaE |
yep I know. |
| 05:05 |
hmmmm |
that's like thinking you're going to learn math by reading other peoples' math notes |
| 05:06 |
VanessaE |
heh, well to be fair, when you're coding, you DO usually start by reading other peoples' code, but I get your point. |
| 05:06 |
hmmmm |
true i guess |
| 05:06 |
VanessaE |
the last time I wrote any real C++ was... fuck... 15 years ago? |
| 05:06 |
hmmmm |
seriously though |
| 05:06 |
hmmmm |
you know a lot about minetest |
| 05:06 |
hmmmm |
you're pretty valuable |
| 05:07 |
hmmmm |
if you have any language questions i can certainly help |
| 05:09 |
VanessaE |
it'll be soon I think. |
| 05:10 |
VanessaE |
I am starting to figure it out, don't get me wrong, just some stuff turns to gibberish sometimes :) |
| 05:14 |
VanessaE |
back in college, I learned K&R C, did well enough to pass the class with an average grade. the one thing that sticks out in my mind was how dissimilar the language was from languages I was used to at the time (BASIC, 65xx assembly). |
| 05:14 |
VanessaE |
of course today that difference doesn't much matter, it's not like I can't figure out how a for() loop works |
| 05:15 |
hmmmm |
yup |
| 05:15 |
VanessaE |
it's the little shit that gets you, like why you put a * before a variable versus after it, etc. |
| 05:15 |
hmmmm |
there aren't as many hard parts as you might think |
| 05:15 |
hmmmm |
yea, see, i can explain those things just fine |
| 05:16 |
hmmmm |
it's the logic that matters most |
| 05:16 |
VanessaE |
yep |
| 05:16 |
hmmmm |
so anyway help me reason this out: |
| 05:16 |
hmmmm |
so we have the base state of this mapblock |
| 05:17 |
hmmmm |
someone wants to possibly do writes to it, so it gets copied |
| 05:17 |
hmmmm |
somebody else wants to do a possible-write to the same mapblock but they need the finished version of the thing that came before it |
| 05:18 |
hmmmm |
the second gets the callback when the first is done, "hey you can do your read/possible write now" |
| 05:18 |
hmmmm |
the original idea was to have all this crazy merge stuff optimized for the read only case but that's not realistic |
| 05:19 |
VanessaE |
well. |
| 05:19 |
VanessaE |
if your only goal were to add decorations, ores, and so on to the mapblock, the emerge-read-copy-read_a-bunch idea actually works fine in practice |
| 05:19 |
VanessaE |
BUT |
| 05:20 |
VanessaE |
you're gonna be adding trees, lakes, or hell doing entirely new map data over the old (depending on the mod being used)( |
| 05:21 |
VanessaE |
what I do, and this should work for the more generic read-copy-write case, is give each block it's own queue, identified by blockhash. |
| 05:21 |
hmmmm |
hrmm |
| 05:21 |
VanessaE |
disregarding for the moment that Lua is single-threaded of course |
| 05:21 |
hmmmm |
the queue contains wanted node modifications? |
| 05:22 |
hmmmm |
these queues are atomically updated? |
| 05:22 |
VanessaE |
something like that yeah |
| 05:22 |
hmmmm |
i can see what you're getting at |
| 05:22 |
hmmmm |
that would clearly work but it's very expensive |
| 05:22 |
VanessaE |
you could even create entries that point to difference maps |
| 05:22 |
VanessaE |
yeah, that's the only problem - it would be both RAM and CPU hungry |
| 05:22 |
hmmmm |
that defeats the purpose basically |
| 05:22 |
VanessaE |
(whereas a single queue is just CPU hungry) |
| 05:23 |
hmmmm |
pfth |
| 05:23 |
hmmmm |
I don't know, this problem is too hard |
| 05:23 |
hmmmm |
thinking about it a bit more, I don't know when the callback-on-finished idea will help |
| 05:24 |
hmmmm |
if anything that's akin to having a trylock on a spin |
| 05:24 |
VanessaE |
yeah |
| 05:24 |
hmmmm |
errm, i mean except not on a spin* |
| 05:24 |
VanessaE |
oh right |
| 05:24 |
VanessaE |
that makes a little more sense. |
| 05:25 |
hmmmm |
a trylock on a spin is just a regular lockl ol |
| 05:25 |
VanessaE |
sounds like the only place the callback would be of much help is in a fairly generic server (i.e. mostly unmodded) on a slow machine |
| 05:26 |
hmmmm |
okay so what about a rather optimistic algorithm |
| 05:26 |
hmmmm |
this is the "true" transaction/commit algorithm |
| 05:26 |
hmmmm |
you get your mapblock |
| 05:26 |
hmmmm |
if somebody else tries to get the same mapblock it sets a bit |
| 05:27 |
hmmmm |
you try to commit your version of the mapblock and it fails |
| 05:27 |
hmmmm |
so you at that point get a copy of the modified mapblock and you... I guess, retry your loop logic? |
| 05:27 |
hmmmm |
this is STM |
| 05:27 |
VanessaE |
ehhh... |
| 05:28 |
VanessaE |
that would get really messy really fast unless you also included a "re-read mapblock" callback also |
| 05:28 |
VanessaE |
(even then it would still be messy) |
| 05:29 |
hmmmm |
so it's like do { for (int i = 0; i != MAPBLOCK_SIZE* MBSIZE * MBSIZE; i++) if (mapblock.m_data[i].getContent == c_grass) mapblock.m_data[i].setContent(c_snow); } while (core.commit_mapblock(mapblock) == false); |
| 05:29 |
hmmmm |
for example that's the way the snow mod would work |
| 05:29 |
hmmmm |
or anything really |
| 05:29 |
hmmmm |
the point here is that it's *optimistic* |
| 05:29 |
VanessaE |
right |
| 05:29 |
hmmmm |
if it does fail, then... so what? |
| 05:30 |
hmmmm |
just try it again |
| 05:30 |
hmmmm |
you're not going to be doing anything else better with your time other than sitting there like a bump on a log |
| 05:30 |
hmmmm |
(this is assuming mods are in their own threads) |
| 05:30 |
VanessaE |
oK |
| 05:30 |
VanessaE |
that changes things |
| 05:30 |
hmmmm |
welllll |
| 05:30 |
VanessaE |
I wasn't thinking in terms of multi-threading Lua here. |
| 05:30 |
hmmmm |
I am going to qualify this with mostly |
| 05:31 |
hmmmm |
the way I want to do lua multithreading isn't one thread per mod |
| 05:31 |
hmmmm |
it'd have to be an apartment model with multiple tenants per thread |
| 05:31 |
VanessaE |
suddenly this seems way less messy. |
| 05:31 |
hmmmm |
of course this is adjustable by the server |
| 05:32 |
hmmmm |
but yeah... you can't have like 200 threads running because it's vanessa's big-ass-world mod |
| 05:32 |
hmmmm |
or whatever |
| 05:32 |
VanessaE |
the way I could see a thread model working is really just one main thread (like now) for well, "all", and just spawn a new thread or two here or there as callbacks are executed |
| 05:32 |
hmmmm |
big-freaking-dig i mean, and that's jordachs, sorry |
| 05:32 |
hmmmm |
yeah |
| 05:32 |
VanessaE |
(not that there's much for "all" to do since Lua is pretty much entirely event driven in practice) |
| 05:33 |
hmmmm |
that's the way sapier's async crap works right now pretty much |
| 05:33 |
hmmmm |
and it's great because mods work off of callbacks |
| 05:33 |
hmmmm |
events |
| 05:33 |
hmmmm |
so most of the time they'd be sitting there doing nothing |
| 05:33 |
VanessaE |
yup |
| 05:34 |
hmmmm |
the problem is when they *do* finally get an event... |
| 05:34 |
hmmmm |
see that's the problem with minetest |
| 05:34 |
VanessaE |
by the sound of it, each thread would need a whole fresh copy of the Lua environment |
| 05:34 |
hmmmm |
everything is polled so there's this spike of CPU usage all at once |
| 05:34 |
hmmmm |
well, yes |
| 05:34 |
hmmmm |
we'd use something like lua lanes |
| 05:35 |
VanessaE |
damn i t stop making me google stuff :P |
| 05:35 |
VanessaE |
hm, you'll have a problem here. |
| 05:35 |
VanessaE |
Lanes doesn't appear to support *BSD. |
| 05:35 |
hmmmm |
r u kidding me |
| 05:35 |
hmmmm |
dammit |
| 05:35 |
hmmmm |
lanes was being advertised to me as the way, the light, the truth, when i first heard of it |
| 05:36 |
VanessaE |
supports OS X PPC and Intel, Linux x86, and win 2k/xp and up it says. |
| 05:36 |
VanessaE |
http://cmr.github.io/lanes/ |
| 05:36 |
hmmmm |
oh |
| 05:36 |
hmmmm |
they're probably just not aware that freebsd exists |
| 05:36 |
hmmmm |
i bet it's just a couple compile issues if anything |
| 05:36 |
VanessaE |
of course this page was last updated two years ago, so who knows :) |
| 05:37 |
VanessaE |
https://github.com/LuaLanes/lanes/blob/master/README#L80 |
| 05:37 |
VanessaE |
the redme contradicts the .io page |
| 05:37 |
VanessaE |
readme* |
| 05:38 |
hmmmm |
ahh |
| 05:38 |
VanessaE |
notes at line 124 about JIT also. |
| 05:39 |
hmmmm |
noted. |
| 05:41 |
VanessaE |
hm. "heavily-threaded" dual-core performance is 50-60% faster than single-thread/core. |
| 05:42 |
hmmmm |
it's better than 0% |
| 05:42 |
VanessaE |
this is true. |
| 05:45 |
VanessaE |
well, it looks like it has everything one would need. |
| 05:45 |
VanessaE |
including a fork() equivalent :) |
| 05:47 |
hmmmm |
hopefully lanes has a preemption mechanism |
| 05:48 |
VanessaE |
http://cmr.github.io/lanes/#status |
| 05:48 |
hmmmm |
i don't know, VanessaE, if I add in transactions for mapblocks, would you use it? |
| 05:48 |
VanessaE |
I don't know if I would or not, to be perfectly frank... |
| 05:49 |
VanessaE |
but, I'll bet you paramat would love it |
| 05:49 |
hmmmm |
well just think of it this way: in the current case where there's one gigantic lock, the transaction will always succeed |
| 05:49 |
VanessaE |
SPlizard too |
| 05:49 |
hmmmm |
now one thing bout mapblock transactions |
| 05:49 |
hmmmm |
i will attempt to merge them even if it's marked as dirty |
| 05:50 |
VanessaE |
well, so long as two block copies are marked dirty *but* they're both "finished" and neither conflicts with the other, I see no reason not to merge them |
| 05:50 |
hmmmm |
so if there's a portion of the mapblock that has an air node set to a flower or something |
| 05:50 |
hmmmm |
that should be okay for another mod with the same thing set to a flower |
| 05:50 |
VanessaE |
right |
| 05:51 |
hmmmm |
VanessaE: this would be optional though because you can't trust the entire mapblock if one thing has been changed |
| 05:51 |
hmmmm |
how do I know you hadn't based your decision to set the node in the center mese based on all of the surrounding nodes? |
| 05:51 |
VanessaE |
good point |
| 05:51 |
hmmmm |
well I guess that mutual exclusion is the only case where this would happen |
| 05:51 |
VanessaE |
I Was of course assuming the simple case of two or more mapgen mods just adding random shit to the mapblock |
| 05:52 |
hmmmm |
it needs to be a case where mod #1 has a problem with certain nodes being there AND mod #2 has the same problem |
| 05:52 |
hmmmm |
like you have place_things_by_water_mod |
| 05:52 |
hmmmm |
where it only places a block if it's completely surrounded by water |
| 05:52 |
hmmmm |
but there's also another mod that does the same thing |
| 05:53 |
VanessaE |
then whoever gets the block first wins, that's pretty simple. |
| 05:53 |
hmmmm |
in the traditional setup, this would work fine because your mod would come first, see the water, place your node |
| 05:53 |
hmmmm |
right |
| 05:53 |
hmmmm |
hrmm |
| 05:53 |
hmmmm |
anyway this is why it has to be optional |
| 05:59 |
VanessaE |
I'm reading through this lanes stuff... one thing they're a little unclear on, they push their Lindas feature for IPC, but what if I just want to deal with a big global table... |
| 06:10 |
VanessaE |
"Data passing (parameters, upvalues, Linda messages) is generally fast, doing two binary state-to-state copies" |
| 06:10 |
VanessaE |
ew. |
| 06:10 |
VanessaE |
*imagines passing a 100 kB table between processes* |
| 06:10 |
|
Hunterz joined #minetest-dev |
| 06:54 |
|
jin_xi joined #minetest-dev |
| 07:11 |
|
denis_ joined #minetest-dev |
| 07:36 |
|
leat joined #minetest-dev |
| 07:55 |
|
Calinou joined #minetest-dev |
| 07:57 |
* hmmmm |
scratches head |
| 07:58 |
hmmmm |
lua_sethook(L, preempt_script, LUA_MASKCOUNT, 10000); |
| 07:58 |
hmmmm |
that was easy! |
| 07:59 |
VanessaE |
*raises eyebrow* |
| 07:59 |
hmmmm |
haha, it took quite a bit of searching to find that |
| 08:09 |
|
selat joined #minetest-dev |
| 08:13 |
|
Jordach joined #minetest-dev |
| 08:16 |
|
kilbith joined #minetest-dev |
| 08:49 |
|
leat joined #minetest-dev |
| 09:58 |
|
cib0 joined #minetest-dev |
| 10:30 |
|
Taoki joined #minetest-dev |
| 10:45 |
|
deezl joined #minetest-dev |
| 11:16 |
|
roniz joined #minetest-dev |
| 11:34 |
|
T4im joined #minetest-dev |
| 11:53 |
|
proller joined #minetest-dev |
| 12:34 |
|
Player_2 joined #minetest-dev |
| 12:41 |
|
Player_2 joined #minetest-dev |
| 13:13 |
|
Zeno` joined #minetest-dev |
| 13:17 |
|
Player_2 joined #minetest-dev |
| 13:26 |
|
cib0 joined #minetest-dev |
| 13:29 |
|
jin_xi joined #minetest-dev |
| 13:45 |
|
MinetestForFun joined #minetest-dev |
| 13:46 |
|
MinetestForFun_ joined #minetest-dev |
| 13:55 |
|
OldCoder joined #minetest-dev |
| 13:55 |
|
Lunatrius joined #minetest-dev |
| 13:55 |
|
Robby joined #minetest-dev |
| 13:55 |
|
Aaron1011 joined #minetest-dev |
| 13:55 |
|
Eivel joined #minetest-dev |
| 13:55 |
|
daswort joined #minetest-dev |
| 13:56 |
|
Taoki joined #minetest-dev |
| 13:56 |
|
JeDa joined #minetest-dev |
| 13:56 |
|
geheimni1 joined #minetest-dev |
| 13:56 |
|
Brains joined #minetest-dev |
| 13:56 |
|
compunerd joined #minetest-dev |
| 13:56 |
|
harrison joined #minetest-dev |
| 13:57 |
|
book` joined #minetest-dev |
| 13:58 |
|
AnotherBrick joined #minetest-dev |
| 13:58 |
|
cvtsx1 joined #minetest-dev |
| 13:58 |
|
msantana joined #minetest-dev |
| 13:58 |
|
jin_xi joined #minetest-dev |
| 13:58 |
|
Zeno` joined #minetest-dev |
| 14:01 |
|
book` joined #minetest-dev |
| 14:08 |
Zeno` |
how do we move forward? |
| 14:09 |
Zeno` |
I think that minesest is currently the in the buggiest state since I discovered the project and I don't know if I enjoy that |
| 14:09 |
Zeno` |
so we probably need a plan |
| 14:10 |
Zeno` |
The thing is I cannot code new features when there are so many (IMO) critical bugs. That's just my personality |
| 14:10 |
Zeno` |
I won't add things when things are not at least semi-stable :/ |
| 14:10 |
Zeno` |
And it's starting to annoy and frustrate me |
| 14:11 |
Zeno` |
celeron55, you're the boss. Any suggestions? |
| 14:17 |
celeron55 |
...uhm, well, sounds like it would be a good idea to look into the matter and figure out where and from which practices and from whom the bugs have come from and deal with it so that when fixing the bugs, people can have confidence in bugs not appearing again so much |
| 14:19 |
|
proller joined #minetest-dev |
| 14:19 |
Zeno` |
I will think |
| 14:22 |
celeron55 |
are these bugs that you consider critical marked somehow as such on github? |
| 14:22 |
Zeno` |
most of them I think |
| 14:22 |
Zeno` |
oh, do they have critical label? |
| 14:23 |
Zeno` |
no, because they can't really be isolated (AFAIK) |
| 14:23 |
celeron55 |
that label doesn't exist |
| 14:24 |
celeron55 |
i don't know if it should, but assessing what you said is difficult without it :P |
| 14:25 |
Zeno` |
critical is not necessary; high priority covers things |
| 14:25 |
celeron55 |
can you make a list of the "imo critical" bugs? |
| 14:26 |
Zeno` |
one the other day took me 4 hours to actually reproduce and another 2 to get a backtrace; they're not really deterministic as far as I can tell and that's the problem |
| 14:26 |
Zeno` |
I guess I can do that, surew |
| 14:26 |
Zeno` |
sure* |
| 14:27 |
Zeno` |
sounds like a good place to start |
| 14:36 |
|
Etzos joined #minetest-dev |
| 14:37 |
|
hmmmm joined #minetest-dev |
| 14:38 |
|
selat joined #minetest-dev |
| 15:11 |
|
Krock joined #minetest-dev |
| 15:16 |
|
proller joined #minetest-dev |
| 15:33 |
|
chchjesus joined #minetest-dev |
| 15:44 |
|
proller joined #minetest-dev |
| 15:49 |
|
proller joined #minetest-dev |
| 16:19 |
|
Gethiox joined #minetest-dev |
| 16:22 |
ShadowNinja |
... http://pastebin.ubuntu.com/10751384/ |
| 16:22 |
ShadowNinja |
Caching the result of a cast, anyone? |
| 16:32 |
Krock |
Uh. that's the new place 1 of the worst codes |
| 17:08 |
celeron55 |
lol |
| 17:22 |
|
ud1_ joined #minetest-dev |
| 17:54 |
|
SopaXorzTaker joined #minetest-dev |
| 18:15 |
hmmmm |
i think we should make an edict to outlaw dynamic casts |
| 18:15 |
hmmmm |
rtti is kind of useless imo |
| 18:16 |
hmmmm |
that looks like sapier code |
| 18:16 |
hmmmm |
celeron55, http://lists.minetest.net/archives/minetest-dev/2015-April/000001.html |
| 18:16 |
hmmmm |
your thoughts? |
| 18:36 |
ShadowNinja |
hmmmm: Currently there are only UDPPeers, so the dynamic_cast is kind of useless. And if other protocols are supposed to be easily interchangeable it certainly doesn't look like it. And yes, it's sapier's connection code. |
| 18:37 |
hmmmm |
well I think it would be useless even if there were other peer types |
| 18:37 |
hmmmm |
i suppose it depends on whether or not you store all peers homogenously |
| 18:37 |
hmmmm |
i personally wouldn't |
| 18:48 |
|
SudoAptGetPlay joined #minetest-dev |
| 19:09 |
|
proller joined #minetest-dev |
| 20:06 |
|
MinetestForFun joined #minetest-dev |
| 20:12 |
|
proller joined #minetest-dev |
| 20:22 |
|
cib0 joined #minetest-dev |
| 20:38 |
|
est31 joined #minetest-dev |
| 20:46 |
|
roniz joined #minetest-dev |
| 21:03 |
VanessaE |
is it just me, or is the yellow hue from light sources particularly "obvious" lately? |
| 21:04 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2004062015%20-%2005%3a07%3a36%20PM.png |
| 21:05 |
est31 |
that doesnt look nice |
| 21:48 |
|
Gethiox joined #minetest-dev |
| 21:52 |
celeron55 |
lol what |
| 21:52 |
celeron55 |
since when has it looked like that |
| 21:56 |
sofar |
well, that question could be answered if there was a visual regression tester. Might not be so hard to build one, too. |
| 21:57 |
kahrl |
sounds hard to me |
| 21:57 |
celeron55 |
hmmmm: you probably should attach a description of the intended optimal map generator api usage to such proposals |
| 21:58 |
kahrl |
the only drivers that are possibly deterministic are the software drivers, and they don't really work for minetest at all |
| 21:58 |
sofar |
should be easy with a little mod to put a test player on a specific map with test objects, then start, logon automatically and take a screenshot |
| 21:59 |
celeron55 |
hmmmm: i mean, that thing doesn't give any solutions to lua-based map generation locking the server for long periods of time |
| 22:00 |
|
paramat joined #minetest-dev |
| 22:00 |
celeron55 |
or, umm... does it do that in the way that the server would run, but the lua environment would be in a stopped state? |
| 22:00 |
kahrl |
ah, if you mean just making the screenshots automatically (but not automatically comparing them to some known-good screenshot), that should be doable with some effort |
| 22:01 |
celeron55 |
that's probably not a good idea as the server has to be able to call callbacks defined by mods in many places... i think |
| 22:03 |
celeron55 |
(i don't intend to look hard into this right now) |
| 22:04 |
hmmmm |
celeron: why not reply to the mailing list thread then |
| 22:04 |
hmmmm |
i think this mailing list thing is great because it's not noisy and much less temporal than irc |
| 22:06 |
celeron55 |
i might answer there if i decide to take the time to take a better look |
| 22:11 |
|
Gethiox joined #minetest-dev |
| 22:13 |
est31 |
pushing in 15 mins, doc rename: http://pastie.org/10077145 |
| 22:13 |
est31 |
(currently comments are wrong) |
| 22:49 |
est31 |
pushed |
| 22:55 |
|
proller joined #minetest-dev |
| 23:09 |
est31 |
:/ as it seems there is more -> _LEGACY renaming required... :/ |
| 23:37 |
|
cib0 joined #minetest-dev |
| 23:45 |
paramat |
oops .. when i added 3d noise tunnels to mgv5/v7 i forgot to make them check for 'is ground content' *=/ will be fixed in the upcoming PR |
| 23:59 |
|
Fritigern joined #minetest-dev |
| 23:59 |
est31 |
the csrp project ShadowNinja linked seems to not fulfil what I need... |
| 23:59 |
est31 |
it can be modified though |
