Time  Nick         Message
00:00 kahrl        I think updateViewingRange() would be a better place to put a // BLACK MAGIC comment in than updateSelectedItem()
00:01 Exio         // DARK MAGIC HERE! READ WITH CAUTION
00:01 Exio         ;P
00:02 VanessaE     PilzAdam: what it should be doing is gradually adjusting the value of wanted_rate_change based on how far the actual fps is from the target, with a minimum value, and use some simple hysteresis to prevent oscillations.
00:02 VanessaE     wait, actually it already does that
00:02 kahrl        VanessaE, you mean a PID controller?
00:02 VanessaE     well, it adjusts the wanted change
00:03 VanessaE     kahrl: no, talking about the view_range tuner.
00:03 kahrl        I know
00:03 VanessaE     but the lack of hysteresis is why it oscillates with larger values.
00:04 kahrl        the "D" in "PID" is what is supposed to dampen oscillations
00:04 VanessaE     kahrl: I dunno about temperature controllers, but think schmitt-trigger in transistor logic
00:05 VanessaE     line 561 almost does that actually
00:10 VanessaE     my mind just isn't comprehending code right now (and this isn't particularly complex) or I'd try to come up with some better numbers
00:10 Exio         just random optimizations
00:11 Exio         wouldn't be better to move the settings, mymax and so, to the class as private?
02:39 hmmmmm       am i going crazy, or did liquids stop transforming?
02:39 kaeza        both
02:39 VanessaE     define "transforming"
02:40 VanessaE     as in flowing?
02:40 hmmmmm       yeah, flowing
02:40 VanessaE     pilzadam's hacky liquid fix probably did that
02:40 VanessaE     it defaults to 500 (from 10000 in the original code)
02:40 hmmmmm       hrm??
02:40 kaeza        they flow for a bit and then stand still
02:40 hmmmmm       this is in the core ?
02:40 VanessaE     https://github.com/minetest/minetest/commit/b1ebd9f79c63cf78b0e0fb2ea6f52d82cdfb95b6
02:41 VanessaE     set liquid = 10000 to get the old behavior.
02:41 hmmmmm       don't really see why he'd set it so low
02:41 hmmmmm       this is breaking shit
02:41 VanessaE     the problem is the queue gets full, but doesn't just throw away events in favor of new events
02:41 VanessaE     they just keep queueing up
02:41 hmmmmm       right
02:42 VanessaE     I hit 500k events in the queue at one point, with the value set to 500, but my server didn't break as it would have with the default code.
02:42 hmmmmm       i am surprised pilzadam would commit something like this...
02:42 VanessaE     I asked him to so it wouldn't get lost/stale.  it keeps servers from barfing when users abuse liquids to create gigantic fountains
02:43 hmmmmm       either way, both 'safety mechanisms' are broken as shit
02:43 VanessaE     so it would seem
02:44 VanessaE     I advocated that liquid flowing events be added to the queue in a completely random order, and have the queue get thrown away when the event list is too long, he said that would be pointless
02:47 Exio         and kahrl said it will fuck up stuff that needs the order of the queue
02:47 Exio         :D
02:47 VanessaE     true, forgot about that.
02:47 VanessaE     the way I figure it, you're only able to process X events per second on the output side of the queue (depending on your CPU I guess).  If you're adding Y events per second to the input side and Y > X, the queue either has to stack up indefinitely, or part of it has to be thrown away to make room for less-stale events.
02:49 hmmmmm       so what's the order of the queue?
02:49 VanessaE     beats me
02:50 VanessaE     but I presume some block-serial order based on what's active in the mass of loaded blocks
02:50 VanessaE     it has something to do with how recently the liquid was placed also
02:50 VanessaE     older placed liquids flow more readily than newer ones.
02:50 hmmmmm       of course, but what would depend on that order?
02:51 VanessaE     other than downward flow of a given liquid, I can't think of anything
02:51 VanessaE     (and I'm sure that could be easily worked around)
02:52 hmmmmm       why should a flowing liquid add things to the transforming liquid queue if it has already spread to its maximum extent?
02:53 VanessaE     well in a horizontal spread of course you're right
02:53 VanessaE     but vertical spread is where the trouble starts I guess
02:53 hmmmmm       and why is that?
02:53 VanessaE     damned if I know :)
02:55 hmmmmm       mm i'll check it out later
02:56 VanessaE     hmmmmm: the test case we used was pretty simple.  Set liquid=10000.  teleport to say 0,400,0. Set a single cobble node up there.  Now build some random scaffold say 10x10 nodes in dimensions, sparsely populated.  pour water and lava.  go on pricewatch and buy a new CPU cooler.
02:56 VanessaE     :)
02:57 hmmmmm       and minecraft cuts off after 40 or so nodes iirc
02:57 VanessaE     kinda hard not to since MC only has a 128-node-tall map, yes?
02:57 VanessaE     the problem is twofold though:
02:57 hmmmmm       i still don't see why we shouldn't cut off vertically
02:58 VanessaE     1 of course is the infinite distance a water node can spread
02:58 VanessaE     2 is the existence of any kind of lavacooling mod including that which is in default.
02:58 VanessaE     as lava hardens, it creates new surfaces for the liquids to spread onto
02:58 VanessaE     s/a water node/a liquid source node/
02:59 Exio         VanessaE: i'm pretty sure the problem was the liquid + the get_node(s) in the "abm"
02:59 kahrl        hmmmmm: I don't know much about the order of the queue, but in removeNodeAndUpdate there is a comment that suggests it is important.
02:59 VanessaE     Exio: I'm sure the abm adds its own load, but I don't think it's as bad as pilz was making it seem
03:00 kahrl        map.cpp:1280
03:00 Exio         (plus it can lead to "sometimes it doesn't apply so continue running it after that")
03:02 VanessaE     Exio: as soon as someone adds a "only_neighboring_faces" field to the ABM definition, I'll remove my extra get_node() checks.
03:02 VanessaE     (and someone adds a way to turn that damn lavacooling ABM off altogether so I can supply my OWN code....)
03:04 Exio         who used a goto in the abm handler? i need to highfive him
03:04 VanessaE     (and if those get_node() checks are as slow as you're implying, the functions they call need to be rewritten.  Such things should be virtually instantaneous on anything less than ~15 years old)
03:05 hmmmmm       wtf
03:05 hmmmmm       here i think there's a bug with my code
03:05 VanessaE     ?
03:05 Exio         what code?
03:05 VanessaE     what bug?
03:05 hmmmmm       how do i subtract v3s16(20,20,20) from a v3s16 table in lua?
03:05 hmmmmm       am i going crazy?
03:05 hmmmmm       this is totally simple
03:06 VanessaE     I don't think there are any such table operations
03:06 Exio         what is a v3s16 in lua
03:06 Exio         a table with .X .Y and .Z?
03:06 hmmmmm       i am doing this
03:06 VanessaE     you'd have to do it manually I guess
03:06 hmmmmm       local p1 = pointer.above
03:06 hmmmmm       p1.x = p1.x - 20
03:06 hmmmmm       so on for the other coordinates
03:06 VanessaE     pointer.above?   did you mean pointed_thing.above  ?
03:06 hmmmmm       no, it's pointer in this code
03:06 VanessaE     ok
03:07 hmmmmm       pointer.above is a v3s16
03:07 VanessaE     what you're doing SHOULD work though,
03:07 hmmmmm       er, holds x y and z rather
03:07 VanessaE     at least from Lua's standpoint
03:07 kaeza        hmmmmm, have in mind that p1 = pointed_thing.above does not copy the table
03:07 VanessaE     that's true, it's all pass-by-reference
03:07 VanessaE     (which has bitten me more times than I can count)
03:07 hmmmmm       aaaaaaaaaaaaaa
03:07 Exio         hahaha
03:07 hmmmmm       oh boy
03:08 VanessaE     hmmmmm <head explode>
03:08 hmmmmm       i really hate lua
03:08 hmmmmm       here i'm trying to treat it like an opaque type
03:08 kaeza        you'd prolly want local p = { x=above.x, ... }
03:09 VanessaE     hmmmmm, what are you trying to do, ultimately?
03:09 Exio         he is writing the lua mapgen, i guess
03:09 hmmmmm       just test out this dumb thing
03:10 hmmmmm       thanks kaez
03:10 hmmmmm       a
03:10 VanessaE     ahhh
03:10 hmmmmm       wow, i can't believe how retarded this is
03:10 kaeza        hmmmmm, np
03:10 kaeza        as VanessaE said, it can lead to weird bugs in code
03:10 VanessaE     hmmmmm: still think "every little thing" doesn't belong in the engine now? :)
03:11 VanessaE     (that was a joke.  it's funny.  laugh.)
03:14 hmmmmm       well at least my code worked
03:16 hmmmmm       so erm, just wondering anyway, does lua have += and -= operators?
03:16 kaeza        nope :<
03:16 hmmmmm       it's really annoying having to repeat myself in the code
03:16 kaeza        and don't even try to suggest the idea in #lua
03:17 kaeza        -> permaban
03:17 VanessaE     wait, I though it did have those?
03:17 kaeza        not in stock Lua at least
03:17 VanessaE     huh.  I guess not.
03:18 kahrl        http://forum.minetest.net/viewtopic.php?id=4952
03:19 kahrl        oh wait, you mean for scalars?
03:19 hmmmmm       that's a cute class, i guess, but it's not very helpful as there's no language integration and it adds a dependency
03:20 VanessaE     kaeza: one I wish it did have was !=  (because ~= is harder to spot and makes less sense)
03:20 kaeza        +1 to that
03:20 hmmmmm       someone ought to make a scripting language with C++ syntax and static typing, and not perl
03:21 kaeza        AngelScript
03:21 VanessaE     bash :P
03:21 hmmmmm       bash script for gamedev
03:21 VanessaE     (well maybe not, but the syntax is at least close to C)
03:21 hmmmmm       top lel m80
03:21 kaeza        http://www.angelcode.com/angelscript/
03:22 hmmmmm       wonder how fast it is in comparison to lua
03:23 kaeza        could be useful to overcomplicate stuff and make a neutral API to which you could plug other scripting languages
03:23 hmmmmm       and what's the difference between foo:bar and foo.bar in lua exactly?  foo:bar is for methods, foo.bar is for members, but if you can call methods with . over :, what's the point ..?
03:23 kaeza        ehh no
03:24 VanessaE     hmmmmm: I use : versus . was more of a reminder
03:24 VanessaE     s/was/as/
03:24 kaeza        foo:bar() is syntactic sugar for foo.bar(foo)
03:24 hmmmmm       ahhh.
03:24 VanessaE     I prefer to call functions et.al using foo:bar() because it reads cleaner to my mind
03:24 hmmmmm       so foo:bar is really a method call and foo.bar is just bar using the namespace foo
03:24 hmmmmm       thank you, that makes a lot of sense.
03:24 VanessaE     and foo.bar for reading/writing individual table elements
03:25 kaeza        (in addition, 'foo' is somewhat optimized by the interpreter)
03:25 kaeza        (in the case of foo:bar() )
03:38 hmmmmm       kaeza, according to the section starting "Now, when we call the method..." http://www.lua.org/pil/16.html it does a1 = Account; Account = nil, then uses a1 right after.  this doesn't happen if you use self. instead of the global object name, however - why?  when does Lua decide to do a deep copy of tables?
03:38 hmmmmm       this seems ridiculously arbitrary to me
03:39 kaeza        ehm
03:39 VanessaE     hmmmmm: afaik it never does
03:40 kaeza        they are just references
03:40 hmmmmm       then why is a1 = Account; Account = nil, a1:foobar() allowed?
03:40 kaeza        local a = { foo="bar" }; b = a; a = nil; print(dump(b)) -> { foo="bar" }
03:40 kaeza        yes
03:41 kaeza        there is a table referenced by variable 'Account'
03:41 kaeza        the reference count is incremented when asigned to a1
03:41 kaeza        and decremented when Accont is set to nil
03:41 hmmmmm       i see
03:42 kaeza        you still have a reference in a1
03:42 hmmmmm       how do i make a completely new object?
03:42 kaeza        you have to copy it manually
03:42 hmmmmm       figured
03:42 kaeza        give me a second
03:42 hmmmmm       i know
03:42 hmmmmm       foreach pairs(k,v) in Account do blahblah
03:43 kaeza        yep
03:43 kaeza        ehh no
03:43 hmmmmm       would've figured there's a convenience function for that in lua
03:43 VanessaE     somewhere in the PiL there is a proper deep copy routine
03:43 kaeza        for k,v in pairs(t) do newt[k] = v end
03:43 hmmmmm       kaeza, yeah.
03:43 hmmmmm       hmm
03:44 kaeza        actually, hmm
03:44 hmmmmm       I hate lua so much
03:44 hmmmmm       why am i doing this
03:44 hmmmmm       why don't i just give it to somebody else to do this part
03:44 kaeza        to create a new table from scratch, you use foo = {}
03:44 hmmmmm       yes
03:44 hmmmmm       hahahahahaha
03:44 hmmmmm       wouldn't it be funny if foo = {} added a reference to the table {}?
03:44 VanessaE     hmmmmm: because if it's Lua, the only other person who's gonna touch it is pilz and he....has his own ways of doing stuff
03:44 hmmmmm       true.
03:46 hmmmmm       setmetatable(a, {__index = b})
03:47 hmmmmm       alright, now things are getting less crap
03:47 kaeza        heh
03:48 kaeza        thought you didn't like operator stuff from C++ cause it tended to hide side-effects
03:49 hmmmmm       vector +, - and = are probably the only exceptions, merely because you know exactly what to expect from them
03:49 hmmmmm       it's the wackier things that people do, and overloading = is especially bad.  some people like overloading = though
03:50 hmmmmm       i mean == for the former
03:50 kaeza        well, I'm used to Lua, so I'd expect a = b to pass a reference (or a pointer in plain C) rather than copying
03:51 kaeza        but I agree to the vector stuff
03:55 Rath         why does the for loop on line 409 in nodedef.cpp use 0xffff intead of MAX_CONTENT ?
03:57 hmmmmm       because celeron added an extra f
03:58 hmmmmm       not that it matters, since there's the assert (c <= MAX_CONTENT) in INodeDefManager::set()
03:59 hmmmmm       oh, nevermind, that's a bug.
04:00 kaeza        suddenly: no more bugs in MT
04:01 Exio         someone told me a bit ago "every time i find a bug, i look around because there are 10 more"
04:06 VanessaE     oh not this subject again.
04:53 hmmmmm       i guess at this point i could commit what i have
04:53 hmmmmm       nah
04:53 VanessaE     I'm almost afraid to look :P
04:54 hmmmmm       i think i'm going to make a series of commits but push them at the same time.  that way it can stay neat and in order, but people won't jump on it all at once
04:55 VanessaE     translation:  "I think I'll make some attempt to hide my nasty code under a bunch of other changes" ;)
04:55 hmmmmm       so right now i just need to pass one of these objects to on_generate() and make my perlin noise maps flag
04:55 hmmmmm       s/flag/flat/
04:56 hmmmmm       not sure what i was thinking when i made them actually 2d and 3d tables...
04:56 hmmmmm       in fact i don't think anybody ever used them in mods
04:56 hmmmmm       and then i'll make the demonstration mapgen
06:28 hmmmmm       aaaaaaha!
06:28 hmmmmm       i got your bug kahrl
06:29 hmmmmm       it has absolutely nothing to do with the block being loaded or unloaded or whatever
06:29 hmmmmm       now if only i can figure out how to reproduce this
06:32 hmmmmm       it happens after a period of high latency
06:33 hmmmmm       i have the lock, no idea why that would happen...
06:42 hmmmmm       also very occasionally, pitch black shadows form over the block where it failed to spawn
06:42 hmmmmm       sounds familiar? *cough* tree lighting bug
07:01 hmmmmm       alright; for some reason the data doesn't exist when this happens.  i would say that it's a air that wasn't loaded and we can't see it, but that's just not possible because i'd see a lower layer of nodes at least
07:02 hmmmmm       both Map::getBlockNoCreateNoEx() returns NULL and VMANIP_BLOCK_DATA_INEXIST on the blocks in question when this happens; yet the blocks are clearly there
07:05 hmmmmm       so it's either a dummy block or not present in the sector
07:10 hmmmmm       the only explanation is that the server removed that block from memory while the client still has it
07:56 celeron55    hmmmmm: that totally can happen, there's nothing to guard against such
07:58 celeron55    this once again means that minetest would need something to allow synchronous loading of blocks for special cases
14:41 hmmmm        right
14:41 hmmmm        minetest has synchronous loading of blocks, just not generation
14:42 hmmmm        i changed this a long time ago, if it can't find the block on disk, it'll create one full of content ignore
14:43 hmmmm        this way you have a block to work with where you can place your nodes and they'll still be there after map generation
14:44 hmmmm        so the solution i figure, is to extent vmanip's initialEmerge and emerge to load blocks or create a blank instead of marking it as inexistent
14:45 hmmmm        this would fix every instance of this problem.... saplings growing into trees, the place_schematic problem, and my current problem
14:45 PilzAdam     hmmmm, I had a new idea about the snow: the nodebox could be extended to add so that there is a layer that covers the node under it (like this: https://gist.github.com/PilzAdam/5859007; https://www.dropbox.com/s/xag8v7q0st4yz2b/Snow.png)
14:45 PilzAdam     -to add
14:46 PilzAdam     the problem with this is that there are rendering glitches if the d < 0.55; but everything > 0.51 doesnt look good
14:46 hmmmm        it looks nice enough i suppose, but that's still a hack
14:47 PilzAdam     a not hacky way would be to change the texture of the node under it at runtime
14:47 hmmmm        also doesn't overuse of nodeboxes decrease performance
14:48 PilzAdam     but since we cant do this currently thats the best way so far
14:48 PilzAdam     this only has 5 nodeboxes per node; pipeworks for example has 90 or so per node
14:49 PilzAdam     and the snow could be changed to only use 1 nodebox
14:53 PilzAdam     the rendering glitches appear at a distance of > 10 nodes
14:59 celeron55    that rendering glitch could probably be largely solved by implementing a properly dynamic near depth value
15:00 celeron55    try if increasing the value given to cam->setNearValue() in camera.cpp helps it
15:01 celeron55    (i'd maybe prefer modifying the textures of the nodes under snow at mesh generation time, if it's reasonably doable)
15:32 hmmmm        oooh heh
15:32 hmmmm        seems like the completely black shadow bug isn't caused by this
15:33 hmmmm        too bad i can't readily reproduce such a thing, i assume it'll work if i set it to load on inexistent block in updateLighting as well
15:33 hmmmm        on the other hand, blitting the data itself is reliable
15:42 hmmmm        http://oi44.tinypic.com/2mmvmub.jpg
15:44 Jordach      is THAT MGV7
15:44 hmmmm        yeah, but that's not the point of the picture... :p
15:45 Jordach      looks awesome
15:45 Jordach      so these bubbles are to prove what?
15:46 hmmmm        i fixed the missing block/pitch black lighting issue for trees growing into saplings and decoration placement
15:47 Jordach      \o/ OMFG
15:47 Jordach      finally
15:50 sfan5        Jordach: ?
15:50 Jordach      <hmmmm> i fixed the missing block/pitch black lighting issue for trees growing
15:51 sfan5        oh ok
15:58 sapier1      is anyone investigating the punch fps problem vanessae found?
16:04 hmmmm        nope
16:04 hmmmm        i told her it'd be helpful if she found the exact commit where the regression started.... that'd be helpful
16:04 hmmmm        https://github.com/kwolekr/minetest/commit/98c7c7aedf0df0bf34a2dffe7636266ee1f81648
16:05 hmmmm        https://github.com/kwolekr/minetest/commit/fcc453ccd8be469a1f09e6e17c763f9a179a71ad
16:07 sapier1      are you sure "manip" is correct term for this interface?
16:07 hmmmm        yup, why not?
16:07 hmmmm        is it a german curse word or something?
16:07 Jordach      hmmmm, i'll take a look for her
16:07 sapier1      I'd expect a manip to modify something but this looks more like chunk save restore
16:08 hmmmm        well, i didn't come up with "manipulator", i just came up with the shortened version that sounds better
16:08 Jordach      hmmmm, 0.4.1 i remember had them
16:09 hmmmm        Jordach, to find the specific commit, figure the points at which you're absolutely sure the bug wasn't there, and you're absolutely sure the bug was there
16:09 sapier1      I guess there's exactly one mod benefiting from this
16:10 hmmmm        then take the middle of those two commits, see if it's present there
16:10 hmmmm        if not, check the middle between that commit and the last one
16:10 hmmmm        so on and so forth
16:10 hmmmm        sapier, any mod that writes to the map a lot
16:11 sapier1      how to create data that can be written?
16:11 hmmmm        you read the chunk, make the modifications, then write it back
16:11 hmmmm        the data that's being written is just a huge, flat table of content ids
16:11 sapier1      yes but how to modify it? maybe I just missed that?
16:12 hmmmm        local c_cobble minetest.get_content_id("default:cobble"); data[a.index(x, y, z)] = c_cobble;
16:13 hmmmm        also i ported VoxelArea to Lua
16:13 sapier1      ok missed that I'll take back what I said it's really a manip
16:14 sapier1      would be good to hava a small example in doc
16:14 hmmmm        we don't have examples in the documentation
16:14 sapier1      any chance to avoid bothering user with the ids?
16:14 hmmmm        i plan on having a demonstration mod for this reason
16:15 hmmmm        and yeah, i was thinking of maybe putting in an "easy mode" that's a bit slower but you only need to specify the node name
16:16 Jordach      hmmmm, https://github.com/minetest/minetest_game/commit/dd9b33db6743812f33bcfe97910d9a110fb0b4f9 and https://github.com/minetest/minetest/commit/506203345ba2795aa0af68a434f4b77cf50e664a
16:16 Jordach      THOSE are the two commits VanessaE was talking about
16:16 hmmmm        wow
16:16 Jordach      one for when the chests got moveed
16:16 sapier1      yes I guess if youz cache id/name mapping within lua it's not that much slower
16:16 Jordach      and when the formspec got added
16:17 Jordach      have a poke about for it
16:17 hmmmm        sapier, i'm thinking more or less the extraneous cpu time being spent on meaningless string copy and manipulation
16:18 hmmmm        hmm, jordach, maybe that's what vanessa was talking about, but i honestly don't see anything there that would cause such a bug
16:18 Jordach      hmmmm, I think parsing of the chest / furnaces take their time
16:18 sapier1      we are talking about the la bug?
16:18 hmmmm        did you actually try out minetest at this specific commit and verify that the problem is present, and the commit before that and saw that it wasn't there?
16:18 Jordach      sapier1, yes
16:18 Jordach      hmmmm, i don't have 0.4.1 and 0.4.2
16:19 hmmmm        ...compile
16:19 sapier1      can_dig?
16:19 Jordach      hmmmm, its just easier as i dont have debugging tools
16:19 hmmmm        easier for you maybe
16:19 Jordach      hmmmm, we also have git tags
16:20 hmmmm        none of this is really helpful as i need to see actual code that would have caused this effect
16:20 hmmmm        i can't pull a solution out of thin air
16:20 Jordach      VanessaE stated that it happened when the nodemeta came about
16:21 Exio         if you don't try that commit and the one *before* it, you are just guessing
16:21 Jordach      i might think that nodemeta might be screwing with node prediction a tad
16:21 Exio         what can mean, that is not true == wasted time
16:21 Jordach      Exio, process of elimination
16:27 sapier1      hmm did anyone already check if mouse beeing hold down causes cyclic events?
16:28 sapier1      if it does we're most likely running line 1135 everytime
16:28 celeron55    stop asking and start testing, goddamnit
16:28 celeron55    and no it doesn't, as far as i tested it
16:28 celeron55    i don't have latest git on this laptop though and won't bother building it because it's so slow
16:28 sapier1      celeron55 it's not worth testing something that already has been ruled out
16:29 celeron55    is there a github issue for this?
16:29 celeron55    1) if there isn't, there should be, 2) if there is, everything should be also written in there
16:29 celeron55    also those who the problem affects are responsible for filling it out
16:30 sapier1      at least no one referenced one the last days but yes you're right
16:30 celeron55    (if they aren't going to fix it, then they should at least help as much as they can)
16:32 sapier1      no there isn't a issue on github
16:33 Jordach      actually, I've just spotted something
16:33 Jordach      you know the node animations, they take up quite a few resources
16:34 sapier1      the crack updates?
16:34 Jordach      yes
16:34 Jordach      because at the end of it, it removes the node + anim
16:34 sapier1      where's the code?
16:36 Jordach      sapier1, its also strange that any server with rtt = < 0.1xx
16:36 Jordach      any dug nodes re-appear then disappear
16:37 Jordach      but some stay as if you never touched it
16:37 sapier1      that's a behaviour that happened quite often when mobf did use abms to spawn mobs
16:38 sapier1      i guess it's related to "long" steplengths on server
16:44 hmmmm        am i going mad, or is there a huge memory leak since finishBlockMake doesn't delete the voxel manipulator
16:45 Exio         try a free()
16:45 Exio         if minetest crashes, no!
16:45 Exio         i think doing that will be faster than trying with valgrind
16:47 hmmmm        the reason why i ask is because minetest was run under valgrind just recently by like three different people, and it would've been caught
16:48 sapier1      if none of them created a voxel manip valgrind can't show an error ;-)
16:48 hmmmm        they ran minetest, yes?
16:48 hmmmm        they emerged map
16:48 sapier1      oh you're not talking about the thing in api
16:50 hmmmm        ah
16:50 hmmmm        the only way it gets cleaned up is by falling out of scope
16:50 hmmmm        that's really.. hidden... if you ask me
16:51 PilzAdam     celeron55, cam->setNearValue() doesnt really help
16:51 sapier1      falling out of scope is perfectly ok if an object has a valid destructore
16:52 hmmmm        sapier, you're all about super-defensive coding, how do you possibly like using C++ for mission critical embedded things?
16:52 celeron55    PilzAdam: eg. 1.0 makes no practical difference?
16:52 PilzAdam     nope
16:52 celeron55    well no luck then :P
16:53 sapier1      if you stick to avoid some language elements c++ isn't that bad ;-) and con/destructors are very very safe things if done right
16:53 celeron55    hmmmm: any object in C++ should be coded so that falling out of scope cleans it up properly
16:54 celeron55    anything else is bullshit
16:54 hmmmm        explicitly deleting things is bullshit?
16:55 celeron55    if you dynamically allocate something, then you delete it (usually in the same function or destructor of some owner object)
16:55 sapier1      hmmm you can't delete a stack object "explicitly"
16:56 hmmmm        BlockMakeData looks like really simple struct and has the potential to fool someone who isn't thinking in C++ mode
16:57 hmmmm        +a
17:00 celeron55    i don't think it's worth it to take in use any conventions to mark whether structs manage their memory themselves or not
17:01 PilzAdam     celeron55, oh, wait, I was modifying the value of the camera for the wielditem
17:01 PilzAdam     setting it to 4.0 for the other camera removes the glitches completly
17:02 PilzAdam     (it was the default value (1.0) previosly)
17:02 celeron55    that'll make you able to easily look through walls by walking near them though 8)
17:02 hmmmm        hmmmm
17:02 hmmmm        celeron, is there a reason why you added minetest.get_perlin()?
17:02 celeron55    it's need some code to scale it based on how close is the nearest thing to the camera (that's what all 3D things should do, but many are lazy)
17:03 celeron55    it'd*
17:03 PilzAdam     3.0 works too, and you cant look through walls with that
17:03 celeron55    hmmmm: is there a reason why you think it shouldn't exist?
17:04 celeron55    PilzAdam: jumping towards ceiling will still work
17:04 hmmmm        i think it should've been implemented in lua
17:04 PilzAdam     celeron55, it also works with 1.0 (wich we have currently)
17:04 celeron55    hmmmm: can't remember
17:05 PilzAdam     0 is a nice wallhack ;-)
17:05 hmmmm        meh
17:05 hmmmm        i'll make a wrapper for VoxelManip:read_chunk()
17:05 celeron55    hmmmm: could have been something like wanting to make it behave exactly like what C++ gets with the same seed difference
17:05 hmmmm        it'll create a VoxelArea and add it in there and all sorts of other convenient things
17:05 celeron55    if done in lua, variables can wrap differently
17:05 hmmmm        that makes sense i guess
17:11 Taoki        hmmmm: Thanks for the script last night. Managed to yry v7 and it's looking pretty good. Although I can see where it needs more work, but I'm glad I got to test it :)
17:11 hmmmm        yep, and i'm not working on it at the moment
17:11 hmmmm        i have other things
17:11 Taoki        Only curiosity is if I can enable spawning of trees yet. Or if that's not implemented currently
17:12 Taoki        ok
17:12 hmmmm        oh, i didn't give you the tree schematic
17:12 Taoki        Ah, there's a separate one for that? Sure, I'd like that too then
17:13 Taoki        If I can get trees working I think I can leave it enabled on my server, since it's good enough apart from some noise / design issues
17:13 Taoki        eg: Floating cave tops and lots of air holes in water. Other than that it feels complete to me otherwise
17:14 hmmmm        http://www.filedropper.com/treewprob
17:15 Taoki        .mts? What folder do these go in?
17:15 hmmmm        ever since omploader vanished, i've been in the market for a new file upload site...
17:15 hmmmm        the way i have it set up, the current working directory
17:16 Taoki        So the root GIT folder?
17:16 hmmmm        the minetest folder that is one level up from the location of the executable
17:18 Taoki        Placed it there but nothing happens. I assume a Lua function is needed to point at the file
17:19 hmmmm        i had it included with the biomes
17:20 Taoki        Ah, I see it there now. It has no path, so it means it's trying to run it from the same folder as the binary most likely. Will fix
17:20 Taoki        Thanks
17:22 Taoki        Works now. But why is it a binary file? How are mts schematics generated?
17:22 Taoki        Might be useful to know
17:22 hmmmm        you can create them using minetest.create_schematic()
17:23 Taoki        oh,,, good to know
17:23 hmmmm        there's a worldedit command for this, //mtschemcreate
17:23 sokomine     those schematics can also be used by the speedy-gonzales branch of worldedit. that works fine already (at least when the area is loaded). uberi introduced it yesterday
17:24 sokomine     ah, hmmm was faster
17:25 sokomine     there is, however, a problem with them: if a furnace is included (perhaps only an active one?), the game will crash after //mtschemeplace because the metadata is empty
17:26 sokomine     changing line 982 in minetest_game/mods/default to "if not( fuel) or fuel.time <= 0 then" solves the problem
17:27 Exio         i think a pull request for that could be pretty nice?
17:27 Taoki        Hopefully that will be fixed in GIT
17:27 sokomine     hm. a pull request for such a small change? wouldn't that be considered spam?
17:31 PilzAdam     sokomine, that fixes the crash but makes the furnace not usable
17:32 PilzAdam     hmmmm, any chance to call on_construct of nodes that are placed by place_schematic()?
17:32 hmmmm        PilzAdam, no.
17:33 PilzAdam     then you break every node that uses metadata
17:33 hmmmm        :/
17:33 hmmmm        i was hoping that a mod knows about nodes that have metadata
17:36 PilzAdam     all nodes that have an inventory set the size of the lists in on_construct()
17:41 hmmmm        it seems to me that everybody believes that new lua api are new features of minetest
17:41 hmmmm        all an api does is exposes something from the engine
17:42 hmmmm        or speeds up something that would've otherwise been restrictively slow
17:42 hmmmm        so, no, new api won't be complete and handle every corner case like node metadata, it's just a thin wrapper
17:43 hmmmm        and i explicitly refuse to deal with metadata in schematics for a couple reasons
17:44 hmmmm        the biggest being the intent.  you're using schematics for transferring data between worlds, but it's intended to be a way to create a schematic file, for use in the schematic decoration type
17:44 hmmmm        it was never intended to be used in the manner you're using it
17:46 PilzAdam     I dont want you to save metadata in the file
17:46 sokomine     the copying between worlds was just a testcase. and, in a way, the schematics we'll use for decoration will have to be built somewhere - in the world of the mod developer - and will be used by those who use the schematic in their worlds, so transfer to other worlds is the expected usage
17:46 hmmmm        if you can use it in the manner you'd like to, that's a convenient plus, but i am under absolutely no obligation to handle your problem that occurs when it doesn't work the way you want it to work
17:46 sokomine     not handling metadata is understandable
17:47 sokomine     no, you are under no obligation at all. you're all doing this for free, for the benefit of others. but that's the problem with users: they may like something you did :-) and request more
17:48 hmmmm        glad you like it :-)! i'm not making more
17:48 PilzAdam     hmmmm, the problem is that lua-api.txt gives a guarantee that on_construct() is called when the node is placed in the worl (except mapgen)
17:48 PilzAdam     +d
17:48 sokomine     no chance for that rotation-feature? *looking hopefully* or that node-replacement-feature?
17:49 hmmmm        should change "except mapgen" to "bulk writes"
17:49 ShadowNinja  sokomine: Very puesdo-codey for (x, y, z) get_node(pos) node.on_construct(pos) end
17:49 hmmmm        that was an easy promise to keep when you only had heavyweight api like set_node() that does everything
17:49 hmmmm        sokomine, rotation is planned
17:49 PilzAdam     ShadowNinja, WE could do that
17:49 hmmmm        it's only going to be along the vertical axis however
17:50 sapier1      hmmmm which of the at least 2 entity rotation variants? I hope both
17:50 celeron55    on_construct should always be called; there are no excuses for that
17:50 sokomine     that sounds good! rotation will be very helpful for all kind of rotation
17:50 hmmmm        ...seriously?
17:50 hmmmm        celeron, i can come up with three undeniable excuses right now off the top of my head
17:51 celeron55    it is explicitly in there exactly to allow nodes to have code that is always run, compared to on_place or such
17:51 sokomine     no entity rotation. node rotation for the new schematic-functions
17:51 celeron55    because some nodes just can't work otherwise
17:51 celeron55    by design
17:51 hmmmm        and those nodes that have code should be specially handled
17:52 hmmmm        any modder worth his weight should be able to find their special nodes, add the position to a list, and then call on_construct manually
17:52 celeron55    IF a way is provided to handle them, then there is an excuse; but for example there is no way furnace code could currently make itself work after being created without on_construct and without horrible hacks, AFAIK
17:52 hmmmm        i'd be interested in somebody making a Lua hook or something to preserve metadata
17:53 hmmmm        all i did was expose part of the core to the Lua scripts via an API
17:53 celeron55    there's no reason to not make it complete
17:53 sapier1      rotation meaning e.g.45 degree rotated nodes or only 90 degree steps?
17:53 hmmmm        i am frankly not very interested in making it "easy to use"
17:53 sokomine     ask uberi. iirc worldedit had an extra function for it. until it switched to a mixed format where node- and metadata was in one table-like file
17:53 hmmmm        sapier, 90 degree steps only
17:54 sapier1      ok good idea :-)
17:54 celeron55    IS there a way a furnace can start operating when missing metadata?
17:54 hmmmm        i'd have to say that's a furnace bug
17:54 celeron55    like, where does it get the first "tick"
17:54 hmmmm        why isn't it more robust?
17:54 celeron55    is it *ABLE* to get it anywhere
17:54 PilzAdam     celeron55, it needs to detect the missing meta in the ABM and then init it there
17:54 sapier1      what about extending on_place signature to parameter node/tableofnodes?
17:55 celeron55    PilzAdam: okay, so that is handled for nodes that have ABM; now the question is, how about those that *don't* have ABM?
17:55 celeron55    i.e. chests
17:55 PilzAdam     no non hack way
17:55 celeron55    that should be fixed in some way
17:56 PilzAdam     a hack would be: catch on_rightclick() and set it there (on_rightclick() is only called if the formspec field is not set)
17:56 sapier1      I suggest doing a single on_construct (per nodetype) passing a list of nodes of that type
17:56 PilzAdam     but it would mean the player has to rightclick it two times and wait for the server
17:56 sapier1      ähh on_place of course
17:57 sokomine     the furnace is really only of intrest when it's supposed to do anything. most likely it will have a player nearby who's eagerly awaiting the result and will change the input of the furnace if needed
17:57 hmmmm        sapier, seems like a great idea for *lua* to do that and not the api
17:57 celeron55    PilzAdam: is that acceptable?
17:58 hmmmm        these minor 'bookkeeping' type tasks are for lua, not the api
17:58 sapier1      hmmmm my intention was to avoid doing maybe hundreds of single node lua calls from c++
17:58 sokomine     chests also loose their functionality. that's not a big problem because that really is something the mod that uses the api function has to plug in - i.e. to fill the chests randomly, to assign them to someone etc (mostly this will be handled by a seperate chest node in my mod - i'm using a dummy for that anyway)
17:58 PilzAdam     celeron55, the problem is that every single mod will have to add these hacks too
17:58 hmmmm        sapier, right, we'd like to avoid doing that in C++ and that's one of the reasons
17:58 hmmmm        no overhead if you call it straight from lua
17:59 celeron55    okay so, i assume we'll go hmmmm's way then
17:59 celeron55    it means that the main public api must be a lua wrapper that provides reasonable means to automate on_constructs
17:59 hmmmm        nevermind that, the furnace should be fixed as well
17:59 sapier1      hmmmm if we do already have all information in lua yes that'd be best
18:00 hmmmm        i would recommend going through the whole space with get_node() and doing something special if it's one of those nodes you're interested in
18:00 hmmmm        it's going to be dog slow anyway, so what's the difference?
18:00 sapier1      alll get_node calls? are you crazy?
18:00 hmmmm        fppppt
18:01 sapier1      I don't even know how often I do get_node in mobf
18:01 sapier1      :-)
18:01 hmmmm        or luavoxelmanip
18:01 celeron55    my main point is that if on_construct isn't called by default, the API is broken from the mod's standpoint because everytime previously the mod has been able to rely on that having been taken care of
18:01 hmmmm        like i said before
18:01 hmmmm        that was an easy promise to make back then when you only had heavyweight set_node calls
18:02 sokomine     is the new api function useful for mobf? the schematic only seems to be saved to a file. of course it would be very useful for spawning the trader homes
18:02 celeron55    if the thing exposed by C++ can be wrapped in lua and presented as the preferred non-broken API and the "raw" C++ API given as something to get huge speeds with if the problems are understood, then it's ok to me
18:02 sapier1      year forget about my comment I missread something :-)
18:02 hmmmm        append _raw?
18:02 celeron55    something like that
18:03 Taoki        hmmmm: Oh... before I forget, regarding v7: I noticed that each biome has an option called terrain_type, which currently has values like "liquid" or "normal". When you'll be working on the mapgen again, can you please please make nether and floatlands part of that setting? Would help with that realms idea I mentioned some days ago
18:03 sokomine     perhaps you just ought to write it into the documentation of the api
18:03 Taoki        If you're going to do those either way (aether and nether), it would sound perfect to make them part of terrain_type
18:03 hmmmm        i'd rather we add a note in the documentation that says "this is a RAW api, here are the problems with it, use this wrapper instead if you can't handle it"
18:03 Taoki        Then by default one can define any min_height and max_height they want, and everyine is happy and has the realms they wish
18:04 hmmmm        taoki, if you saw that piece of code then you know what the answer is
18:04 hmmmm        no point in asking
18:04 Taoki        I only saw the function's use in the script. I'll go ahead and check it in the code actually
18:04 * Taoki      hopes that is good news :)
18:05 sapier1      main question how big is the risk we gain huge speed in a rare case but add significat slowdown in common case?
18:05 hmmmm        oh..
18:05 hmmmm        hold on a minute
18:05 sokomine     hmmm: yes, that's what i wanted to say. if a working wrapper is supplied - fine. but what we need is the speed gain through the new functions
18:05 hmmmm        i forgot to take that field out
18:06 hmmmm        yes, and the option is there to use the raw version if the modder wants to, so you have a choice between slow but very complete, and fast but doesn't get 100% of the work done
18:06 hmmmm        better than "here, slow as shit but it's REALLY easy to use!" and that's your only option
18:06 celeron55    it is an important question that how wast the complete one is though
18:06 celeron55    fast*
18:06 hmmmm        go profile it
18:07 celeron55    but that can be improved later anyways
18:07 Taoki        Haha... checked it and the other options are indeed there like I imagined
18:07 Taoki        Awesome work hmmmm, that will prolly be helpful :)
18:07 celeron55    there could be a C++ API to do a quick check whether a schematic contains nodes that have on_construct
18:07 celeron55    so that the complete lua wrapper can do that first and skip slowness if it indeed is safe
18:08 sokomine     the main problem with spawning larger...areas/houses/whatever in mt is that it scales very badly. even more than the speed issue, the problem with add_node is that it only works in loaded areas. which makes life hard for people who want to place these things. the new function helps there
18:08 celeron55    or whatever, don't mind the details for now (i'm quite ignorant on this thing as a whole)
18:08 Taoki        celeron55: Kept wanting to ask; Is the feature to adapt draw distance to FPS broken? I have min fps set to 60, but if I look toward some directions I still get 30. Isn't it supposed to adapt dymanically each frame?
18:09 hmmmm        yeah, celeron, that sounds good but you won't need a C++ api for that.  again, VoxelManip
18:09 celeron55    Taoki: how do you think it tries to adapt?
18:10 Taoki        celeron55: Thought it reads the FPS and decreases draw distance till it pops up past the minimum limit
18:10 celeron55    it should work, but it's slow
18:10 hmmmm        how is it slow?? pure computational stuff like looping and checking numbers is fast enough in lua
18:11 celeron55    (being *that* slow is a bug; but it can't be very fast because otherwise looking down from towers and such would cause terrible, horrible oscillation)
18:11 celeron55    hmmmm: completely different thing
18:11 hmmmm        well that's the idea
18:11 Taoki        hmmmm: FPS / distance adaptation is a C++ client thing
18:11 Taoki        celeron55: I see. Hope the bug that makes it overly slow can be fixed
18:11 hmmmm        oh, you're talking about something separate.
18:12 PilzAdam     Taoki, its not a bug
18:12 Taoki        ah
18:12 VanessaE     it's not so much a bug as a bad formula
18:13 PilzAdam     its not meant to instantly change the viewing range; it watches the FPS for some time
18:13 Taoki        I'd love the magic trick that would yeld me 60fps wherever I look, even if draw distance would switch quickly
18:13 VanessaE     it moves too slowly when the target fps is close to the real fps, which is a problem if the real fps is less than the target.
18:13 PilzAdam     so if you constantly look into the low-FPS direction then it will decrease the viewing range
18:13 Taoki        Would be a nice option to have in minetest.conf
18:13 celeron55    VanessaE: it's not a bad formula; it's the best i could come up in like a month of tuning it in early MT development
18:13 Taoki        PilzAdam: I remember I left it looking into a 30 FPS area for a while and it did nothing. I'll try again
18:14 celeron55    VanessaE: it's actually way better than anyone would come up with from scratch
18:14 celeron55    it's just gotten out of tune somehow
18:14 VanessaE     it's a problem because it makes the engine stick with a low fps and long view distance for far too long when it shouldn't.
18:14 Taoki        Gonna leave it for a minute or two in an area where I hav eexactly 30 fps and see
18:14 celeron55    again, if it bothers you, tune it
18:15 VanessaE     celeron55: "early MT development".   and you've had HOW long to fix it?
18:15 celeron55    it doesn't bother me so it's hard to fix it
18:15 VanessaE     that's my only gripe right there guys - I can't do shit to fix this, but you can, and you've had virtually forever to do it.
18:15 celeron55    it behaves so differently depending on how fast a computer is and what is the ratio of GPU speed to CPU speed
18:15 celeron55    i don't have a fast computer like you
18:15 celeron55    so it's basically blind tuning
18:16 VanessaE     you said you did some time back, fast enough anyway to see these kinds of things happening.
18:16 VanessaE     but one which you don't use for MT, as I recall
18:16 hmmmm        i don't see any problem with that.... i have a very fast cpu compared to my gpu however
18:16 celeron55    it's not nearly as fast as yours
18:16 Taoki        Been over 3 minutes, FPS still at 30. So it's certainly out of tune somewhere
18:16 sokomine     regarding fps...that "fps drops around spawn" due to too-many-objects (if i got that right? what pilzadam tested on menches server?) is something that ought to be fixed if possible. it makes mt slow
18:17 PilzAdam     sokomine, kahrl said he probably will look into the object duplication bug
18:17 PilzAdam     celeron55, VanessaE, the auto tuner works perfectly fine for me, with high-end GPU and CPU
18:17 VanessaE     PilzAdam: define "high end".
18:18 PilzAdam     GeForce GTX 460 and intel core i7 8 cores @ ~2.9 GHz
18:18 sokomine     that's fine! if he can use any help (i.e. shown servers where it happens) please just tell
18:18 VanessaE     2.8 Ghz 6-core Phenom II w/16GB + HD 6870 video w/1GB here.
18:18 celeron55    VanessaE: camera.cpp: try adjusting min_time_per_range
18:18 Taoki        PilzAdam: Mine are pretty high-end too, but it doesn't work
18:19 Taoki        Well, it DOES make sure I don't go under 30 FPS at any moment. But I want it to make sure I don't go under 60 and set it to that. THAT doesn't work
18:19 VanessaE     celeron55: I looked at that code yesterday but wasn't able to really understand it at the time
18:19 PilzAdam     though, I dont use fancy leaves to cap the FPS drops in jungles
18:19 celeron55    VanessaE: yes, the code would need some higher-level documentation to be understood, don't worry about that
18:19 PilzAdam     Taoki, set fps_min (or so) in minetest.conf to 60
18:19 celeron55    but try making that value lower
18:19 VanessaE     celeron55: you could try this yourself if you'd try using some high rez texture pack (any one, doesn't matter if HDX or not) and visit the spawn on my server.
18:20 celeron55    VanessaE: i won't
18:20 VanessaE     you have to see how drastic the view range has to change to see what REALLY happens.
18:20 VanessaE     then you're lazy.
18:20 Taoki        PilzAdam: Wasn't it wanted_fps? That one is set to 60
18:20 celeron55    more of working on other things than lazy, and the computer that is fast enough to maybe show something isn't in use at the moment
18:20 VanessaE     idc if you actually try to TUNE the code, I care if you try to see it happen at all.
18:20 VanessaE     in other words, I care if you PLAY the damn game for two minutes to see it happen.  That's it.
18:21 celeron55    do you seriously think i haven't EVER seen that happen?
18:21 celeron55    go to hell
18:21 VanessaE     besides, I'd think a slow computer would show it more.
18:21 Taoki        PilzAdam: In minetest.conf, the only options are fps_max and fps_wanted
18:21 VanessaE     celeron55: I'm not talking about minor changes in view distance because of a few trees here or there.  I'
18:21 celeron55    it's tuned for slow computers running at slow FPS requiring larger proportional viewing range changes per frame
18:22 VanessaE     I'm talking about changes on the order of 100-150 nodes' distance just by turning around and looking the other way.
18:22 celeron55    VanessaE: if you won't try adjusting the value i mentioned, i'm not going to try to take this forward at all; just so that you know
18:23 VanessaE     celeron55: I've given up trying to help tune the engine, because you'll just reject my change anyway.
18:23 celeron55    VanessaE: so you don't expect anything from me either; good
18:23 VanessaE     so all I have left is to point out bugs and faults when I find them.
18:24 proller      on mountain maps peoples wants more range, like 200+
18:24 Exio         PilzAdam: 8 cores? threads? what?
18:24 Anchakor     seriously C++ isn't that hard to learn :)
18:24 Exio         ;P
18:24 PilzAdam     Exio, 4 hyperthreaded physical cores
18:25 Exio         8 threads then
18:25 * Taoki      wishes there wouldn't be so much conflict on the dev team and solutions could be found
18:25 Taoki        PilzAdam: Same on my machine. I've an i7, which is 4 cores and 8 threads (hyper-threading)
18:25 hmmmm        if everybody here had a very agreeable personality, the result would be a chaotic mess
18:26 Jordach      youre still forgetting one thing: minetest targets low-end machines
18:26 Jordach      not your i7s and Xeons
18:26 Exio         why should it target *only* low-end machines
18:26 hmmmm        minetest only runs well on this machine :/
18:26 hmmmm        it's unplayable on my laptop
18:26 Taoki        Jordach: I don't think targets is the right word. More like aims to support. But true too
18:26 Jordach      it ran FINE on a > 1GHZ Tower
18:26 VanessaE     Exio: because at the time it was written, c55 only had a low-end laptop :P
18:27 Exio         VanessaE: i'm retyping the low-end
18:27 VanessaE     s/written/started/
18:27 Jordach      you should fix memory leaks before adding any new feature.
18:27 Exio         Jordach: GHz doesn't mean anything man btw
18:27 VanessaE     Jordach: most have been fixed.
18:27 Jordach      Exio, it had 256mb of ram
18:27 Exio         Jordach: the only mem leaks "left" are in irrlicht iirc
18:28 Jordach      then do what optifine does.
18:28 Exio         Jordach: what version was it?
18:28 Jordach      0.2.x
18:28 Jordach      0.3.x had 21fps
18:28 Jordach      0.4.x has 12fps
18:28 Jordach      (0.2 had 30)
18:28 VanessaE     Jordach: same or equivalent map, same or equivalent game content?
18:28 Anchakor     seems like nobody is against finding a solution which works for all configs, problem is *somebody* bossing people arround to work on it
18:29 Taoki        I'm running latest GIT, and apparently FPS adaptation doesn't work the slightest
18:29 Exio         Jordach: i guess you are trolling then
18:29 Jordach      VanessaE, vanilla games
18:29 Jordach      new maps each time
18:30 VanessaE     Anchakor: no one's bossing anyone around - but I have to ask you seriously, how much time has to elapse between filing a bug report or issue, and expecting a fix for it?  (assume a relatively simple issue)
18:30 hmmmm        why should you expect a fix for it anyway?
18:30 hmmmm        it's released without warranty
18:30 VanessaE     Jordach: to be fair, you'd need to compare exact equivalent maps/game content.
18:30 celeron55    anything from zero to infinite; it's up to the details of finding a reasonable fix
18:30 VanessaE     hmmmm: "without warranty" does not mean "without any intent to fix bugs that are reported to us"
18:31 VanessaE     when I say "expect" in that sentence, I don't mean it the way you seem to have interpreted it.
18:31 celeron55    VanessaE: seriously, what you say is full of bullshit; it's not like a bazillion of bugs hadn't been already fixed
18:31 celeron55    i don't understand you at all
18:31 hmmmm        yeah, seriously, i've noticed it too
18:31 hmmmm        you have this holier-than-thou attitude like we're not doing crap here and you have all the answers and what not
18:32 VanessaE     *facepalm*
18:32 Taoki        :(
18:32 hmmmm        try developing minetest and then come back with the same attitude
18:33 VanessaE     which one of us is telling others to "go to hell" and calling names now?
18:33 hmmmm        neither?
18:33 VanessaE     [06-25 14:21] <celeron55> do you seriously think i haven't EVER seen that happen?
18:33 VanessaE     [06-25 14:21] <celeron55> go to hell
18:33 hmmmm        oh
18:33 VanessaE     yeah, "oh"
18:34 VanessaE     and you wonder why I seem to have an attitude?????
18:34 hmmmm        that was a page up
18:34 celeron55    i did; and it's perfectly reasonable after the replies i got
18:34 Taoki        I think VanessaE means we could do even more about some things
18:34 VanessaE     Taoki is close.
18:35 hmmmm        i get what vanessa says
18:35 VanessaE     what I mean is the wrong things are getting the focus right now, if only because that's what is interesting to each of the people working on this project.
18:35 hmmmm        she says that we have this apathetic attitude about things that don't directly affect us, and we ought to fix everybody's problems
18:36 hmmmm        but ought is just ought, who says that something ought to be, and why is it "ought"?
18:36 Taoki        It is true that it's hard to work on something when you don't feel motivated enough on that feature. I can say that from experience
18:36 Anchakor     who wouldn't be pissed with being bossed around how he spends the free time he chooses to dedicate to what esentially is a hobby
18:36 Taoki        However, if a feature is broken, I do personally believe that's something to be urgently fixed (if it's an official feature in the engine)
18:36 sokomine     most of you do not seem to play the game much. that's understandable - there's only so much time you can spend on anything. the game got improved a lot in the past - it is now much more fun than it was in the 0.4.2 days or so. still, there are problems around which the users encounter and which trouble them...
18:36 VanessaE     bug fixes are more important than new features, especially when they affect user-facing things in the project.
18:37 VanessaE     this is programming 101 stuff here guys, I mean come on.
18:37 Taoki        Farmesh for example (last time I tried it) wasn't broken but outright destroyed. Even if it's a feature I know many don't use. Broken features don't sound like something good to have
18:37 Jordach      until you play your own game, you will never know how bad / good it is
18:37 hmmmm        taoki, it was pending removal (or some kind of revival, celeron likes it)
18:37 Anchakor     this is Project Management 101, not Programming 101
18:37 Taoki        I see
18:37 hmmmm        but farmesh just can't be used
18:37 Taoki        I only like it cuz it allows large view distances without losing FPS. Or well, I thiink that's its purpose anyway
18:37 hmmmm        the framerates...
18:37 PilzAdam     this is an Open Source project, nobody has the right to get any attention from developers; everyone just does what he wants
18:38 hmmmm        whattt!?
18:38 Anchakor     most open source projects have 0 project mangement and it is fine... others have lots of it and it is fine
18:38 hmmmm        taoki, how do you get high framerates with farmesh?
18:38 hmmmm        last time i checked i got about 5 fps with it on
18:38 Taoki        hmmmm: I don't. I get 10 times less FPS
18:38 Taoki        I meant I think its purpose was to improve frame rate
18:38 hmmmm        exactly, it's broken and crap and needs to be scrapped completely
18:39 hmmmm        it looks bad, it's inconsistent, and slow
18:39 Exio         i wonder
18:39 Taoki        I would be ok with removing it if it's not fixed
18:39 hmmmm        celeron and i were talking about how farmesh can be done better a while ago
18:39 Exio         did anyone try https://github.com/minetest/minetest/pull/789?
18:39 celeron55    farmesh was a prototype from the start; it's something i'd have in a personal branch if i made it these days
18:39 Taoki        I'd instead like to see some other LOD system though. To allow for huge draw distances without loss of FPS
18:40 hmmmm        we were thinking, generate a very small texture with the approximate colors for each visible side of the mapblock
18:40 Exio         you mean, making far-mapblocks simple when drawing them
18:40 Taoki        Maybe after some distance, nodes are combined and rendered as one node. After even more distance, 3 nodes combined, then 4 and so on
18:40 hmmmm        like mipmapping
18:40 hmmmm        the farther away you are, it uses the less detailed version of the texture for that mapblock
18:40 celeron55    rendering multiple nodes as one isn't going to look like it's further in the distance
18:41 celeron55    you need something more like what hmmmm is saying
18:41 Taoki        mm... yeah
18:41 celeron55    (maybe; it's what my intuition tells me)
18:41 celeron55    it's somewhat a heavy thing to test anything though
18:42 Anchakor     hmmmm: you mean like 3 sprites 1 for each axis? I thought about that too
18:42 celeron55    there's like everything involved
18:42 PilzAdam     Exio, yes, I tested it
18:42 hmmmm        anchakor, yeah.
18:42 PilzAdam     Exio, I havent noticed anything bad about it (tested performance and stuff)
18:43 Exio         VanessaE: can you try it? with your 4000+ nodes?
18:43 Exio         PilzAdam: same here, that is why i'm asking
18:43 VanessaE     what, farmesh?
18:43 Taoki        I assume farmesh was meant to be a geometry LOD system. Personally I find the idea of farmesh good... but sadly the system is currently broken\
18:43 Exio         no, https://github.com/minetest/minetest/pull/789
18:43 Taoki        If I enable farmesh, I get polygons thrown in my face and FPS is 5 times slower
18:43 PilzAdam     Taoki, download 0.3.x and test it there
18:44 VanessaE     Exio: texture atlas is disabled on my client already anyway, I don't see how that pull would change anything.
18:44 celeron55    farmesh is implemented with throwing each polygon separately to the GPU
18:44 celeron55    it's not going to be fast on modern GPUs
18:44 Exio         VanessaE: for checking if it didn't break anything in the middle
18:44 celeron55    don't even talk about it's speed :P
18:44 VanessaE     oh. maybe I'll try it.
18:44 PilzAdam     VanessaE, turning the setting off and completly removing it from core are two very different things
18:45 VanessaE     PilzAdam: I am well aware of that.  I just didn't understand Exio's point of requesting the test.
18:45 Exio         i guess if it passes your tests, it is 99% bug free in corner cases ;P
18:48 Taoki        Ah, I think I can tell why wanted_fps was not working. I had minimum view distance to more than 35 nodes
18:48 Taoki        Not it would appear to be working, but ugly low draw distance
18:49 Taoki        **now
18:50 Exio         what is your gpu, btw?
18:50 Taoki        I wonder why it's still so slow to render simple block faces. I mean in an environment like Minetest, one could expect over 60 FPS with reasonable draw distances
18:51 Taoki        Especially since celeron55 mentioned block surfaces are now combined and faces merged into one face where possible
18:51 Taoki        Exio: Radeon HD 6870
18:51 PilzAdam     Taoki, do you look at a tree with fancy leaves enabled?
18:51 Taoki        PilzAdam: I have that option on. Will try with it off then
18:52 Taoki        Ah... without it trees are opaque. Uuuuuugly  :P
18:53 VanessaE     Exio: had to re-clone for some reason.  anyway, compiling now.
18:53 VanessaE     Taoki: same GPU as me.  Windows or linux?  I don't remember now which you used.
18:54 Taoki        VanessaE: Linux, and the fglrx driver
18:54 VanessaE     ok, so basically the same setup as me.
18:54 Taoki        Minetest seems to work faster on the open-source Radeon driver, but I need frlgx for higher-end games
18:54 Taoki        nice
18:57 Taoki        PilzAdam: FPS adaptation is SLIGHTLY working. If I set my minimum draw distance very high then back down to 50, it slowly begins decreasing the actual view distance till it's enough to get 60FPS. But not the other way around: If distance is initially low, it doesn't try going higher as long as it keeps to 60 fps
18:58 VanessaE     Exio: ok, I'm on my server now - fresh git clone + kahrl's patch.
18:58 PilzAdam     Taoki, can you try the default settings?
18:58 Taoki        So if you start with a high draw distance it will go lower till you get 60 fps. But if you start with a low one, it doesn't go higher as long as it stays 60
18:58 Taoki        ok
18:59 Exio         so
19:00 Exio         that is gpu is better than mine, nvm :P
19:00 VanessaE     Taoki: that's been my general experience alos.
19:00 VanessaE     also*
19:01 VanessaE     Exio: looks normal.  Nothing unusual so far.
19:02 hmmmm        hmmmmmm i have a question about lua callbacks
19:02 Taoki        PilzAdam: With wanted_fps at 30 it seems to be slightly increasing
19:02 hmmmm        is there any way to store information along with a registered callback?  i want to pass certain parameters to it if a certain option is present
19:03 hmmmm        for example i'd like to be able to do minetest.register_on_generated(WANT_VMANIP | WANT_HEIGHTMAP, function (blah blah blah)
19:04 Taoki        surprisingly, with wanted_fps 30 I still don't get less than 60
19:04 Taoki        Well, about 55 at least
19:04 sapier1      hmmmm you always can change the data stored saving the function in a sub element and store the data to another one
19:06 Taoki        Yeah now it gets to about 40
19:08 hmmmm        actually this is kinda hard
19:08 hmmmm        i need t ochange environment_OnGenerated much more than i wanted to
19:09 sapier1      why? in worst case you could register a single callback making that callback distribute it to other ones within lua
19:10 sapier1      ok ok
19:10 sapier1      special callback handling
19:11 hmmmm        i'd have to make a different on generate
19:11 hmmmm        on_generate_ex() also passes a table of optional parameters
19:12 hmmmm        based on what the mod doing the registering wants, that table will get populated with whatever
19:16 celeron55    hmmmm: what are you trying to do?
19:16 celeron55    uhm
19:17 celeron55    well at least don't make a yet another function, just make an optional second parameter to register_on_generated()
19:17 Taoki        Is the character model with divived limbs part of Minetest officially?
19:17 Taoki        I'm seeing that on VanessaE's server, but the latest source blend isn't updated
19:17 Taoki        Arms and legs are still whole blocks there
19:18 VanessaE     that's stu's model
19:18 celeron55    IIRC somebody made a second version of it in addition to yours and released it
19:18 VanessaE     it's not part of minetest and probably won't be.
19:18 Taoki        ok
19:18 VanessaE     (someone here already said the difference in file size was too great or some such)
19:28 Jordach      which with todays internet
19:28 Jordach      thats absolute bullshit
19:28 Jordach      size is no longer a constraint
19:29 sapier1      jordach you're kidding?
19:29 kahrl        today's internet has the only ISP available around here essentially cut off your internet after you use a few GB per month
19:29 PilzAdam     Jordach, not everyone is blessed with a fast internet connection like you have
19:30 sapier1      kahrl german telecom tries to establish "flatrates" cut down to 256kbit after budget is exceeded ;-)
19:31 kahrl        sapier1: genau :)
19:31 sapier1      wait its been 384 ... but I've read they try to avoid regulation by setting it to 2mbit
19:32 sapier1      but real problem is priorized data transfer to their own or paying services
19:33 kahrl        some areas even only have LTE or some bullshit like that
19:52 Taoki        celeron55: Is it really a good idea to let Minetest send things that aren't rendered to the video card? It does feel like this might be making it slower instead...
19:55 celeron55    Taoki: can't you understand that the reason why MT is running slow on your beast GPU is because MT sends stuff to be rendered in so small pieces and does not store them on the GPU
19:56 Taoki        Ah... that I didn't understand yet.
19:56 Taoki        I assume it can't be fixed?
19:56 celeron55    of course it can, but it's not exactly trivial
19:56 celeron55    also, both need to be fixed at the same time, because either done on their own is useless
19:57 Taoki        I think it would be a very important thing to fix, since FPS is very slow due to it
19:57 Taoki        Maybe not the ost important, but I'd say one of the
19:57 celeron55    i'm not 100% sure it's the main reason for a given kind of slowness, but it sure creates very different kind of GPU utilization than modern games do
19:58 Taoki        From what I can think of, it's probably a huge reason. If each face or polygon is sent individually than as a whole, I'm surprised it even works as fast as now
19:59 celeron55    ...ehm
19:59 celeron55    they are sent as individual mapblocks (to put it simply)
20:00 celeron55    and that is not large enough batching
20:00 Taoki        Ok, to some extent that is good. But if the GPU doesn't keep then and the CPU has to send the model each frame, I think that means a lot of slowness.
20:00 Taoki        Pretty sure actually. Although I could be wrong, that sounds like a really bad thing
20:01 celeron55    storing those on the GPU doesn't give any more performance at least on my laptop
20:01 celeron55    (also it's kind of wonky to do in irrlicht, you set a flag and then hope that it maybe does what you want in the background)
20:02 Jordach      how about we delete unused chunks
20:02 Jordach      in ram
20:02 Jordach      that is where performance is lost. chunks that are "loaded" but not used.
20:02 Taoki        Has anyone tried setting that flag in Minetest? Which line of code can I try it at?
20:03 celeron55    i'm trying to find it ATM
20:03 PilzAdam     Jordach, blocks are unloaded after some time, there is a setting for this
20:03 Taoki        ok. Let me know please, I'd really like to test this
20:03 PilzAdam     one for client and one for the server
20:03 Jordach      PilzAdam, yes, i know of the delete chunks after x seconds
20:03 Jordach      but even that doesnt prune very quickly
20:03 celeron55    vertex data stored on GPU like that is usually called a VBO
20:03 Taoki        Again, I could be wrong. But the thought of sending data to the GPU every frame when the GPU could simply keep it sounds ludicrous to me (on a general 3D knowledge)
20:04 Taoki        Yes, I think it's the VBO part
20:05 celeron55    Taoki: in mapblock_mesh.cpp, search EHM_STATIC; and in main.cpp, uncomment line 1576 (setMinHardwareBufferVertexCount)
20:05 Taoki        Most engines have VBO as a setting. So if this can be figured out I believe it should be an option
20:05 celeron55    the latter because the default minimum size of VBO'd buffers in irrlicht is 500
20:05 Taoki        Awesome, thanks. Will try it out now
20:05 celeron55    also, you will experience horrible memory leaks
20:05 celeron55    because irrlicht doesn't handle deletion of VBOs properly at all
20:06 celeron55    (at least 1.7 doesn't)
20:07 Taoki        celeron55: I wonder. Could we add an #ifdef check to detect the Irrlicht version? Any only enable it with +1.7 then?
20:07 celeron55    of course; but i don't think it's fixed
20:07 Taoki        ok
20:07 Taoki        Will see how faster it is, really curious
20:08 celeron55    i'm curious too
20:08 PilzAdam     celeron55, I get 60+ FPS in a jungle where I formerly got 20
20:09 PilzAdam     and constantly increasing RAM usage
20:10 Taoki        It is a LOT FASTER!
20:10 Taoki        I enabled full view range and so far nothing under 60 FPS
20:10 Exio         it doesn't perform that well for me
20:10 Taoki        Damn... I never thought I'd see a view range this large at 60 FPS in Minetest
20:11 Jordach      dun dun durr
20:11 celeron55    something like calling IVideoDriver::removeHardwareBuffer for mapblock meshes that are deleted should be done
20:11 Taoki        Exio: Can depend a lot on drivers and hardware. For me it does miracles
20:11 PilzAdam     with full view range looking at a huge jungle with fancy leaves enabled and I still get 50 FPS
20:11 Exio         but i can have more mapblocks when looking at it
20:11 proller      btw Irrlicht Engine version 1.9.0
20:11 Jordach      make VBOs a conf setting
20:11 celeron55    Exio: well, what hardware?
20:11 Exio         celeron55: gt 610 (low-end and old-ddr3 nvidia gpu, the cheapest) and if matters, bulldozer x6 6100 the cpu
20:11 Exio         (3.3 but turbo at 4ghz)
20:11 Taoki        only now I'm starting to get 40 FPS at full view range.
20:11 Taoki        I can't tell how many nodes that is but it's reasonably far
20:12 Taoki        proller: Hold on, I'll look in my system packages
20:12 Taoki        Anyway, for my hardware at least, this is a HUGE improvement
20:12 PilzAdam     celeron55, overall I would guess 400% performance increase
20:12 Taoki        It's probably 3-5-7 times faster
20:12 Jordach      fuck me backwards.
20:12 Jordach      my gpu supports VBOs
20:12 proller      lets make config value for it
20:12 celeron55    the funny thing is, i've said this like a million times and this is the first time anyone actually bothered trying it
20:12 Exio         it is mem leaky
20:12 proller      run_fast=1
20:13 Taoki        proller: +1
20:13 Exio         run_fast_but_consume_1mb_of_ram_every_second
20:13 PilzAdam     the RAM fills up very quickly, though
20:13 Taoki        proller: No. If it's called VBO the option should be called VBO too. It's that way for most engines
20:13 Jordach      if we used cleared unused chunks, then it shouldnt leak allover the place
20:13 proller      now very cheap memory, no problem 8)
20:13 PilzAdam     its not usable in "normal  usage"
20:13 celeron55    Taoki: so does it consume infinite memory on your computer and what version of irrlicht is it?
20:13 Exio         1.8 here
20:13 Taoki        celeron55: So far no excess RAM usage
20:14 Exio         now it got stable
20:14 PilzAdam     celeron55, 1.7.3 here and each loaded block increases the RAM usage
20:14 celeron55    so it could be that 1.8 fixes it; needs more testing though
20:14 Taoki        My Irrlicht version is 1.8.2
20:14 Taoki        I'll keep exploring and see
20:15 Exio         fwiw i'm using a 256x texture pack
20:15 Exio         i'll try with default
20:15 Taoki        Default textures here
20:15 Taoki        I can test if with Irrlicht 1.8 the problem still exists, will go exploring on my local server now
20:16 Exio         it works very well with a damn lot of mapblocks
20:16 Exio         but with less, it is the same :P
20:16 Taoki        Exio: All I can tell is that at big view distance, it's awesomely faster
20:16 celeron55    anyhow, seems to turn out that actually it doesn't need larger batches at all
20:17 PilzAdam     celeron55, Ill test if 1.8 cleans up the memory
20:17 Exio         and if c55 said it didn't make any difference with "low-end hardware" (even if mine is low-end-but-new-ish)
20:17 Taoki        Sadly, memory is increasing for me too. 380 MB so far
20:17 Taoki        I wonder if anything can fix that
20:17 Exio         it seems so
20:17 PilzAdam     Taoki, I was at 2.5 GiB
20:17 celeron55    Taoki: that amount is probably just regular operation if you're exploring places
20:18 celeron55    or, well, could be
20:18 Exio         if there is a leak, in 1.8, it is small :P
20:18 Taoki        650 after flying a bit forward. So yes, the memory leaks are true
20:18 Taoki        Yes, it keeps adding as I explore
20:18 Exio         that is obvious
20:18 Exio         mapblocks are always in ram, even air uses ram
20:18 Taoki        On the other side, wasting such a good improvement would be a crime. So what can be done at all? What causes the leaks?
20:19 celeron55    MT will start deleting mapblocks from memory only after 5 minutes of not rendering them, by default
20:19 celeron55    23:11:45 < celeron55> something like calling IVideoDriver::removeHardwareBuffer for  mapblock meshes that are deleted should be done
20:19 Taoki        I see
20:20 Taoki        celeron55: What if it were done instantly after not rendering them? Would it hurt anything, and fix the leaks with this?
20:20 Taoki        PilzAdam: And yes, overall I would say an average of 40% improvement too. Possibly more depending on circumstance, at first it felt like a lot more
20:21 Taoki        Either way, the improvement is huge
20:21 PilzAdam     Taoki, +0
20:21 PilzAdam     (400%)
20:21 celeron55    mapblock_mesh.cpp:1233 maybe
20:21 celeron55    as long as that is done in the main thread of the client
20:21 celeron55    i think it is
20:21 celeron55    or hope it is
20:21 celeron55    otherwise it's getting messy
20:22 celeron55    but that place in the code doesn't have the device pointer so that needs some logistics
20:22 Taoki        yeah
20:22 celeron55    (it's complete bullshit that irrlicht doesn't free it by itself when the mesh is freed)
20:23 celeron55    (it could do it easily if it wanted)
20:23 Taoki        It's pretty sad; I can't waste such an improvement, but the memory leaks aren't acceptable either
20:24 * Taoki      thinks
20:24 Taoki        You said after 5 minutes of not rendering them. Where is that code, and what happens if it's made instant?
20:24 celeron55    aaaactually
20:25 celeron55    it has access to IGameDef... no, that doesn't give access to IrrlichtDevice either
20:25 celeron55    it could be a shortcut for doing that for now though
20:26 hmmmm        could do it like minecraft and only keep a largeish box radius around the player loaded
20:26 PilzAdam     tested a build with 1.8 same leaks, and worse performance
20:26 Taoki        Should work. It should be possible to get the device by referencing from another file from what I remember
20:26 hmmmm        taoki, i don't think gpu bandwith is the problem, video cards do the occlusion on their own
20:26 celeron55    of course you can put it in a global, but that isn't going upstream by any chance
20:26 Taoki        PilzAdam: I can confirm the leaks too. I think the leaks themselves decrease performance, after VBO initially improves it a ton
20:26 PilzAdam     *slightly worse
20:26 Taoki        So vbo without the leaks should mean huge improvement on some cards
20:27 Taoki        hmmmm: Well, the VBO's improve performance quite a lot
20:27 kahrl        celeron55: gamedef->tsrc()->getDevice()?
20:27 hmmmm        VBO is something differen, i was talking about what you said earlier
20:27 celeron55    kahrl: good catch
20:27 celeron55    PilzAdam: go test that
20:27 Taoki        hmmmm: Ah, ok.
20:27 Taoki        celeron55: If you put it on a pastebin I can test too
20:28 PilzAdam     celeron55, gimme a second
20:28 celeron55    in mapblock_mesh.cpp:1233, do m_gamedef->tsrc()->getDevice()->removeHardwareBuffer() for each meshbuffer of m_mesh
20:28 hmmmm        so why is irrlicht 1.8 slower exactly?
20:28 celeron55    hmmmm: many people say so, but nobody has yet said why
20:28 PilzAdam     hmmmm, I head 1.8 is generally slower
20:28 celeron55    (outside MT too)
20:28 hmmmm        newer versions of things should never be slower than older ones
20:28 PilzAdam     *heard
20:29 sapier       hmmmm tell that to eclipse developers ;-)
20:29 hmmmm        yeah we heard, it'd be nice to do a side-by-side comparison though
20:29 Taoki        Anyway, I know that for some cards and drivers VBO can be problematic instead. So IMO this must be a minetest.conf option. But it needs to happen
20:29 Taoki        And I'll try that too
20:30 celeron55    i have never heard of a card that says it supports VBO but breaks if actually used with it
20:30 kahrl        isn't removeHardwareBuffer in IVideoDriver?
20:30 celeron55    uhm
20:30 celeron55    yes it is
20:30 celeron55    so yet another -> there!
20:31 Taoki        celeron55: For me it depended on engine some time ago. Years ago for instance, enabling VBO in Second Life caused very jittery loading
20:31 Taoki        Of course, that's a TOTALLY different type of architecture
20:31 celeron55    oh
20:31 celeron55    it indeed may cause jitter
20:31 celeron55    that's why it's an option
20:31 Taoki        yes
20:31 Taoki        But a damn good option in this case :D
20:31 celeron55    (the GPU can be slow at storing it)
20:32 celeron55    (that is, meant to be used so that everything is loaded into it at game startup, which we can't do)
20:32 Exio         if the gpu ram is fast, the VBO will make the stuff way faster :P
20:32 Taoki        For me there's no jitter however, so it's good on my hardware at least
20:32 Taoki        yes
20:32 PilzAdam     celeron55, what do I pass to removeHardwareBuffer()?
20:33 Taoki        celeron55: mapblock_mesh.cpp:1234:34: error: ‘class irr::IrrlichtDevice’ has no member named ‘removeHardwareBuffer’
20:33 celeron55    each meshbuffer of m_mesh
20:33 celeron55    Taoki: what kahrl said
20:33 Taoki        oh
20:34 Taoki        It doesn't find IVideoDriver() either. What's the include file for it?
20:35 Exio         did you mean ->getVideoDriver()
20:35 PilzAdam     and segfault
20:36 Taoki        <+kahrl> isn't removeHardwareBuffer in IVideoDriver?
20:36 Taoki        m_gamedef->tsrc()->getDevice()->IVideoDriver()->removeHardwareBuffer();
20:36 celeron55    m_gamedef->tsrc()->getDevice()->getVideoDriver()->removeHardwareBuffer()
20:36 Exio         Taoki: http://irrlicht.sourceforge.net/docu/classirr_1_1_irrlicht_device.html
20:36 celeron55    read the irrlicht docs
20:36 PilzAdam     for(u322 i=0; i<=m_mesh->getMeshBufferCount(); i++)
20:36 PilzAdam     m_gamedef->tsrc()->getDevice()->getVideoDriver()->removeHardwareBuffer(m_mesh->getMeshBuffer(i));
20:36 celeron55    PilzAdam: so it actually doesn't work? 8)
20:37 celeron55    lol
20:37 celeron55    i<=
20:37 PilzAdam     oh, damnit, Lua...
20:37 Exio         haha
20:37 Taoki        I forgot to add the ; at the end due to Lua habit :P
20:37 PilzAdam     it increase slower
20:37 PilzAdam     +s
20:39 PilzAdam     ok, it doesnt use infinite ram now
20:40 PilzAdam     but the performance isnt better than normal...
20:41 Exio         is it enabled? :P
20:42 PilzAdam     the performance is only better if it stays in RAM
20:42 PilzAdam     so its not useable :-/
20:43 celeron55    welcome to the fun irrlicht world
20:43 celeron55    8D
20:43 Taoki        Not sure if the memory leak still exists, might be fixed. Performance still seems to be improved though
20:44 celeron55    next you'll find yourselves browsing through the (actually quite readable) irrlicht sources figuring out what it does in the opengl backend
20:44 Taoki        Yes... pretty sure that performance remains as improved with the removing of those drivers
20:45 Exio         celeron55: where is the 5 minutes timeout defined?
20:45 PilzAdam     Exio, minetest.conf
20:45 Exio         aw :P
20:45 Exio         #client_unload_unused_data_timeout = 600
20:45 Exio         i see, thanks
20:46 celeron55    hmm actually that's 10 minutes
20:46 PilzAdam     wait, it works better in 1.7.3
20:46 celeron55    whatever
20:46 PilzAdam     its only not good in 1.8
20:47 PilzAdam     another reason not to upgrade to 1.8
20:47 Taoki        PilzAdam: I can't tell if the memory leaks are solved after that loop, but performance is surely still improved
20:47 PilzAdam     Taoki, what Irrlicht version?
20:47 Taoki        1.8.2
20:47 Taoki        It's the latest in my distro and I don't have an 1.7
20:48 celeron55    PilzAdam: did you do the setMinHardwareBufferVertexCount thing?
20:48 PilzAdam     yea
20:48 PilzAdam     maybe I messed something up...
20:48 celeron55    well it could be that 1.8 does something that is not optimal on your GPU; can't really know
20:49 PilzAdam     we can make it optional in minetest.conf so people can test it themselves
20:49 Taoki        Sounds good
20:49 Taoki        If you add the commit now I can test it with VanessaE
20:49 PilzAdam     how to call that setting?
20:49 Taoki        PilzAdam: VBO. It's the correct name and most engines call it that
20:50 PilzAdam     so enable_vbo
20:50 Taoki        sure
20:50 PilzAdam     celeron55, should the cleanup be disabled too if vbo is disabled?
20:50 Taoki        Or just vbo though that's a bit too short :P
20:51 Exio         VanessaE: ping?
20:51 celeron55    PilzAdam: irrlicht does a binary tree search out of all existing meshbuffers when you call removeHardwareBuffer
20:51 VanessaE     pong.
20:51 celeron55    so... umm
20:51 Exio         VanessaE: are/did you try the atlas remove?
20:51 celeron55    dunno, getting the setting is probably similarly heavy
20:52 celeron55    i'd say just call the removal always
20:52 hmmmm        storing a boolean is similarly heavy!?
20:52 Taoki        Calling it always sounds good to me too
20:52 celeron55    well storing a boolean is of course cheaper
20:52 Taoki        I mean, it makes sense
20:53 PilzAdam     celeron55, and driver->setMinHardwareBufferVertexCount(50); can be called always too?
20:53 celeron55    that can be called always; it only takes effect for meshes with the EHM_STATIC flag
20:53 kahrl        could getHardwareMappingHint be called to see if removeHardwareBuffer must be called?
20:54 celeron55    i was just going to search if something like that exists
20:54 celeron55    of course that way in that case
20:54 VanessaE     Exio: yes, and it had no visible effect, which I guess means it worked.
20:54 VanessaE     Exio: I saw no issues at all with that patch
20:54 * Exio       bugs kahrl, c55 and PilzAdam about merging it
20:55 Taoki        http://code.google.com/p/opennero/source/browse/vendor/Irrlicht/current/include/EHardwareBufferFlags.h?r=849 This is somewhat inspiring
20:55 kahrl        celeron55: SMesh doesn't have it, SMeshBuffer has getHardwareMappingHint_Vertex and _Index
20:55 Taoki        I wonder if the vertex buffers would also improve anything
20:55 Taoki        Apart from VBO's, there's also FBO\
20:55 Taoki        Frame Buffer Objects or something
20:56 PilzAdam     ok, it always segfaults when I shut down minetest
20:57 Taoki        I wonder: What happens if we change the buffer type (that thing I linked shows it)
20:57 Taoki        Maybe some are even faster and don't cause the leak?
20:58 celeron55    Taoki: it doesn't mean what you think it does; read the doc of setHardwareMappingHint
20:59 Taoki        There's also EHM_DYNAMIC and EHM_STREAM
20:59 Taoki        ok
20:59 PilzAdam     now the question is why does it segfault?
20:59 celeron55    Taoki: those mean it's not stored on the GPU
20:59 Taoki        oh, useless then
20:59 celeron55    PilzAdam: the answer comes when you run it in gdb with a debug build of irrlicht, i guess 8)
21:00 Taoki        PilzAdam: Can you use a function to if() check if the meshbuffer exists before removing it? That should fix it
21:00 Taoki        if(m_mesh->getMeshBuffer(i))
21:00 PilzAdam     nope tested it
21:00 Taoki        hmm...
21:01 celeron55    irrlicht does that already
21:03 PilzAdam     ummm
21:03 PilzAdam     the backtrace doesnt even show any Irrlicht functions...
21:06 Taoki        I'm surprised you can't detect if the meshbugger you're getting == null however. Normally anything should allow that
21:09 PilzAdam     (gdb) bt
21:09 PilzAdam     #0  0x0000010000000010 in ?? ()
21:10 PilzAdam     I have an Irrlicht and Minetest debug build
21:11 celeron55    it's 42
21:11 celeron55    it's the answer
21:11 celeron55    well no, umm
21:11 celeron55    well the stack is borked
21:12 celeron55    i'd throw it in valgrind instead and hope for the best
21:12 PilzAdam     what command line parameters?
21:13 hmmmm        ugh this is so messy.  so in order to do what i want to do, i'm going to have t ochange make_registration() to return a function that takes a function and a table of parameters, and inserts that into registered_on_generateds, and then i have to change runCallbacks and all this nonsense
21:13 celeron55    defaults should do
21:13 hmmmm        because it's no longer a table of functions, it's a table of tables of functions and options, and it's only a single specific callback that uses this
21:14 celeron55    why don't you just special case your registration function
21:14 celeron55    don't use make_registration() or runCallbacks
21:14 hmmmm        i'd have to rewrite the universe
21:14 celeron55    nobody is going to do the same in the long time anyway
21:14 hmmmm        alright, i have a better idea
21:14 celeron55    and when somebody does, then it's worth the job
21:14 hmmmm        i add a new api that switches it on
21:15 hmmmm        completely internal
21:15 PilzAdam     celeron55, :-/ nothing useful
21:15 PilzAdam     ==17945==  Access not within mapped region at address 0x0
21:15 PilzAdam     ==17945==    at 0x6FAE2F: MapBlockMesh::~MapBlockMesh() (mapblock_mesh.cpp:1236)
21:15 kahrl        hmmmm: maybe it would be cleaner to add a 'callback' decoration type?
21:15 kahrl        but I don't know what you are trying to do
21:15 hmmmm        erm, this isn't a decoration :)
21:15 celeron55    hmmmm: what if you added a new API function to get the vmanip in on_generated
21:16 celeron55    and leave it otherwise the same
21:16 PilzAdam     celeron55, might it be that one of these (m_gamedef->tsrc()->getDevice()->getVideoDriver()->removeHardwareBuffer(buf);) is NULL
21:16 PilzAdam     +?
21:16 hmmmm        that's an option too
21:16 celeron55    PilzAdam: oh, can be of course
21:16 PilzAdam     wait, gamedef doesnt exist after returning from the_game()?
21:16 celeron55    hmmmm: i think it's the best thing you can do, assuming there's nothing making it inconvenient to implement
21:16 Taoki        Logically, only one thing could explain the segfault: Something removes the buffers before that function runs upon exit
21:16 hmmmm        alright, that's the best choice then.. i'll have it fail if called outside of on_generated
21:16 Taoki        Or the mesh is not referenced properly which isn't the case
21:16 celeron55    PilzAdam: that's an easy fix then 8)
21:17 Taoki        So what removed the buffers before shutting down Minetest?
21:17 Taoki        Ah... or that :P
21:17 Taoki        Which implicitly means the buffers don't
21:17 celeron55    PilzAdam: umm actually no, you can't know it in there... ehm
21:17 PilzAdam     if(m_gamedef) doesnt work :-/
21:17 celeron55    of course, it's a dangling pointer 8)
21:18 Taoki        Needs to be de-referenced perhaps
21:19 PilzAdam     cant I just try {..} catch(segfault) ? ;-)
21:20 PilzAdam     celeron55, the dtor is called from MapSector::deleteBlocks(), what if I let it just set a flag or something?
21:20 kahrl        the scary thing is that since this just accesses a pointer variable in TextureSource this might have actually worked if we were less lucky
21:20 Taoki        PilzAdam: What if you try if(*m_gamedef)?
21:21 kahrl        and then would have become the untraceable bug that noone will ever find
21:21 PilzAdam     Taoki, that doesnt even compile
21:21 Taoki        ouch. Was supposed to dereference it
21:22 celeron55    the problem is really that ClientEnvironment is destructed after the Client (=gamedef) destructor is done, because it exists as a member of Client
21:22 celeron55    umm... i think
21:24 celeron55    the fix? well, allocate Client::m_env dynamically so you can control when it's freed 8)
21:25 celeron55    (should work)
21:25 celeron55    (it's hackish of course but technically not wrong at all)
21:25 hmmmm        ah this is a much better idea, thanks celeron
21:27 hmmmm        i generalized it to VoxelManip:get_mapgen_object(["vmanip", "heightmap", "biomemap", "heatmap", "humiditymap"])
21:27 PilzAdam     heres the diff is anyone is interested: https://gist.github.com/PilzAdam/5862595
21:29 * Taoki      is interested to see it upstream :) Testing part of it manually still, hoping to find a check
21:32 celeron55    PilzAdam: for a quick and not-touching-everywhere fix, you could of course just add a bool to MapBlockMesh that will be set in MapSector::deleteBlocks() before deleting them
21:33 celeron55    dunno what should be considered upstream quality regarding to this
21:34 celeron55    not that really at least
21:34 * Taoki      is up for anything that works. And is of course upstream quality too
21:36 Taoki        If only we could get m_device there...
21:37 Taoki        m_device->getVideoDriver()
21:37 Taoki        Instead of doing it through m_gamedef->tsrc()
21:38 BrandonReese That's a big improvement, it's playable with draw full range enabled. I get ~ 60fps with draw full disabled and ~25 with it enabled, it would have been around 8-10 before
21:38 celeron55    BrandonReese: what kind of hardware?
21:38 PilzAdam     hm, I just noticed that the RAM still fills up slowly when flying over many blocks
21:39 PilzAdam     there is a leak left
21:39 PilzAdam     (and FPS decrease too)
21:39 BrandonReese ATI Radeon HD 7560D
21:39 Taoki        FPS decrease is prolly related to the leak
21:41 Taoki        Performance slightly decreases for me too as the leak takes place I think
21:42 BrandonReese yeah Memory usage continues to climb
21:47 PilzAdam     heres the diff that sets the flag: https://gist.github.com/PilzAdam/5862737
21:49 Taoki        Awesome
21:49 Taoki        I wonder where the other leak could be tho..
21:49 kahrl        you could initialize clearHardwareBuffer to false and set it to true when you call setHardwareMappingHint
21:50 PilzAdam     kahrl, that wouldnt really help
21:50 kahrl        PilzAdam: I know, just an observation
21:50 PilzAdam     its used to indicate if gamedef exists
21:51 PilzAdam     oh, yea, Ill do that
21:51 PilzAdam     valgrind doesnt find any leaks :-/
21:57 Taoki        Will test more too, not sure why any leaks would still exist
21:57 PilzAdam     holy... this speeds things really up; 11 FPS in valgrind
21:57 Taoki        yeah :)
21:58 VanessaE     with my luck all of these improvements will still not help on my setup :)
21:59 Taoki        VanessaE: You have my setup, and for me it helps a ton. Surely it will for you too, maybe some other issue
21:59 VanessaE     ok
22:01 Taoki        PilzAdam: And that speedup is explainable. VBO likely takes a lot of load off the CPU, who had to send to the GPU each frame. Valgring is prolly a bit CPU intensive (last I remember), so the improvements is even more visible
22:05 PilzAdam     grrrr... why does this leak hide in valgrind?
22:07 VanessaE     PilzAdam: because you're searching for it, of course. :P
22:07 kaeza        try other more aggressive options
22:07 PilzAdam     anyone patient enough to fly arround with valgrind with 2FPS and load some blocks?
22:07 Taoki        PilzAdam: Does Valgrind detect if something is truly a leak or not? Maybe it's just using memory badly and not necessarily leaking...
22:08 Taoki        PilzAdam: Will try it as well now
22:09 PilzAdam     be sure to run it with --leak-check=full
22:09 PilzAdam     I use: valgrind --leak-check=full --log-file=valgrind.log bin/minetest
22:10 Taoki        will do and paastebin
22:10 kaeza        now Taoki's client is leaking 'a's
22:10 * kaeza      shuts up
22:10 Taoki        :3
22:10 celeron55    it might not be technically a leak, because irrlicht could free it at shutdown time
22:10 celeron55    but leave it around until then
22:11 celeron55    (irrlicht likes doing that)
22:11 Taoki        Sometimes I wonder what Minetest would have looked like if we chose OGRE
22:12 PilzAdam     round
22:13 VanessaE     kaeza: no, see, it's not leaking a's, he's just using a slightly different wording, like "haagen dasz" :D
22:13 celeron55    it would still have a command line UI because ogre doesn't contain any GUI capabilities
22:17 Taoki        The default Ogre samples and sample browser have a GUI
22:20 Taoki        Damn Valgrind is slow
22:22 Taoki        Interesting. Sometimes chunks are loaded / generated into view without increasing memory usage and causing the leaks. I think
22:29 Taoki        PilzAdam: http://paste2.org/ymHZjIJP
22:31 Taoki        One huge log... 2 MB. Barely found a pastebin that accepted it x_x
22:38 Taoki        PilzAdam: Does it help and explain what's happening?
22:42 * Taoki      feels alone
22:47 Taoki        celeron55: Can you deschipher anything of importance from that log?
22:48 Taoki        Funny thing: On VanessaE's server, memory usage is still slightly increasing although I'm no longer exploring
22:50 Taoki        Even more funny thing: I was debugging a code when suddenly, everyone I was working on it with went AFK :)
22:55 PilzAdam     Taoki, that log is very helpful for fixing more memory leaks in the future :-)
22:55 Taoki        Well, at least it did something :)
22:55 Taoki        Nothing on the memory leak with VBO's though?
22:58 PilzAdam     have you compiled minetest in debug mode?
22:58 Taoki        Don't think so
22:59 PilzAdam     well, there are no line numbers in the log
22:59 PilzAdam     so its not very useable
22:59 Taoki        I'll comiple in debug mode and run valgrind with the same parameters again
23:00 PilzAdam     only the part under "HEAP SUMMARY:" is interesting to find memory leaks
23:00 Taoki        Hopefully I'll have a new log in about 30 minutes or more
23:02 Taoki        So after I compile MT with the Debug flag in cmake, I just run valgrind the same way, right?
23:03 PilzAdam     yep
23:03 Taoki        ok, let's see how this works
23:03 PilzAdam     Id recommend to make a short test first to see if everything works (i.e. line numbers)
23:03 PilzAdam     also get a debug build of irrlicht
23:04 PilzAdam     (maybe its helpful)
23:04 Taoki        A debug build of irrlicht would be too advanced. I use Irrlicht from the system-wide installation (Linux software packages)
23:04 PilzAdam     just apt-get install libirrlicht<something>-dbg
23:04 PilzAdam     (or whatever package manager you have)
23:05 Taoki        irrlicht-debugsource?
23:05 Taoki        or libirrlicht1_8_debuginfo
23:05 PilzAdam     ehm, what distro?
23:05 Taoki        openSUSE
23:06 Taoki        I guess I'll just install both. Once I do that, will cmake automatically detect the change and compile Debug minetest with Debug irrlicht?
23:06 PilzAdam     I usually rm bin/* CMakeCache.txt and run cmake and make again
23:06 PilzAdam     just to be sure that it links correctly
23:07 Taoki        I can do that. But it will all be re-detected properly? How do I know it uses debug Irrlicht?
23:07 PilzAdam     good question
23:08 PilzAdam     just hope that it works, its not that important that you have a debug build of irrlicht
23:08 Taoki        Will compile MT again and give it a try, hopefully it will
23:09 Taoki        I set CMAKE_BUILD_TYPE to Debug, but that might affect only the Minetest source and not Irrlicht source. If the cmake setup is done properly though, it will try to use debug Irrlicht too
23:09 PilzAdam     it should be irrlicht-debuginfo
23:09 Taoki        Good, I installed it too
23:12 kahrl        Taoki: you can look at src/CMakeFiles/minetest.dir/link.txt to see the link command it uses
23:20 Taoki        Alright, in valgrind now and making a new log
23:27 Taoki        434 MB, a minute then posting log
23:27 PilzAdam     <PilzAdam> only the part under "HEAP SUMMARY:" is interesting to find memory leaks
23:28 Taoki        will do
23:33 Taoki        Even the text under heap summary is too large to post anywhere...
23:33 PilzAdam     zip it
23:34 Taoki        http://www.sendspace.com/file/3rhaux
23:35 Taoki        Amazing how 6.5 MB becomes 250 KB with one zip
23:36 Taoki        Anbyway it's showing some code functions now. Sure hope it's our memory leak too
23:38 kahrl        most of these leaks seem to be in fglrx_dri.so
23:38 kahrl        these could be the VBOs
23:39 Taoki        The part specifying code functions: http://paste2.org/5U31mtUF
23:39 kahrl        unfortunately fglrx_dri.so seems to have been compiled with something that destroys stack frames (-fomit-frame-pointer?) so the stacktraces aren't helpful
23:40 Taoki        kahrl: Possibly. I assume it's not a fglrx-only issue but could happen with any video driver
23:40 Taoki        I have fglrx from the geeko repository. Only the ATI devs know how they compiled it :P
23:40 Taoki        It's the closed source driver
23:41 kahrl        well how about this solution: 1) apply for a job at ATI, 2) compile a debug build of fglrx_dri.so, 3) ????, 4? profit
23:42 Taoki        It's more likely something between Minetest and Irrlicht
23:42 Taoki        Yeah... what a job as an undercover spy :P
23:42 Taoki        PilzAdam: Any thoughts? Is that being helpful?
23:43 PilzAdam     by 0x584703: MapBlock::reallocate() (basic_string.h:930) <- wtf?
23:44 Taoki        mapgen v7, mentioning just in case :P
23:45 Taoki        Ah, MapBlock. That sounds more related to the problem...
23:48 PilzAdam     "irr::scene::SAnimatedMesh::getMeshBuffer(unsigned int) const (SAnimatedMesh.h:135)"
23:49 Taoki        Doubt that's related, nodes aren't animated meshes
23:49 Taoki        Well, it mentions mesh buffer...
23:50 PilzAdam     I guess kahrl is right
23:51 kahrl        yeah, that particular stack trace looks like leftover data from a previous call
23:51 Taoki        It's strange that fglrx (the video driver) has an importance here. Thought this is an irrlicht issue
23:51 Taoki        No other way to know what causes the leaks?
23:52 kahrl        does the open source driver support VBOs?
23:53 Taoki        Most likely yes. The open-source driver has all features, I only don't use it because it can't handle large textures yet (high-end games lag horribly when VRam is filled and needs to swap ro RAM)
23:53 Taoki        And I'm not switching drivers now... not something I feel comfortable playing with
23:53 PilzAdam     maybe ask some Irrlicht devs?
23:53 kahrl        since the open source driver can be compiled in debug mode it would probably give more helpful stack traces
23:54 Taoki        Well, what to ask them exactly? They don't know the Minetest code
23:55 kahrl        perhaps make an extremely stripped down version of minetest (well, not actually minetest anymore)
23:56 kahrl        which is basically an irrlicht sample that creates meshes in a loop and destroys them
23:56 kahrl        and see if that causes leaks if you set EHM_STATIC and call removeHardwareBuffer
23:58 Taoki        Told them about the problem in short, if anyone's active I'll see what they say
23:58 PilzAdam     what channel?
23:58 Taoki        #irrlicht
23:58 Taoki        Also, something quite interesting: http://irrlicht.sourceforge.net/forum/viewtopic.php?t=37558