Minetest logo

IRC log for #minetest-dev, 2014-07-14

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:00 ImQ009 joined #minetest-dev
00:00 ImQ009 joined #minetest-dev
00:04 sapier left #minetest-dev
00:07 us`0gb joined #minetest-dev
00:32 Robby joined #minetest-dev
01:04 kaeza joined #minetest-dev
02:06 Miner_48er joined #minetest-dev
04:29 diemartin joined #minetest-dev
05:27 kahrl joined #minetest-dev
05:44 Hunterz joined #minetest-dev
06:01 deltib joined #minetest-dev
06:12 LemonLake joined #minetest-dev
06:43 yaman_ joined #minetest-dev
06:56 proller joined #minetest-dev
07:07 nore joined #minetest-dev
07:12 Calinou joined #minetest-dev
07:15 proller joined #minetest-dev
08:20 Krock joined #minetest-dev
08:27 CraigyDavi joined #minetest-dev
08:30 OldCoder joined #minetest-dev
08:58 Garmine joined #minetest-dev
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:06 Anchakor_ joined #minetest-dev
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)
09:12 proller joined #minetest-dev
09:32 pitriss` joined #minetest-dev
09:32 Ritchie_ joined #minetest-dev
09:33 Robby joined #minetest-dev
09:47 proller joined #minetest-dev
09:52 troller joined #minetest-dev
09:53 vifino joined #minetest-dev
09:56 PenguinDad joined #minetest-dev
10:00 Garmine joined #minetest-dev
10:23 CraigyDavi` joined #minetest-dev
11:05 CraigyDavi joined #minetest-dev
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 Jordach joined #minetest-dev
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
11:51 ImQ009 joined #minetest-dev
11:52 CheapSeth joined #minetest-dev
12:07 Megaf joined #minetest-dev
12:10 SmugLeaf joined #minetest-dev
12:12 Megaf joined #minetest-dev
12:18 PenguinDad joined #minetest-dev
12:19 Megaf joined #minetest-dev
12:19 PenguinDad joined #minetest-dev
12:46 jojoa1997_ joined #minetest-dev
13:12 AnotherBrick joined #minetest-dev
13:20 vifino joined #minetest-dev
13:41 CraigyDavi` joined #minetest-dev
14:28 LemonLake joined #minetest-dev
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.
14:50 Calinou joined #minetest-dev
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/v​iewtopic.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
15:37 rubenwardy joined #minetest-dev
16:06 zat joined #minetest-dev
16:07 Hunterz joined #minetest-dev
16:52 Krock https://github.com/minetest/minetest/pull/1483
17:07 rubenwardy joined #minetest-dev
17:32 Garmine joined #minetest-dev
17:49 grrk-bzzt joined #minetest-dev
17:55 Zefram_Fysh joined #minetest-dev
18:32 smoke_fumus joined #minetest-dev
18:34 rubenwardy left #minetest-dev
18:37 ImQ009 joined #minetest-dev
18:42 Megaf joined #minetest-dev
19:20 proller joined #minetest-dev
19:23 Miner_48er joined #minetest-dev
19:23 Kray joined #minetest-dev
19:36 sapier joined #minetest-dev
19:49 nore joined #minetest-dev
19:49 iqualfragile joined #minetest-dev
20:33 AnotherBrick joined #minetest-dev
20:35 Megaf_ joined #minetest-dev
20:37 Megaf joined #minetest-dev
21:47 nore joined #minetest-dev
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:54 Kray joined #minetest-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/com​mit/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:13 hmmmm joined #minetest-dev
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/m​inetest/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
23:37 sapier left #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext