Time Nick Message 00:21 paramat i'll push this trivial fix later game#485 00:21 ShadowBot https://github.com/minetest/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat 00:28 est31 paramat, I think game#485 is small enough to be merged directly. 00:28 ShadowBot https://github.com/minetest/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat 00:29 paramat yes i was going to merge it without approval =) 00:30 paramat the ice PR can wait for the mtg team to see it on sunday 00:35 paramat now pushing game#485 00:35 ShadowBot https://github.com/minetest/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat 00:38 paramat done 02:17 est31 Merging in 5 minutes: http://pastie.org/10074257 02:26 hmmmm looks good to me 02:27 kahrl that was more than 5 minutes later :P 02:28 est31 now its pushed 02:30 ShadowNinja est31: Don't remove newlines at the ends of files. 02:31 ShadowNinja Also, should be 115 mins IIRC. 02:31 ShadowNinja 15 rather. 02:31 est31 ShadowNinja, why? 02:31 ShadowNinja est31: Because they're supposed to be there. 02:31 est31 why that? 02:33 ShadowNinja est31: Lets you can them together, start editing at the end easily, some tools require it. 02:33 ShadowNinja It could be changed if there are good reasons though. 02:33 ShadowNinja est31: Have you read all of http://dev.minetest.net/All_rules_regarding_to_development ? 02:33 est31 ok, noted. 02:35 est31 ShadowNinja, I think I have read most, but I guess reading it all again is a good idea 02:39 kahrl huh, why was the "rule 1" stuff removed from http://dev.minetest.net/Git_Guidelines? 02:39 hmmmm who wrote all this stuff 02:39 hmmmm i didn't even know those pages existed 02:40 est31 This isn't done at all: http://dev.minetest.net/Merging_core_pull_requests_to_upstream 03:05 est31 #2602 looks good except of style issues and it needs to be squashed. they use a map now instead of a vector. What do you think, can I merge it when I squash and fix the style? 03:05 ShadowBot https://github.com/minetest/minetest/issues/2602 -- move particle spawners to env by obneq 03:05 * est31 needs a second +1. 03:06 hmmmm hopefully those are going to get squashed... 03:07 hmmmm est31, are you sure that pull request is ready? 03:07 VanessaE est31: wait a bit - jin_xi has more stuff he's doing 03:07 hmmmm yes, please don't be so ready to merge PRs unless there's been actual discussion 03:08 VanessaE #2587 in particular 03:08 ShadowBot https://github.com/minetest/minetest/issues/2587 -- wip irrlicht particles 2 by obneq 03:08 est31 I have seen that one 03:09 est31 its only a "move A out of server.cpp" PR, nothing functional 03:09 est31 (read it in one of those wiki rules that server.cpp has to be shortened.) 03:10 est31 I'll let jin_xi do it themselves 04:27 hmmmm agh 04:27 hmmmm i never tried compiling with leveldb before, but now that I am, I get an error 04:27 hmmmm precisely because I'm using gcc 04:27 hmmmm compile with clang, no problem 04:27 hmmmm but at the same time i have no debugging info 04:39 ShadowNinja I am now a l33t net pro ;-) #2604 04:39 ShadowBot https://github.com/minetest/minetest/issues/2604 -- Add support for multiple listen addesses by ShadowNinja 04:52 est31 my craft speedup patch #2596 works with deadbeef power 04:52 ShadowBot https://github.com/minetest/minetest/issues/2596 -- Crafting speedup by est31 04:52 est31 did you know that 0xdeadbeef allocates exactly 32 bytes? 04:59 ShadowNinja est31: Um, you mean (void* (*)(void))(0xdeadbeef)()? (call that address as a function returning a void*). 05:00 est31 you know, dead beef is so salty, so that I can use it for salting... 05:00 ShadowNinja est31: Or you mean it's 32 bits because it's a 8-char hex string? 05:02 ShadowNinja est31: It looks like you're basically just making a custom std::unordered_map. 05:02 est31 yes that one. 8 characters times 4 bits per character are 32 bit 05:02 est31 mhh 05:02 est31 dammit I have 32 bit free space 05:02 est31 byte 05:02 est31 we have to live with the zeroes 05:03 est31 we don't want to use too much salt do we 05:05 ShadowNinja est31: Why do you need a salt? 05:05 est31 bc I'm hashing. 05:05 est31 would live well with 0 too I guess 05:06 est31 but as the method requires a salt to be passed... 05:06 ShadowNinja est31: This kind of change should come with a lot of comments, or someone is going to go "why all this complexity?" 05:06 est31 see commit message 05:07 ShadowNinja est31: The code should be understandable without reading through the commit history for the commit that added the code. 05:08 ShadowNinja The commit message should only describe what the commit does, not what the code does. 05:10 est31 ShadowNinja, I can move paragraphs 2, 3 and 4 into comments somewhere in the code, is that sufficient? 05:11 ShadowNinja est31: Add comments anywhere that might be confusing. 05:11 est31 lol 05:11 ShadowNinja I read the commit message but I still don't understand what it does, except that it apparently involved three hashtables. 05:12 ShadowNinja Maybe I'm just tired though. 05:12 est31 you made #2604 thats alot of work 05:12 ShadowBot https://github.com/minetest/minetest/issues/2604 -- Add support for multiple listen addesses by ShadowNinja 05:12 hmmmm jesus christ 05:13 hmmmm well that's not overkill or anything 05:13 est31 hmmmm, my change or ShadowNinja's? 05:13 hmmmm yours :p 05:14 est31 you want to have the server to spend the quarter of a second searching for sth to craft? 05:14 hmmmm no, but that's a false dichotomy 05:14 hmmmm you could've gained roughly the same speed increase just using std::map 05:16 hmmmm i don't quite understand the whole "layers" thing 05:16 hmmmm ahh I see what you did 05:17 est31 craft definitions with groups in their grid are a problem otherwise 05:17 hmmmm hrmm 05:17 hmmmm what is the hash output size of xxhash? 05:17 est31 32 bytes 05:17 hmmmm yikes 05:17 est31 (u32) 05:17 hmmmm erm, u32 is 32 bits 05:18 hmmmm 32 bytes would be something like SHA-2 05:18 est31 ok 05:18 hmmmm that's a lot of stuff going on just for 4 bytes of hashing 05:19 hmmmm unless the collision properties are superior to that of a 64-bit murmur hash, why not just use that one instead? 05:19 est31 I'm ok with other algs too, just want to have 4 bytes at the end 05:19 hmmmm 1). murmur hash is already there 05:19 hmmmm 2). it has twice as big of a space 05:19 hmmmm hash space 05:19 hmmmm 3). it doesn't need to be "initialized" 05:19 est31 ? 05:19 hmmmm but maybe this is better, i need to understand the layers better 05:20 est31 ah initialisation is still needed 05:20 est31 its because we allow aliasses to be defined after craft definition 05:20 est31 otherwise we would need to change even minetest_game 05:21 hmmmm hmm 05:21 hmmmm in the header file it actually compares against murmur hash 05:21 hmmmm this appears to be twice as fast 05:21 hmmmm key word appears :p 05:21 est31 or not, because we dont use aliases there in craft definitions, but what I have checked is that the files get loaded in the wrong order 05:21 hmmmm i'd just prefer to not have unnecessary stuff 05:22 hmmmm and like this is a whole huge new file 05:23 est31 murmur seems to be ok too. 05:25 est31 I'll let it do murmur 05:25 hmmmm you don't have to change things if this works fine 05:25 hmmmm the work has already been done 05:26 * hmmmm scratches head 05:26 est31 its a single line commit for the usage, and a texteditor u32->u64 replace 05:26 hmmmm okay, so tell me if this is how it works: 05:26 hmmmm different *parts* of the CraftDefinition get hashed based on something 05:27 hmmmm each "level" controls how much of the definition is hashed 05:27 hmmmm yes or no so far? 05:27 est31 tough descision 05:27 est31 the deeper the "level" the more the collision rate 05:28 est31 so yes to that one 05:28 est31 and yes to the first 05:28 hmmmm but wait that doesn't make sense 05:28 hmmmm if you have more data being hashed, wouldn't that lower the collision rate? 05:29 hmmmm actually nevermind, that's true for things below the hash size 05:29 est31 for me the highest level is the one thats checked first, the CRAFT_HASH_TYPE_ITEM_NAMES 05:29 hmmmm how likely is it that there's a collision to begin with? 05:30 est31 at that layer you can collide if you have two reorderings of the same craft grid 05:30 hmmmm and so what if there is a collision? shouldn't you have a collision resolution mechanism already? 05:30 est31 yes 05:30 est31 there is one 05:30 hmmmm what is it? 05:30 est31 the map maps to a vector 05:30 est31 (from the hash) 05:31 hmmmm can't you just use a multimap? 05:31 * est31 googles 05:31 hmmmm std::multimap 05:31 est31 is it stable? 05:32 hmmmm in which sense? 05:32 hmmmm like a stable sort? 05:32 est31 yes 05:32 hmmmm why do things need to be sorted? 05:32 est31 so when I enter two elements with the same key in a certain order, do I also get them with that order 05:33 est31 its so that later craft definitions can override earlier ones 05:33 est31 some mods do that 05:33 hmmmm the answer is that i don't know 05:33 * est31 reads doc 05:34 hmmmm i *would* assume it uses std::sort internally but i have no way of knowing that for sure 05:35 est31 it seems its not stable http://bytes.com/topic/c/answers/480984-std-multimap-stable 05:35 est31 by standard 05:35 est31 but all implementations keep it stable 05:36 hmmmm ahh 05:36 hmmmm looks like you should stick with your map/vector implementation then 05:36 est31 yea 05:39 hmmmm so the levels are in this order: 05:40 hmmmm CRAFT_HASH_TYPE_COUNT, CRAFT_HASH_TYPE_ITEM_NAMES, then CRAFT_HASH_TYPE_UNHASHED as the lowest level 05:40 hmmmm correct? 05:40 est31 yes 05:40 est31 no 05:40 est31 no 05:40 est31 item names and count flipped 05:40 hmmmm okay :) 05:40 est31 like they are defined in the enum 05:41 hmmmm so a count of the items has more uniqueness than the names of the hash types? 05:41 hmmmm err, the name of the items 05:41 est31 no, read above 05:42 hmmmm yeah my questions still stands 05:42 hmmmm so why not make the hash just use *both* item names and count? 05:42 est31 count of the items has less uniqueness agreed 05:43 est31 the hash already does that internally, by adding the \n occurences into the result 05:43 est31 but thats not the point 05:43 est31 the point is that there are craft definitions where names dont help 05:44 est31 thats all craft defs where you have one element which is group:something 05:44 est31 then you can't add group:something to the hash 05:44 hmmmm ahhh 05:44 hmmmm ahhhhh 05:44 est31 you dont know to check that on the other side 05:44 hmmmm i just realized that a craft def lookup is actually sort of complicated 05:44 est31 you could make a brute force search 05:45 est31 horribly expensive 05:45 hmmmm by the way, if you don't specify a = number in an enum, it's 0 by default 05:45 hmmmm so starting an enum by ELEMENT_NAME_HERE = 0 is redundant 05:45 est31 nice 05:46 hmmmm looks good to me 05:46 hmmmm +1 05:46 hmmmm you *could* switch to murmur hash if you'd like 05:46 est31 yaay 05:46 hmmmm it's in util/numeric.h 05:46 est31 will switch to murmur 05:46 est31 yea found it 05:46 est31 and will remove the =0 05:46 hmmmm yea I added that for alphanumeric seeds 05:47 hmmmm i'm glad it's being useful somewhere else too 05:48 hmmmm ugh so it looks like i'm gonna have to disable leveldb for now 06:31 hmmmm speaking of which I just found a bug with murmur_hash_64_ua() 06:31 hmmmm I wonder if the memcpy() call was there originally in the code I got it from or did I add that?? 06:37 est31 github is stupid 06:37 est31 I've pushed to the branch, but nothing changed 06:38 est31 https://github.com/minetest/minetest/pull/2596 06:38 est31 here an old version of my commit is shown 06:38 est31 and on my branch, the new version is shown: https://github.com/est31/minetest/tree/craftingspeedup 06:39 est31 this is the new version https://github.com/est31/minetest/commit/927c33309b06d0c1c96e87efc04eadfd055c0cc2 06:39 est31 the old version still has the xxhash thingy 06:41 est31 ShadowNinja, can you confirm that there are enough comments now? 07:11 est31 ShadowNinja is asleep as it seems 07:14 est31 I have however made the code document 07:15 est31 added some hints here and there 07:18 est31 idk should I wait for him? 07:23 est31 I think I'll merge, as I mostly did what he requested. 07:23 est31 pushing #2596 now 07:23 ShadowBot https://github.com/minetest/minetest/issues/2596 -- Crafting speedup by est31 09:17 nrzkt hi, i pushed two changes: some uninitialized variabled into ConnectionEvent and also return 0 after assert in est31 craftdef code to make clang happy 10:37 lordfingle hello 10:56 kilbith [Alert] nrzkt, 8804c47e still cause a crash near the signs_lib : http://pastie.org/10074694 10:57 kilbith it was fine before that commit 10:57 kilbith https://github.com/minetest/minetest/commit/8804c47e59b550ec9a533de662f086af623d68c1 10:59 nrzkt ugh. wtf we only catch an error without doing nothing else 10:59 nrzkt i think the problem was never solved in fact 11:00 kilbith it was fine before that commit (bis) 11:00 kilbith ie. no crash 11:00 nrzkt this commit does nothing 11:00 kilbith i have crashes with it, none before 11:02 nrzkt please retest without the commit it's impossible. This commit only add a catch for packet error on client side to catch PacketError when the packet is unreliable 11:02 nrzkt then the crash was also present before 11:03 kilbith factually, it is 11:03 kilbith i'm not talking about theory man 11:03 nrzkt also, please note the catching error is not in this function but in processActiveObjectMessage 11:03 nrzkt and processActiveObjectMessage hasn't changed. Then the problem was here before. 14:37 est31 breaking the network with git versions of minetest that are newer than the latest release *is* allowed, isnt it? 14:38 est31 because I don't like to avoid breaking it when I want to change sth the protocol changed 14:38 est31 e.g. master has a new packet 14:38 est31 and I want to remove a flag 14:38 est31 from that packet 14:38 est31 then I dont want to make a new protocol version just because 14:39 est31 of course, compat with releases needs to be maintained 14:40 est31 hmmmm, ^ 14:40 hmmmm man i'm trying to get minetest to compile 14:40 hmmmm and you're over there talking about protocol changes 14:43 est31 I just asked because nrzkt seemed to have other things in mind in a comment on a PR (not related to my example). 14:43 est31 and I had plans to change packets that were introduced in protocol version 25. 14:45 est31 to not make it overly complicated (having legacy logic for protocol versions that only clients/servers have that use a custom source build of un-released (as in release) minetest) 14:45 hmmmm if there are protocol changes within a version we try to coordinate and batch them all together 14:45 est31 ok 14:46 est31 I'm not sure what nrzkts auth plans are, my ideas require those packet changes. 14:47 est31 thanks for answering, I'm off now. the PR I mentioned was 2592 btw 14:47 hmmmm okay. 14:47 hmmmm pfth 14:48 hmmmm looks like I got a minimal test case for my issue 16:21 Megaf_ Man, I never get nrzkt online 18:32 paramat nore, sfan5, please could you review/approve game#484 ? Since PilzAdam's comment i have added more screenshots showing why icesheet caves are so messy 18:32 ShadowBot https://github.com/minetest/minetest_game/issues/484 -- Default/nodes: Make ice not ground content by paramat 20:59 hmmmm do you guys think the currently executing mod name should be available after initialization? 21:38 paramat erm, can't think of a use for that at the moment 21:45 paramat because this is more of a mapgen issue i will probably go ahead and push game#484 soon, seems obvious to me there should not be caves in icesheet. highlighting hmmmm and sfan5 21:45 ShadowBot https://github.com/minetest/minetest_game/issues/484 -- Default/nodes: Make ice not ground content by paramat 21:47 sfan5 paramat: seems ok 21:51 paramat thanks, alternatively i could edit mgv6 caves to check for ice, this may be better i will think on it 21:54 hmmmm paramat +2 21:54 paramat thanks 21:54 est31 hmmmm, this isn't possible: http://irc.minetest.ru/minetest-dev/2015-04-05#i_4214025 21:55 est31 we have a common lua context after loading 21:55 est31 it is possible to e.g. use the stack, but that isn't nice either, imagine library mods. 21:55 hmmmm mods register callbacks on loading 21:55 est31 ? 21:56 hmmmm so you just register the name of the mod associated with the callback 21:56 hmmmm then every time it's called, set the context 21:57 est31 if we do it that way, the fact whether we register something for that special mod should be settable by flag 21:57 est31 but mh 21:58 est31 your solution works without that flag too 21:58 hmmmm the mod api is basically a miniature OS with cooperative multitasking 21:59 hmmmm setting the context before making a callback is akin to setting segment descriptors to point to the correct processes' PEB before handing over execution 22:01 est31 !g PEB process operating system 22:01 ShadowBot est31: https://msdn.microsoft.com/en-us/library/windows/desktop/aa813706(v=vs.85).aspx | Indicates whether the specified process is currently being debugged. The PEB structure, however, is an internal operating-system structure whose layout may ... 22:01 paramat ah.. v5/v7 cavegen already check for ice (as well as checking 'is ground content') and don't remove it. v6 cavegen doesn't check for 'is ground content' or for ice, i will update it. so the simplest fastest solution is making ice not ground content .. will do this 22:01 est31 yeah 22:01 est31 (to hmmmm) 22:02 hmmmm that being said 22:02 hmmmm it would be very nice if we had more advanced scheduling constructs for modding 22:02 est31 is luajit multithreadable? 22:03 paramat (..perhaps better and simpler i can also make water and lava not ground content) 22:03 hmmmm multithreading is absolutely useless because of the scope of the locks held 22:04 hmmmm what would be nice is if mods could be pre-empted however 22:04 est31 yes 22:04 est31 then they dont cause lags 22:05 est31 or still do, but dont stop the whole server 22:06 paramat (..this will reduce checks for more speed, will do) 22:06 est31 problem is however: data can change 22:07 hmmmm yeah 22:07 hmmmm the solution to this would be to take a snapshot of the map or whatever it is at that point in time it's being called 22:07 hmmmm and each time the thread is resumed, it'd read the map out of that snapshot 22:07 hmmmm the problem is that old mods wouldn't be able to do this... 22:08 hmmmm so it'd break compatibility? 22:08 est31 even if, how do you feed back the changes? 22:08 hmmmm you have a transaction list 22:08 est31 this still would require certain locks 22:08 hmmmm yeah there's locking any way you look at it, but this modifies the scope of locks 22:09 est31 yea 22:09 est31 umm no 22:09 est31 your idea is to dynamically cache something, but that can end up bad 22:09 hmmmm how so? 22:09 hmmmm explain. 22:11 est31 what is when mod A does something on place X and adds them to the transaction log. then player B comes, modifies sth on place X and then mod C sees what A has done and adds something else to the transacion log too, overriding the players modifications. 22:12 hmmmm if another mod attempts to read a MapBlock that has a pending write transaction it should take the most recent version 22:13 hmmmm so it's like this: 22:13 est31 also, if we have this model implemented, nothing stops us from multithreading, does it? 22:13 hmmmm mod A expresses its intent to read an area of nodes from (4, 3, 10) to (20, 19, 26) 22:14 hmmmm so it atomically sets a little flag on each of them that means they're currently being read 22:15 hmmmm then if another mod comes around to write on any one of those, it notices the flag and it instead adds a pending transaction to that 22:15 hmmmm this is kind of like the idea behind RCU 22:16 est31 you basically want to implement area-based locking? 22:16 hmmmm it's not area-based locking because there are never any waiters 22:17 hmmmm the only time a lock does happen, it's to do something with the transaction list, which is very well defined and bounded 22:17 hmmmm so we know the lock operation will take at the very most, say, 1 ms 22:17 hmmmm and yes, this would allow for multithreading 22:19 hmmmm but let's think about the broader problem than ways to efficiently lock the map structure 22:19 hmmmm what is it we're actually trying to accomplish? 22:19 est31 when both mod A and B add transactions, mod A places dirt, mod B places stone. 22:19 hmmmm access to the environment needs to be synchronized because __________________________________ ? 22:20 est31 mod A starts from (3,0,0), B starts from (0,0,0) 22:20 est31 and both work in opposite directions 22:20 hmmmm note this would only work if the mods define the bounds in which they intend to operate 22:21 hmmmm if they attempt to access a piece of the map that hasn't been snapshotted, it'll have to incur a penalty 22:21 est31 we can get in the log: (A, dirt (3,0,0,)), (b, stone, (0,0,0)), (A, dirt (2,0,0,)), (B, stone (1,0,0,)), (A, dirt (1,0,0,)), (B, stone (2,0,0,)), (A, dirt (1,0,0,)), (B, stone (3,0,0,)), (A, dirt (0,0,0,)) 22:22 hmmmm that's not an issue. 22:22 est31 then in the end, we have (stone, 3,0,0) (stone, 2,0,0) (dirt, 1,0,0) (dirt 1,0,0) 22:22 hmmmm er 22:23 est31 basically and config possible, depending on scheduling 22:24 hmmmm by definition, mod B is taking a snapshot of the current state of the map 22:25 hmmmm perhaps there could be a R/W flag 22:25 hmmmm if one mod takes an R/W snapshot of a mapblock, then another mod later on can be notified of this 22:26 hmmmm "hey there's another mod that intends to modify this area of map, so you might not be looking at the most recent" 22:26 est31 so we allow the mod to either wait, or not wait 22:26 hmmmm at this point it could say it's either OKAY with that 22:27 hmmmm or it's not okay, and it wants a callback when that mod has no pending writers that came before it 22:28 est31 that sounds better 22:28 est31 mods who intend to write should also have this option: is there currently any mod reading that block? 22:28 hmmmm but, in practice, all mods are going to want the most up-to-date version, even when they won't really need it 22:29 hmmmm so there's this 22:29 est31 its locking, again, btw 22:29 est31 not that I'd think its bad 22:30 est31 (locking with the option, nah I ignore) 22:30 hmmmm how about having a reader/writer lock 22:30 hmmmm multi-reader/single writer 22:31 hmmmm hrmm http://en.wikipedia.org/wiki/Seqlock 22:33 hmmmm that's conceptually simpler but probably less useful 22:34 hmmmm as far as I can tell, the only reason why there currently needs to be an envlock is contention between serverthread and emergethreads 22:35 est31 seems so 22:35 hmmmm if emergethread sticks to creating only new blocks (i.e. we stop doing shenaningans in others pieces of the map outside of chunk boundaries) then in theory it wouldn't need synchronization 22:36 est31 if the data structures dont need it, yes 22:36 hmmmm the data structures can be made wait-free 22:36 est31 ? 22:37 est31 ah 22:37 hmmmm before the ServerThread enqueues mapblocks for emerging, it could reserve the nodes or whatever in the std::map//std::vectors 22:37 hmmmm and set it to NULL 22:37 hmmmm it'd also pass pointers to these newly created nodes in the data structures as part of the block-making data 22:38 hmmmm then when the emergethread is completely finished with making the blocks and initializing them, it'll atomically swap in the mapblock pointers 22:38 est31 what is this exactly supposed to do? 22:38 hmmmm it's just an idea 22:38 hmmmm it would become a useless idea if true mod multithreading were added 22:39 hmmmm i'm just saying that an envlock isn't strictly 100% necessary 22:39 est31 yes 22:39 est31 I dont know though how hard current envlock is 22:43 est31 As a first step on the multithread route, we can do it like freeminer, and move basic server tasks out of the thread that does the mods. 22:44 est31 so e.g. chat or moving SAOs aroung will still work, even when the server is busy doing other things 22:44 est31 around* 23:38 hmmmm sure 23:38 hmmmm we should continue this discussion on the dev mailing list, don't you think? 23:38 est31 good idea 23:38 VanessaE we have a mailing list? :P 23:39 est31 http://lists.minetest.net/archives/minetest-dev/2015-April/thread.html 23:39 est31 very testy 23:44 est31 ShadowNinja still hasnt said why my provider is greylisted 23:44 est31 also idk what that even means 23:44 VanessaE it means your provider is thought to be a source of spam. 23:45 est31 whatever, I didnt have to give them my mobile phone number 23:45 est31 which is good 23:45 VanessaE didn't say it was such a source :) just that that's what I got when I looked it up yesterday 23:46 VanessaE (looked up "greylist" that is) 23:49 est31 btw, what happened of that nice ascii art network protocol comment? 23:49 est31 did it get deleted? 23:50 VanessaE ? 23:50 VanessaE on the list? I see only one post at the moment. 23:50 est31 somewhere in network src, there was an ascii art 23:50 VanessaE oh 23:51 hmmmm you know 23:51 hmmmm I seriously wonder how much contention the envlock really has 23:51 hmmmm locks aren't slow, contention in locks is 23:55 VanessaE looks like it was removed, est31. I don't find it anyway from a quick skim of the network code 23:55 VanessaE (unless it's just so small I missed it) 23:56 est31 nono was bit larger 23:56 est31 I guess nrzkt didnt want to maintain it 23:57 VanessaE est31: then I guess it's gone. good luck finding the commit that nuked it though 23:57 est31 even if if it isnt maintained, its of no use 23:58 hmmmm so right now the client message model is that the game loop grabs events from multiple sources, e.g. network and environment 23:59 hmmmm we know this /works/, but does this make sense? 23:59 hmmmm shouldn't the game loop maintain a thread-safe message loop that it exposes to event producers, such as the environment and network? 23:59 VanessaE hmmmm: sure, it makes perfect sense, if we can guarantee that no one event will ever take longer to process than the minimum amount of time that it'll take for another event to arrive