Time  Nick         Message
00:58 E4xoi        hmmmm: i fail to see your argument against making the code use more OOP features! you know, those features are there for using it!
00:59 hmmmm        ???
04:28 RealBadAngel hi
04:29 RealBadAngel hmmmm, here?
04:29 hmmmm        ???
04:30 RealBadAngel have you tested shaders commit?
04:31 hmmmm        no
04:31 hmmmm        i haven't run minetest in over 2 weeks
04:31 RealBadAngel why so?
04:32 hmmmm        just haven't been doing anything minetest related for a while
04:32 RealBadAngel so you have now opportunity to do something, go test the shaders ;)
04:33 RealBadAngel i really would like to get them merged at least
04:33 hmmmm        oh
04:33 hmmmm        i'll check them out in time
04:34 hmmmm        what do other people say about it?
04:34 RealBadAngel im pretty advanced with another stage and im blocked with previous commit
04:35 RealBadAngel it works flawlessly for whoever tried them
04:35 RealBadAngel i got no error feedback at all since a week or two
04:36 hmmmm        sounds pretty cool
04:36 RealBadAngel sapier, vanessae, nore have tested it
04:38 RealBadAngel this one was mainly glsl commit, now im in core again, rebuilding shader.cpp and dynamic mesh (and shaders) loading
04:38 RealBadAngel and i cant mix those two
04:40 RealBadAngel next commit will move shaders generation from runtime to startup only, unite shaders for terrain, allow other shaders for sky, water and postprocess
04:41 RealBadAngel with what i have already done in shader and mapblock_mesh, my box runs with shaders significantly faster
04:49 RealBadAngel but, back to #1117, title doesnt say it all. this commit is loaded with more stuff
04:49 ShadowBot    https://github.com/minetest/minetest/issues/1117 -- Normal maps generation on the fly. by RealBadAngel
04:51 RealBadAngel it also have bugfix that fixes issue with shaders turning all black on some gpus (nore and sokomine were unable to run shaders at all before)
04:51 RealBadAngel parallax mapping with slope information implemented
04:52 RealBadAngel overriding normal maps, see https://forum.minetest.net/viewtopic.php?id=8714
04:53 RealBadAngel and some speedup fixes in general
04:53 RealBadAngel also it has basics for sun/lighsources calculations
04:54 RealBadAngel so, imho its already worth a few separate commits
04:56 RealBadAngel and to tease you more, you wont get this before it got merged ;) https://www.youtube.com/watch?v=sc3R16QASBY
04:58 RealBadAngel this will become possible when im done with current work
12:49 CheapSeth    Hi
12:58 celeron55    can someone change the thing 1 described here on minetest.net? if not this will serve as a todo item for me after work: https://forum.minetest.net/viewtopic.php?id=8566
13:12 sfan5        celeron55: done
14:04 spillz       @celeron: have you looked at Ubuntu's PPA recipes? just set up an auto import from github to launchpad (that includes the debian stuff) and then you get auto amd64 and i 386 build for all supported Ubuntu versions. you can set up one for stable and one for nightly
14:05 celeron55    spillz: looked at what?
14:05 celeron55    i'm not interested at all in maintaining that ubuntu stuff
14:05 celeron55    i'm every day hoping some ubuntu person will take it and maintain it
14:05 celeron55    and rename it to minetest
14:06 celeron55    everyone in here hates it 8)
14:07 spillz       Maybe i will set something up then. where are the debian files?
14:07 celeron55    they're in some obscure bazaar repository in launchpad
14:07 celeron55    are they publicly visible? i'd guess they are
14:07 celeron55    i can give you membership to the PPA if you want to do stuff
14:09 spillz       Mostly all I am going to do is setup a recipe then hopefully Noone has to worry about it (so long as they keep the debian stuff up to date)
14:09 celeron55    but there already is a stable and daily recipe
14:09 celeron55    how does it differ from that
14:10 celeron55    some random guy set it up years ago and then left
14:11 celeron55    we've been able to keep it working altough probably not up to any kind of actual ubuntu or debian standards
14:11 celeron55    this one, i mean https://launchpad.net/~minetestdevs/+archive/stable
14:31 spillz       Sorry - didn't realize that was already based on a recipe because some Ubuntu's aren't being updated, specifically 13.04 and 14.04 (i have machines running both of these)
14:33 spillz       You already have a debian maintainer right? (i have no interest in being involved in that anal retentive process)
14:34 spillz       Probably a good idea to rename minetestc55 to minetest. That way the new one cleanly replaces the one in the official ubuntu repos.
14:37 celeron55    it's not trivial to rename it because there are reference to the name inside of itself
14:37 celeron55    and also the autoimports are set up by the launchpad staff and something might break, no idea
14:38 celeron55    someone should spam the ubuntu and debian maintainers with emails as long as is needed for them to take that to themselves
14:38 celeron55    and fix it
14:38 celeron55    references*
14:39 spillz       But it's only the recipe that's weirdly named right? the package in the official ubuntu repo is called minetest
14:40 spillz       *recipe, meant ppa
14:40 celeron55    you seem so interested about it that how about you request membership and i allow you to take care of it 8)
14:40 celeron55    i probably hate it more than you
14:42 celeron55    in any case, i have no contacts to any distro maintainer whatsoever; any and all of those are working independently (and it seems like independently of each other too)
14:42 spillz       If I can... let me think about it.at least I can see all of the recipe stuff now.
14:43 celeron55    if you log in there, you get a button that allows you to spam me with an email asking me to click a link, and then you get to change anything you want there
14:43 spillz       The whole maintainer thing is just weird. so often just who has nothing to do with the project,  just apparently good at compiling shit.
14:44 spillz       Just *someone who
14:44 celeron55    yeah it's just random; they also randomly stop updating and then users come to us asking why isn't it updated
14:47 celeron55    unrelated:
14:47 celeron55    i think the forceloading api and implementation is bad and should be at least declared unstable
14:48 celeron55    i started replying to this thread and started looking at what the situation currently is and i can't recommend the api to anyone; it's just too crappy: https://forum.minetest.net/viewtopic.php?pid=133824#p133824
14:49 celeron55    so now i'm probably going to recommend using a voxel manipulator until it's made somehow sane
14:49 spillz       Why is it that more of the world is not in client memory (network overhead?)
14:50 CiaranG      The thing he's talking about here.... https://forum.minetest.net/viewtopic.php?pid=133679#p133679
14:50 CiaranG      is caused by the unloaded blocks bug I fixed recently
14:51 spillz       *client, mean server
14:52 celeron55    CiaranG: it is fully caused by it?
14:53 CiaranG      Yes
14:54 CiaranG      I've seen that lots of times, with my own carts mod
14:54 CiaranG      That's why I fixed it
14:54 celeron55    my reply: https://forum.minetest.net/viewtopic.php?pid=133883#p133883
14:55 CiaranG      I'm not sure force loading or voxelmanip would help anyway - the server things the block is active, so it won't try to load it again. It's a race condition.
14:56 CiaranG      s/things/thinks/
14:59 celeron55    hmm
14:59 celeron55    the voxelmanip will help because it doesn't care about that active block stuff
14:59 celeron55    the forceloading cares and thus might not work, yes
15:13 sfan5        celeron55: why don't we have something like this? https://gist.github.com/sfan5/9586533#file-minetest-patch
15:40 celeron55    it's not good like that
15:41 celeron55    that's an asynchronous call without any kind of callback or indication of when the result is loaded
15:41 celeron55    oh well, i guess polling get_node kind of works
15:41 celeron55    get_node_or_nil*
16:49 us`0gb       proller: I was told you were the one to ask about the Minetest protocol. It's based on UDP, right? And does it have a name? MTP, perhaps?
16:49 proller      why me?
16:50 proller      udp
16:50 proller      wtfp ;)
16:50 us`0gb       I don't know why you. I was pointed in your direction.
16:51 us`0gb       WTFP? Is that our final answer? I'm going to try to implement SERV records.
16:59 spillz       Meant to ask this yesterday... What do you guys think of this? https://forum.minetest.net/viewtopic.php?id=8730
16:59 spillz       Is the intention to merge in a c++ mapper to replace the python?
16:59 sfan5        yes
16:59 sfan5        I think it would make more sense if you would help me with my cpp mapper :-)
17:00 sfan5        https://github.com/sfan5/minetest-mapper-cpp
17:00 spillz       c++ hurts my head more. maybe...
17:01 sfan5        c++ isn't that hard
17:01 CiaranG      spillz: Love the cross-sections :)
17:02 spillz       Not hard, just more of a context switch. I help a bit with Code::Blocks IDE which is mostly C++ but mostly just added stuff for working with python
17:03 spillz       @Clarian: thx. The code to do that is kind of clunky. would want something more elegant for the cpp version
17:05 proller      us`0gb, for name ask celeron55
17:06 us`0gb       celeron55: What is the Minetest protocol called? MTP? WTFP?
17:08 spillz       For cpp mapper I think it would be good to reuse engine code for the db interface. (sfan, i think you said that would necessitate some extra includes, but one way to handle would be to have a minetest dll/so for common components for client/server/mapper)
17:09 proller      maybe include mapper to MT?
17:09 proller      server can save images on block save
17:11 proller      and future - serve this images and player positions from embended http server
17:11 proller      ^ realtime map ready
17:12 spillz       But the server usually only loads bits of map on demand from client and as far as i can tell doesn't keep that much in memory. I think the mapper has different requirements.
17:13 proller      server can serve images of unloaded areas from disk
17:20 sfan5        spillz: the db interface my cpp mapper has is similar to the engines interface
17:24 spillz       sure, but better for maintainability if same.
17:28 spillz       Have you had issue where lookup of db coordinates by x, y, z using the decodeBlockPos and its inverse return the wrong thing? I was having some issue with python equivalents and found it safer to cache the raw id.
17:29 sfan5        no
17:30 spillz       It came up more with cross sections. maybe unrelated bug in my changes...
17:38 celeron55    us`0gb: if you want to have a short name for the minetest protocol, call it mtgp (minetest game protocol) because mtp is "media transfer protocol"
17:39 sfan5        in contrast to mtp mtgp actually works well
17:50 celeron55    us`0gb: also, who told you that you should ask anything about the protocol from proller? that doesn't make any sense
17:51 us`0gb       celeron55: I forget who told me. It was via PM and I don't know how to pull up the chat record unless I already know who I was chatting with.
17:52 us`0gb       Thanks for the info! I'll work on implementing SERV records soon. I hope.
17:53 us`0gb       Actually ... I might be able to find the record in my file tree.
17:54 us`0gb       celeron55: Sokomine told me to ask proller.
17:54 sapier       what do you want to use the protocol fore us'0gb?
17:55 us`0gb       sapier: I want to implement DNS SERV records, so example.net (Minetest) doesn't have to run at the same IP address as example.net (Apache).
17:56 us`0gb       To do that by the books, I need the protocol name.
17:56 sapier       oh I see :-)
17:59 us`0gb       It will fall back to using A records as it does now if the SERV records are not present. Anyone not needing this feature will not need to make any changes to their setup.
19:29 sapier       https://github.com/sapier/minetest/tree/android_3 http://animalsmod.comuf.com/downloads/Minetest-debug.apk now users should be able to respawn on android clients too
19:58 ShadowNinja  hmmmm: Because we don't have fixed-width format specifiers and long long is C99-only.  It's also much easier to read.
20:10 ShadowNinja  RealBadAngel: I tried your shaders patch.  It works pretty well.
21:27 hmmmm        SHadowNinja, yeah I realized that when I saw the commit you reverted earlier on.  that's totally fine.
21:29 hmmmm        I just wanted to make sure it wasn't a commit that only changes style instead of functionality.  those kinds of commits are no good.  whenever somebody makes a commit like that, it's akin to pissing on top of somebody else's dirt mound, and exclaiming "MY STYLE > URS"
21:53 RealBadAngel ShadowNinja, hmmmm so can we get that patch merged ?
21:53 hmmmm        sure
22:22 RealBadAngel ShadowNinja, ok with you too?
22:24 ShadowNinja  RealBadAngel: Yep.
22:24 RealBadAngel ok, will check if its still safe to merge and will push it tonight
22:29 ShadowNinja  RealBadAngel: It applied over my copy, which is very recent.
22:30 RealBadAngel checkin once more wont hurt ;)
22:31 RealBadAngel btw, some1 should code colors for labels, same as for text_area
22:31 ShadowNinja  Better yet: Just rewrite the formspec.
22:31 RealBadAngel oh cmon, not again ;)
22:32 ShadowNinja  Here's what I came up with in terms of design: http://pastebin.ubuntu.com/7127731/
22:35 RealBadAngel basically a table instead of strings, yes?
22:41 ShadowNinja  I'll merge #1180 in a minute if there are no objections.
22:41 ShadowNinja  RealBadAngel: Yes.
22:41 ShadowBot    ShadowNinja: Error: ProcessTimeoutError: Process #564 (for String.re) aborted due to timeout.
22:41 ShadowNinja  Grrr.
22:45 ShadowNinja  https://github.com/minetest/minetest/pull/1180 -- Add a midpoint function to the vector helpers
22:46 celeron55    ShadowNinja: why midpoint?
22:46 celeron55    why not eg. interpolate?
22:46 celeron55    thus allowing the caller to say what factor to use instead your fixed 0.5
22:47 celeron55    i strongly oppose midpoint; it's not any kind of common practice for vector implementations
22:48 celeron55    but i'm fine with interpolate
22:51 Jordach      celeron55, or use midpoint to modify the interpol
22:53 ShadowNinja  celeron55: Good idea.  CiaranG: ^
23:04 CiaranG      Well it's definitely a common practice, otherwise I wouldn't be calling it in 20 different places already
23:04 CiaranG      But yeah, interpolate would be more flexible. I'll change it to that.
23:08 CiaranG      If we're being picky, that whole thing should not be called vector, it should be called vec3d, because it doesn't handle any other kind of vector ;)
23:08 CiaranG      How does ShadowBot manage to interpret 1180 as 564 anyway?
23:09 celeron55    it's a process id
23:09 CiaranG      Oh, lol
23:10 CiaranG      Didn't actually read the message
23:10 ShadowNinja  Fox for #1158: http://ix.io/bbU
23:10 ShadowBot    https://github.com/minetest/minetest/issues/1158 -- Some warning during compilation
23:11 ShadowNinja  Fix*
23:12 CiaranG      So you can do things with this interpolate that are not really interpolating (e.g. by giving it -0.5, or 1.5) - happy with that?
23:16 ShadowNinja  That seems fine.
23:20 celeron55    of course; then it's just extrapolating 8)
23:23 kahrl        vector.interpolate_or_extrapolate_depending_on_the_value_of_lambda
23:24 celeron55    _also_works_as_midpoint_if_value_is_half
23:24 ShadowNinja  CiaranG: getlastcollisionresult <-- This is too squashed.  It should be something like get_last_collision_result.
23:26 celeron55    what
23:26 celeron55    https://github.com/CiaranG/minetest/commit/8a70b8f737d6aad44179416e4c2c5e6683df3c01
23:26 celeron55    why change the returned value to be a parameter?
23:27 celeron55    that makes zero sense
23:27 ShadowNinja  celeron55: It returns a stack variable by reference.
23:28 kahrl        ShadowNinja: where do you see the reference?
23:28 ShadowNinja  +local
23:28 celeron55    and?
23:28 celeron55    of course it does
23:28 ShadowNinja  Hmmm, copies it then.
23:29 celeron55    result should always be returned if possible, it makes better and more understandable code
23:30 celeron55    the C antipattern of never returning anything else than stuff that you would use exceptions for in C++ doesn't belong here
23:31 CiaranG      So if you return it as a value, it has to make a copy of the whole thing
23:31 CiaranG      Including the vector within it
23:32 celeron55    the whole thing, which is like 10 bytes?
23:34 celeron55    also even if you would do it that way, why in hell are you removing the constructor
23:34 CiaranG      And then (because the caller is saving it elsewhere) it would have to make a third copy of it
23:34 CiaranG      That's just silly. If it's 10 bytes (it's more) or 1000 bytes, why not just put it where it's going in the first place
23:36 celeron55    if you can make code that is more reliable and less prone to errors, you should
23:37 celeron55    and more readable
23:37 celeron55    in any case i'm still waiting for an explanation of removing the constructor of a C++ struct that contains uninitialized values
23:38 celeron55    that previously had a constructor
23:39 celeron55    and have you noticed that the thing your commit message refers to is a minor part of the contents of the commit, the larger part not being mentioned at all
23:42 CiaranG      What is the larger part?
23:43 celeron55    the larger part is reworking the collisionMoveSimple interface
23:43 CiaranG      Seriously?
23:45 CiaranG      Slightly changing the semantics of how the value is returned is the major part of the commit, and the feature it adds is the minor part.
23:45 CiaranG      ok
23:46 celeron55    it is, because it's not a strict dependency and consists of a lot of changed lines
23:46 celeron55    in any case, i'm still waiting for an explanation of removing the constructor
23:47 CiaranG      It would have to be duplicated, in order to allow the in-place collisionResult member to be reset
23:47 celeron55    and you are sure that removing it won't cause bugs that will annoy people in the future? i wouldn't
23:49 celeron55    you don't need to duplicate anything if you just call reset() in the constructor
23:49 CiaranG      I guess so, yeah
23:50 celeron55    also, it would be best to move the &result to be within the other output references at the end; generally inputs are first, outputs last
23:50 CiaranG      They are, but the last parameters are optional
23:51 celeron55    hmm, well whatever then
23:51 CiaranG      Inserting it at some random point in the middle didn't seem sensible
23:55 CiaranG      So the only thing I would change is the constructor/reset thing, which you are absolutely right about
23:56 CiaranG      (and the squashed nature of 'getlastcollisionresult' - which was supposed to be consistent with the other get... functions on the luaentity api, which are also squashed)
23:56 celeron55    there are like 2 other squashed names like that
23:56 celeron55    everything else is not
23:56 celeron55    grep get_ doc/lua_api.txt
23:57 CiaranG      all of them except two (on the luaentity)
23:57 celeron55    it should be the long version anyway
23:58 CiaranG      yeah
23:59 celeron55    then there is one thing: it should be commented somewhere that that interface shouldn't be used for checking collision events but only static collision state
23:59 celeron55    for collision events there should be an entity member function called by the engine