Time Nick Message 00:02 TBC_x so est31, does client->create_player_on_auth_success indicate that the client just connected to the server? 00:03 TBC_x because the only place it gets set is in handleCommand_Init() 00:04 est31 TBC_x, the commit that added the flag was a57d83b4 00:05 TBC_x yes 00:05 TBC_x is it necessary? 00:05 est31 its a bugfix commit 00:05 est31 yes it is neccessary 00:06 est31 create_player_on_auth_success is true if the player's resources should be allocated on auth success 00:06 est31 this is only required when you have default passwords 00:06 TBC_x I'm trying to reduce (almost) permanently stored temporary variables 00:07 est31 its needed for the auth, after auth it can be removed 00:08 TBC_x it is better to ask than leave broken code behind 00:16 TBC_x I want to convert RemoteClient class to POD structure 00:16 TBC_x it should be possible 00:41 hmmmm :) i'm so happy i'm not the one releasing 01:36 * VanessaE peeks in 01:36 VanessaE did I miss all the fun then? :) 08:00 rubenwardy paramat doesn't have the `developer` rank on the forum: https://forum.minetest.net/memberlist.php?mode=viewprofile&u=3380 10:21 kilbith please someone update that page : http://www.minetest.net/download 11:22 TBC_x what is an average size of mapblockmesh? 11:22 rubenwardy sounds like i 11:23 rubenwardy *sounds like Irrlicht wizardry and dark magic 11:24 TBC_x I am asking because big subgames are ramming RAM 11:25 TBC_x and I've noticed that item visuals are generated as mapblock meshes unless I'm wrong 15:47 VanessaE hmmmm: what's the general level of interest here in getting off of irrlicht? 15:47 hmmmm high. 15:47 VanessaE wait. 15:47 VanessaE it would seem that zeno has completed his abstraction. 15:47 VanessaE he's got MT working with Ogre. 15:47 hmmmm wow! 15:48 VanessaE he says he's not ready to make it public yet. guess some polishing still needed. 15:49 VanessaE I'm trying to drag him back over here 15:49 nore this is impressive 15:49 VanessaE [08-21 11:48] I'm not ready to make it public yet 15:49 VanessaE [08-21 11:48] it runs but it's not great. So much shit code to replace 15:49 VanessaE [08-21 11:49] when I do it won't be a PR ;) 15:49 VanessaE [08-21 11:49] way too big for a PR 15:51 VanessaE it'll be a fork because.... [08-21 11:51] because I can't keep up with syncing it 15:52 VanessaE [08-21 11:52] seriously, I am probably 7-8 weeks off making it public 15:52 VanessaE [08-21 11:52] and then I will 15:52 nore wouldn't it be possible, once it is done, to make a week-long freeze 15:53 nore sync the code, merge it 15:53 nore and then resume development normally, so we still have it? 15:54 nore it would be sad if we threw all this code away 15:54 VanessaE [08-21 11:54] neither am I... I don't know how it can be merged. It probably can, but it's too much work for me 16:02 VanessaE he says he will push it to a repo tomorrow. 16:02 VanessaE he wants to run through it one last time, just to make sure his code isn't any worse than MT ;) 16:04 celeron55 well, just let zeno finish his unsynced code 16:06 VanessaE well in any case he says it's quite late for him, and he's booted into windows at the moment, else I guess he'd have released it now. 16:07 VanessaE he says that he was going to release anyway, but now his plans have been "accelerated" since at least a couple people in here are interested in it. 16:07 celeron55 also... i'm not going to say i'm impressed until i actually see it. but once i do, i probably am 16:07 VanessaE heh 16:11 celeron55 (i mean, i kind of know how much work that is, because i've been looking into doing the same thing with urho3d, though which would be way more insane) 16:11 VanessaE well he did say that this ended up being a lot more involved than he first figured 16:11 celeron55 it's insane. that's how i would describe it 16:11 VanessaE heh 16:19 celeron55 also i must say coding instead of arguing on IRC is a good plan 16:25 hmmmm nice 16:25 hmmmm honestly I'm impressed too 16:26 hmmmm this is the kind of stuff that will push us closer to 1.0.0 16:26 nore I am impressed too 16:27 rubenwardy if it works 16:27 rubenwardy :P 16:27 nore (I remember when I tried to remove map size limit, it was difficult, and this must have been much harder) 16:27 rubenwardy It's very impressive 16:28 VanessaE nore: you DO realize what you've just done, right? :) 16:28 nore what did I do ? 16:29 nore well, except saying I was impressed 16:29 VanessaE nore: "well I tried to A, but he did B and B was MUCH harder." Ergo, you now have to do A ;) 16:29 nore hm... 16:29 nore so that means I have to try again to remove map limit ? :s 16:30 VanessaE yes. :-) I'm of course kidding, as there seems to be no real call for that. 16:30 nore I remember that the old code segfaulted often 16:30 nore for a quantity of reasons, most of which I couldn't find :( 16:46 TBC_x what limits the world size? just irrlicht? 16:46 hmmmm the data types in the v3s16 structure 16:46 VanessaE the fact that 16-bit typoes were used 16:46 VanessaE types* 16:46 hmmmm typos lol 16:46 VanessaE lol 16:47 TBC_x imho that could be worked around using spatial location 16:47 VanessaE well given the number of typos I've made over the users, you'd need a u16 to store them :D 16:47 VanessaE G*d damn it 16:47 VanessaE over the YEARS. 16:48 TBC_x and I was earlier talking about asynchronous world simulation 16:50 TBC_x and I think that client would be even satisfied by v3s8 type 16:50 TBC_x if anyone is crazy enough to do that 16:53 H-H-H lol"16 bit typos 17:24 * Sketch2 imagines Luigi as a typo. instead of #ff0000 for Mario's red, they put in #00ff00 and got green 17:26 rubenwardy hmmmm, https://forum.minetest.net/viewtopic.php?f=6&t=13081 17:26 rubenwardy About OOM 17:27 hmmmm ohh man :) 17:27 hmmmm >Current Lua memory usage: 44 MB 17:27 VanessaE well that kinda blows away the theory that it was Sokomine's markers mod :P 17:28 hmmmm no it's sokomine's markers mod as well 17:28 VanessaE ok 17:28 hmmmm there are a ton of different reasons why this could happen 17:28 rubenwardy all of those mods use noise, which is why I though it was noise 17:28 hmmmm Sketch: unlikely, the NES used NTSC color codes. 17:29 hmmmm dammit 17:29 rubenwardy Why didn't this crash before? 17:29 hmmmm this is most likely a luajit problem 17:30 VanessaE hmmmm: I dunno...someone calling it "4.13" doesn't strike me as the sort of person who would be using luajit 17:30 hmmmm don't windows builds come with luajit? 17:30 VanessaE the unofficial ones do 17:30 hmmmm hmm 17:30 VanessaE but I'm not sure if the official ones do. 17:31 Sketch2 it was a joke. they might not have used hex to represent the color, but the idea is still sound. 17:32 hmmmm :) 17:32 TBC_x will see whether the OOM will happen after I fix the heap corruption 17:32 hmmmm lol 17:33 hmmmm this is so messed 17:36 TBC_x I wish that fix could work without messing the code so deep but I don't know any other correct way 17:42 VanessaE bbl 18:00 paramat hmmmm see https://forum.minetest.net/viewtopic.php?p=187847#p187847 18:04 VanessaE hmmmm, kahrl: two more indirect calls for "simple" shaders, just fyi. 18:05 VanessaE s/calls/requests/ 18:21 paramat pathv6alt has 9 2D noises, so all those have perlinmap z dimension != 1, consuming lots of memory 18:22 * VanessaE begins to worry a little 18:22 VanessaE biome_lib has three or four perlin noises... though they're not the same sort of calls as you're using 18:23 paramat you use perlinmaps? 18:24 VanessaE I use the PerlinNoise() call to get them 18:24 VanessaE so probably not even the same thing 18:25 paramat correct, no need to worry 18:25 VanessaE and get_perlin() in one case. 18:25 VanessaE ok, just checking 18:26 paramat it's the bulk perlinmaps that consume much memory 18:26 VanessaE yeah 18:26 VanessaE so no worries here then 18:27 VanessaE typical usage in my case: https://github.com/VanessaE/biome_lib/blob/master/init.lua#L203-L209 18:28 paramat yes the pre-perlinmap method 18:28 VanessaE ok 18:29 VanessaE some day I will probably update to the newer method, but not now :) 18:29 VanessaE anyway bbl for real this time 19:04 Donillo does LuaJIT make troubles? 19:04 Donillo I am using it only at server 19:20 Calinou rarely 20:13 est31 TBC_x, what precisely is the heap corruption about? 20:22 TBC_x it is the way of how is RemoteClient accessed 20:22 TBC_x without a mutex inside packet handlers 20:23 est31 so its a race condition ... between? 20:23 TBC_x between server thread and emerge thread 20:23 nrzkt emerge thread doesn't give packet. 20:23 est31 TBC_x, why does emerge thread access remoteclient? 20:23 nrzkt please learn to read code properly and stop insert mutex where not needed. 20:24 nrzkt Packets are read from ConnectionReceiveThread into a mutexqueue. 20:24 nrzkt Stop use gedit and please use a good EDI to follow code, like VS, Eclipse or QTCreator. 20:26 TBC_x I'll look that up 20:29 est31 EDIs are too heavy, slow and sluggish 20:29 est31 they distract IMO 20:29 est31 but fortunately everybody is free to choose what tools they want 20:30 kahrl what's an EDI? 20:30 est31 french for IDE? 20:30 kahrl oh, yeah 20:30 kahrl Environnement de développement intégré 20:30 est31 sometimes they swap letters 20:31 est31 french name for UNO is ONU :) 20:31 nrzkt IDE is IDE in french 20:31 est31 https://fr.wikipedia.org/wiki/Organisation_des_Nations_unies 20:31 nrzkt no it's EDI .. i inverted it :p 20:32 nrzkt because everybody in france said IDE and nobody use EDI :p 20:32 nrzkt UNO is a good card game :D 20:33 est31 germans say VN, but only at the website of the foreign ministry 20:33 est31 everywhere else they say UN 20:33 nrzkt xD 20:33 Krock nrzkt +1 20:34 nrzkt for the IDE it's very good to track bugs, everybody is free, but for mutexes, concurrent threading etc, IDE are the most pratical to catch those bugs because you can see easily the whole call tree for a variable 20:36 TBC_x oh yeah, server thread and emerge thread stepping over each other at SetBlocksNotSent 20:36 nrzkt there is a queue for that with a mutex too if i remember. 20:37 nrzkt and there is the m_env mutex for that also 20:37 nrzkt please be sure of what you said. 20:39 TBC_x what mutexes are hold when packet handler runs? 20:39 nrzkt packet handlers are called by server thread 20:40 nrzkt in the main loop 20:41 TBC_x so I assume that calling packet handler body don't hold any mutex 20:41 TBC_x on itself 20:41 nrzkt why do you want to call a mutex on ServerThread for ServerThread itself ? 20:42 TBC_x It looks like m_clients mutex is not held when it should be because there is concurrent access from emerge thread 20:42 nrzkt look at EmergeThread m_clients calls then 20:43 TBC_x http://sprunge.us/YUZU 20:43 TBC_x had to dig it up in logs 20:45 est31 can I push https://github.com/est31/minetest/commit/4b0f8096601224b4716e4d655217fe203aac848c 20:46 est31 would be interesting for nrzkt to backport for his play store builds as well 20:47 TBC_x what led me to believe that it is caused from conucrrency of emerge thread and server thread is because I have noticed that when there is extracted RemoteClient with getClient() the usage of the client is not guarded by any mutex and any thread theroetically can call Server::SetBlocksNotSent() which does lock clients but it is useless because packet handlers don't lock clients 20:48 nrzkt est31: okay for me 20:48 nrzkt i haven't do the play store build yet but i will use this commit okay 20:48 est31 pushed 20:49 est31 nrzkt, it should be doable to use the commit without backporting, as the "continue with -dev" commit doesnt affect the android build process 20:49 nrzkt TBC_x: please look at the m_env mutex, it can be the protector for the whole thing 20:50 nrzkt est31: yes 20:50 nrzkt the client version is in AndroidManifest, the ID is the most import, other things are not important 20:51 TBC_x do you mean that I should add m_env lock to SetBlocksNotSent() ? 20:51 nrzkt TBC_x i don't said that, i said m_env protect many and many things 20:51 nrzkt and it's the lock used generally between emerge and server threads 20:52 est31 well, its better to be lock free than to restructure entire files 20:52 est31 err 20:52 est31 its better to have locks than to restructure entire files 20:52 nrzkt :) 20:52 est31 but lock freedom is good as well 20:53 TBC_x that would have to be done once anyway 20:53 nrzkt lock freeing a so huge project is... death 20:53 nrzkt lock freeing is not as easy as mutexes. Minetest should be rewrote heavily to have this 20:54 TBC_x freeminer "fixed" this problem using individual RemoteClient mutex and shared_ptr 20:55 TBC_x I would rather do more rewriting that keeping this abomination 20:55 nrzkt shared_ptr couldn't be use by minetest atm, we are c++89 20:55 TBC_x I don't even suggest it 20:56 est31 nrzkt, that even is a reason to use shared_ptr 20:56 TBC_x it is not 20:56 est31 err 20:56 nrzkt i didn't said taht 20:56 est31 thats an acually valid argument for switching to c++11 20:57 est31 I dont care that we can write for loops shorter with the : now 20:57 est31 thats syntactic sugar 20:57 est31 but shared_ptr is a really interesting feature 20:57 TBC_x shared_ptr is a patch 20:58 TBC_x literally 20:58 TBC_x or a carpet 20:58 TBC_x to hide problems underneath 21:02 TBC_x imho 21:03 TBC_x unless it is used on immutable data 21:05 est31 well yes, using shared_ptr for sharing data between threads is not enough 21:05 est31 but if both just read, everything is ok 21:06 kahrl what is the point of shared_ptr if everyone just reads? 21:06 kahrl (I don't count deleting the object as just reading) 21:07 est31 I do :) 21:07 est31 but yeah, generally its not good to count it as reading 21:08 TBC_x If you have for example a texture used in multiple places 21:08 est31 the only thing shared_ptr protects you from is the deletion race condition 21:08 est31 everything else is kept unprotected 21:08 est31 you have to keep that in mind 21:09 TBC_x shared state is evil 21:09 TBC_x shared mutable state 21:10 est31 ? 21:11 TBC_x it is error prone 21:11 est31 well yes, multithreading is error prone 21:12 est31 but its hard to do in a fast way without sharing data 21:14 TBC_x you need to have clearly defined ownership 21:14 est31 you need to share data in some way 21:14 est31 otherwise you have separate programs 21:15 est31 but yes, race conditions are race conditions, and evil 21:15 est31 if you mean that 21:17 TBC_x hmm... ownership... I meant lifetime 21:19 TBC_x sharing mutable data should be done using agents 21:19 TBC_x i count queues in 21:20 TBC_x if you know what I mean 21:21 TBC_x race conditions are just innocent creatures 21:22 TBC_x spawned by higher evil 21:24 TBC_x my changes remove the single TODO in clientiface.h 21:42 hmmmm as a general rule of thumb: 21:42 hmmmm DON'T USE SHARED_PTR 21:42 hmmmm if you find yourself needing to, your thing is probably designed the wrong way 21:42 TBC_x that is basically what I wanted to say 21:43 est31 I admit I dont have the experience with shared ptr to really judge it 21:44 TBC_x I have noticed that reference counting is usually used in places without properly defined lifetimes or ownership 21:45 est31 its like saying "i dont use a while loop, because I like for loops so much" 21:46 rubenwardy for(;cond;) 21:46 rubenwardy :( 21:49 TBC_x sometimes I get mad when I can't use a for loop 21:49 TBC_x I don't mean that I use `for (;;)` 21:53 TBC_x I dislike while loops where I have to use ++i inside while body 22:50 VanessaE wow mgv7 produces an awful lot of those square, black shadows 22:51 VanessaE particularly when an l-systems tree is spawned at mapgen time 22:51 VanessaE (I was curious how plantlife + moretrees behaves) 22:54 VanessaE example: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-08-21_18-54-03.png 22:56 hmmmm hrm 22:56 hmmmm to me, that looks like an interaction between mgv7 and a misbehaving mod that uses luavoxelmanip 22:56 VanessaE can't be. 22:56 VanessaE only moretrees, plantlife, unified inventory, and minetest_game here. 22:56 hmmmm if mapgen v7 raw gave that kind of output there'd be lots to be concerned about 22:56 hmmmm it has to be moretrees causing it 22:57 VanessaE and at least moretrees and plantlife do not use lua vmanips 22:57 hmmmm yeah but moretrees uses lsystem trees 22:57 VanessaE true. 22:57 VanessaE this reminds me a lot of that glitch we had a while back with mgv6 22:57 VanessaE when spawning a tree from a sapling would cause shadows 22:58 VanessaE despite the lighting bug, the terrain is interesting 22:59 VanessaE holy crap there's stuff extending way up past the clouds with this map :) 22:59 VanessaE (it's my usual test map, decided to delete the map.sqlite and switch the mapgen to v7 just to putter around) 23:04 Wayward_One I notice those shadows also when using the ruins mod from blockmen's wasteland game 23:34 VanessaE paramat: snow coverage on pines seems to have minor map chunk edge issues (not very visible in the world but you can see it in the minimap) 23:43 * VanessaE hides 23:44 paramat yeah i noticed that too 23:44 paramat hehe 23:44 VanessaE you've created some epic terrain here 23:44 paramat something to do with pines overgenerating across chunk borders 23:44 VanessaE see above (logs) about the lighting glitch being triggered by lsystem trees 23:44 paramat saw that 23:46 paramat something to do with moretrees plus mgv7 23:46 VanessaE mmhmm 23:46 VanessaE it's a race condition 23:47 VanessaE if the relevant land and its air above has had "enough" time to fully generate, the tree appearing there seems to not cause a problem 23:52 paramat l-system trees use 'updateLighting', that's known to be buggy 23:53 paramat the shadow bugs are worse in mgv7 than mgv6? 23:54 VanessaE yes 23:54 VanessaE WAY worse 23:54 VanessaE in v6 they almost don't happen in practice 23:54 paramat mgv5/v7 use a different mapgen calcLighting to mgv6, might be relevant 23:56 paramat hmmmmm added a 4-argument calcLighting for mapgens that overgenerate, as v5/v7 do