Time Nick Message 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: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! 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 15:26 RealBadAngel est, hmmmm have you seen my proposal> 15:26 RealBadAngel ? 15:29 RealBadAngel whatever, i know its a masterpiece 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 "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: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* 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: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 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/commit/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 hmmmm then, it's possible that changes to the functionality may possibly be considered trivial 23:08 est31 perhaps we can adopt a multi-branch development model http://mozilla.github.io/process-releases/draft/development_specifics/ 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: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: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 ;)