Minetest logo

IRC log for #minetest-dev, 2015-07-06

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

All times shown according to UTC.

Time Nick Message
00:04 diemartin joined #minetest-dev
01:33 kaeza joined #minetest-dev
01:48 diemartin joined #minetest-dev
01:55 blaaaaargh joined #minetest-dev
02:14 Zeno` joined #minetest-dev
02:15 kaeza joined #minetest-dev
02:17 * Zeno` slaps kaeza with a large trout.
02:18 kaeza ow
02:18 kaeza sorry about frequent reconnects; stupid mobile network decides to time out every 15 mins
02:19 Zeno` Maybe it's sleepy
02:26 diemartin joined #minetest-dev
02:41 kaeza joined #minetest-dev
02:46 kaeza left #minetest-dev
02:52 RealBadAngel joined #minetest-dev
02:53 * RealBadAngel yawns
02:53 RealBadAngel whats up folks?
02:54 VanessaE hi
02:54 RealBadAngel VanessaE, hi, i managed to fix texture glitches with parallax
02:55 VanessaE told you :)
02:55 VanessaE tape the edges together :)
02:55 RealBadAngel i did
02:55 RealBadAngel but mods will have to tell the shaders if they are using non tiling texture
02:58 RealBadAngel https://imgrush.com/QnUp3FBFt1qF.png
02:58 VanessaE I saw it
02:59 RealBadAngel and?
02:59 VanessaE looks good
03:00 VanessaE except there's this one little glitch ... right...there.
03:00 * VanessaE points at a random spot along a random edge ;)
03:00 RealBadAngel dont even try ;)
03:01 RealBadAngel i got rid with it of enable and disable images
03:02 VanessaE how's that work?
03:03 RealBadAngel wrote a neat piece of code that generates textures with flags on the fly
03:03 RealBadAngel http://pastie.org/10274997
03:04 RealBadAngel atm it only sets one flag, but makes adding new ones trivial
03:08 RealBadAngel and tape n glue code: http://pastie.org/10275002
03:09 VanessaE brb
03:10 RealBadAngel first of all it offsets texture with maximal parallax value, depending on the angle which makes glitch less visible
03:10 RealBadAngel then freezes 1% of the texture near the edges
03:11 RealBadAngel above code is for case the texture is tileable on x, but non tileable on y, like dirt with grass
03:13 Zeno` __shaderFlagsTexture1 is a valid string?
03:13 RealBadAngel for the code to work, nodedefs will have to set tile properties
03:13 RealBadAngel Zeno`, ofc it is
03:14 Zeno` I mean... hmm, how to put it
03:14 RealBadAngel put where?
03:14 Zeno` If another flag was added what would it look like?
03:14 Zeno` I mean I'm not sure how to phrase my question :)
03:14 RealBadAngel __shaderFlagsTexture1011101101 for example
03:14 Zeno` ah ok
03:14 Zeno` cool
03:15 RealBadAngel ofc having 8 flags passed will require 256 textures
03:15 RealBadAngel but thats not that costly
03:16 RealBadAngel 8 flags case will require 1kb of memory for the textures
03:18 RealBadAngel not that much, and im able to pass whatever flags i do need per tile, without further shaders instancing
03:18 Zeno` Oh each is a texture. I get it now
03:19 RealBadAngel http://pastie.org/10275012
03:19 RealBadAngel this is what i do with it inside shader
03:20 Zeno` yep, I understand now. Makes more sense when seen in context
03:21 RealBadAngel adding next flag will be just setting and reading pixel at pos (1, 0)
03:22 VanessaE have you tested this with Havel et al. yet?
03:22 RealBadAngel didnt have to, normalmaps are 256x
03:23 VanessaE er Haven*
03:24 RealBadAngel if you will take a closer look you will see that pixels in the row next to edge (i mean "pixel" sized from 16x16 originals) is slightly bigger than those one in the middle
03:24 RealBadAngel geometry of bump for it is not deformed
03:27 RealBadAngel but to notice you would need to walk around and pick an angle
03:28 RealBadAngel propably best seen when lookin at texture with an zero angle
03:32 RealBadAngel next thing is how we will define tiling in nodedefs
03:34 RealBadAngel seamless will be propably default value, so such nodes will remain unaffected
03:34 RealBadAngel but dirt with grass for example,
03:37 RealBadAngel http://pastie.org/10275029
03:49 RealBadAngel bbl
03:49 VanessaE freeze
03:50 VanessaE you can't go nowhere :)
03:58 Zeno` I'm Ma Baker!
04:01 sloantothebone_ joined #minetest-dev
04:02 prozacgod joined #minetest-dev
04:54 kaeza joined #minetest-dev
04:57 jin_xi joined #minetest-dev
05:13 nore joined #minetest-dev
05:52 Hunterz joined #minetest-dev
06:07 RealBadAngel joined #minetest-dev
06:09 OldCoder joined #minetest-dev
06:30 Calinou joined #minetest-dev
06:46 AnotherBrick joined #minetest-dev
07:28 diemartin joined #minetest-dev
07:35 johnnyjoy joined #minetest-dev
07:36 werwerwer joined #minetest-dev
07:48 asl97 joined #minetest-dev
08:00 Yepoleb_ joined #minetest-dev
08:26 Krock joined #minetest-dev
08:45 Darcidride joined #minetest-dev
08:52 blaze joined #minetest-dev
08:56 Amaz joined #minetest-dev
10:19 Taoki joined #minetest-dev
11:12 diemartin joined #minetest-dev
11:58 RealBadAngel joined #minetest-dev
12:08 julienrat joined #minetest-dev
12:21 proller joined #minetest-dev
12:27 msantana joined #minetest-dev
12:43 julienrat left #minetest-dev
12:45 SopaXT joined #minetest-dev
13:14 sloantothebone joined #minetest-dev
13:20 est31 joined #minetest-dev
13:24 Darcidride joined #minetest-dev
13:27 julienrat joined #minetest-dev
13:33 est31 here it is #2889
13:33 ShadowBot https://github.com/minetest/minetest/issues/2889 -- Client: better m_proto_ver initialisation by est31
13:33 est31 the only point where that value is actually read is "Client::sendChangePassword", where a check with < or > 25 is done
13:34 est31 and I think you are not abled to change your password on just test server because of this bug
13:35 est31 the other point is src/guiFormSpecMenu.cpp
13:35 est31 to check whether we are abled to send a movesomewhere inventory action
13:35 est31 (in proto < 25 that didnt exist)
13:36 est31 it even didnt exist for a long time with protocol 25, but I didn't want to bump the protocol just because of that
13:45 est31 kahrl, can you look at it now? storm should have reached you too by now, with cooler air :)
13:49 est31 btw, hmmm won, I wont push anything to master anymore
13:50 est31 I will create dozens upon dozens of pull requests instead
13:50 est31 going the formal way
13:50 est31 master will be a dead branch
13:50 est31 but I dont give a fuck anymore
13:57 Robert_Zenz joined #minetest-dev
13:58 jin_xi joined #minetest-dev
14:53 hmmmm joined #minetest-dev
15:26 RealBadAngel est, hmmmm have you seen my proposal>
15:26 RealBadAngel ?
15:29 RealBadAngel whatever, i know its a masterpiece
15:37 giacomo986 joined #minetest-dev
15:45 julienrat left #minetest-dev
15:57 OldCoder joined #minetest-dev
16:02 CraigyDavi joined #minetest-dev
16:02 proller joined #minetest-dev
16:08 ElectronLibre joined #minetest-dev
16:10 Amaz left #minetest-dev
16:13 proller joined #minetest-dev
16:15 Lunatrius joined #minetest-dev
16:37 AnotherBrick joined #minetest-dev
17:06 Tesseract Fine if I push this to master?: http://ix.io/jwa/diff
17:07 Tesseract (GetValue is unsafe because the value can change between the two calls, resulting in a long wait)
17:08 Tesseract It seems the semaphore's just used as a "something's ready" variable instead of a resource counter.
17:10 Tesseract And MinimapUpdateQueue is just a MutexedQueue it seems...
17:11 Tesseract This is not how semaphores are supposed to be used.
17:13 est31 joined #minetest-dev
17:13 est31 "And MinimapUpdateQueue is just a MutexedQueue it seems..."
17:13 est31 yes ^
17:13 est31 also true to your "variable" thing
17:13 est31 comment*
17:14 est31 I'd have used a binary semaphore if we had one
17:14 Tesseract JEvent
17:14 est31 but I don't see, how can it be dangerous?
17:14 Tesseract Moment.
17:14 est31 JEvent is just a thin wrapper around the normal semaphore, and doesnt do that emptying
17:15 est31 so if you call deferupdate() twice, it will need two wait() calls to get "blocking" again
17:15 est31 perhaps it uses a "real" event on windows though
17:16 Tesseract est31: http://pastebin.ubuntu.com/11831810/
17:16 est31 there is only one thread accessing that
17:17 Tesseract Also, GetValue is *VERY* slow and hacky on OSX (the other reason I removed it)
17:17 est31 minimap update thread
17:17 est31 you can remove the whole while loop, its not needed
17:17 est31 its only there to spare multiple traversions through doUpdate()
17:18 Tesseract est31: Yes, Event isn't quite right on Linux, but it should be fixed rather than another hack used.
17:18 est31 if we called deferUpdate before
17:18 Tesseract The semaphore should be a counter of the units that need to be processed.
17:18 est31 Tesseract, I havent looked at how it was done on mac or win (isnt there only a posix implementation, linux and mac unified?), only linux
17:18 est31 no
17:19 est31 thats wrong
17:19 Tesseract Why?
17:19 est31 what if you call to stop the thread?
17:19 est31 then it either waits until a new element comes in
17:19 est31 or you will have to raise the semaphore counter
17:20 est31 which is wrong when you look at it the "element counter" way
17:20 Tesseract "action counter" then, with a stop action.
17:20 est31 also, minimapupdate thread does some other business too, not just the queue stuff
17:21 est31 deferUpdate gets called when you change minimap modes for example
17:22 Tesseract Just push a "change mode" event to the queue.
17:22 est31 a stop action should be served right now
17:22 est31 shouldnt be hidden in a queue
17:22 est31 just like change of mode
17:22 Tesseract Then push to the front of the queue.
17:23 est31 its no queue then anymore
17:23 Tesseract deque then.
17:23 Tesseract It would be nice if we could make this lock-free with the semaphore though.
17:23 est31 ?
17:24 Tesseract The current method uses a locked queue.
17:25 est31 yes, you wont get rid of that
17:27 est31 I think we even have a queue with a semaphore somewhere
17:27 est31 still uses a lock
17:28 est31 what if two threads want to put something into the queue?
17:28 est31 same time
17:29 est31 so, I agree, you can replace the queues with mutexed queue
17:30 est31 for mesh and for minimap threads
17:30 est31 also, you can use JEvent
17:30 Tesseract est31: You make sure that the actual insertion is atomic.
17:31 est31 Tesseract, and by what? by using a lock.
17:31 est31 I dont know how I would implement a thread safe insertion routine elsehow
17:31 Tesseract est31: 1-word loads/stores are atomic on most architectures.
17:32 est31 also, you said before you want to put stuff at the front too.
17:32 Tesseract Yes, that part will make it a lot harder.
17:32 est31 Tesseract, which data structure do you want to use? std::deque? is that one thread safe for insertions?
17:34 Tesseract deque will definitely need a lock.  We'd need a custom data structure.
17:34 est31 I dont see a benefit in forcing *everything*, even stop events into the queue.
17:34 Tesseract The lock probably isn't a big issue though.
17:34 est31 whats wrong about updatethread?
17:35 Tesseract For now I'll just fix that loop and maybe switch to MutexedQueue.
17:35 Calinou maybe you want a fade effect
17:36 est31 Tesseract, I dont see any need to fix here.
17:36 est31 its more a cleanup
17:37 est31 the only case that loop can be dangerous is how hmmmm said it, when the production is so fast even that while loop can't empty the semaphore fast enough
17:37 Tesseract est31: The MutexedQueue thing, yes.
17:37 est31 yes that should be fixed probably
17:37 Tesseract Unless you have 2+ consumers.
17:38 Tesseract Although that may or may not be possible.
17:38 est31 yes, but right now we only have one. Its called UpdateThread not updateThreads
17:38 Tesseract Regardless, we won't be able to keep it with my threading fixup.
17:38 est31 why?
17:42 est31 Ah I see you removed the count getter
17:42 est31 well, then make it wait(0) instead
17:43 Tesseract est31: Just look at how GetValue was implemented on Windows and OSX.  On OSX it was actually a global counter for all semaphores!
17:43 est31 eww
17:44 est31 thats a reason I accept
17:49 MinetestForFun joined #minetest-dev
17:50 est31 also, feel free to fix jevent, and use that then
17:50 * est31 is still wondering how Tesseract wants to make an atomic queue insert.
17:51 est31 I mean there are different steps here:
17:51 est31 1. update the "last element" pointer of the queue
17:51 Tesseract est31: Search for "lock-free queue".
17:51 est31 err no
17:52 est31 0. store the "last element" pointer of the queue
17:52 est31 then 1.
17:52 est31 then 2. add your new "last element" to the "next" pointer of your stored "last element"
17:53 est31 if you do 2. before 0, you get in trouble
17:53 est31 if you do it this way, you get in trouble too
18:01 est31 confirmed, some dude on the internet actually claims to have found a way. I have to read it later
18:01 est31 well some dude on the internet can claim alot of stuff
18:02 est31 it has to be read and understood in order to be confirmed
18:02 est31 which happens "later"
18:02 est31 cye
18:02 est31 cya*
18:14 Wuzzy joined #minetest-dev
18:48 proller joined #minetest-dev
20:13 Amaz joined #minetest-dev
20:24 selat joined #minetest-dev
20:49 paramat joined #minetest-dev
20:51 est31 joined #minetest-dev
20:51 paramat hi hmmmm, please could you review this later? #2890
20:51 ShadowBot https://github.com/minetest/minetest/issues/2890 -- Mgv7: Auto-set lowest mountain generation level by paramat
20:52 hmmmm yea i'll take look
20:52 hmmmm busy atm
20:52 hmmmm sorry
20:53 est31 so hmmmm we finally want to the second server
20:53 est31 err
20:54 est31 what I wanted to say was "so hmmmm we finally want to remove rule 1"
20:55 est31 I mean paramat lives without rule 1 very fine too
20:55 est31 he even does PRs.
20:57 hmmmm rule 1?
21:00 JZTech101 joined #minetest-dev
21:11 paramat no problem hmmmmm
21:20 paramat commit rules i guess. erm, i possibly might be a sort-of second mapgen maintainer, and am the maintainer for mgv7 and the current biome API. so yes i sometimes commit alone
21:43 est31 joined #minetest-dev
21:52 kaeza joined #minetest-dev
22:02 err404 joined #minetest-dev
22:14 paramat left #minetest-dev
22:47 diemartin joined #minetest-dev
22:48 hmmmm est31:  i would have to argue that many of paramats commits fall under a trivial exception
22:48 hmmmm they're usually just adjusting a parameter or something - adjusting mapgen parameters might make new maps look a tad uglier, but they're not going to blow up the entire engine
22:49 hmmmm he's definitely allowed to take control of the artistic direction for mapgen v5 and v7 - i am not actively working on v7 and v5 was his to begin with
22:49 est31 I didnt knew paramat uses the first rule too, I have used him as example that you can live without it
22:50 est31 (wrongly)
22:50 hmmmm i don't know the rules by their numbers
22:50 est31 "trivial rule"
22:50 hmmmm i just know what most people agree to at some point
22:50 hmmmm the trivial exception, you mean
22:50 est31 yes
22:51 hmmmm it's not so much a rule as it is an allowance to not totally bring engine development to a halt
22:51 est31 at least you admit
22:51 hmmmm and I'm not liking it as of recently because trivial needs to be better defined
22:51 hmmmm it's being used as an excuse rather than respected
22:52 est31 even if you commit something seemingly trivial, it can blow up
22:54 est31 the problem with PRs is, that they usually don't get merged even the same day.
22:55 est31 some of them stay open for months, even if they do fall under the triviality rule
22:55 hmmmm we're working on clearing it out
22:56 hmmmm we'll do another PR clear-out session tomorrow maybe
22:57 est31 do you want to remove the "trivial" rule?
22:57 hmmmm i'd like to define it better
22:58 hmmmm ugh
22:59 hmmmm it would be so nice to write a lint-like tool to detect if changes are non-trivial or not
22:59 est31 ?
22:59 hmmmm well I can tell you which changes are trivial
22:59 hmmmm - changing a comment
22:59 hmmmm - changing code style
22:59 hmmmm - renaming variables
22:59 hmmmm - changing numeric variables of noise parameters
23:00 hmmmm what else..
23:00 est31 for example, do you think that this was trivial: https://github.com/minetest/minetest/commi​t/96989e0a6aa3ab069b5aeeab44a6280d6d51364a
23:00 hmmmm - changing constant strings
23:00 hmmmm that are meant for display
23:00 est31 what about #2889 is that trivial?
23:00 hmmmm yes, i would consider that trivial
23:00 ShadowBot https://github.com/minetest/minetest/issues/2889 -- Client: better m_proto_ver initialisation by est31
23:01 hmmmm that one, no
23:01 hmmmm absolutely not
23:01 est31 you know where that variable is used?
23:01 hmmmm doesn't matter!
23:01 est31 yes its touching the network
23:01 hmmmm such a change could have dire effects
23:01 est31 but you shouldnt be scared of it
23:01 hmmmm well it's not trivial
23:01 est31 its used at two places
23:02 hmmmm i wouldn't know that it's harmless unless I looked deeper into the code
23:02 hmmmm i.e. not trivial
23:02 est31 I wouldn't know that for mapgen parameter changes either
23:03 est31 changing a siggle number can mean everything is stone now
23:03 est31 single*
23:03 hmmmm so, true
23:03 hmmmm maybe, then...
23:04 hmmmm any changes that modify the functionality are non-trivial, unless you're a subject matter expert in that part of the code
23:04 est31 ^
23:04 werwerwer joined #minetest-dev
23:04 hmmmm then, it's possible that changes to the functionality may possibly be considered trivial
23:08 Niebieski joined #minetest-dev
23:08 est31 perhaps we can adopt a multi-branch development model http://mozilla.github.io/process-re​leases/draft/development_specifics/
23:08 cvtsx1 joined #minetest-dev
23:09 est31 they bind "pushing features" to the lower branches to releases, we dont have to
23:09 est31 also they have multiple branches, we can only have two
23:09 est31 "unstable" and master
23:10 est31 one branch where we can merge PRs to, and non-trivial smaller fixes
23:10 est31 still can be tested by people
23:10 hmmmm call me cynical, but wouldn't that just encourage everybody to move to the unstable version
23:10 est31 another branch which is more stable, stuff only gets merged when its stable
23:11 est31 well they know then what they are into
23:12 est31 this wouldn't make creating bugs not a "how could you?" every time. bugs happen, you have to fix them, not be too frightened to make changes because you want to avoid every bug.
23:12 est31 -not
23:13 hmmmm alright
23:13 hmmmm we could try it
23:13 hmmmm anyway i'm more afraid of people shit-committing poor quality code
23:13 hmmmm it might work but it's extremely sloppy
23:13 hmmmm and because it's committed, people think it's done, and that's that
23:14 est31 if its shitty code, we dont push it "lower"
23:14 hmmmm but it might interfere with others' commits
23:14 kaeza joined #minetest-dev
23:15 est31 most times this isnt the case, but you are right, we have to find a good way to deal with this
23:15 hmmmm like...
23:15 hmmmm keep each new feature in its own branch?
23:15 hmmmm 8)
23:15 hmmmm like we already do?
23:16 est31 its hard for people to test it
23:16 est31 my approach would make more PRs open to testing
23:16 est31 from people
23:17 est31 we have few devs to review code, but lots of folks who like trying new stuff, buggy or not
23:18 hmmmm well
23:18 hmmmm we'll try it out i guess
23:18 est31 take cheapie's bug for example
23:19 est31 #2815
23:19 ShadowBot https://github.com/minetest/minetest/issues/2815 -- Texture corruption
23:19 cheapie Ah, that one...
23:19 est31 it took one day after it got reported
23:19 cheapie The one that is supposedly "by design".
23:21 est31 it was #2810
23:21 ShadowBot https://github.com/minetest/minetest/issues/2810 -- Remove textures vertical offset. Fix for area enabling parallax. by RealBadAngel
23:22 est31 a fix I think for the earlier parallax mapping changes
23:23 est31 also take my utf changes
23:23 est31 in the start, they created alot of regressions
23:23 est31 I had to examine them one by one
23:24 est31 there are still many open
23:24 est31 its a change where its hard to oversee everything
23:25 hmmmm so why does it have to be pushed before it's ready is what i'm wondering
23:26 est31 well if its hard to review, you will need to test instead
23:26 est31 its hard to replicate all possible combinations
23:27 est31 and sometimes you even discover unrelated bugs, that now get exposed more
23:27 diemartin joined #minetest-dev
23:28 hmmmm well alright then
23:29 hmmmm I just don't want this super unstable branch to become a cesspool where people dump their poop
23:29 hmmmm there needs to be some standard of quality there
23:29 est31 agreed
23:31 est31 what would be a good method in your opinion? one dev to agree on it? one dev regardless whether proposed by themselves or sb else? its still less than three like for PRs submitted by devs
23:32 hmmmm not three, just two people /other/ than yourself
23:32 hmmmm having your own vote count is quite deceptive
23:33 est31 it works for politicians
23:33 est31 ;)
23:48 blaaaaargh joined #minetest-dev

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