Time  Nick         Message
00:21 ShadowNinja  ''tell sapier I was having the scaling issues on a Nexus 10, not a Nexus 7.
00:21 HLuaBot      I'll tell that to "sapier" next time I see them around.
08:10 Zeno`        hi
08:14 VanessaE     RealBadAngel: https://github.com/minetest/minetest/issues/1469
08:15 * darkrose   pokes VanessaE
08:16 VanessaE     hey darkrose  :)
08:16 darkrose     hi :)
08:16 darkrose     you poked me a couple of days ago?
08:16 RealBadAngel hi all
08:17 VanessaE     darkrose: yeah, I was trying to see if that was you on a certain 0.4.x server - I assumed not but I wanted to be sure.
08:17 darkrose     yeah, I don't play 0.4
08:17 RealBadAngel VanessaE, one side effect of my changes to cracks, one will be able to disable the effect just by removing (not supporting) the texture
08:19 RealBadAngel so it could be used to speedup the game on slower machines, digging wont be causing meshupdates then
08:19 VanessaE     RealBadAngel: interesting.  well the game will always have the cracks texture anyway so that's no big deal
08:20 RealBadAngel by now the file is required, after it COULD be used
08:20 RealBadAngel and file is supported by game not the engine
08:21 VanessaE     darkrose: that's what I thought.
08:22 VanessaE     RealBadAngel: read the above bug report please.  you fucked up either in lua_api.txt or in the C++ code. :)
08:22 VanessaE     also optional cracks imagery might actually be a good thing in some random game.
08:22 RealBadAngel i already did
08:22 VanessaE     (imagine some game where there's just no need for it)
08:23 VanessaE     oh, so you did :)
08:27 RealBadAngel i want to finish that crack/animation stuff now, then i will fix the trees
08:28 RealBadAngel what im doing right now is makin meshupdates as fast as possible
08:28 RealBadAngel which means all the code that plays with strings, file access etc get kicked outter space from here
08:32 VanessaE     good. :)
08:45 Zeno`        RealBadAngel, I also wondered if ps.next() was intentionally omitted in the first loop
08:46 Zeno`        :range() doesn't update the next random number
08:46 RealBadAngel how im supposed to remember that after year or something like that? ;)
08:46 Zeno`        nfi
08:46 Zeno`        lol
08:46 Zeno`        that's what comments are for :p~
08:47 RealBadAngel random stuff was working correctly but then PA insisted on generating the very same trees depending on seed
08:47 RealBadAngel which is nonsense for me, but i added that
08:47 RealBadAngel maybe then i broke something
08:48 Zeno`        well, I think the seed is correct (just not initialised so it's undefined behaviour) but the chances are definately wrong (>= conditional instead of <=)
08:49 Zeno`        generating the same tree given the same seed would be expected
08:50 Zeno`        It needs to be stressed in the docs though... I suppose I could do that
08:50 RealBadAngel i suck creating any docs ;)
08:52 Zeno`        it's not really nonsense (same seed making same tree) :p Same as rand() will return the same sequence if srand() is given the same seed or not at all
08:53 Zeno`        I think PA was correct in saying that, but yeah
09:15 sapier       seems like mapgen somehow manages to delay mainloop, does anyone know how this happens?
09:16 sapier       result is a runaway mainloop delay causing visible stutter in game
09:16 sapier       as delay builds up to an extent where network packets are dropped
09:18 sapier       you can see it in plain game too, enable profiler, stand still wait till all is done ... them move around and look at incoming packets ... you'll see wholes and spikes in there as packets haven't been handled and get handled at once
09:19 sapier       in a new world of course
09:35 cerulean256  Hi guys, is there a plan regarding how lag is going to be dealt with. It is really a problem when compared to other games like minecraft.
09:36 sapier       read up about 10 lines
09:36 sapier       in history ;-)
09:36 cerulean256  I just joined so I can't
09:36 sapier       http://irc.minetest.ru/minetest-dev/ you can
09:36 cerulean256  ahha.. ok :)
09:37 sapier       short ... seems to be a bug
09:38 cerulean256  a long lived bug :)
09:38 cerulean256  the jumping characters around the map is quite disruptive
09:38 sapier       well that's not really a bug
09:39 cerulean256  I think the discussion of "try to follow someone in minetest" is a perfect example of a problem.
09:39 sapier       that's just result of minetest accepting player position from client and not controling it server side (within boundarys)
09:39 cerulean256  it may be a design choice - hence not a bug - but it may not have been the best choice.
09:40 sapier       maybe but chances to change this aren't that big ... depends on how much needs to be changed of course
09:41 cerulean256  when it comes to player position it would be possible to have the client send the position updates and the server confirm them before updating the other connected clients with the new location
09:42 sapier       that'd increase network load by factor 2
09:42 cerulean256  it may be considered added overhead.... but it should smoothout the gameplay
09:43 sapier       how is this supposed to smooth gameplay? there'd be a change for player itself only but not for others?
09:44 cerulean256  well each update does rely on the client doing some of the work in smoothing things over, like processing the animations, etc. right?
09:45 cerulean256  we could also use TCP and make sure everything arrives in  order and that will smooth the traffic stream substatailly
09:46 cerulean256  substantially*
09:46 sapier       we already ensure everything arrives in order
09:47 sapier       tcp may even increase lag effect as any single client position update has to be received in order to receive the important data
09:47 sapier       and client sends a lot of them
09:47 cerulean256  ok... then why can one follow another player in games like Halflife with little / no jumpiness and minetest not?
09:47 sapier       guess they're smoothing client side
09:48 sapier       and send less position updates then we do
09:48 sapier       but as said that's a guess
09:48 cerulean256  less?? I have to disagree
09:48 cerulean256  it's a shooter.. how would less make the game playable?
09:48 sapier       have you ever had a look at network packets?
09:48 cerulean256  yes
09:49 sapier       client sends tremendous amounts of packets once a player moves
09:49 cerulean256  you mean minetest packets imparticular?
09:49 sapier       that might even be the problem as those packets are passed to each player on server
09:50 sapier       thus multiplying by player count
09:51 cerulean256  but that shouldn't be a problem for server grade hardware
09:51 sapier       it is
09:51 celeron55    if people prefer smoothness in place of low latency, the minetest client could buffer movement data for like a second or two
09:51 cerulean256  are you suggesting that the lag the I see on the nummerous minetest servers out there are just home run vms?
09:51 celeron55    Taoki's post seems to refer to this
09:52 cerulean256  celeron55: I think that would be a nice compromise
09:52 sapier       cerulean256: lots of them
09:52 celeron55    but the real problem is the server's design; all of this are just workarounds
09:52 Zeno`        cerulean256, for the most part, yes
09:52 celeron55    so you have to first choose between whether you want to make a workaround or actually make the server not laggy
09:52 Taoki        celeron55: Yeah, I mentioned buffering movement client-side a few times. IMO that's very necessary to get good movement
09:53 cerulean256  Taoki: I agree with that assessment.
09:53 sapier       I think there are multiple flaws resulting in this issue
09:53 celeron55    it's possible to not make the server laggy, but there's no quick way for achieving that; it's a long process of improving the architecture that has already started
09:53 Taoki        It's good if it already started
09:53 celeron55    the server of eg. quake or stuff like that does almost nothing compared to the MT server
09:54 celeron55    they just check some physics and route position packets around
09:54 Taoki        celeron55: For me it was just a visual problem mostly. But some players said you can't even follow someone else in multiplayer, because the player is seen snapping all over the place. So someone can barely even show you to their house
09:54 Taoki        Yeah... I hope someday we'll have Quake engine quality movement prediction
09:54 celeron55    the MT server runs a huge amount of all kinds of crap that currently interferes with the basic operation like quake's
09:54 cerulean256  celeron55: it's good to know if it's on the roadmap
09:55 cerulean256  Taoki: The "snapping" problem is something I see constantly and even worse.. I'll be building and put down say 20 blocks and the they disappear.. then show up 3 seconds later
09:55 celeron55    so to me this seems that decoupling the basic interaction loop from the heavy lifting should be achieved ASAP
09:55 sapier       one of my next major tasks is spliting game physics from player interaction
09:55 celeron55    that could still imply a year of development though
09:55 Taoki        ouch
09:55 Zeno`        I doubt that many MT servers are running on server grade hardware. Correct me if I'm wrong.
09:55 Taoki        @cerulean256
09:55 Taoki        Zeno`: Not all Quake / etc servers are either
09:56 celeron55    cerulean256: that's caused by the server running some mod code and stopping everything else while doing it, and then resuming from where it left off
09:56 VanessaE     Zeno`: and even if they are, the problem still persists.
09:56 sapier       a year ... yes I was hoping to get it done a little bit more fast but it's in same range I expected it to be
09:56 celeron55    cerulean256: nothing about network or any kind of conventional lag that people generally talk about
09:56 Zeno`        Taoki, true. But I think Quake has movement prediction
09:56 Zeno`        same with projectile paths
09:56 Taoki        true
09:57 sapier       we've got projectile path prediction too ;-)
09:57 cerulean256  what are the minimum system requirement for a good performing minetest server?
09:57 sapier       cerulean256: depends
09:58 sapier       it's more about the mods you wanna run
09:58 cerulean256  related to this discussion ;)
09:58 sapier       for some mods there's no "good enough" hardware
09:58 celeron55    and the amount of players you want to host
09:58 proller      i want 1000
09:59 celeron55    almost any hardware can run a vanilla minetest_game with a couple of players; then everything else is up from there
09:59 Taoki        Also, I think another problem is we don't network movement fast enough perhaps. Server step is still 0.1 I believe. I suggested (and still do) using at least 0.05
09:59 Taoki        I mean does it eat that much CPU?
09:59 celeron55    Taoki: stop talking about that crap; you don't gain anything from it
09:59 cerulean256  if what celeron55 is saying is true about the mods delaying server execution then maybe registering mods with the main minetest loop needs to be done with care by mod developers
10:00 Taoki        aha, ok
10:00 celeron55    Taoki: the only things we need are decoupling of fast and slow processing and better interpolation
10:00 Taoki        I agree about that
10:00 Taoki        Yeah, aht the classic yaw interpolation too heh
10:00 Taoki        **and
10:01 sapier       cerulean256: excactly but most mod developers don't care and blame engine ;-)
10:01 celeron55    cerulean256: yes, writing mods carefully certainly helps; but it's a lot of work
10:01 Zeno`        To be fair, at least some of the blame belongs with the engine
10:01 celeron55    yes, because the engine's job is to make writing content easy
10:01 cerulean256  Zeno`: sure, to a certain degree
10:01 Taoki        Yes, mods also need to be optimized. The engine can't do much if a Lua script is used badly. I always try to optimize mine the most
10:02 Zeno`        I mean the main game loop is 4000 fucking lines long (or something like that)
10:02 celeron55    currently writing processing-heavy content is not easy
10:02 sapier       yes but it's allways gonna be if you abuse tomethin result will be bad
10:02 Zeno`        no scheduling (last I looked), nothing
10:02 cerulean256  celeron55: can you clarify what heavy content is?
10:02 sapier       anything accessing more then one node on map
10:03 celeron55    cerulean256: like a lua-based map generator or a mob mod making heavy use of pathfinding
10:03 sapier       pathfinding for more then about 10 nodes distance will most likely be uusable
10:04 sapier       not in regular case, there it's quite fast, but worst case is the problem
10:04 cerulean256  ok.. here's another question that I haven't even looked at... is the minetest-server multithreaded?
10:04 sapier       that part isn't
10:04 cerulean256  I know trying to code multitrhreaded processes in C/C++ is a bitch :)
10:04 celeron55    some parts are, some aren't
10:04 sapier       and that's the improvement celeron is talking about
10:04 Zeno`        reentrant and mutex-locked code isn't /that/ hard in C or C++
10:05 sapier       Zeno`:  that doesn't help anything if you lock your code down to be singlethreaded again
10:05 sapier       except adding locking overhead
10:05 cerulean256  sapier: :)
10:05 Zeno`        sapier, correct, which is why I mentioned scheduling earlier
10:06 Zeno`        I may be stupid but the main server loop is in my eyes an atrocity
10:07 sapier       yes celeron I know I'm using locks very much too :-)
10:08 sapier       I'd prefere to use "atomic" for most of those locations but as long as we don't have c++11 ...
10:08 sapier       having to protect a variable increment by mutex is just overkill
10:09 sfan5        <sapier> I'd prefere to use "atomic" for most of those locations but as long as we don't have c++11 ...
10:09 sfan5        #if ENABLE_CXX11
10:09 sfan5        do c++11 stuff
10:09 sfan5        #else
10:09 sfan5        do c++03 stuff
10:09 sfan5        #endif
10:09 sapier       I won't do that for sure
10:09 proller      lol
10:09 sfan5        why not
10:09 sapier       cause code will be unreadable
10:10 cerulean256  it'll also become more difficult to maintian in general
10:10 Zeno`        I disagree. Most pre c++11 (or C) code works fine with mutexes and it doesn't cause considerable processing
10:10 sfan5        how about writing a generic class for mutexes, locks, etc. and varying the implementation of those between C++11 and C++03?
10:11 Zeno`        Does the Linux kernel use C++11 atomic ops?
10:11 proller      time to https://github.com/minetest/minetest/pull/1390
10:11 celeron55    mutexes do have overhead; you can only do like tens of thousands of lockings per second with those without making them a bottleneck
10:11 sapier       for sure not kernel is C
10:11 Zeno`        yeah of course there is overhead, but it should not be a bottleneck
10:12 Zeno`        ok, so the Linux kernel doesn't use atomic ops (it may in some places with ASM, but in general no) and it's not what I'd call inefficient
10:13 Zeno`        Anyway, I am tired :)
10:13 Zeno`        maybe that main loop will be looked at one day
10:13 sfan5        so.. does anyone want to react to my suggestion?
10:14 celeron55    sfan5: we have generic classes for those
10:14 Zeno`        sfan5, #ifdef... yuck
10:14 celeron55    sfan5: it's called our fork of jthread
10:14 celeron55    sfan5: so feel free to
10:14 celeron55    as long as you are testing it
10:14 * sfan5      adds to TODO list
10:14 Calinou      <Taoki> Also, I think another problem is we don't network movement fast enough perhaps. Server step is still 0.1 I believe. I suggested (and still do) using at least 0.05
10:15 Calinou      we used to use 0.05, for some time (how much time?)
10:15 Zeno`        I don't agree that using C++11 crap is the solution
10:16 sfan5        who said that it is the solution?
10:16 Zeno`        the solution is to refactor the main game loop so it's not so sequential
10:16 Calinou      cerulean256, map generation can use multiple threads (num_emerge_threads = N where N is number of threads, default is 1), but concurrency often happens and the speedup is small
10:16 Zeno`        sfan5, I dunno :)
10:16 Calinou      (and since there's lots of concurrency, you waste power)
10:16 sapier       nooooooo
10:16 sapier       don't use emerge thread multithreaded
10:16 sapier       it's broken
10:16 sapier       hmmmm is working on it but it's not completed
10:18 sapier       and won't help too
10:18 Zeno`        many, many, many games are not multithreaded
10:18 sapier       we're working at main server loop but it's nothing that can be fixed in no time
10:19 Zeno`        I will bet $1 that changes to the main server loop will/can solve 90% of the problems
10:20 Calinou      …and by tweaking server settings
10:20 sapier       and cause about 20% new issues
10:20 Calinou      http://paste.ubuntu.com/7784138/
10:20 Calinou      (-:
10:20 Calinou      tweak max block sends depending on your bandwidth
10:21 Zeno`        if refactoring the main server loop causes 20% more issues then that's a problem :p
10:22 celeron55    Zeno`: an MT server without mods doesn't cause "server lag"
10:22 celeron55    Zeno`: mods cause it by doing a lot of processing during a single tick
10:22 sapier       if refactoring means just moving aroun then it's not gonna fix any issue too
10:22 celeron55    they run in the same thread
10:23 Zeno`        fair enough then
10:23 sapier       I was talking about spliting async (player related) from sync(mod/game/world) stuff
10:23 Zeno`        and I didn't mean "just moving stuff around"
10:23 celeron55    really the only built-in heavy processing on the server is the map generator / loader, which is run in a separate thread for that exact reason
10:23 Zeno`        but I guess moving stuff around would at least make it more comprehensible heh
10:23 sapier       and mods ;-)
10:24 Zeno`        I refuse to blame the mods
10:25 Zeno`        Mods are an integral part of MT... to blame them is kind of passing the buck
10:25 celeron55    sapier: yes, mods, that aren't run in a separate thread
10:25 celeron55    Zeno`: knowing an issue doesn't mean blaming anyone
10:25 sfan5        we should really add threading for lua
10:25 celeron55    Zeno`: this is a completely objective thing
10:25 Zeno`        that might help yeah
10:25 Zeno`        celeron55, maybe
10:26 celeron55    sfan5: only if it's done properly with added locks in the engine so that it isn't effectively singlethreaded if any api calls are made
10:26 sfan5        yeah, otherwise there wouldn't be any benefit
10:26 celeron55    this is again what sapier is aiming for
10:26 celeron55    and which will take long to achieve
10:27 sfan5        goal for 0.5.0?
10:27 sapier       nope
10:27 celeron55    no goal
10:27 sapier       it's a evulutionary process
10:28 sapier       if I change it once everything will be broken
10:28 sapier       my next step towards is adding async api for mods (quite limited in first step but already helpfull for mapgens)
10:29 sapier       as a mapgen doesn't need to interact to map while generating it this can be done completely async
10:30 Zeno`        why not take a step back before doing that?
10:30 Zeno`        I agree that that is a good thing to do, but... hmm
10:31 Zeno`        Even if there is a penalty (speed-wise) for refactoring that horrible main loop I'd do that first
10:31 sapier       because I do this in my freetime and fixing it is about half a year full time work
10:32 Zeno`        I understand that completely sapier and am truly grateful. I did not mean to imply otherwise.
10:32 sapier       guess how long it's gonna be broken if you try to do that much work in free time ;-) ... minetest will work again in ... hmmm ... 2016
10:33 sapier       I know this isn't perfect but as long as there's noone having that much time available
10:34 Zeno`        I didn't mean to offend, honestly. I just say it as I see it (without consideration of the things you rightfully mention heh)
10:34 Zeno`        Maybe I'll rewrite the loop *shrug*
10:35 Zeno`        I don't need to sleep anyway
10:36 sapier       for this point we know what to do for about a year now
10:36 sapier       ok last half year was spent for getting android port fly ... anyone willing to polish it? so I can focus on server improvement?
10:40 Zeno`        I'll call my for ZenoTest!
10:40 Zeno`        fork*
10:40 Zeno`        android? errr. /me hides
10:43 RealBadAngel sapier, i will take care of opengles shaders, for sure
10:45 celeron55    there's probably infinite polishing in it, i can't really suggest anything as i am not in the target audience
10:45 celeron55    well i can suggest not focusing on it anymore
10:46 celeron55    maybe try to fix things based on user requests
10:50 sapier       actually that's been my current plan to, fix the bugs but don't do changes like "improved controls" or things like that
10:51 sapier       e.g. a new main menu for small devices would be nice too but I don't think it's fun to play on those devices anywa
10:51 sapier       y
11:01 sfan5        >maybe try to fix things based on user requests
11:01 sfan5        this is a very good idea
11:01 cerulean256  Minetest on PC is best!
11:01 cerulean256  :)
11:02 sfan5        request after building bridges over lava for 6 hours: if I place a node somewhere it should stay there and not momentarily disappear
11:02 sapier       the difference between what you understood and what is meant is "fix" isn't same as "implement" sfan5 ;-)
11:03 sfan5        ik
11:04 sapier       if someone complains "hey my icons are messed up" I'll fix it for sure but if it's "hey controls aren't same as in xzy" ... nope
11:05 sapier       btw can someone reproduce ShadowNinja's issues on Nexus10 and Nexus7? at least on emulator with nexus7 skin (new variant) it doesn#t happen
11:05 Zeno`        my icons are messed up
11:05 sapier       cleanup your desktop ;-P
11:06 Zeno`        oh
11:06 Zeno`        yes, good point
11:06 sapier       no without joking is there a issue with minetest? ;-)
11:06 Zeno`        nope :)
11:07 sfan5        sapier: yes, icons are messed up on windows
11:08 sapier       sfan5 a screenshot would help ;-)
11:08 sfan5        the inventory image for cobble is just blank
11:10 sapier       any errors in log?
11:14 sfan5        no
11:18 sapier       what graphics card?
11:19 sfan5        AMD
11:19 sfan5        with Direct3D9 btw
11:23 sapier       hmm
11:24 sapier       other inventorycubes are ok?
11:25 sfan5        sometimes, sometimes not
11:26 sapier       hmm sadly my invenctorycube render fix for android isn't compiled on pc
11:26 sapier       tile.cpp L832 you could try to compile this on py and then set "inventory_image_hack" to true in config
11:27 sfan5        I'll consider that
11:30 Zeno`        Is inventory pronounced "invent oree" or "inven toree"?
11:32 Zeno`        "invent oree" would suggest a list of items that you invent things with
11:32 Zeno`        "inven toree" would suggest... I dunno
11:33 Zeno`        or isn't it important?
11:36 Zeno`        Maybe it's like "factory" which has nothing at all to do with facts (it stems from "manufactory")
13:04 sapier       >>>// Reset periodically to workaround for some bugs or stuff<<<<  I hate comments like that causing bugs to be hidden instead of fixed
13:05 sapier       in this special case we send map to player each 20 seconds ... no mater if necessary or not
13:32 celeron55    sapier: it's not exactly for bugs, it's more about the quirks of the design of the algorithm
13:33 celeron55    and, well, implementation too; it's just not designed or implemented to be perfect
13:34 sapier       I'm not quite sure but what I think this was necessary because of player modifications may not have been sent soon enough
13:34 sapier       at least that's my current state of investigation
13:34 celeron55    wait, where is that comment
13:34 sapier       code detecting which blocks to send next
13:35 celeron55    yes it's where i thought it is
13:35 sapier       I think if I mark blocks modified by player and queue them prior doing the geometry based sending that hack might be unneccessary
13:36 celeron55    if you want to remvoe that, then it needs proper and solid reset mechanisms for when map has been generated in the area it has skipped, when the player has moved a large distance (i don't know about the exact details involved in doing this) and so on
13:36 celeron55    it just forces the algorithm to restart to catch all possible things it might not be accounting for
13:36 celeron55    which in my opinion is the right thing to do instead of making it fail if someone has forgotten to account for some situation
13:37 sapier       right now that code results in nodes having been dug reappearing and vanishing
13:37 celeron55    because there are many rare and extremely hard to test situations it can run into
13:38 celeron55    that isn't a problem in the algorithm
13:39 sapier       it seems to me like node mofifications not getting accounted soon enough
13:39 celeron55    the correct way to fix that is not to remove the ability to send blocks near the player in situations where it is actually needed
13:40 celeron55    but by doing something else to disallow it handling the state in two places and then mixing them up
13:40 celeron55    including block modification timestamps in the protocol comes to mind
13:40 sapier       player moving wouldn't be a problem as this can be detected ... not generated blocks ... puuhh not sure about that one
13:41 sapier       when you say blocks you really mean blocks and not nodes true?
13:42 sapier       I don't really understand "(15:39:25) celeron55: the correct way to fix that is not to remove the ability to send blocks near the player in situations where it is actually needed" who does remove the ability to send blocks?
13:43 celeron55    the issue likely is that when the client is placing nodes, it predicts the placement; then the server may have been doing something during that time and as a result of that, it for some reason sends and updated full mapblock to the client not yet containing the placements made by the client to it; then it proceeds to read what the client placed and handles them in whatever way it does it
13:44 sapier       maybe but that's not what I experience, I dig a lot of nodes in creative mode
13:44 celeron55    and the client does not know that its actions weren't yet accounted on the data it received while it received the data after its actions
13:44 sapier       on network I see client sending the interact packets as I dig,
13:44 sapier       but block updates are somehow stuffed
13:45 celeron55    what?
13:45 sapier       I get wholes in update stream ... most likely due to congestion as block information is sent on low priority
13:46 sapier       making the issue even worse
13:46 sapier       basicaly I need a way to handle player originated block changes at higher priority then regular map transmission ... well that's my current working thesis
13:47 celeron55    oh, so the block update is de-synced from the single-node digging updates and then the client receives it late from some congestion buffer?
13:47 sapier       yes
13:47 celeron55    this is very likely to be fixed with modification timestamps
13:47 sapier       ok "yes" as I know so far
13:48 sapier       but I'd either have to sync them client server or stop player from changing a block till I got result ... last one is quite laggy
13:48 celeron55    this is actually caused by your network changes, because the previous code didn't send anything with differing priority
13:49 sapier       I know :-/
13:49 celeron55    it might need some weird way of merging past changes into data that is newer than the past changes
13:49 celeron55    or you could be lazy and just disable differing priorization
13:49 sapier       yes but that'd reintroduce lag
13:49 sapier       well another sort of lag
13:50 celeron55    so the client needs to be able to see "oh i applied these updates to this block already, but the server is now telling that the block actually was this way so i'll apply all nodes from this block except the ones i updated after its timestamp" 8)
13:50 sapier       that's why I prefere to move the player originated changes ot a higher priority .... as it's supposed to be, sadly for blocks it's not that easy to decide
13:50 sapier       actually server doesn't even send an update if it's fine
13:51 sapier       making it even worse as the outdated block is visible on client till next regular update is received
13:51 celeron55    usually diggings and placings are handled as single-node updates but we always need to have a functional fallback case of updating the whole mapblock if there is no single-node packet for doing the needed synchronization that the action caused (it can cause anything)
13:52 celeron55    and that reset in the block sending code enables us to see the bugs in this system
13:52 sapier       for what I've seen that's not correct, client sends single node updates yes
13:52 sapier       but server sends whole block if the result is not as expected by client
13:52 sapier       for digging
13:53 sapier       haven't had a look at placing by now
13:53 celeron55    yes, that's how it works
13:53 proller      want commit  https://github.com/minetest/minetest/pull/1390
13:54 sapier       I think I know what to do, serve remembers what blocks are on wire, in case a player modifies a block on wire we need to send it too even if the result is as expected
13:55 celeron55    could work
13:55 sapier       I'll try it that way
13:57 celeron55    proller: the comments in there seem somewhat reasonable
13:58 proller      nobody never use it
13:59 proller      its outdated and useless
13:59 celeron55    i think the indev mapgen should be removed too if math is removed
14:00 proller      its other pull
14:01 proller      i can remove both
14:02 celeron55    hmmmm: https://github.com/minetest/minetest/pull/1390
14:03 proller      and https://github.com/minetest/minetest/pull/1407
14:06 hmmmm        sounds great
14:07 proller      merge?
14:10 hmmmm        yep
14:10 proller      both?
14:10 hmmmm        yep
14:10 proller      okay
14:16 sapier       celeron55 thanks for discussing that issue just flaging a block being transmitted solves the issue on digging and is way less change then what I first wanted to do :-)
14:19 sapier       I'll check placing too
14:24 sapier       that's strange ... for placing logic is exactly opposite, if there's a prediction block is sent, if not, we'll wait for at max 20 seconds
14:24 proller      done
14:25 sapier       are you done with removing your work by now proller? ;-)
14:26 proller      maybe need to remove json lib too
14:26 proller      but..
14:26 proller      sapier, write small xml replacement please
14:26 sapier       nope not my issue
14:46 sfan5        proller: not XML
14:46 sfan5        xml sucks
14:46 proller      mtml
14:47 sfan5        how about YAML?
14:48 kahrl        isn't YAML = JSON + stuff?
14:52 sfan5        yes
14:59 sapier       I don't see any reason to do any work just because of "proller wants to extinguish his help"
15:01 proller      but json is too bad
15:02 sapier       bad ... yes ... bad enough to justify the work? ... no
15:16 sfan5        so.. what about merging https://github.com/minetest/minetest/pull/1461 ?
15:17 sapier       did you check it with all those databases?
15:19 proller      whats about disabling compression for leveldb
15:19 sapier       for what reason?
15:21 sfan5        sapier: yes, I even tested migration
15:21 proller      leveldb compress data
15:21 proller      block->searialize too
15:21 proller      why to compress 2 times?
15:22 sapier       serialization does compress block?
15:22 sfan5        only node data
15:22 sfan5        nothing else is compressed by ser.
15:22 sfan5        leveldb can still compress things like node mappings
15:23 proller      so mt compression  must be disabled when use leveldb
15:24 sfan5        why?
15:25 proller      because leveldb will compress anything
15:30 sapier       if there's a resonable amount of additional data to nodes that might still be acceptable
15:32 sfan5        sapier: can we merge #1461 then?
15:35 sapier       ok merge it
15:36 * sfan5      yays
15:38 sfan5        k, pushed
16:15 hmmmm        lol
16:15 hmmmm        in a random text file I have "minetest TODOs"
16:15 hmmmm        that obviously hasn't been updated for about a year
16:15 sapier       just for curiosity what's been on that list? ;-)
16:16 hmmmm        "TODO:  Un-fuck proller's getHeat/getHumidity bullshit; define an 'unset' value to use as a placeholder when weather is disabled"
16:16 hmmmm        "look into possibility of removing client-side knowledge of heat/humidity"
16:18 sapier       guess that's been done
16:19 hmmmm        ehm.  I have an entirely different list of personal todos now, namely "merge some initBlockMake tasks into finishBlockMake"  "add a std::set containing the chunk positions currently being generated or queued"
16:19 hmmmm        once this moving BS is done I should be able to finally make progress
16:20 hmmmm        I am glad Freeminer exists as an outlet for features we don't think fit into minetest or have poor implementations well below standards
16:23 sapier       well if fm was lgpl I'd agree but the way it it now it's quite annoying
16:24 hmmmm        there are a couple memory leak fixes that are great to backport but for the most part I don't feel like it affects us too much
16:24 hmmmm        and again, we can circumvent that problem by doing a clean-room implementation of the same fixes by having one person describe the issue and somebody who hasn't seen freeminer's code fix it
16:25 sapier       puuhh ... sounds like a lot of work ... ;-)
16:37 BlockMen     sfan5, https://github.com/minetest/minetest_game/issues/273 im fine with. but please not with fencelike drawtype
16:37 hmmmm        so anyway I've settled on a bloom filter to store blocks generated in memory
16:38 hmmmm        only issue is you can't unset elements, but that's O.K. because you're almost never deleting a block from the database, and if you are, the performance penalty of having to do the actual fetch is worth it
16:39 hmmmm        thing is, now I need to compare it to the performance of the various databases doing a query to see if the block is simply present or not
16:39 BlockMen     nore, since all other but not you answered: i think a darker steel texture makes it harder to differ between the stone and steel tools.
16:40 BlockMen     and if you/all want those darker texture change all steel-ting textures aswell before mergin
16:41 nore         hm... hadn't thought about the tools
16:41 kaeza        regarding fences: would it be possible to adapt the collision box to fit the node box (and optionally make it so you can't jump over fences?)
16:42 kaeza        ?>>1
16:42 nore         but anyway, I don't have opinion on dark/light textures being better than the other
16:43 BlockMen     kaeza, you can already add a nodebox to def to prevent jumping over it
16:43 kaeza        BlockMen, hm?
16:43 BlockMen     IIRC PA did that in minitest
16:44 kaeza        BlockMen, yes, but the collision is still kinda "full-node"
16:44 kaeza        +box
16:44 kaeza        i.e. you can't actually go near the fence
16:44 kaeza        I was saying something like xyz's xfences
16:45 kaeza        (but those are implemented kinda like mesecons wires/technic cables)
16:45 BlockMen     kaeza, oh. umm...try out? ;)
16:45 BlockMen     maybe it uses the nodebox at all for collision detetction then
16:46 kaeza        MT doesn't compile under cygwin :/
16:47 kaeza        or rather, it requires a high amount of hackery in the Irrlicht makefiles
17:53 crazyR_      did someone create a swim model for minetest?
17:53 crazyR_      i remember it but cnt remember where i saw it
17:54 LemonLake    just get lay and rotate it 180
18:23 sapier       https://github.com/minetest/minetest/pull/1475 is supposed to fix most of the creative node digging lag
18:24 sapier       not exactly all as the updated block is still sent after receiving ack for "on wire" block
18:58 ShadowNinja  I got this message about the launchpad builds, can someone more knowledgable with launchpad fix this?: http://pastebin.ubuntu.com/7785873/
18:59 ShadowNinja  It seems like you just have to increment a revision mumber and initiate a re-build.
19:59 celeron55    sapier: at least one comment is quite inaccurate
19:59 celeron55    sapier: "make sure client knows this block was updated"
20:00 celeron55    that's not really a useful comment at all
20:00 celeron55    also client->SetBlockUpdated is a bad method name
20:01 celeron55    actually, the method name might be fine, but it needs a comment to describe what it exists for
20:02 celeron55    the comment in where it is used from should say something like "make sure to re-send block to client in case outdated data is still being sent on the wire"
20:03 celeron55    otherwise it's just wtf and nobody will understand why it's there
20:10 sapier       ok I'll change the comments
20:11 sapier       what about calling the function "MarkBlockUpdated"?
20:12 sapier       or better NotifyBlockModified
20:13 Megaf_       [17:12:50] <Megaf_> sfan5; sapier; Can you please make a link that points to the latest Androids builds?
20:13 sapier       they're released ;-)
20:13 sapier       github releases
20:17 Megaf_       sapier; I mean, something like, http://downloadlink,com/latestx86.apk
20:17 Megaf_       and latestarm.apk
20:18 Megaf_       like the builds for windows here http://minetest.megaf.info/index.php?id=download-minetest
20:19 Megaf_       ^ PenguinDad
20:20 Megaf_       Like this http://sfan5.pf-control.de/minetest-builds/latest.php?b=minetest
20:20 Megaf_       but for apks
20:52 sapier       why?
20:52 sapier       there's no newer version
20:52 sapier       once there's something usefull I'll build a new version but by now there is none
20:55 sfan5        <BlockMen> sfan5, https://github.com/minetest/minetest_game/issues/273 im fine with. but please not with fencelike drawtype
20:55 sfan5        why not?
20:56 VanessaE     sfan5: I dunno what BlockMen has in mind but I could see a "jersey wall" type of "fence" being useful perhaps, if made of cobble.
20:56 sfan5        "jersey wall"
20:56 VanessaE     http://static.artfagcity.com/wordpress/wp-content/uploads/2012/05/new_jersey_barrier_2000.jpg
20:56 sfan5        whats that?
20:57 VanessaE     it's a type of barrier commonly used to separate two sides of a high-speed motorway
20:57 sfan5        ah
20:57 VanessaE     something like this, made of cobble, might make sense perhaps
20:57 VanessaE     if the cobble were combined with some kind of mortar in the crafting recipe anyway
20:58 sfan5        what I want is something like those stone things in MC
20:58 VanessaE     those stone things?
20:58 sfan5        I don't want a thing this 'heavy' to seperate a walkway from lava..
20:58 sfan5        ..
20:58 sfan5        http://minecraft.gamepedia.com/Cobblestone_Wall
20:58 VanessaE     ah
20:58 VanessaE     I think the castles mod has something like this
21:04 VanessaE     hm, no.  strike that, it doesn't.
21:04 VanessaE     still, I like that general idea, but honestly not that form.  it's too medieval imho