Minetest logo

IRC log for #minetest-dev, 2015-08-21

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

All times shown according to UTC.

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:01 twoelk joined #minetest-dev
01:21 twoelk joined #minetest-dev
01:36 * VanessaE peeks in
01:36 VanessaE did I miss all the fun then? :)
02:30 sgtbigman joined #minetest-dev
02:56 Siva_Machina left #minetest-dev
02:59 Siva_Machina joined #minetest-dev
03:00 Hunterz joined #minetest-dev
03:42 Siva joined #minetest-dev
03:50 Siva-Android joined #minetest-dev
04:21 OldCoder joined #minetest-dev
04:29 Sketch2 joined #minetest-dev
04:33 Sketch2 joined #minetest-dev
04:45 tuy joined #minetest-dev
04:50 Siva_Machina joined #minetest-dev
05:10 Siva joined #minetest-dev
05:42 Hunterz joined #minetest-dev
05:49 nrzkt joined #minetest-dev
06:12 Siva-Android joined #minetest-dev
06:35 Siva_Machina joined #minetest-dev
06:40 Siva joined #minetest-dev
07:10 Calinou joined #minetest-dev
07:26 Gael-de-Sailly joined #minetest-dev
07:40 nore joined #minetest-dev
07:48 nrzkt joined #minetest-dev
07:51 emptty joined #minetest-dev
07:52 rubenwardy joined #minetest-dev
08:00 Yepoleb_ joined #minetest-dev
08:00 rubenwardy paramat doesn't have the `developer` rank on the forum: https://forum.minetest.net/memberli​st.php?mode=viewprofile&u=3380
08:31 Siva_Machina joined #minetest-dev
08:48 julienrat joined #minetest-dev
08:53 julienrat left #minetest-dev
08:56 twoelk joined #minetest-dev
08:57 Amaz joined #minetest-dev
09:01 err404_ joined #minetest-dev
09:20 julienrat joined #minetest-dev
09:39 ElectronLibre joined #minetest-dev
10:00 julienrat joined #minetest-dev
10:17 julienrat left #minetest-dev
10:20 kilbith joined #minetest-dev
10:21 kilbith please someone update that page : http://www.minetest.net/download
10:24 H-H-H joined #minetest-dev
10:25 emptty joined #minetest-dev
10:40 Donillo joined #minetest-dev
11:04 julienrat joined #minetest-dev
11:05 julienrat1 joined #minetest-dev
11:07 julienrat joined #minetest-dev
11:07 julienrat2 joined #minetest-dev
11:12 julienrat joined #minetest-dev
11:16 julienrat1 joined #minetest-dev
11:22 julienrat1 left #minetest-dev
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
11:38 Darcidride joined #minetest-dev
11:40 Zeitgeist_ joined #minetest-dev
11:55 Siva joined #minetest-dev
11:56 sgtbigman joined #minetest-dev
12:01 Gael-de-Sailly joined #minetest-dev
12:07 proller joined #minetest-dev
12:33 WSDguy2014 joined #minetest-dev
12:52 proller joined #minetest-dev
13:27 zupoman joined #minetest-dev
13:40 johnwayne1986 joined #minetest-dev
13:57 emptty joined #minetest-dev
14:18 hmmmm joined #minetest-dev
14:55 julienrat joined #minetest-dev
14:58 H-H-H joined #minetest-dev
15:10 Hunterz joined #minetest-dev
15:16 proller joined #minetest-dev
15:38 Gael-de-Sailly joined #minetest-dev
15:46 Samson1 joined #minetest-dev
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] <Zeno`> I'm not ready to make it public yet
15:49 VanessaE [08-21 11:48] <Zeno`> it runs but it's not great. So much shit code to replace
15:49 VanessaE [08-21 11:49] <Zeno`> when I do it won't be a PR ;)
15:49 VanessaE [08-21 11:49] <Zeno`> way too big for a PR
15:51 VanessaE it'll be a fork because.... [08-21 11:51] <Zeno`> because I can't keep up with syncing it
15:52 VanessaE [08-21 11:52] <Zeno`> seriously, I am probably 7-8 weeks off making it public
15:52 VanessaE [08-21 11:52] <Zeno`> 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] <Zeno`> neither am I... I don't know how it can be merged. It probably can, but it's too much work for me
15:55 rubenwardy joined #minetest-dev
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:02 emptty joined #minetest-dev
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:23 leat joined #minetest-dev
16:25 hmmmm nice
16:25 hmmmm honestly I'm impressed too
16:26 Player_2 joined #minetest-dev
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:35 nrzkt joined #minetest-dev
16:38 julienrat joined #minetest-dev
16:39 sfan5 joined #minetest-dev
16:43 wischi joined #minetest-dev
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:01 julienrat joined #minetest-dev
17:03 Taoki joined #minetest-dev
17:08 Taoki joined #minetest-dev
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/v​iewtopic.php?f=6&amp;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 Taoki joined #minetest-dev
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:33 julienrat joined #minetest-dev
17:34 julienrat1 joined #minetest-dev
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
17:52 Krock joined #minetest-dev
17:53 Calinou joined #minetest-dev
17:59 paramat joined #minetest-dev
18:00 paramat hmmmm see https://forum.minetest.net/vi​ewtopic.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 Gael-de-Sailly joined #minetest-dev
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
18:40 paramat left #minetest-dev
18:43 OldCoder joined #minetest-dev
18:50 Taoki joined #minetest-dev
19:04 Donillo does LuaJIT make troubles?
19:04 Donillo I am using it only at server
19:09 casimir joined #minetest-dev
19:14 MinetestForFun joined #minetest-dev
19:20 Calinou rarely
19:26 Taoki joined #minetest-dev
19:55 Siva joined #minetest-dev
20:12 est31 joined #minetest-dev
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:25 Krock joined #minetest-dev
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 proller joined #minetest-dev
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 OldCoder joined #minetest-dev
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:26 Siva_AndroIRC joined #minetest-dev
21:30 ElectronLibre left #minetest-dev
21:33 H-H-H joined #minetest-dev
21:34 Sketch2 joined #minetest-dev
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
21:58 Siva joined #minetest-dev
21:59 Siva joined #minetest-dev
22:03 Niebieski joined #minetest-dev
22:23 Siva_Machina joined #minetest-dev
22:29 H-H-H joined #minetest-dev
22:34 Taoki joined #minetest-dev
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/vanes​sa/hobbies/minetest/screenshots/rando​m/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:32 sgtbigman joined #minetest-dev
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 paramat joined #minetest-dev
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
23:57 wischi joined #minetest-dev

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