| 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/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 |
| 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/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: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/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 |
| 23:37 |
|
sapier left #minetest-dev |
