Time  Nick        Message
09:04 Krock       So. I scrolled through github and noticed myself some issues and pull which can be (merged and) closed
09:04 Krock       #1471, #1354, #1339 (can be added with a mod if required), #1328 (done in Lua), #1263 (fix referenced), #1232 and #1189 (ok to merge)
09:09 VanessaE    1354 can't be closed.
09:09 VanessaE    it's a bug, regardless if sapier thinks it is or not.
09:10 VanessaE    (and if it's not, it's the result of undocumented behavior)
11:14 VanessaE    Taoki: *poke*
11:14 Taoki       hi
11:14 VanessaE    Taoki: idea for the colored fog I wanted to bounce off of you...
11:15 Taoki       ok
11:16 VanessaE    I was at the lake just the other day, really REALLY foggy day, looked like one of those "the map refuses to load" situations in Minetest, like I could only see 40m in front of me ;-)
11:16 VanessaE    it was just at sunrise, and the color of the fog made me think,
11:16 VanessaE    you should fade the color toward greyish-blue (but much more grey than it ever was in the past) the closer the player's view range is.
11:17 VanessaE    the fog was so thick that the sunrise's color was simply drowned out by the fog itself
11:18 VanessaE    visibility was maybe half a kilometer, what in minetest would look, like I said, maybe 40-50m
11:18 Taoki       Hmm. This still looks better for Minetest I think. Although tonemaps color the fog too, so this is possible if you make a foggy game or can change them on the run
11:19 VanessaE    so I was thinking, as the player's view range gets foreshortened, the fog could just start to go grey - but how grey and how fast it gets there is a matter of debate
11:43 * VanessaE  sulks
11:43 VanessaE    I thought it was a good idea :P
11:48 Taoki       I'll keep it in mind. But maybe with a mod for tonemaps
11:50 VanessaE    how would that work?
11:50 VanessaE    this would be client-side, and realtime
11:50 VanessaE    based on the current view range
14:36 VanessaE    sapier:  reported by Krock, client shows *CDP for the flags for all servers in the Public server list, regardless of what their actual properties are in the master list.  Just checked and this happens with current HEAD also.
15:00 Krock       https://github.com/minetest/minetest/pull/1480
15:11 nore        bug: with android, inventory images are upside-down
15:12 VanessaE    nore:  turn on the inventory image hack.
15:12 nore        what is that?
15:12 VanessaE    inventory_image_hack = true  in minetest.conf
15:12 VanessaE    uses an alternative way to generate inventory cubes
15:12 VanessaE    some sort of screenshot-based method I think
15:13 VanessaE    he added that feature for just that sort of situation
15:13 VanessaE    "inventory_image_hack = true (in case you have broken inventorycubes, PLEASE TELL ME ABOUT YOUR DEVICE)"
15:13 VanessaE    https://forum.minetest.net/viewtopic.php?f=3&t=9389
15:21 nore        hm... still upside-down
15:23 nore        well, it isn't exactly upside-diwn
15:23 VanessaE    it's inside-out.
15:23 nore        I don't see the correct faces (i.e, I see *bottom of node*)
15:23 VanessaE    I know
15:24 nore        with image_hack, the bottom is at the top
15:24 VanessaE    I've seen that same effect on my device before, and on some other users' screenshots of buildcraft et al. in the past
15:24 VanessaE    (without image-hack that is)
15:24 * nore      doesn't understand
15:24 nore        ^ that is with image hack
15:25 VanessaE    it was like this:  https://github.com/minetest/minetest/issues/1478
15:25 VanessaE    nodes int he inventory were behaving like this entity here.
15:25 VanessaE    in the*
15:26 nore        same result without the image_hack
15:27 nore        except that I see the visuals in the bottom-left corner instead of the middle of the screen
15:27 nore        also, the furnace hasn't buggy transparent pixels (without the hack)
15:28 nore        and it's really upside-down
15:28 nore        (see the circular saw for example)
15:28 nore        that's *not* inverted backface-culling
15:29 VanessaE    screenshot:?
15:29 VanessaE    I gotta see this :)
15:31 nore        (see also the problem with the inventory image of glasslike nodes)
15:32 VanessaE    whoa wtf
15:33 VanessaE    that would be almost funny if it weren't such a usability issue; note the water turbine also (first row, 3rd from right)
15:33 nore        (the technic machines are also quite funny to look at)
15:33 nore        have you seen the problem with the glass too?
15:34 VanessaE    yeah, many empty nodes here, sand some are garbage, as in the craft guide at the left
15:34 VanessaE    and*
15:34 nore        yep, that's supposed to be glass
16:52 Krock       https://github.com/minetest/minetest/pull/1483
21:53 Zefram_Fysh I found a bug that causes timers to sometimes miss a time step, and so run more slowly than intended.  patch at http://paste.scsys.co.uk/408408
21:53 sapier      timers are not guaranteed to hit
21:53 Zefram_Fysh in what form should I submit the patch?  I don't use github, because it has bad terms of service, so can't submit an issue ticket or a pull request there
21:54 VanessaE    Zefram_Fysh: you just did.  sapier is a core dev.
21:56 sapier      not sure if that fix is ok if I recall correct that might result in a nil access
21:57 Zefram_Fysh the intent of the timer code is obviously for the timer callback to run at the next global step after its time has expired.  sure, steps can be larger than desired, so making timers not fire in a guaranteed time, but that's not the bug here
21:58 Zefram_Fysh the timer loop as it exists currently actually fails to decrement some timers' TTLs for some global steps.  my fix makes the loop iterate through pending timers more reliably, so that it decrements all the TTLs
21:58 sapier      true they should hit by some time
21:58 Zefram_Fysh how could it result in a nil access?
21:59 sapier      I'm not quite sure let me check something
21:59 Zefram_Fysh I don't see any new scope for a nil to arise
22:01 sapier      I do similar thing in mobf and there it seemed like #something is evaluated a single time only
22:03 Zefram_Fysh I was a bit surprised that the ipairs() version worked at all.  empirically, the ipairs() loop stops at the reduced top index; it's checking #core.timers each time round
22:04 Zefram_Fysh empirically, "for index, timer in ipairs(core.timers) do ... end" has the same behaviour as "local index = 1; while index <= #core.timers do local timer = core.timers[index]; ...; index = index + 1 end"
22:04 Zefram_Fysh at least in this situation where the loop body can make the table shorter but not longer
22:05 sapier      As I said I know about the # variant crashing
22:05 Zefram_Fysh the effect is that the ipairs() version, in each global step, fails to process (decrement TTL and maybe fire) the timer that comes immediately after any timer that fired in that step
22:06 Zefram_Fysh do you have a way to reproduce the crash of which you speak?
22:06 sapier      for me it's been removing first element of table within table
22:07 Zefram_Fysh with a while loop?  or was it "for index = 1, #tbl"?
22:07 Zefram_Fysh I'd expect the # to be evaluated only once in that for, but it can't be when it's in the condition of a while
22:07 sapier      https://github.com/sapier/animals_modpack/commit/b877954644c9e9ca6d102c32455a330f003dd798 this is what I did to fix it in mobf
22:08 Zefram_Fysh yeah, that's using # for the top index of a for
22:08 Zefram_Fysh using # in the condition of a while is quite different
22:09 sapier      for what reason?
22:09 sapier      some lua specific thing?
22:09 Zefram_Fysh the condition of a while loop is necessarily reevaluated on each iteration.  that's its purpose, and it necessarily extends to subexpressions
22:10 sapier      but that's supposed to happen on for too?
22:10 Zefram_Fysh the pre-packaged for loop is a different situation.  the details of it differ between languages, but it's certainly possible and sane for the finishing index to be determined once per loop, when the loop is entered
22:11 sapier      exactly so if there's no special language specific reason why for behaves different I'd be carefull with while too
22:12 Zefram_Fysh http://www.lua.org/pil/4.3.4.html specifically says that the indices in the numeric for are evaluated only once
22:13 Zefram_Fysh http://www.lua.org/pil/4.3.2.html isn't so specific about when the while condition is evaluated, but really there's no way while could behave otherwise
22:14 sapier      ok ... another special of lua language I didn't know about till now ... and not something increasing my opinion on lua
22:14 Zefram_Fysh my opinion of lua hasn't been increased today either
22:16 sapier      fixed value for control variables ... tztztz who designs languages like that
22:16 Zefram_Fysh this bug is basically a problem of getting confused by mutating a data structure that other code assumed would stay the same.  it so happens that I ran into it while chasing down a bug in a mod that turned out to be a completely separate case of data structure being surprisingly mutated
22:16 Zefram_Fysh lua relies far too much on data structure mutation for my liking
22:17 sapier      well in lua you have to be quite carefull with "structures" as anything non primitive is basicaly passed by reference
22:17 Zefram_Fysh for the for, I guess you'd prefer the C-style for that decomposes trivially into a while loop
22:18 Zefram_Fysh after so many years of using C, I generally avoid the "from index to index" packaged for loops in other languages.  I prefer the explicitness of the terminating condition and the evaluation semantics
22:18 Zefram_Fysh but I don't think lua is in any way wrong in using once-per-loop evaluation for the limits of its for loop
22:18 sapier      for c I understand but on c++ not having to polute namespace by index variables is quite helpfull ;-)
22:19 Zefram_Fysh well, C++ lets you declare the index valiable inside the for(), giving it limited scope.  that's nice
22:20 Zefram_Fysh anyway, is this the preferred way for me to submit patches?  pastebin and link in this channel?  I have some other patches to propose, and very likely more in the future
22:21 sapier      actually prefered way is git pull requests ;-) but for small things like that I'll just merge it manually
22:22 Zefram_Fysh I also have the changes in a public git repo, and I can point to that.  it's just not github, and the "pull request" would be me saying "please pull from my git repo", rather than the formalised thing that github tracks
22:23 sapier      that's a good way too yes
22:23 Zefram_Fysh I am very happy with git; just not with github
22:24 sapier      please remove the [] from first line of commit message
22:24 Zefram_Fysh huh?  there are no square brackets in my commit message
22:25 Zefram_Fysh do you mean the "[PATCH]" generated by git-format-patch?
22:25 Zefram_Fysh git://git.fysh.org/zefram/minetest/minetest_engine.git is my public git repo.  this change is commit 5322f3d77c278a45274aecc3460fa13bb849bb7f, which you should cherry-pick if you're going that route
22:25 sapier      ok if that one isn't part of the commit message then you don't have to do anything ;)
22:26 Zefram_Fysh git-am should interpret that paste correctly
22:27 sapier      ok I'll merge it tomorrow
22:28 Zefram_Fysh thanks
22:28 Zefram_Fysh in my repo there are three other patches I'd like considered, two of them bugfixes and one a small feature
22:29 Zefram_Fysh commit 35814845f7e08b433cc6d294df472354e25b441a makes tooltip_show_delay=0 work properly
22:29 Zefram_Fysh commit 12c5f8e6408ad2a2d251d7747eeb118cbf6c56ee makes item_image[] in a formspec accept non-integer sizes, as all other formspec constructs do
22:30 Zefram_Fysh commit 727ab558bef8c519b45a375b581e7b598a3970ae makes digging resumable in a limited way
22:30 Zefram_Fysh please consider each of them, when convenient
22:30 sapier      wait wait wait ;-) I can't merge that many commits without review ;-)
22:32 Zefram_Fysh sure.  I don't know what the review processes are like round here
22:33 sapier      not that difficult
22:33 sapier      just some ppl having a look at it
22:34 sapier      sadly small things are usually checked better then big things ... but as we just released we'll have time to fix bugs
22:36 Zefram_Fysh do I need to do anything further to make appropriate review happen?
22:40 sapier      well a github pull request could help ;-)
22:42 Zefram_Fysh as I said, I'm not willing to accept github's terms, so I can't do that bit
22:42 sapier      I understand this but then you can't do much more on your own
22:43 sapier      I'll check those pull requests if they're small enough to decide for me on my own I'll just merge if not I'll have to create pull requests ... will take some time
22:43 Zefram_Fysh ok.  thanks