Time  Nick       Message
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.
01:33 paramat    hmmmm, when you have time please could you review/merge https://github.com/minetest/minetest/pull/1982
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
03:03 paramat    okay
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: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 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: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: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
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: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:35 Zeno`      Seems I've started a trend with these callback mechanisms
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:41 Zeno`      I think these are all good ideas for after 0.4.11
10:41 Zeno`      the code needs a spring clean
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:12 Megaf_     Ok
12:12 Megaf_     I will try that in a couple of minutes
12:16 VanessaE   bbl
12:17 Zeno`      Megaf_, it's updated
12:39 Zeno`      https://github.com/minetest/minetest/commit/7e34621b1de754449a5849f3ddfe8f77f32e64f5?diff=unified <-- does anyone know what this fixed?
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: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: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
15:30 mint       Wayward_One
15:30 mint       !@##$
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 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: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: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:58 Zeno`      I'm not sure if it was a brainstorm heheh
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 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:20 Zeno`      anyway since you suppose it's good enough I'll merge before I sleep unless someone objects in the meantime
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
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 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 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: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!
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: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: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: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
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.