| Time |
Nick |
Message |
| 00:37 |
|
hintss joined #minetest-dev |
| 00:57 |
|
proller joined #minetest-dev |
| 01:14 |
|
hintss joined #minetest-dev |
| 01:58 |
|
jin_xi_ joined #minetest-dev |
| 02:01 |
|
peacock486 joined #minetest-dev |
| 02:03 |
|
disablec1 joined #minetest-dev |
| 02:06 |
|
Taoki joined #minetest-dev |
| 02:52 |
|
hintss joined #minetest-dev |
| 03:01 |
|
Wayward_One joined #minetest-dev |
| 03:33 |
|
hintss joined #minetest-dev |
| 04:01 |
VanessaE |
hmmmm: can we PLEASE get 0.4.12 out soon? 0.4.11 is broken beyond repair for too many people |
| 04:01 |
VanessaE |
here's a crash that happened earlier for one of my users: [01-21 22:59] <xxxx> Hey VaneesaE force to use 4.11 and it craps out on both win32 and win64 versions.... ERROR[MeshUpdateThread]: Waiting for texture disable_img.png timed out. |
| 04:02 |
VanessaE |
(I have strict version checking enabled) |
| 04:02 |
hmmmm |
isn't disable_img.png part of the base texture set? |
| 04:02 |
hmmmm |
was this a bug fixed between 0.4.11's release and now? |
| 04:02 |
VanessaE |
idk |
| 04:03 |
VanessaE |
I've never seen that one happen before myself |
| 04:03 |
VanessaE |
(but I have seen OTHER textures "time out" before) |
| 04:03 |
hmmmm |
and you know for sure this is a bug that was fixed in 0.4.11?? |
| 04:03 |
hmmmm |
otherwise why would you've brought it up |
| 04:04 |
VanessaE |
I don't. But I DO know it was introduced sometime between 0.4.10 and 0.4.11. |
| 04:04 |
VanessaE |
I'm operating under the assumption that if it works for me and others, it would work for him too were he running it :) |
| 04:04 |
hmmmm |
i'm not going to pretend i know anything about the source of that error but |
| 04:04 |
VanessaE |
(it being current HEAD) |
| 04:04 |
hmmmm |
he can definitely solve it by getting a better texture pack that doesn't omit disable_img.png |
| 04:05 |
hmmmm |
or by turning shaders on |
| 04:05 |
VanessaE |
erm, I think he's using default textures? |
| 04:05 |
VanessaE |
can't say about shaders - he already signed off before I could investigate further. |
| 04:05 |
hmmmm |
well |
| 04:06 |
hmmmm |
i can agree to a release |
| 04:07 |
hmmmm |
we'll set the release date to be the 28th |
| 04:08 |
VanessaE |
ok |
| 04:09 |
VanessaE |
meanwhile, another user indicates that there's evidence of another memory leak that will need addressed. Zeno will probably handle that though. |
| 04:09 |
VanessaE |
his build is from the 17th, so his bug may already be fixed by now. |
| 04:09 |
VanessaE |
(I think that's the date) |
| 04:09 |
VanessaE |
damn it why does everyone have to sign off before I can ask questions *grumble* |
| 06:10 |
|
paramat joined #minetest-dev |
| 06:26 |
|
hintss left #minetest-dev |
| 06:33 |
paramat |
hi hmmmm this is ready for review and merge #2161 |
| 06:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/2161 -- Mgv7: Improve rivers and remove abysses. Speed optimise perlinmap calculations. by paramat |
| 06:33 |
hmmmm |
i'll check it out |
| 06:41 |
|
Hunterz joined #minetest-dev |
| 06:52 |
hmmmm |
ahh it's good to see somebody working on mapgen v7 again |
| 06:53 |
hmmmm |
sadly none of this fixes the crap terrain output |
| 06:53 |
hmmmm |
the next chance I get some more free time i'm going to work on the biome stuff |
| 06:56 |
hmmmm |
maybe generateRidgeTerrain needs to be redone entirely |
| 06:56 |
paramat |
i intend to tune the terrain for a future PR |
| 06:57 |
hmmmm |
a lot of the code there is sooo arbitrary, and the effect each bit produces is either unnecessary or duplicated |
| 06:57 |
hmmmm |
s/duplicated/redundant/ |
| 06:58 |
paramat |
yes i simplified it a little, i still like the results so left it mostly as it is |
| 06:58 |
hmmmm |
generateBaseTerrain sucks too because the attempt at interpolation between normal height and highlands height doesn't really work and it takes 3 noises to get something just as good looking as one |
| 06:59 |
hmmmm |
sometimes, just sometimes, i thought about copying v6's terrain function. for being entirely 2d it sure has nice output |
| 06:59 |
paramat |
yeah i agree it's output is not great |
| 07:00 |
paramat |
will try some alternative noiseparams |
| 07:00 |
hmmmm |
the persistence variation is the only saving grace |
| 07:00 |
hmmmm |
yep... you just found the most time consuming part of working on the mapgen |
| 07:00 |
hmmmm |
tuning the noise parameters has such a profound effect on the quality of the output but takes so much diddlying around |
| 07:01 |
paramat |
so true =P |
| 07:01 |
hmmmm |
for v8 I have an idea |
| 07:01 |
hmmmm |
the first attempt with v7 i had negative 3d noise carving out pieces of large 2d noise mountains |
| 07:02 |
hmmmm |
and due to an oversight it cut off at y == water_level |
| 07:02 |
hmmmm |
but it made awesome looking flat areas |
| 07:02 |
hmmmm |
so I'm thinking of doing negative 3d noise with hard cutoffs to make parts of land very buildable |
| 07:03 |
hmmmm |
the effect area could be determined by 2d noise and the effect detail with 3d |
| 07:04 |
hmmmm |
so one of those 2d noise * 3d noise types of things |
| 07:05 |
hmmmm |
also try using log(y^3) for things, it has a very nice cutoff that gives flat, buildable areas on top of mountains while still maintaining a naturally curved look around the edges |
| 07:06 |
paramat |
interesting .. |
| 07:06 |
hmmmm |
hrmm |
| 07:07 |
hmmmm |
are you sure it's a wise idea to remove the persistmap rangelim? |
| 07:07 |
paramat |
i looked at the noiseparams, they look to limit the values well enough |
| 07:07 |
paramat |
.. between 0.4 and 0.9 |
| 07:08 |
paramat |
if not they should be tuned to do so |
| 07:09 |
hmmmm |
well |
| 07:09 |
paramat |
perhaps you wanted it to be clipped for large areas of 0.4? |
| 07:09 |
hmmmm |
you've tested it, right? |
| 07:09 |
paramat |
yeah tested |
| 07:09 |
hmmmm |
no, clipping for large areas of a certain persistence value doesn't make much sense |
| 07:09 |
hmmmm |
it just makes large areas of terrain boring, doesn't add any nice effect |
| 07:09 |
hmmmm |
that is, if it often dives below 4 |
| 07:09 |
paramat |
yeah |
| 07:11 |
paramat |
i know how to look at noiseparams and calculate the range of the output, so can tune persist to not need limiting |
| 07:11 |
hmmmm |
ahh nice catch, i didn't realize the river generation wasn't relative to the water level |
| 07:11 |
hmmmm |
calculating the range of noise given a noiseparams is slightly more difficult now that lacunarity is modifiable |
| 07:12 |
hmmmm |
i should probably write functions for getting min/max of a noiseparam |
| 07:12 |
paramat |
i'll check to see if the whole v7 terrain is relative to water level |
| 07:12 |
hmmmm |
it shouldn't be |
| 07:12 |
|
ImQ009 joined #minetest-dev |
| 07:12 |
hmmmm |
the whole point of water level is to cover more or less of the land with water |
| 07:12 |
paramat |
ah yes |
| 07:13 |
hmmmm |
if you make all terrain generation relative, then it's as if there was no water level parameter to begin with |
| 07:13 |
paramat |
whereas v6 is all relative i think |
| 07:13 |
hmmmm |
hrmmm... could've sworn I fixed that |
| 07:13 |
paramat |
okay im probably wrong |
| 07:14 |
hmmmm |
it definitely was all relative a couple versions ago |
| 07:14 |
hmmmm |
i remember fixing this |
| 07:14 |
paramat |
sometimes i wonder if another mg param 'terrain average y' could set the terrain height |
| 07:15 |
paramat |
just a random thought, not important |
| 07:16 |
hmmmm |
i think that's the wrong way to approach things |
| 07:16 |
hmmmm |
you mean just offset all the generated terrain by + whatever, right? |
| 07:17 |
paramat |
yes |
| 07:17 |
paramat |
so terrain y and water level y are independant |
| 07:17 |
paramat |
and settable |
| 07:17 |
hmmmm |
making everything higher/bigger/larger on average is an effect that can be done with noiseparams |
| 07:17 |
hmmmm |
but you need to know the right ones |
| 07:17 |
hmmmm |
it sounds like a good idea might be to have some kind of mapgen meta-param |
| 07:18 |
hmmmm |
where if you set this, it'll auto-adjust the right noiseparams needed to get the desired effect |
| 07:18 |
hmmmm |
but as for adding another actual mapgen parameter? please no :( |
| 07:19 |
paramat |
i agree |
| 07:19 |
hmmmm |
i severely overdid the mapgen parameter thing |
| 07:19 |
hmmmm |
the entire reason why i made noiseparams was because i wanted the terrain output to be flatter or larger so i could have buildable terrain |
| 07:20 |
paramat |
.. just a random thought that is not worth developing |
| 07:20 |
hmmmm |
and then i went overboard |
| 07:20 |
hmmmm |
making every tiny thing that can be adjusted into something adjustable |
| 07:23 |
hmmmm |
so i'm not sure if i ever mentioned it but the original idea with the noiseparam thing was to have a bunch of preset ones |
| 07:24 |
hmmmm |
this was back when mapgen v6 was the only one |
| 07:24 |
paramat |
you mean a choice of different complete sets of noiseparams? |
| 07:25 |
hmmmm |
like i envisioned being able to select "desert land" which cranks up the spread factor for base terrain, sets the biome threshhold level very low, and the base terrain scale low |
| 07:25 |
paramat |
ah nice |
| 07:25 |
hmmmm |
or maybe a "tropical island" preset that's crank up the v6 humidity for lots of jungle trees and increase the water level so mostly everything is an island |
| 07:26 |
hmmmm |
s/that's/that'd/ |
| 07:26 |
paramat |
this one is WIP but almost done #2175 |
| 07:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/2175 -- Mgv5: Speed optimise noise. Remove blobgen, add large caves. Cavegen: add mgv5 large caves by paramat |
| 07:26 |
hmmmm |
blobgen lol |
| 07:27 |
hmmmm |
not every tiny component needs to be "thing"-gen |
| 07:27 |
hmmmm |
oh no, more 3d noise :) |
| 07:27 |
hmmmm |
as if it weren't slow enough |
| 07:28 |
hmmmm |
ahh you're using the procedural caves |
| 07:28 |
paramat |
hehgen |
| 07:28 |
paramat |
mvgv5 is faster now, 70ms on my i5 |
| 07:28 |
hmmmm |
with debug? |
| 07:29 |
paramat |
no normal build |
| 07:29 |
hmmmm |
oh |
| 07:29 |
hmmmm |
yeah.. in practice i can't notice a difference between anything faster than ~150ms |
| 07:29 |
hmmmm |
it's because of the mesh generation GPU lag |
| 07:29 |
hmmmm |
i have an nvidia card |
| 07:30 |
hmmmm |
you're probably much better off with intel integrated graphics |
| 07:30 |
paramat |
all those tiny lava pockets really lagged the game due to the liquid queue |
| 07:30 |
hmmmm |
yup |
| 07:30 |
hmmmm |
the real solution is to fix liquid flowing to be less cpu intensive, instead of making the mapgen more boring |
| 07:31 |
hmmmm |
i have a feeling not nearly as many liquids need to be in the queue as there are |
| 07:31 |
paramat |
yes i have intel integrated haswell 4600 or something.. |
| 07:31 |
|
leat joined #minetest-dev |
| 07:33 |
VanessaE |
<offtopic for this discussion> a user and I were discussing a feature where the user would, on hitting an appropriate climb or descend key, automatically snap to whatever climbable node is focused, if any. that's _game specific, but I can't see any way to even detect user-specific keypresses in realtime, or get the pointed_thing even if I did. Any thoughts on this? |
| 07:34 |
VanessaE |
(and did that whole thing actually make it through?) |
| 07:34 |
paramat |
cool, thanks for the merge |
| 07:34 |
VanessaE |
the above is something I was gonna code myself, but I can't see any way to do so without a bit of engine support. |
| 07:39 |
hmmmm |
yup, you can't do that from a mod |
| 07:39 |
paramat |
sorry not keen on the auto-snap, players can position themselves properly and not be lazy =) |
| 07:39 |
hmmmm |
i like auto-snap |
| 07:40 |
VanessaE |
paramat: well I would normally agree, but I can see it being useful in e.g. tablet clients |
| 07:40 |
VanessaE |
and this guy had some trouble getting his client centered on the ladder prior to climbing |
| 07:40 |
VanessaE |
so I figured I'd code a mod...but I can't :) |
| 07:41 |
|
cib0 joined #minetest-dev |
| 07:41 |
hmmmm |
client side lua is going to be awesome |
| 07:41 |
hmmmm |
for this kind of stuff |
| 07:42 |
paramat |
i personally don't care about smartphones and tablets hehe pain in the ass to cater for |
| 07:47 |
VanessaE |
also, I don't know if you saw, over on #minetest, sofar proposed an idea of allowing animated textures to be used within particles (I don't know one way or the other if they can be). I believe he intends to code it. |
| 07:48 |
hmmmm |
pretty sure this conflicts with the upcoming irrlicht particles... |
| 07:49 |
VanessaE |
good point. |
| 07:49 |
paramat |
wow looking at my todo list, 'all' that's left to do in v7 is tune the terrain through noiseparams, time consuming but fun |
| 07:51 |
VanessaE |
looks like a few people have inquired about it in the past. |
| 07:51 |
VanessaE |
(that is, making irrlicht's particles allow animations) |
| 07:53 |
VanessaE |
*shrug* |
| 07:53 |
|
Sissiuser joined #minetest-dev |
| 08:13 |
|
FR^2 joined #minetest-dev |
| 08:20 |
|
paramat left #minetest-dev |
| 08:50 |
|
nrzkt joined #minetest-dev |
| 08:50 |
nrzkt |
hi all ! |
| 08:51 |
VanessaE |
hi |
| 09:04 |
|
kilbith joined #minetest-dev |
| 09:24 |
|
cib0 joined #minetest-dev |
| 09:41 |
kahrl |
VanessaE: I always get a timeout on disable_img when I run minetest on an extremely slow computer |
| 09:41 |
kahrl |
that is, valgrind |
| 09:41 |
kahrl |
it doesn't cause a crash though |
| 10:20 |
|
jin_xi joined #minetest-dev |
| 10:27 |
|
twoelk|2 joined #minetest-dev |
| 10:39 |
|
n4x joined #minetest-dev |
| 10:45 |
|
kaeza joined #minetest-dev |
| 10:45 |
|
alexxs joined #minetest-dev |
| 12:10 |
|
werwerwer joined #minetest-dev |
| 12:17 |
|
proller joined #minetest-dev |
| 12:29 |
|
ImQ009 joined #minetest-dev |
| 12:39 |
|
gregorycu joined #minetest-dev |
| 12:41 |
gregorycu |
Hi there |
| 12:55 |
|
leat joined #minetest-dev |
| 13:13 |
|
T4im joined #minetest-dev |
| 13:21 |
nrzkt |
hi |
| 13:26 |
gregorycu |
So, the performance around lighting is no the best |
| 13:49 |
|
Kalabasa joined #minetest-dev |
| 14:13 |
|
SopaXT joined #minetest-dev |
| 14:23 |
|
proller joined #minetest-dev |
| 14:26 |
kilbith |
ShadowNinja, are you going to send a PR for the writtable book ? |
| 14:51 |
|
CraigyDavi joined #minetest-dev |
| 14:54 |
|
jin_xi joined #minetest-dev |
| 15:05 |
|
hmmmm joined #minetest-dev |
| 15:07 |
|
DFeniks joined #minetest-dev |
| 15:22 |
|
cib0 joined #minetest-dev |
| 15:47 |
|
roniz joined #minetest-dev |
| 15:53 |
|
kilbith joined #minetest-dev |
| 16:02 |
|
VanessaE joined #minetest-dev |
| 16:03 |
|
ImQ009 joined #minetest-dev |
| 16:06 |
|
Calinou joined #minetest-dev |
| 16:48 |
|
ImQ009 joined #minetest-dev |
| 16:50 |
|
leat joined #minetest-dev |
| 16:51 |
|
MinetestForFun joined #minetest-dev |
| 16:52 |
|
MinetestForFun joined #minetest-dev |
| 17:02 |
|
rubenwardy joined #minetest-dev |
| 17:04 |
|
cib0 joined #minetest-dev |
| 17:19 |
|
sofar joined #minetest-dev |
| 17:28 |
|
Krock joined #minetest-dev |
| 17:30 |
|
Amaz joined #minetest-dev |
| 17:36 |
|
Hunterz joined #minetest-dev |
| 17:50 |
|
Acerspyro joined #minetest-dev |
| 18:21 |
|
NakedFury joined #minetest-dev |
| 18:44 |
|
DFeniks joined #minetest-dev |
| 18:53 |
|
Nate123 joined #minetest-dev |
| 19:03 |
kilbith |
someone can close #2161 ? |
| 19:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/2161 -- Mgv7: Improve rivers and remove abysses. Speed optimise perlinmap calculations. by paramat |
| 19:03 |
kilbith |
already merged by hmmmm. |
| 19:06 |
|
PilzAdam joined #minetest-dev |
| 19:08 |
|
nrzkt joined #minetest-dev |
| 19:09 |
|
rubenwardy joined #minetest-dev |
| 19:18 |
|
Wayward_One_ joined #minetest-dev |
| 19:25 |
|
twoelk joined #minetest-dev |
| 19:34 |
kahrl |
kilbith, done |
| 19:42 |
|
Player_2 joined #minetest-dev |
| 19:49 |
|
Miner_48er joined #minetest-dev |
| 19:51 |
|
cib0 joined #minetest-dev |
| 20:31 |
|
MinetestForFun joined #minetest-dev |
| 20:39 |
|
ImQ009 joined #minetest-dev |
| 20:51 |
|
nore joined #minetest-dev |
| 20:57 |
|
DaveTheModder joined #minetest-dev |
| 21:54 |
|
Player_2 joined #minetest-dev |
| 21:56 |
|
Acerspyro joined #minetest-dev |
| 21:56 |
|
diemartin joined #minetest-dev |
| 22:38 |
|
Player_2 joined #minetest-dev |
| 22:43 |
|
proller joined #minetest-dev |
| 22:52 |
VanessaE |
connected_glass = false <--- this is still the default setting for default glass, yes? |
| 22:53 |
VanessaE |
(because if it is, it ain't workin') |
| 22:53 |
VanessaE |
well wait, is that a client-side setting? |
| 22:56 |
|
nrzkt left #minetest-dev |
| 22:58 |
|
MinetestForFun joined #minetest-dev |
| 22:59 |
kahrl |
VanessaE: client side, yes |
| 22:59 |
VanessaE |
ok, then it doesn't really default to false |
| 23:00 |
VanessaE |
lemme update just to be sure. |
| 23:01 |
VanessaE |
hm. maybe something in dreambuilder needs updated. |
| 23:01 |
VanessaE |
I'll bet moreblocks is redefining glass. |
| 23:04 |
kilbith |
VanessaE, https://github.com/minetest/minetest_game/issues/394 |
| 23:05 |
kahrl |
I can't reproduce that bug |
| 23:05 |
kahrl |
connected_glass = false works fine in current minetest_game |
| 23:05 |
kilbith |
ditto |
| 23:05 |
VanessaE |
yeah, it works fine for me in mt_game too |
| 23:06 |
|
blaaaaargh joined #minetest-dev |
| 23:06 |
VanessaE |
the node def in dreambuilder is identical (drawtype = "glasslike_framed_optional"), so it must be some mod redefining it |
| 23:07 |
kahrl |
VanessaE: you already guessed the offender ;) |
| 23:07 |
kahrl |
moreblocks |
| 23:07 |
kahrl |
"grep -R glasslike ." works wonders |
| 23:07 |
VanessaE |
yep, I'm checking now |
| 23:08 |
VanessaE |
minetest.override_item("default:glass", { |
| 23:08 |
VanessaE |
drawtype = "glasslike_framed", |
| 23:08 |
VanessaE |
}) |
| 23:08 |
VanessaE |
*growl* |
| 23:11 |
|
MinetestForFun_ joined #minetest-dev |
| 23:26 |
VanessaE |
ok that's sorted. |
| 23:28 |
VanessaE |
btw, why is it that some glass objects in the inventory are dark? |
| 23:28 |
VanessaE |
seems to only happen with glasslike drawtype (or _framed_optional when it's not set to framed in the client). been that way for ages. |
| 23:31 |
VanessaE |
(default glass is unaffected because it uses minetest.inventorycube() to draw its inventory image) |
| 23:33 |
|
shadowzone joined #minetest-dev |
| 23:34 |
kahrl |
could be because NDT_GLASSLIKE uses wrong normals |
| 23:35 |
kahrl |
it sets them to zero in fact |
| 23:36 |
VanessaE |
shall I apply the usual workaround to moreblocks then? |
| 23:40 |
kahrl |
ok, simply setting EMF_NORMALIZE_NORMALS doesn't do the trick |
| 23:40 |
kahrl |
(makes sense since it's not recalculating but just normalizing) |
| 23:40 |
kahrl |
so glasslike itself needs to be fixed |
| 23:41 |
kahrl |
VanessaE: I have no clue about moreblocks |
| 23:42 |
VanessaE |
well I know how to fix it there. |
| 23:42 |
kahrl |
it shouldn't be needed though if moreblocks just does override_item |
| 23:42 |
VanessaE |
it does override for default glass but it has some of its own glass items that are fully-defined (of course), so those need fixed |
| 23:42 |
kahrl |
in that case yes |
| 23:43 |
VanessaE |
just wanted to make sure if I was about to fix something that didn't actually need done on the mod side :) |
| 23:43 |
kahrl |
well as I said, if glasslike is fixed to provide correct normals, it will work |
| 23:44 |
VanessaE |
*nod* |
| 23:45 |
kahrl |
actually providing incorrect, but different normals might be enough |
| 23:46 |
kahrl |
https://gist.github.com/kahrl/a7fb4ad0ae4a3d760739 |
| 23:46 |
kahrl |
this sets a normal of (0,0,-1) on every face |
| 23:46 |
kahrl |
that's where the light comes from in rendered inventory textures, so glass will be bright |
| 23:47 |
kahrl |
(the alternative is unrolling the whole loop or making it much more inefficient to fix an edge case) |
| 23:49 |
kahrl |
well or do this: https://gist.github.com/kahrl/15f5221561d293cd98ca |
| 23:49 |
kahrl |
^ slightly slower than the first gist but calculates correct normals |
| 23:49 |
VanessaE |
well that first one makes the glass a tad dimmer in-game |
| 23:49 |
VanessaE |
oh ok, lemme give that a try then |
| 23:50 |
kahrl |
I'm pretty sure that is impossible |
| 23:50 |
kahrl |
the in-game shaders ignore the normals |
| 23:51 |
|
VanessaE_ joined #minetest-dev |
| 23:51 |
|
proller joined #minetest-dev |
| 23:51 |
VanessaE_ |
*growl* |
| 23:51 |
VanessaE_ |
X is not exactly the most stable these days :-/ |
| 23:51 |
kahrl |
actually.. no they don't |
| 23:52 |
kahrl |
the top face is lighter for example, which is calculated by checking normals |
| 23:55 |
kahrl |
ugh |
| 23:55 |
kahrl |
why does the second gist cause these strange lighting patterns in-game |
| 23:56 |
|
Megaf joined #minetest-dev |
| 23:56 |
kahrl |
oh derp |
| 23:57 |
* VanessaE_ |
waits.. :) |
| 23:57 |
kahrl |
it'd make sense to change all 4 vertices, wouldn't it? :) |
| 23:57 |
VanessaE_ |
haha |
| 23:57 |
kahrl |
that's why I didn't do it :P |
| 23:57 |
kahrl |
ok, fixed now: https://gist.github.com/kahrl/1c4531242eb2aaefcfa2 |
