| Time |
Nick |
Message |
| 00:04 |
|
Wayward_One joined #minetest-dev |
| 00:14 |
Fritigern |
grondilu: when trying to solve issues, never delete files, just rename them. that way if what you tried didn't work, you can restore the original file name. And if what you tried DOES work, you have something to show devs. |
| 00:14 |
grondilu |
indeed. I'll try to remember in the future. |
| 00:44 |
|
proller joined #minetest-dev |
| 00:56 |
|
shadowzone joined #minetest-dev |
| 00:57 |
|
shadowzone joined #minetest-dev |
| 01:06 |
|
MinerDad joined #minetest-dev |
| 01:10 |
|
diemartin joined #minetest-dev |
| 01:33 |
paramat |
hmmmm, when you have time please could you review/merge https://github.com/minetest/minetest/pull/1982 |
| 01:36 |
|
exio4 joined #minetest-dev |
| 01:41 |
|
MinerDad joined #minetest-dev |
| 02:15 |
|
Megaf joined #minetest-dev |
| 02:40 |
hmmmm |
hmm |
| 02:42 |
hmmmm |
while we're on the topic of improving noiseparams documentation, would you mind writing about using noise objects created for 2d being used by 3d noise and vice versa? |
| 02:42 |
hmmmm |
write a warning that specifying a greater size than necessary consumes more memory |
| 02:43 |
hmmmm |
and maybe the "flat" format isn't clear enough |
| 02:43 |
hmmmm |
it would be clear to any serious programmers but probably not casual lua scripters |
| 02:55 |
|
MinerDad joined #minetest-dev |
| 02:57 |
|
exio4 joined #minetest-dev |
| 03:00 |
|
electrodude512 joined #minetest-dev |
| 03:02 |
|
Megaf joined #minetest-dev |
| 03:03 |
paramat |
okay |
| 03:11 |
|
MinerDad joined #minetest-dev |
| 03:13 |
hmmmm |
paramat: http://fpaste.org/160439/86020141/ |
| 03:14 |
hmmmm |
if you try to use 3d noise on an object created with z == 1, i.e. created for 2d noise, getPerlinMap3D would return nil |
| 03:15 |
hmmmm |
if you try to use 2d noise on an object created with z != 1, and use it for 3d noise, you're wasting shittons of memory |
| 03:15 |
hmmmm |
and not use it for 3d noise** |
| 03:25 |
* paramat |
looks |
| 03:25 |
|
Megaf joined #minetest-dev |
| 03:26 |
paramat |
thanks for extra explanation |
| 03:27 |
hmmmm |
also include another line "Likewise, for 3d maps, V[x y z] can be accessed by V[(z * n * m) + (y * n) + (x * 1)]" |
| 03:28 |
hmmmm |
we might want to encourage the use of VoxelArea for flat perlin maps |
| 03:28 |
hmmmm |
but then again, if people are that dumb they might as well be using the structured perlin map variants |
| 03:28 |
paramat |
are the non-flat arrays useful for anything? i know that a flat array is faster to access |
| 03:28 |
hmmmm |
non-flat arrays are more user friendly |
| 03:29 |
paramat |
lol |
| 03:31 |
paramat |
never seen anyone use non-flat arrays, modders just copy my flat array mapgen examples |
| 03:32 |
hmmmm |
not sure if this is the right terminology, but i feel as if the modder community is mostly a cargo cult |
| 03:33 |
hmmmm |
as of right now there are only a very few at the top who actually understand what it is they're writing when they write mods |
| 03:34 |
paramat |
on that subject i will rewrite your voxelmanip lua mapgen example in the news thread to use your recommended method i'm now using in watershed https://github.com/paramat/watershed/blob/master/init.lua#L247 |
| 03:34 |
paramat |
tested to confirm noise objects are created once only on first mapchunk |
| 03:35 |
hmmmm |
oh i did it the stupid way didn't i |
| 03:35 |
hmmmm |
and everybody copied that example |
| 03:35 |
hmmmm |
fools |
| 03:35 |
paramat |
i copied it and pepole cpoied me hehe |
| 03:36 |
|
Megaf joined #minetest-dev |
| 03:36 |
hmmmm |
i think my original luavoxelmanip example had the parameters to calcLighting as well |
| 03:37 |
paramat |
when i tried to rewrite watershed to create noise objects outside 'on generated' i could not access them inside 'on generated', the objects were always nil |
| 03:37 |
paramat |
might be my mistake of course |
| 03:37 |
paramat |
is that because you can only pass 'minp maxp sed' to 'on generated'? |
| 03:38 |
paramat |
in the end what you see coded there seems simpler |
| 03:39 |
hmmmm |
what did you pass as the size parameters when you created them outside of on_generated()? |
| 03:42 |
hmmmm |
hrmm, looks like i was mistaken, you are able to leave z undefined as the size to get_perlin_map |
| 03:43 |
hmmmm |
it defaults to 0 when it gets read in, it's assumed to be 1 when allocating the noise point buf, and the z component is entirely ignored in getPerlin2D |
| 03:43 |
hmmmm |
i don't even need to write a patch for this |
| 03:59 |
paramat |
i used 'on mapgen init' to get chunksize and created the noise objects inside 'on mapgen init' |
| 04:00 |
hmmmm |
they're global in scope, still, right? |
| 04:00 |
paramat |
thats what i thought |
| 04:00 |
hmmmm |
chunksize is the number of blocks that make up a chunk btw, not the sidelen |
| 04:00 |
hmmmm |
chunksize * MAP_BLOCKSIZE == sidelen |
| 04:00 |
paramat |
yeah, i multiplied by 16 |
| 04:00 |
paramat |
nevermind it was probably a mistake of mine |
| 04:01 |
hmmmm |
no idea |
| 04:01 |
paramat |
don't have code to show you sorry i was that frustrated |
| 04:01 |
hmmmm |
i wouldn't rely on chunksize because it's so new |
| 04:01 |
hmmmm |
it'd break compatibility with older minetest servers |
| 04:01 |
paramat |
yep |
| 04:01 |
paramat |
so for the moment i'll consider current watershed to be the optimum method |
| 04:02 |
hmmmm |
i'd say that's fair |
| 04:02 |
paramat |
on the (delicate) subject of water flow, i often wonder if it should be changed to not spread out and multiply so much |
| 04:03 |
hmmmm |
isn't that configurable? |
| 04:03 |
paramat |
since now we have floatland worlds and fissures that are perfect for creating an ever-multiplying waterfall |
| 04:03 |
paramat |
oh liquid range yes |
| 04:04 |
hmmmm |
speaking of water behavior, i wish minetest's were more like minecraft's |
| 04:04 |
paramat |
thats what i was considering |
| 04:04 |
hmmmm |
where if an open area has a critical mass of water it flood fills everything fast |
| 04:04 |
hmmmm |
there's a good video of it.. hold on |
| 04:05 |
paramat |
i do think liquid range could be halved and still look fine |
| 04:05 |
paramat |
but might break worlds |
| 04:06 |
paramat |
maybe |
| 04:07 |
|
grondilu left #minetest-dev |
| 04:08 |
paramat |
my mapgens always seem to overload the liquid queue, there is always much non-flowing water around. not so much a problem in core mapgen |
| 04:13 |
|
Megaf joined #minetest-dev |
| 04:17 |
|
exio4 joined #minetest-dev |
| 04:46 |
paramat |
my vague/naive idea for waterflow was that when a falling column of water hits a surface, the potential 'spread footprint' is searched for the closest falloff (if there is one) and the water flows only to that one falloff only, creating a downhill one node wide stream, one falling column of water will then only result in another single falling column at the one falloff (no doubt problems i havent thought of, also com |
| 04:46 |
paramat |
plex, more processing) |
| 04:47 |
VanessaE |
I'd make it spread based on falloff depth |
| 04:47 |
VanessaE |
like if you find a falloff point, do a quick check for how many air nodes there are below that point, weight the flow toward that |
| 04:48 |
VanessaE |
so that you get rivers maybe several nodes wide |
| 04:48 |
VanessaE |
up to some reasonable cap |
| 04:48 |
VanessaE |
but always centered around the deepest cut |
| 04:49 |
paramat |
nice idea |
| 04:50 |
paramat |
like a search for 'most downhill direction' |
| 04:50 |
VanessaE |
yeah, something like that |
| 04:52 |
paramat |
MTs current system is probably the simplest and most lightweight, but the extreme water multiplication might make this simple system heavyweight |
| 04:53 |
paramat |
MC doesnt have to worry about huge vertical distances so i'm wary of it's sytems |
| 04:54 |
VanessaE |
what system does it use? |
| 04:54 |
paramat |
Vanessa something similar you wrote on IRC a while back was actually my inspiration for this idea |
| 04:55 |
VanessaE |
yeah? |
| 04:55 |
paramat |
dunno :} |
| 04:55 |
paramat |
yeah |
| 04:55 |
VanessaE |
what'd I say then? I don't remember :D |
| 04:55 |
VanessaE |
(as for MC< if they use a system like MT' |
| 04:55 |
VanessaE |
gah |
| 04:56 |
VanessaE |
(as for MC, if they use a system like MT's, while there's no height issue, there's a width issue, so it would just take more large water flows to DoS the system, if it isn't well-coded to handle that) |
| 04:56 |
paramat |
it was fairly close to what you proposed above: search for downhill, flow only towards that |
| 04:56 |
VanessaE |
oh ok |
| 04:57 |
VanessaE |
I guess the Achilles heel of any water reflow code is the get-node checks.. |
| 04:57 |
paramat |
so perhaps if no falloff is found in the spread footprint just spread out as currently to look 'right' |
| 04:57 |
VanessaE |
right |
| 05:15 |
|
neoascetic joined #minetest-dev |
| 05:19 |
|
DuDraig joined #minetest-dev |
| 05:29 |
|
sol_invictus joined #minetest-dev |
| 05:33 |
|
paramat left #minetest-dev |
| 05:42 |
|
exio4 joined #minetest-dev |
| 06:29 |
|
compunerd joined #minetest-dev |
| 06:31 |
|
neoascetic joined #minetest-dev |
| 06:32 |
|
Bratmon joined #minetest-dev |
| 06:40 |
|
Hunterz joined #minetest-dev |
| 06:50 |
|
Zeno` joined #minetest-dev |
| 06:59 |
|
chchjesus joined #minetest-dev |
| 07:05 |
|
exio4 joined #minetest-dev |
| 07:30 |
|
Megaf_ joined #minetest-dev |
| 07:40 |
|
jin_xi joined #minetest-dev |
| 07:55 |
|
neoascetic joined #minetest-dev |
| 07:57 |
|
Fritigern joined #minetest-dev |
| 08:13 |
|
proller joined #minetest-dev |
| 08:15 |
Zeno` |
#1979 is updated |
| 08:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/1979 -- Do not allow the m_transforming_liquid queue to increase until all RAM is consumed by Zeno- |
| 08:19 |
Zeno` |
perhaps it would be better to dump enough items so that the queue size becomes <= liquid_loop_max |
| 08:20 |
|
kilbith joined #minetest-dev |
| 08:21 |
|
Amaz joined #minetest-dev |
| 08:21 |
hmmmm |
i'll have to take a look at it tomorrow |
| 08:21 |
hmmmm |
you guys have a look at this https://github.com/kwolekr/minetest/commit/51b47c13ead13e6bd78bed210ec88962823303cb |
| 08:21 |
hmmmm |
'night |
| 08:25 |
Zeno` |
ok made the queue size after dumping have liquid_loop_max items |
| 08:29 |
|
exio4 joined #minetest-dev |
| 08:35 |
Zeno` |
Seems I've started a trend with these callback mechanisms |
| 08:37 |
|
chchjesus joined #minetest-dev |
| 08:47 |
|
neoascetic joined #minetest-dev |
| 09:07 |
|
AndChat|235809 joined #minetest-dev |
| 09:09 |
|
Amaz left #minetest-dev |
| 09:10 |
|
OldCoder joined #minetest-dev |
| 09:43 |
|
FR^2 joined #minetest-dev |
| 09:51 |
|
exio4 joined #minetest-dev |
| 10:13 |
|
ImQ009 joined #minetest-dev |
| 10:14 |
|
AnotherBrick joined #minetest-dev |
| 10:21 |
|
ImQ009_ joined #minetest-dev |
| 10:24 |
|
ImQ009 joined #minetest-dev |
| 10:30 |
Zeno` |
Ok, after 2 hours of real life testing I think #1979 is good to go |
| 10:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/1979 -- Do not allow the m_transforming_liquid queue to increase until all RAM is consumed by Zeno- |
| 10:34 |
neoascetic |
Shouldn't all commented code be removed? |
| 10:34 |
Zeno` |
neoascetic, where? |
| 10:34 |
neoascetic |
https://github.com/minetest/minetest/pull/1979/files#diff-ab005ad9757130721ffb66a09833090aR1934 |
| 10:34 |
Zeno` |
nah, it's handy for debugging |
| 10:35 |
Zeno` |
I should probably change that to infostream though |
| 10:35 |
neoascetic |
yeah |
| 10:35 |
Zeno` |
it's not worth having it there in "final" code though which is why it's commented out |
| 10:37 |
Zeno` |
neoascetic, I understand what you mean though. There is lots of "dead and useless" code all through the codebase. I don't think this is useless though. I could wrap them in #ifndef GIMME_DEBUG_STUFF but... |
| 10:37 |
neoascetic |
debugstream? |
| 10:38 |
Zeno` |
maybe yeah |
| 10:39 |
neoascetic |
maybe parametrized define statement? |
| 10:40 |
|
GrimKriegor joined #minetest-dev |
| 10:41 |
Zeno` |
I think these are all good ideas for after 0.4.11 |
| 10:41 |
Zeno` |
the code needs a spring clean |
| 10:50 |
|
proller joined #minetest-dev |
| 11:10 |
|
DFeniks joined #minetest-dev |
| 11:10 |
|
exio4 joined #minetest-dev |
| 11:26 |
|
DFeniks joined #minetest-dev |
| 11:26 |
|
ImQ009 joined #minetest-dev |
| 11:56 |
Megaf_ |
VanessaE: Hi, have you tried Zeno`s PR to fix the memory leak? |
| 11:56 |
VanessaE |
not yet |
| 11:56 |
VanessaE |
we discussed it a bit though |
| 12:01 |
|
ImQ009 joined #minetest-dev |
| 12:06 |
|
selat joined #minetest-dev |
| 12:12 |
Megaf_ |
Ok |
| 12:12 |
Megaf_ |
I will try that in a couple of minutes |
| 12:14 |
|
ImQ009 joined #minetest-dev |
| 12:16 |
VanessaE |
bbl |
| 12:17 |
Zeno` |
Megaf_, it's updated |
| 12:28 |
|
exio4 joined #minetest-dev |
| 12:39 |
Zeno` |
https://github.com/minetest/minetest/commit/7e34621b1de754449a5849f3ddfe8f77f32e64f5?diff=unified <-- does anyone know what this fixed? |
| 12:44 |
|
kaeza joined #minetest-dev |
| 12:59 |
Megaf_ |
Zeno`: Im compiling my server with this now, https://github.com/minetest/minetest/pull/1979 |
| 13:00 |
Megaf_ |
#1979 |
| 13:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/1979 -- Do not allow the m_transforming_liquid queue to increase until all RAM is consumed by Zeno- |
| 13:00 |
Zeno` |
thank you |
| 13:00 |
Megaf_ |
https://github.com/minetest/minetest/commit/7e34621b1de754449a5849f3ddfe8f77f32e64f5?diff=unified This is client side right? |
| 13:00 |
|
troller joined #minetest-dev |
| 13:08 |
Zeno` |
yes |
| 13:08 |
Zeno` |
what made you paste that? |
| 13:08 |
Zeno` |
I just pushed a candidate fix for it |
| 13:08 |
Megaf_ |
Is that pushed already or not? I don't get ti |
| 13:08 |
Megaf_ |
it* |
| 13:09 |
Zeno` |
yeah what you linked to is in the current source code |
| 13:09 |
Megaf_ |
right, I just pulled that then, recompilining the client here |
| 13:09 |
Megaf_ |
I have just put my server online with your memory leak patch |
| 13:10 |
Zeno` |
:3 |
| 13:10 |
Megaf_ |
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND |
| 13:10 |
Megaf_ |
20177 minetest 20 0 280m 85m 5540 S 7.3 8.4 0:21.75 minetestserver |
| 13:10 |
Megaf_ |
so far so good |
| 13:10 |
Megaf_ |
85 MB of RAM use, but nobody has joined yet |
| 13:20 |
|
johnnyjoy joined #minetest-dev |
| 13:23 |
Megaf_ |
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND |
| 13:23 |
Megaf_ |
20177 minetest 20 0 329m 150m 5936 S 9.6 14.7 2:08.11 minetestserver |
| 13:23 |
Megaf_ |
still not too bad |
| 13:23 |
Megaf_ |
two players joined and dug and built stuff |
| 13:24 |
Zeno` |
yeah, that's within what I expect using the default settings |
| 13:36 |
|
PilzAdam joined #minetest-dev |
| 13:42 |
|
exio4 joined #minetest-dev |
| 13:59 |
|
shadowzone joined #minetest-dev |
| 14:11 |
|
gravgun joined #minetest-dev |
| 14:20 |
|
exio41 joined #minetest-dev |
| 14:30 |
|
proller joined #minetest-dev |
| 14:30 |
|
selat joined #minetest-dev |
| 14:53 |
|
exio4 joined #minetest-dev |
| 15:00 |
|
MinerDad joined #minetest-dev |
| 15:10 |
|
proller__ joined #minetest-dev |
| 15:16 |
|
proller__ joined #minetest-dev |
| 15:17 |
|
shadowzone joined #minetest-dev |
| 15:25 |
|
ImQ009 joined #minetest-dev |
| 15:29 |
|
mint joined #minetest-dev |
| 15:30 |
mint |
Wayward_One |
| 15:30 |
mint |
!@##$ |
| 15:59 |
|
exio4 joined #minetest-dev |
| 16:02 |
|
hmmmm joined #minetest-dev |
| 16:02 |
|
kilbith joined #minetest-dev |
| 16:17 |
hmmmm |
#1979 I would prefer if you do not commit this |
| 16:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/1979 -- Do not allow the m_transforming_liquid queue to increase until all RAM is consumed by Zeno- |
| 16:17 |
hmmmm |
faulty time delta handling to say the least |
| 16:18 |
|
GrimKriegor joined #minetest-dev |
| 16:18 |
hmmmm |
it'd probably fail once every ~4 days |
| 16:18 |
Zeno` |
faulty in what way? |
| 16:19 |
hmmmm |
well overflow for one |
| 16:19 |
Zeno` |
yes |
| 16:19 |
Zeno` |
expected |
| 16:19 |
Zeno` |
it won't overflow :/ |
| 16:19 |
hmmmm |
two, why are you using getTime(PRECISION_MILLI) |
| 16:20 |
Zeno` |
because that it the most appropriate unit |
| 16:20 |
Zeno` |
how can the time overflow? |
| 16:22 |
hmmmm |
there are like 100 other places where timestamps are taken... i know they don't use getTime(PRECISION_MILLI) |
| 16:22 |
Zeno` |
if it overflows it dumps |
| 16:22 |
Zeno` |
who cares? |
| 16:22 |
hmmmm |
the unflowed liquids |
| 16:24 |
Zeno` |
>>> there are like 100 other places where timestamps are taken... i know they don't use getTime(PRECISION_MILLI) what's that mean? |
| 16:24 |
Zeno` |
it can't overflow btw |
| 16:26 |
hmmmm |
what if m_inc_trending_up_start_time = 0xFFFFFFFF and curr_time = 0x00000008 |
| 16:27 |
Zeno` |
How could that occur? |
| 16:27 |
hmmmm |
what are you talking about |
| 16:28 |
hmmmm |
m_inc_trending_up_start_time gets set when the timestamp == 0xFFFFFFFF |
| 16:28 |
hmmmm |
the loop runs 9 ms later at timestamp == 0x00000008 |
| 16:29 |
|
Calinou joined #minetest-dev |
| 16:33 |
hmmmm |
oh whoops, that only happens if the parameters are reversed |
| 16:35 |
hmmmm |
why not use dtime? |
| 16:36 |
hmmmm |
meh that's too complicated for this |
| 16:44 |
Calinou |
https://github.com/minetest/minetest/pull/1984 |
| 16:44 |
Calinou |
one-line change |
| 16:49 |
Zeno` |
you're right in a way, hmmmm but not in the way you first thought. Perhaps I should add if (m_inc_trending_up_start_time > curr_time) m_queue_size_timer_started = false; |
| 16:51 |
Zeno` |
? |
| 16:51 |
Zeno` |
that way every ~~~~~~~4 days the purge might not happen |
| 16:52 |
Zeno` |
well it will, it'll just be delayed a bit |
| 16:52 |
Zeno` |
Adding that now |
| 16:53 |
|
john_minetest joined #minetest-dev |
| 16:55 |
Zeno` |
ok, pushed |
| 16:55 |
Zeno` |
as for the milleseconds objection I think that's pedantry |
| 16:56 |
Zeno` |
hmmmm, ok to merge? |
| 16:56 |
hmmmm |
i would like if celeron weighed in on this |
| 16:56 |
Zeno` |
I'd like it if he didn't |
| 16:56 |
Zeno` |
:) |
| 16:57 |
hmmmm |
i am still reading the backlog from that day you two were brainstorming |
| 16:57 |
|
Hunterz joined #minetest-dev |
| 16:58 |
Zeno` |
I'm not sure if it was a brainstorm heheh |
| 16:59 |
|
kilbith joined #minetest-dev |
| 17:00 |
|
MinetestForFun joined #minetest-dev |
| 17:06 |
Zeno` |
Calinou, what's that for? |
| 17:07 |
Calinou |
for officially supporting sound replacing feature |
| 17:07 |
Calinou |
(a feature I was looking for) |
| 17:07 |
Calinou |
now you name the directory just sounds/, instead of testsounds/ (which sounds hacky) |
| 17:07 |
hmmmm |
is what's currently in 1979 an updated version of your pull request? |
| 17:08 |
Zeno` |
yes 1979 is now updated based on your feedback |
| 17:08 |
Zeno` |
adds 2 lines |
| 17:09 |
|
VanessaE joined #minetest-dev |
| 17:09 |
|
mpa1212 joined #minetest-dev |
| 17:09 |
Zeno` |
i.e. https://github.com/minetest/minetest/pull/1979/files#diff-ab005ad9757130721ffb66a09833090aR1940 |
| 17:10 |
hmmmm |
so it's basically your original solution with a much, much slower limit smoothing rate, with a "dump everything" provision |
| 17:10 |
Zeno` |
yes |
| 17:11 |
Zeno` |
basically |
| 17:11 |
hmmmm |
does increasing the multiplier according to server_step like that work in practice? |
| 17:11 |
Zeno` |
it did in my tests |
| 17:11 |
hmmmm |
my own feedback was to make the entire thing based on wall time, not server step time |
| 17:11 |
hmmmm |
well good enough i suppose |
| 17:12 |
hmmmm |
we'll see how it fares |
| 17:12 |
Zeno` |
I tried that as well but it caused the server to process way too much (i.e. it translated into lots of lag) |
| 17:13 |
Zeno` |
the "burst" deals with minor spikes only though |
| 17:14 |
Zeno` |
servers may have to adjust liquid_queue_purge_time to get an "optimal" value, but for every single test I did 30 seemed good |
| 17:16 |
|
exio4 joined #minetest-dev |
| 17:20 |
Zeno` |
anyway since you suppose it's good enough I'll merge before I sleep unless someone objects in the meantime |
| 17:23 |
|
rubenwardy joined #minetest-dev |
| 17:33 |
Zeno` |
is #9184 good to go? |
| 17:33 |
ShadowBot |
Zeno`: Error: Delemiter not found in "HTTP Error 404: Not Found" |
| 17:33 |
Zeno` |
err #1984 |
| 17:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/1984 -- Rename testsounds/ directory to sounds/ by Calinou |
| 17:37 |
|
Calinou joined #minetest-dev |
| 17:50 |
|
Krock joined #minetest-dev |
| 18:03 |
celeron55 |
about john_minetest's IRC log thing: i would like to put a very heavy weight on this issue on whether the logs are being used or not, eg. judged by referrers from serach engines |
| 18:03 |
celeron55 |
serach* |
| 18:04 |
celeron55 |
if people are searching and finding useful things in the logs, then they should not be deleted |
| 18:04 |
celeron55 |
if not, then they can be deleted |
| 18:05 |
hmmmm |
celeron, what do you think about zeno`'s latest iteration of the liquid transform limiting |
| 18:07 |
celeron55 |
i think it's too complicated for what it does but i trust Zeno` to have finally tested it enough |
| 18:07 |
celeron55 |
if not, it's his fault |
| 18:08 |
celeron55 |
i'll delete my pull request |
| 18:08 |
celeron55 |
(i mean, close) |
| 18:08 |
celeron55 |
the main point of my issue still stands though |
| 18:08 |
|
shadowzone joined #minetest-dev |
| 18:08 |
celeron55 |
nobody will configure those values so they might just as well not be settings |
| 18:08 |
Krock |
hmmmm, Could you tell me if "flags = eased," (how it is in lua_api.txt and "flags = "eased"," (with quotes) have the same functionality? |
| 18:08 |
celeron55 |
or at least the setting that already did exist |
| 18:09 |
celeron55 |
the new value is more useful |
| 18:10 |
celeron55 |
i mean, new setting |
| 18:11 |
hmmmm |
krock, the latter of the two is invalid syntax, plain and simple |
| 18:11 |
hmmmm |
celeron, the idea is that if it presents a problem you could increase the setting |
| 18:11 |
|
Wayward_One joined #minetest-dev |
| 18:11 |
Krock |
hmmmm, what if 'eased' s set to a value (like 0 or nil), then the value will be took |
| 18:12 |
hmmmm |
"will be took"? |
| 18:13 |
hmmmm |
hrmm.. celeron, thoughts on this? https://github.com/kwolekr/minetest/commit/51b47c13ead13e6bd78bed210ec88962823303cb |
| 18:13 |
|
Miner_48er joined #minetest-dev |
| 18:14 |
celeron55 |
hmmmm: but that was possible previously too |
| 18:14 |
celeron55 |
hmmmm: and it presented a problem (the memory leak) |
| 18:14 |
celeron55 |
hmmmm: but nobody increased the setting to fix it |
| 18:14 |
celeron55 |
i don't need more proof for my point 8) |
| 18:14 |
hmmmm |
maybe because nobody knew there was a memory leak going on |
| 18:15 |
hmmmm |
this stops memory leaks from happening by clearing the queue completely if left unhandled for 30s by default |
| 18:15 |
celeron55 |
practically nobody will know in the future either |
| 18:15 |
celeron55 |
it should be just automatic |
| 18:15 |
celeron55 |
and zeno's patch is automatic |
| 18:15 |
hmmmm |
maybe there should be something printed to errostream |
| 18:15 |
celeron55 |
it wouldn't really even need the starting value to be configurable |
| 18:15 |
hmmmm |
"liquid transforming took too long, dropping queue" |
| 18:16 |
celeron55 |
it doesn't log an error? |
| 18:16 |
celeron55 |
it definitely should |
| 18:16 |
hmmmm |
i don't think... let me look |
| 18:16 |
celeron55 |
that if anything is an error |
| 18:16 |
hmmmm |
ahh okay nevermind it does print |
| 18:16 |
hmmmm |
to infostream though |
| 18:16 |
hmmmm |
is this an informational event or an error event? |
| 18:17 |
celeron55 |
about your patch: no thoughts except that i noticed that you removed the large doxygen comments you previously had |
| 18:17 |
celeron55 |
i didn't bother to try to understand the previous one |
| 18:17 |
hmmmm |
well yeah, this new interface is much more intuitive |
| 18:20 |
celeron55 |
how does this even affect the user experience of MT? |
| 18:21 |
celeron55 |
i don't really understand why modifying or adding something like this had to be done in the first place |
| 18:22 |
hmmmm |
the developers are happier and more productive, meaning they enhance user experience in all the other ways they would be working on otherwise |
| 18:23 |
celeron55 |
maybe i will trust you on that |
| 18:23 |
celeron55 |
it's of no use if the latter doesn't happen though! |
| 18:25 |
hmmmm |
the clean, cool, convenient internal interfaces of the core attract other would-be developers to work on minetest even more! |
| 18:29 |
|
roniz joined #minetest-dev |
| 18:41 |
|
kilbith joined #minetest-dev |
| 18:57 |
|
roniz joined #minetest-dev |
| 18:58 |
|
exio4 joined #minetest-dev |
| 18:58 |
|
cg72 joined #minetest-dev |
| 19:00 |
|
Bratmon joined #minetest-dev |
| 19:01 |
|
cg72 left #minetest-dev |
| 19:02 |
|
shadowzone joined #minetest-dev |
| 19:18 |
|
HoloIRCUser4 joined #minetest-dev |
| 19:25 |
|
werwerwer joined #minetest-dev |
| 19:35 |
|
HoloIRCUser5 joined #minetest-dev |
| 19:46 |
|
ImQ009 joined #minetest-dev |
| 20:03 |
|
exio4 joined #minetest-dev |
| 20:13 |
|
Wayward_One joined #minetest-dev |
| 20:14 |
|
FR^2 joined #minetest-dev |
| 20:35 |
|
exio4 joined #minetest-dev |
| 20:52 |
|
Amaz joined #minetest-dev |
| 21:01 |
|
HoloIRCUser4 joined #minetest-dev |
| 21:01 |
|
HoloIRCUser5 joined #minetest-dev |
| 21:02 |
|
HoloIRCUser6 joined #minetest-dev |
| 21:04 |
kahrl |
celeron55: the irc logs are highly useful to me |
| 21:05 |
kahrl |
whenever I want to know what the intention behind some ancient commit was, I just go to the corresponding irc logs for that day/week |
| 21:06 |
kahrl |
(that means almost always the logs for #minetest-dev but occasionally there's useful info in the #minetest logs too) |
| 21:08 |
|
HoloIRCUser4 joined #minetest-dev |
| 21:09 |
|
AnotherBrick joined #minetest-dev |
| 21:09 |
|
HoloIRCUser5 joined #minetest-dev |
| 21:11 |
celeron55 |
kahrl: i know #minetest-dev is very useful; i would never allow any of them to be unpublished |
| 21:11 |
celeron55 |
it's rarer for #minetest logs for me but i guess it's not nonexistent |
| 21:14 |
|
proller joined #minetest-dev |
| 21:16 |
|
electrodude512 joined #minetest-dev |
| 21:31 |
|
Amaz left #minetest-dev |
| 21:47 |
|
exio4 joined #minetest-dev |
| 21:50 |
|
twoelk joined #minetest-dev |
| 21:55 |
twoelk |
iirc there are places in the forum and the two wikis that use the logs as references and link to specific places in them. This alone seems to me to justify to keep as much of the irc logs as possible. |
| 22:01 |
|
kilbith joined #minetest-dev |
| 22:04 |
Megaf_ |
I think they must not be kept due to privacy reasons |
| 22:05 |
Megaf_ |
Everyone talk useless stuff and even some private stuff sometimes, and we don't expect that to be saved for ever |
| 22:05 |
Megaf_ |
people have actual chats on IRC and talk about serious stuff, not only minetest |
| 22:12 |
celeron55 |
everyone knows logs are kept |
| 22:12 |
celeron55 |
talk elsewhere if you want to talk about private things |
| 22:13 |
gravgun |
Tox? |
| 22:13 |
celeron55 |
you can't justify this based on your own ignorance |
| 22:15 |
Megaf_ |
celeron55: Are you ok? |
| 22:15 |
Megaf_ |
celeron55: almost nobody know that logs are kept |
| 22:15 |
Megaf_ |
dont think that everyone is like you |
| 22:16 |
Megaf_ |
most users use Windows and dont even know what IRC is |
| 22:16 |
gravgun |
Megaf_: "almost" nobody? |
| 22:16 |
gravgun |
On #minetest, probably, but less likely on #minetest-dev |
| 22:16 |
Megaf_ |
there are some old school people that might know that, |
| 22:16 |
Megaf_ |
gravgun: I'm talking about #minetest yes |
| 22:16 |
gravgun |
Am I old school for knowing we're logged then? |
| 22:17 |
Megaf_ |
no, you are not |
| 22:17 |
gravgun |
Oh I have an idea |
| 22:18 |
gravgun |
Here, done |
| 22:29 |
|
pro joined #minetest-dev |
| 22:34 |
|
proller joined #minetest-dev |
| 22:44 |
|
exio4_ joined #minetest-dev |
| 22:48 |
|
AndChat|235809 joined #minetest-dev |
| 22:48 |
|
roniz_ joined #minetest-dev |
| 23:11 |
|
Megaf joined #minetest-dev |
| 23:22 |
|
jin_xi joined #minetest-dev |
| 23:25 |
|
CraigyDavi joined #minetest-dev |
| 23:39 |
PilzAdam |
hmmmm, mg_biome.cpp:75:31: warning: comparison between signed and unsigned integer expressions |
| 23:55 |
hmmmm |
welp |
| 23:59 |
Bratmon |
I'm intrigued by the idea of Voxel Area Entities. |
