| Time |
Nick |
Message |
| 00:04 |
hmmmm |
okay |
| 00:04 |
hmmmm |
i'll have to take a look |
| 00:30 |
|
waressearcher2 joined #minetest-dev |
| 01:03 |
|
Icedream- joined #minetest-dev |
| 01:16 |
|
Icedream joined #minetest-dev |
| 01:45 |
|
kaeza joined #minetest-dev |
| 01:46 |
|
harrison joined #minetest-dev |
| 01:50 |
|
harrison joined #minetest-dev |
| 02:03 |
|
Guest61682 joined #minetest-dev |
| 02:48 |
|
diemartin joined #minetest-dev |
| 03:24 |
|
kaeza joined #minetest-dev |
| 03:26 |
|
Miner_48er joined #minetest-dev |
| 03:30 |
|
Miner_48er joined #minetest-dev |
| 03:46 |
hmmmm |
paramat: we can fix the oregen crash by switching to PcgRandom |
| 03:52 |
|
paramat joined #minetest-dev |
| 03:52 |
paramat |
ah okay |
| 03:52 |
paramat |
good idea |
| 03:54 |
hmmmm |
what do you think about 3237 |
| 03:55 |
hmmmm |
#3237 |
| 03:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/3237 -- PseudoRandom always generating same sequence with big seed |
| 03:55 |
paramat |
hm yeah, a dilemma |
| 03:57 |
hmmmm |
oh darn |
| 03:57 |
hmmmm |
paramat, I just noticed something about the fractal mapgen |
| 03:57 |
hmmmm |
you didn't include mapgen_fractal.cpp in the android makefile |
| 03:58 |
paramat |
i did in a following commit |
| 03:58 |
hmmmm |
ahh good |
| 03:58 |
paramat |
but yes stuff broke for a day |
| 03:59 |
paramat |
does 3237 affect core mapgens too? |
| 04:00 |
hmmmm |
it affects anything unfortunately |
| 04:00 |
hmmmm |
any time you add a new source file, it needs to be added there |
| 04:00 |
paramat |
ok |
| 04:00 |
hmmmm |
i really do not like the way our android build system operates but it's like that until somebody who is knowledgeable enough about the android build can fix it |
| 04:02 |
paramat |
so issue 3237 is only for seeds used in on-gen functions, so just mods and lua mapgens? |
| 04:03 |
hmmmm |
the blockseed is 64 bit in all new mapgens i think |
| 04:03 |
hmmmm |
it's still 32 bit in v6 |
| 04:04 |
paramat |
ah yes i remember mgv5/v7 being updated to a new blockseed creation |
| 04:04 |
paramat |
anyway for the fractal bug i'll try some different 'getters' and also try using v3fs for some parameters |
| 04:04 |
hmmmm |
yeah one of the problems with v6 is that the blockseed used a VERY bad 'hash' of the position coords and seed |
| 04:05 |
hmmmm |
the bottom bits had zero enthropy depending on whether the seed was even or odd |
| 04:05 |
hmmmm |
ahh okay, getBlockSeed2 is 32 bit as well |
| 04:05 |
hmmmm |
it just has improved enthropy |
| 04:11 |
paramat |
the fractal mapgen bug repeatedly throws up this number 163148516993831175979008.0 i wonder if that's familiar to anyone .. |
| 04:12 |
hmmmm |
paramat, how have you been selecting the fractal mapgen btw? |
| 04:12 |
hmmmm |
just wondering |
| 04:13 |
paramat |
well when it was just a local branch normally, now of course it's hidden so i use a mod using 'set mapgen params' |
| 04:13 |
paramat |
buh was present both ways |
| 04:13 |
paramat |
(bug) |
| 04:13 |
hmmmm |
oh okay |
| 04:13 |
hmmmm |
was about to say, that's pretty telling |
| 04:13 |
paramat |
buhhh ... |
| 04:14 |
paramat |
getFloatNoEx seems to work in mgv6 |
| 04:14 |
hmmmm |
first I need to fix the mapgen selection |
| 04:22 |
hmmmm |
hmmm this is gonna be hard with the way formspec works |
| 04:23 |
hmmmm |
so, my idea was to get the full list of mapgen names as well in create_world_formspec() |
| 04:23 |
hmmmm |
if the mapgen name isn't in the publically available list, then check the full list |
| 04:23 |
hmmmm |
if it's in the full list, set the contents of the combobox to that mapgen name, but don't add it to the dropdown |
| 04:24 |
hmmmm |
maybe even add a label to the side that says "(EXPERIMENTAL)" or something along those lines |
| 04:24 |
hmmmm |
however we can't do this without adding a new formspec type |
| 04:24 |
paramat |
i noticed i couldn't select a hidden mapgen using .conf, only by a mod |
| 04:25 |
hmmmm |
right, obviously this doesn't matter so much for singlenode but for the fractal mapgen this might be a real problem |
| 04:25 |
hmmmm |
not really sure how to "fix" this |
| 04:26 |
paramat |
currently i like how maogens can be well hidden, and only knowledgeable users know how to select with a mod |
| 04:26 |
paramat |
devving a mapgen that is 'in' is a relief |
| 04:27 |
hmmmm |
fair enough, i guess |
| 04:27 |
paramat |
i have another one i might like to add hidden soon |
| 04:29 |
hmmmm |
the way caves are asymmetrical kind of ruins the fractal mapgen imo |
| 04:29 |
kahrl |
how about showing the fractal mapgen in the menu, but only if mg_name is set to fractal |
| 04:29 |
paramat |
lol, normal v7 tunnels |
| 04:30 |
hmmmm |
paramat, at y=62.5 there are abnormal shadows |
| 04:30 |
hmmmm |
just dyi |
| 04:30 |
hmmmm |
fyi* |
| 04:30 |
hmmmm |
how do you replicate this problem? just by joining & leaving the game repeatedly? |
| 04:31 |
paramat |
yes either to menu or to OS |
| 04:31 |
paramat |
the bug can happen on first session in a new world |
| 04:31 |
hmmmm |
and how frequently do you experience the issue? |
| 04:32 |
paramat |
it occurs randomly, maybe 25% of sessions |
| 04:33 |
paramat |
lighting bugs at y = 63 #2759 in mgv5/v7/fractal |
| 04:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/2759 -- Lighting bug at y = 63 in mgv7 and core mapgens in development |
| 04:34 |
paramat |
probably due to the alternative 'calc lighting' used in overgenerating mapgens |
| 04:34 |
hmmmm |
now is that really the case |
| 04:34 |
hmmmm |
the overgenerating mapgens only overgenerate noise |
| 04:34 |
hmmmm |
not the actual result |
| 04:34 |
hmmmm |
anyway I can't reproduce your problem |
| 04:34 |
paramat |
the fractal bug occurs more often in julia mode |
| 04:35 |
paramat |
mgfractal_spflags = julia |
| 04:35 |
hmmmm |
kudos to making a playable, actually nice looking fractal mapgen |
| 04:35 |
hmmmm |
this is miles better than what proller had |
| 04:35 |
paramat |
but you'll need to fly east 500-1000 nodes to find it |
| 04:35 |
hmmmm |
the most important thing is that it's actually playable |
| 04:36 |
hmmmm |
it's not an incoherent jumble of nodes |
| 04:37 |
paramat |
the slice param provides a range of different shapes, the julia mode another set of shapes |
| 04:37 |
paramat |
all scalable and offsettable for crazy stuff if users want |
| 04:38 |
paramat |
anyway i'll try using v3fs for some params in case that helps |
| 04:38 |
hmmmm |
eh that's not going to help... |
| 04:38 |
hmmmm |
the julia mode seems to be all water |
| 04:39 |
paramat |
fly east 500-1000 nodes, if it doesnt appear bug is occuring, re-enter world |
| 04:39 |
paramat |
it might then appear |
| 04:40 |
paramat |
btw someone else has replicated the bug |
| 04:45 |
hmmmm |
yeah sorry paramat, can't reproduce |
| 04:46 |
paramat |
no problem, it can take some time to do so |
| 04:48 |
paramat |
very frustrating bug *=( |
| 04:49 |
hmmmm |
try running with valgrind |
| 04:50 |
paramat |
hm i'll have to learn that, about time i did |
| 04:50 |
paramat |
now merging 3236 |
| 04:54 |
hmmmm |
want me to retrofit the decorations to use PcgRandom |
| 04:54 |
hmmmm |
? |
| 04:56 |
paramat |
done |
| 04:56 |
paramat |
for that ore issue yeah |
| 04:56 |
paramat |
oh sorry |
| 04:57 |
paramat |
doesn't seem essential, only if you feel like it |
| 04:58 |
paramat |
but of course the new PR is better |
| 04:59 |
paramat |
i'm up to 100 commits to engine crumbs |
| 05:02 |
hmmmm |
heh |
| 05:03 |
hmmmm |
hi five |
| 05:03 |
hmmmm |
and you originally thought that core development would be too difficult for you to handle |
| 05:06 |
hmmmm |
anyway, my initial reaction to the non-user visible mods is to fix that oversight so a mod isn't absolutely necessary to use it, but I think you make a good case for leaving it as-is |
| 05:07 |
hmmmm |
non-user visible mapgens i mean |
| 05:08 |
paramat |
indeed :} |
| 05:09 |
paramat |
as-is is fine for now |
| 05:09 |
paramat |
http://i.imgur.com/hFPGIpk.png taste of my rivergen branch |
| 05:11 |
VanessaE |
beautiful |
| 05:12 |
paramat |
http://i.imgur.com/3Olw5am.png also playing with floatlands in mgv7, easy to add but need to think about how to get up there |
| 05:14 |
paramat |
http://i.imgur.com/iNJ0xSP.png for example playing with towers |
| 05:20 |
|
paramat left #minetest-dev |
| 05:20 |
hmmmm |
rivergen is probably the most realistic looking mapgen |
| 05:21 |
hmmmm |
i can't help but look at that first screenshot and think, "yeah, that place exists somewhere in colorado." |
| 05:24 |
VanessaE |
I thought the same |
| 05:24 |
VanessaE |
or more like "wow, that looks rather real." |
| 05:32 |
VanessaE |
bbl |
| 05:45 |
|
Hunterz joined #minetest-dev |
| 05:52 |
waressearcher2 |
hmmmm: universe should've used some mapgen anyway |
| 05:52 |
hmmmm |
huh? |
| 05:55 |
waressearcher2 |
hmmmm: "that place exists somewhere in colorado", that could mean your mapgen very close to that universe used to create itself |
| 06:15 |
|
est31 joined #minetest-dev |
| 06:16 |
hmmmm |
alright here's what I think I want to do |
| 06:16 |
hmmmm |
first I'll finish off what I'm working on |
| 06:16 |
hmmmm |
the lua envlock interface |
| 06:16 |
hmmmm |
then i'm going to merge est's LuaSecureRandom |
| 06:17 |
hmmmm |
then I'm going to combine all the different Randoms into a single base class, |
| 06:17 |
hmmmm |
and expose the same kind of object oriented interface through lua |
| 06:17 |
hmmmm |
so that way somebody can do local rand = new Random(type="secure") or type="pcg" etc. |
| 06:18 |
hmmmm |
or... |
| 06:18 |
hmmmm |
local rand = new SecureRandom |
| 06:18 |
hmmmm |
so on |
| 06:19 |
est31 |
the first two things sound great, about the last, I'm not sure how you want to unify algorithms with different input sizes/output sizes? |
| 06:20 |
hmmmm |
the input/output sizes will be interface defined and abstracted over each implementation |
| 06:21 |
est31 |
the specific low level methods should still be available |
| 06:21 |
hmmmm |
of course |
| 06:21 |
hmmmm |
but in general i think more attention ought to be payed to the interface |
| 06:21 |
est31 |
some don't need such, like the secure random |
| 06:22 |
est31 |
(methods, not attention :p) |
| 06:22 |
hmmmm |
everybody wants to add something to the modding api |
| 06:22 |
hmmmm |
they don't give a crap if it's symmetrical or makes sense or is consistent with the rest of it or not |
| 06:23 |
hmmmm |
i think we owe it to our modders to give them a consistent, predictable interface |
| 06:23 |
est31 |
agreed |
| 06:23 |
hmmmm |
like even Win32 api is more consistent than what we have right now |
| 06:23 |
hmmmm |
christ.. |
| 06:23 |
est31 |
but we shouldnt also hide away algorithm details from them |
| 06:24 |
est31 |
at least not here |
| 06:26 |
est31 |
we should provide an api for #3237 like expectations "throw this number at it, let it do something with it" as well as one for those who can handle strict specifications of input/output for algorithms |
| 06:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/3237 -- PseudoRandom always generating same sequence with big seed |
| 06:27 |
est31 |
but yeah, there are horribly ugly examples of what you talk about, like #2658 |
| 06:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/2658 -- get_look_yaw, set_look_yaw, get_look_pitch, set_look_pitch unable to use same values as input/output |
| 06:28 |
hmmmm |
not only that but this is a perfect of example of why people should wait for the client side modding |
| 06:28 |
est31 |
btw why did I say "but" |
| 06:28 |
hmmmm |
come on man |
| 06:28 |
est31 |
there is no but here |
| 06:29 |
hmmmm |
there's so much development TODO, such little time :( |
| 06:29 |
hmmmm |
I can't do any meaningful amount of development on minetest outside of vacations |
| 06:30 |
est31 |
it still should be fun, not an obligation |
| 06:31 |
|
Lunatrius` joined #minetest-dev |
| 06:37 |
est31 |
what do you think hmmmm, once client side modding arrives, should such callbacks be removed? |
| 06:38 |
|
nrzkt joined #minetest-dev |
| 06:38 |
hmmmm |
which callbacks |
| 06:38 |
est31 |
like set_look_pitch for players |
| 06:38 |
hmmmm |
that's a callback?? |
| 06:39 |
est31 |
API callback or whatever |
| 06:39 |
hmmmm |
modding API function |
| 06:39 |
hmmmm |
we can't really remove things from the modding api |
| 06:39 |
waressearcher2 |
est31: is client side modding in development ? it should decrease lag, right ? |
| 06:39 |
est31 |
waressearcher2, it is not, but it is planned |
| 06:40 |
est31 |
or dont know |
| 06:40 |
est31 |
ask hmmmm |
| 06:40 |
est31 |
he had parts of a patch a while back |
| 06:40 |
hmmmm |
things that obviously should be client side modding get emulated by broadcasting a mod RPC call |
| 06:40 |
hmmmm |
yeah it is in development but I put it on pause for a while to fix bugs |
| 06:41 |
est31 |
nrzkt, can you replace the line in server.cpp with |
| 06:41 |
est31 |
actionstream<<player->getName() <<" [" << ip_str << "] joins game (id " << player->getPlayerSAO()->getId() << "). " << std::endl; |
| 06:42 |
est31 |
that gives you the id, once your wife gets deleted, you can look up the id, and find out if indeed that id was scheduled for deletion |
| 06:47 |
nrzkt |
est31: good idea, i will add a else in my condition to handle player |
| 06:48 |
nrzkt |
i need to fix my puppetmaster , 200 servers are disconnected at work, and i add this condition :p |
| 06:57 |
hmmmm |
ShadowNinja: is there a reason for src/threads.h? |
| 06:58 |
|
Krock joined #minetest-dev |
| 07:08 |
|
Darcidride joined #minetest-dev |
| 07:11 |
|
Puma_rc joined #minetest-dev |
| 07:25 |
hmmmm |
okay, now that I'm actually working with the new threading interface I have a couple of complaints... |
| 08:33 |
|
jin_xi joined #minetest-dev |
| 09:16 |
|
Dartmouth joined #minetest-dev |
| 09:17 |
|
julienrat joined #minetest-dev |
| 09:30 |
|
Amaz joined #minetest-dev |
| 09:38 |
|
julienrat left #minetest-dev |
| 09:51 |
|
kaeza joined #minetest-dev |
| 10:01 |
|
Player_2 joined #minetest-dev |
| 10:15 |
|
OldCoder joined #minetest-dev |
| 10:43 |
|
proller joined #minetest-dev |
| 11:03 |
|
proller joined #minetest-dev |
| 11:59 |
|
proller joined #minetest-dev |
| 12:15 |
|
julienrat joined #minetest-dev |
| 13:06 |
|
nyje joined #minetest-dev |
| 13:13 |
|
zat joined #minetest-dev |
| 13:18 |
|
WSDguy2014 joined #minetest-dev |
| 13:18 |
|
zat joined #minetest-dev |
| 14:43 |
|
julienrat joined #minetest-dev |
| 14:59 |
|
hmmmm joined #minetest-dev |
| 15:00 |
|
jin_xi joined #minetest-dev |
| 15:43 |
|
rubenwardy joined #minetest-dev |
| 15:44 |
|
Hunterz joined #minetest-dev |
| 15:57 |
|
Icedream joined #minetest-dev |
| 15:57 |
|
nrzkt joined #minetest-dev |
| 16:23 |
|
julienrat joined #minetest-dev |
| 17:07 |
|
Gael-de-Sailly joined #minetest-dev |
| 17:27 |
|
Darcidride joined #minetest-dev |
| 17:42 |
|
younishd joined #minetest-dev |
| 17:47 |
|
DFeniks joined #minetest-dev |
| 17:49 |
|
gravgun joined #minetest-dev |
| 17:54 |
|
Puma_rc_ joined #minetest-dev |
| 18:13 |
|
CraigyDavi joined #minetest-dev |
| 18:13 |
|
celeron55 joined #minetest-dev |
| 18:20 |
|
est31 joined #minetest-dev |
| 18:21 |
est31 |
btw paramat congrats to your 100th commit |
| 18:24 |
Krock |
\o/ |
| 19:37 |
|
FR^2 joined #minetest-dev |
| 19:57 |
|
Player_2 joined #minetest-dev |
| 20:13 |
|
shadowzone joined #minetest-dev |
| 20:19 |
|
Amaz joined #minetest-dev |
| 20:37 |
|
proller joined #minetest-dev |
| 22:53 |
|
gravgun left #minetest-dev |
