Time Nick Message 06:00 Zeno` est31, I updated my comment (just in case you missed it) ;) 06:00 Zeno` just checking the std now, but I'm 99.999999% positive bitshifts on signed numbers are implementation-defined 06:00 nrz Hey Zeno :D 06:01 Zeno` hi. been a while :D 06:01 nrz of course :) 06:01 Zeno` hehe, ok, left shifts are undefined behaviour 06:02 nrzkt better like this :) 06:02 Zeno` :P 06:02 Zeno` how's things? 06:03 est31 hey Zeno` 06:03 est31 so what do you think should be done about it 06:03 est31 also, do you like the feature at all 06:03 est31 paramat didnt 06:05 Zeno` est31, I guess I'd cast them to u64 before shifting 06:05 Zeno` it's just to get a unique number, right? 06:05 Zeno` number/seed 06:05 est31 yes 06:06 Zeno` yeah, I doubt the undefined behaviour matters in that case but I'd cast anyway 06:06 Zeno` (for the sake of "properness" heh) 06:06 Zeno` I don't mind the feature btw 06:09 Zeno` I've also changed my mind. Bitshifts are the clearest way to do what you're doing 06:09 nrzkt u64 should be used for every unique ID 06:11 hmmmm undefined? 06:12 Zeno` hmmmm, yes 06:12 hmmmm I thought the operation forces them to implicitly convert to an unsigned type 06:12 Zeno` apparently not 06:12 Zeno` 6.5.7 06:12 Zeno` para 4 06:12 hmmmm is this from the C++ spec or C spec 06:13 hmmmm i've been noticing subtle differences between the two in regard to type promotion and conversion 06:14 Zeno` C 06:14 Zeno` umm, I don't think there's a difference there... but 06:14 Zeno` looking 06:15 Zeno` the C++ standard says that if anything isn't mentioned than the C standard applies 06:15 Zeno` still looking... 06:15 est31 hmmmm, what do you think about the feature 06:16 hmmmm what feature 06:16 Zeno` yep undefined 06:16 Zeno` 5.8.2 06:17 hmmmm heh good to know 06:17 est31 the one i add in #2910 06:17 ShadowBot https://github.com/minetest/minetest/issues/2910 -- Treegen: Add enable_unique_ids option by est31 06:17 hmmmm although I don't think I ever do bit operations on signed types to begin with 06:17 hmmmm out of principle 06:17 Zeno` it's only undefined if the value is actually negative though 06:18 hmmmm aren't enum values implicitly signed? i.e. enum values defined with (1 << n) are relying on undefined behavior 06:18 Zeno` Otherwise, if 06:18 Zeno` E1 06:18 Zeno` has a signed type and non-negative value, and 06:18 Zeno` E1 06:18 Zeno` × 06:18 Zeno` 2 06:18 Zeno` E2 06:18 Zeno` is representable 06:18 Zeno` in the corresponding unsigned type of the result type, then that value, converted to the result type, is the 06:18 hmmmm ahh okay 06:18 Zeno` resulting value; otherwise, the behavior is undefined 06:18 Zeno` shit 06:18 Zeno` didn't know it'd do that 06:18 hmmmm fwiw I absolutely can't stand it when people misuse enum 06:19 hmmmm using enum as set of flags 06:19 hmmmm using enum to define a constant integer value 06:21 Zeno` I use 1U << :) 06:21 Zeno` but probably not in an enum 06:21 Zeno` #define usually 06:22 est31 isn't enum meant to supersede #define ?? 06:22 hmmmm absolutely not 06:22 est31 i mean for that usecase 06:22 hmmmm not for flag-types, no. 06:25 est31 I have mixed enums and flags a *bit* for srp 06:25 est31 the server sends a list of supported auth protocols as a flagbyte 06:25 est31 then the client decodes it, and choses one auth mechanism 06:26 est31 that is then stored as enum 06:26 hmmmm that is fine 06:26 hmmmm selecting one option of numerous 06:26 hmmmm storing numerous options... is not fine 06:27 hmmmm an enum is supposed to be a data type where only those enum options are the possible values 06:27 hmmmm it may be undefined behavior to attempt to store a value not part of an enum into an enum 06:27 Zeno` pretty sure it *is* undefined 06:27 hmmmm but at the very least, you lose the advantage in debugging 06:29 kahrl_ the C++ standard defines enumeration types in terms of their underlying integral type 06:29 kahrl_ so I'm pretty sure using them as flags is legal 06:30 Zeno` but, hmmmm, you could have enum { BLAH = 1U << 0; FOO = 1U << 1; BLAH_AND_FOO = 1U << 0 & 1U << 1; } I suppose 06:30 hmmmm the underlying integral type's only assurance is that it's convertable to int, no? 06:30 Zeno` I think what hmmmm is saying is that you should store the byte flags (combined) in the enum 06:30 hmmmm which means you don't have any hard guarantees on how many options you can fit beyond 16 06:30 hmmmm or rather, 15 :) 06:30 Zeno` which I'd agree with 06:31 Zeno` hmm 06:31 Zeno` I'm confused by what's being said now, lol 06:31 hmmmm Zeno`: yes, you can have that. but specifying each and every combination defeats the purpose of flags 06:31 Zeno` hmmmm, should NOT* store the byte flags (combined) 06:31 hmmmm right 06:32 Zeno` yeah, that would seem like abuse of the enum 06:33 hmmmm hmm 06:33 Zeno` I've never seen code that does that though I don't think 06:33 hmmmm i can't find my C++11 spec 06:33 hmmmm I have... 06:33 hmmmm it's horrifying because the people who do that believe they are so clever 06:33 hmmmm "look at all these high level C++ constructs I am using!" 06:34 kahrl_ hmmmm: http://paste.debian.net/282818/ 06:34 kahrl_ see 6. specifically 06:34 hmmmm nice 06:37 Zeno` kahrl_, you don't agree that it would be bad form to write something like.... MyEnumType flags = ENUMA | ENUMB; 06:37 Zeno` I don't like that much at all. heh 06:38 kahrl_ does that even work? wouldn't you have to define an operator| first? 06:38 Zeno` no sure 06:38 Zeno` not* 06:38 kahrl_ like in http://stackoverflow.com/a/1448478 06:39 Zeno` http://codepad.org/Vp3YVtdF 06:39 Zeno` heh 06:42 kahrl_ ugh, how do I tell github markdown to not change tabs to spaces in a code block 06:42 hmmmm yuck 06:43 kahrl_ I guess I'll have to upload my tiny patch as a gist or commit 06:43 hmmmm nobody has tried this so far but would you agree to banning enum-flags? 06:43 Zeno` it works fine now that I've cast the expression 06:43 Zeno` kind of ugly though lol 06:44 Zeno` fully conforming and elegant: http://codepad.org/tjzhmeys 06:45 hmmmm hm i'm surprised you don't need to cast A and B to int first 06:46 Zeno` http://codepad.org/na6MkM2E 06:46 Zeno` I am guessing you can't actually use bitwise operators on enum values 06:46 Zeno` ? 06:46 Zeno` I never knew that. Probably because it never occurred to me to try it 06:47 hmmmm no 06:47 hmmmm you can 06:47 hmmmm look you're doing it with A and B the line above 06:47 Zeno` you can, but not assign them back to the enum 06:47 hmmmm the error is converting it back to blah 06:47 Zeno` yeah 06:47 Zeno` so you'd have to jump through hoops to do the ugliness anyway 06:47 hmmmm right. 06:47 hmmmm so anyway 06:48 hmmmm if you do this, it might be valid C++, but you lose all advantages of enums in debugging 06:48 Zeno` interesting diversion for 30 minutes :) 06:48 hmmmm and then there's the uglyness 06:48 hmmmm the only people who would write code like this are those holier-than-thou language "experts" 06:48 hmmmm you know the ones i mean 06:50 Zeno` haha :) 06:50 Zeno` Linus 06:51 Zeno` lol, just kidding 06:51 Zeno` I had a program once.. an expression parser thing 06:51 Zeno` wonder what I did with it 06:52 Zeno` kahrl_, you wrote it? 06:52 Zeno` yikes! Time! bbl 06:52 Zeno` cyas on the flipside 07:41 est31 opinions on #2916 07:42 ShadowBot https://github.com/minetest/minetest/issues/2916 -- Use Z-order curves? Or split up the coordinates? 09:51 VanessaE another backtrace added to #2913 09:51 ShadowBot https://github.com/minetest/minetest/issues/2913 -- Unexplained, random crashes (segfaults, aborts, OOM) 09:52 est31 VanessaE, fix the formating 09:52 VanessaE oops 09:52 est31 well this line the lines are broken at least 09:52 VanessaE fixed. 09:52 VanessaE forgot to wrap the paste in ``` ``` 09:55 est31 first it crashed at the deallocation of a SharedBuffer, now it cries at the allocation of a SharedBuffer. 09:55 est31 the first one was an assertion failure 09:55 est31 whats this 09:57 VanessaE beats me, this last one didn't even allow the engine to throw a "shutting down..." message to clients 10:06 nrzkt you should find which SharedBuffer is used and why it's misused 10:06 est31 nrzkt, you are the network guy 10:07 nrzkt SharedBuffer is not used in network 10:07 est31 #6 0x00000000005fbaa6 in con::ConnectionReceiveThread::receive (this=0x7fffffffe438) at /home/minetest/minetest_core/src/network/connection.cpp:2099 10:08 nrzkt i miss this line, sorry. 10:08 nrzkt I'm at work i cannot look at this atm 10:09 nrzkt and kicking player on shutdown is not a role of a mod. Mod is an extension for the core. Core doesn't need to be extended for kicking player at shutdown, it's a core normal function. 10:09 est31 nrzkt, if we dont kick players on a crash the feature is half assed and we don't meet user's expectations 10:10 nrzkt the crash issue should be avoided by using a ping packet function 10:10 est31 mods can do this stuff already, and no need for c++ on this 10:10 est31 if there werent the crash issue, i would even have agreed it being in lua 10:10 nrzkt proper shutdown should be handled by core, kicking all player before unallocating everything 10:11 est31 yes, thats ok, but only if together when we look for a crash 10:12 est31 also kicking should only be done for players using the legacy protocol 10:12 nrzkt why ? 10:12 est31 because ERROR: ACCESS DENIED is bad 10:13 est31 or ERROR:ACCESS DENIED. REASON: KICKED: REASON: SERVER SHUTTING DOWN 10:13 est31 instead it should read SERVER SHUTTING DOWN 10:13 nrzkt right 10:14 est31 so we need a proper "TOCLIENT_SERVER_SHUTDOWN" packet 10:14 est31 or however its named 10:15 nrzkt agree with this. 10:15 nrzkt but what does kick player function ? 10:15 nrzkt ACCESS DENID ? 10:15 nrzkt because it remove the datas and then the UDP socket doesn't work ? 10:15 est31 yes, it shows that in the client last time i checked 10:16 nrzkt okay i see 10:16 nrzkt for legacy we don't have choice 10:16 est31 if i see a way to do it, I will change it to "you have been kicked", ok? 10:16 TBC_x better would be Disconnected fom server\nKicked: $REASON and Disconnected from server\nServer shutdown 10:17 TBC_x rather than adding specialized packet IMHO 10:17 nrzkt i think the TOCLIENT_SERVER_SHUTDOWN is a good idea, and this packet show the connection error screen and close properly resources clientside 10:17 nrzkt or better 10:17 nrzkt TOCLIENT_KICK 10:17 TBC_x so string like Disconnected from server\n$CUSTOM_STRING 10:18 nrzkt with a u8 REASON std::string custom_string 10:18 est31 ah i see 10:18 nrzkt like in the new error message at connection, 10:18 est31 TBC_x, remember that the message is the same for wrong password and kicks 10:18 nrzkt u8 reason => classic messages, which can be translated 10:19 nrzkt and reason == KICKREASON_CUSTOM we read string 10:20 nrzkt then, mods can kick with a custom reason :) 10:21 TBC_x that makes sense 10:23 nrzkt okay then 10:24 nrzkt est31, are you hot to code this, or minetest will wait for my PR in next days ? :) 10:28 est31 nrzkt, take your time, and make it properly 10:32 nrzkt i propose first, to add the function to kick players with the current method at shutdown 10:32 nrzkt and next, the new function 10:33 VanessaE wtf guys? 10:33 VanessaE are you insane? 10:33 VanessaE telling the player they've been KICKED? 10:33 VanessaE no 10:33 VanessaE that's a flat out NO 10:33 VanessaE players think kick -- ban 10:33 VanessaE == 10:34 nrzkt if you ban, tell them you ban 10:34 nrzkt :p 10:34 VanessaE it should show one and ONLY one thing to the client: "Disconnected -- server shutting down... or similar. 10:34 VanessaE nrzkt: it doesn't work that way in a production server. 10:34 VanessaE ANY kick, to a user, looks like a ban 10:34 VanessaE even if you expressly tell them it's not a ban 10:35 est31 VanessaE, you should comment on #2845 10:35 ShadowBot https://github.com/minetest/minetest/issues/2845 -- Kick players on server shutdown by red-001 10:35 nrzkt VanessaE: we are talking technically there. 10:36 nrzkt the message is a futile string, KICK is a technical word there 10:36 nrzkt Server Shutdown is the message shown to client. 10:36 VanessaE nrzkt: yes and when you send a kick command to the client, it's gonna tell the user they've been kicked. 10:36 nrzkt KICK is generic for our packet 10:37 nrzkt we will not create a packet to kick and a packet to shutdown server 10:38 nrzkt it's the same way to handle it on client 10:38 TBC_x Wouldn't it be better to replace bools with enums in void Client::addUpdateMeshTaskWithEdge(v3s16 blockpos, bool ack_to_server, bool urgent) and such? 10:39 est31 ?? 10:39 VanessaE est31: commented. 10:39 TBC_x because addUpdateMeshTaskWithEdge(i->first, false, true) won't tell much 10:40 est31 so you want to do what instead? 10:40 nrzkt thanks VanessaE 10:40 TBC_x addUpdateMeshTaskWithEdge(i->first, NO_ACK, URGENT) for example 10:40 est31 meh, rather no 10:40 TBC_x you know what it means without looking up the definition 10:40 est31 yea has a charme 10:41 est31 but you have to define the enum somewhere 10:41 est31 you will have to think of a nice name for the enum 10:41 est31 then how do the checking? 10:41 est31 If urgency_level == URGENT then 10:41 est31 thats bad 10:41 est31 the user has to look up the enum instead 10:42 TBC_x good point 10:42 est31 what if there is SUPER_URGENT, and URGENT is the "less urgent" one? 10:44 VanessaE sorry to be a hard-ass with my comments here, but I have to deal with total idiot users on an continuous basis, so whatever message is sent to the client, it must be user-friendly above all else. 10:45 TBC_x hmm... namespace Bool { enum Urgent } could solve that 10:46 TBC_x or just use const bool URGENT = true 10:46 est31 ah dude 10:47 TBC_x hehe 11:04 est31 rebased #2885, nrzkt would be perhaps good to have network maintainer have a look at it 11:04 ShadowBot https://github.com/minetest/minetest/issues/2885 -- Utf8 based chat by est31 15:42 nrzkt VanessaE crazyR: https://github.com/minetest/minetest/pull/2918 15:42 nrzkt i push it in 3 hours if no objection 15:43 nrzkt #2918 15:43 ShadowBot https://github.com/minetest/minetest/issues/2918 -- Kick players when shutting down server by nerzhul 15:45 crazyR nrzkt looks good, althought i think build checks have failed. you may wanna have a quick look :) 15:47 nrzkt i will look at home, a++ 16:16 Krock I ran into a struct array problem: http://pastebin.com/DUe6iuMJ What's wrong here? It gives me an error about a misplaced '{' in the line "a_env[ENV_UNKNOWN] = {" 16:16 H-H-H that failed due to not being able to download irlict source 16:18 nrzkt #2918 refactored to have a custom string when kicking all players. Also use it when Lua stack exception shutdown occurs 16:18 ShadowBot https://github.com/minetest/minetest/issues/2918 -- Kick players when shutting down server by nerzhul 16:19 nrzkt for core segfault is not handlable with this, because it's a coredump 16:20 Krock oh well, could someone tell me how I could solve that problem? 16:20 nrzkt H-H-H right, i have this error 16:21 nrzkt the next build works properly, hopefully 16:21 H-H-H nrzkt you also do android builds dont you 16:21 nrzkt ofc 16:22 nrzkt it's a Debian VM under BHyve on FreeBSD on my own server 16:22 H-H-H have you tested any recent android builds on hardware / 16:22 nrzkt which is a jenkins slave 16:22 nrzkt no, i haven't do android build since a long time. Is there any problem ? 16:23 H-H-H i can build head for android but theres something wrong with the sound it seems it is seriously loud and distorted however i can build stable 0.4 for android and the sound is fine 16:23 nrzkt i also noticed with clang that SRP needs a little fix, i will talk to est31 to fix those warns 16:23 H-H-H tested on galaxy fame and galaxy note 10.2 16:23 H-H-H 10.1* 16:23 nrzkt i didn't worked on sound, but i could test it maybe 16:23 nrzkt https://jenkins.unix-experience.fr/job/minetest-android-OfficialRepository-RollingRelease/ 16:24 nrzkt have you tested this APK ? 16:24 H-H-H i used exactly same setup as in ndk and sdk were same when i built the 2 and as i say stable-4.0 works fine just not head 16:24 nrzkt this a daily build which generate an apk for users 16:24 H-H-H i will d/l and test now 16:25 nrzkt you can test many APK, there is a build history, one build per day :) 16:25 H-H-H will have to sign it first :) 16:25 nrzkt oh, you must be logged to dl ? 16:25 H-H-H nope im not logged in 16:25 nrzkt ah oh no, sign the apk 16:25 nrzkt it's not needed, it's a debug apk 16:26 H-H-H i just saw a link that was the unsigned one 16:26 H-H-H it says its minetest-release-unsigned 16:26 nrzkt yes, signing is done on my PC if i remember, i will automate it on jenkins maybe at next release 16:26 H-H-H i can sign it no big deal 16:26 nrzkt it's not needed for debug builds :p 16:27 nrzkt oh no 16:27 nrzkt it's a release build, not a debug build, i looked at the command line 16:27 nrzkt you can test and bissect, this will show a commit interval 16:29 H-H-H signed now installing 16:30 nrzkt good luck for your tests 16:32 H-H-H thanks for your help it seems i must be missing something in my build setup as minetest 0.4.12-315b works fine :| 16:35 H-H-H hmm ok thats not head of minetest thats head of stable -0.4 16:35 H-H-H i mean master has sound issues 16:36 nrzkt i don't think this is maintained... 16:41 H-H-H yeah it just gets built from the stable-0.4 branch 16:41 H-H-H try building an apk from master branch :) 17:19 H-H-H hmmm seems like the bah sourceforge is down so irrlicht d/s are down 17:20 nrzkt down and up sometimes 17:20 nrzkt i will download it locally 17:25 H-H-H i have it in a git repo i could add to github if it helps 17:26 H-H-H sorry i meeant svn 17:27 nrzkt we could add it as a download on github minetest also 17:28 H-H-H would need to be maintained though 17:28 nrzkt yes 17:28 nrzkt http://irrlicht.sourceforge.net/ is down too 17:30 TBC_x shouldn't we use nullptr instead of NULL where possible? 17:30 nrzkt why ? 17:30 sfan5 why? 17:31 TBC_x if we'll migrate to C++11 eventually... it would work with smart pointers 17:31 sfan5 is smart pointers using auto everywhere? 17:31 sfan5 if thats the case, no 17:32 TBC_x smart pointers have specializet template for comparing nullptr 17:32 sfan5 sounds like a lot of overhead 17:33 TBC_x for compiler, maybe 17:33 TBC_x you can't initialize smart pointer with NULL 17:34 TBC_x I'm tracking the memory leak with smart pointers btw 17:35 sfan5 not being able to use NULL sounds like a stupid thing 17:36 TBC_x you'll get used to it, probably 17:36 sfan5 you know 17:36 sfan5 NULL has a point 17:36 sfan5 ah 17:36 sfan5 https://en.wikipedia.org/wiki/Smart_pointer 17:37 sfan5 it was those things 17:37 sfan5 answer: no 17:37 TBC_x reason? 17:37 sfan5 a lot of work 17:38 TBC_x replacing NULLs? 17:38 sfan5 no 17:38 TBC_x replacing raws? 17:38 sfan5 replacing every single mention of pointers 17:38 TBC_x could find someone to do it 17:39 sfan5 thats not the point 17:39 sfan5 it changes a lot of code 17:39 sfan5 causes merge conflicts with most if not all PRs 17:40 TBC_x could be done progressively 17:41 sfan5 still causes merge conflicts 17:42 TBC_x rebase 17:42 TBC_x needs coordinating 17:42 sfan5 lolno 17:43 sfan5 you won't get anyone to agree to rebase all the PRs 17:44 TBC_x true 17:45 TBC_x could change all pointers when refactoring tho 17:45 TBC_x as refactoring may cause merge conflicts anyway 17:46 sfan5 refactoring does not happen on all code at the same time 17:47 TBC_x rewriting for smart pointers usually requires to change a single line 17:48 sfan5 because only a single line of code uses the pointer types, right? 17:49 TBC_x not necessarily 17:50 TBC_x you can unwrap it if you need to use raw pointer 17:51 sfan5 that would be stupid 17:51 TBC_x yes 17:51 sfan5 then the majority of code would use raw points 17:51 sfan5 pointers* 17:51 sfan5 just to have less changed lines 17:54 TBC_x need to compe up with a better transition strategy before and if that happens 17:54 sfan5 or alternatively we just leave all the code alone and don't use smart pointers 17:56 TBC_x unless the code has significant memory leak and is hard to track down 17:57 sfan5 transitioning all code to smart pointers will cause more problems than fix memory leaks 17:57 TBC_x I'm aware of that 17:58 sfan5 why are you even trying to argue then 17:59 TBC_x majority of the problems would be just revealed by the smart pointers, not caused by them 18:00 TBC_x if you don't count needed refactoring as a problem 18:03 nrzkt last call: #2918 will be pushed in 30 min (android build failed due to sourceforge pb) 18:03 ShadowBot https://github.com/minetest/minetest/issues/2918 -- Kick players when shutting down server and fatal Lua stack exception occurs by nerzhul 18:11 hmmmm that's not a trivial PR 18:12 nrzkt i tell this 2 hours ago. hurry hup. And this was discussed with est31 and 30 min are okay :p 18:12 hmmmm where 18:12 hmmmm i don't see est31's approval anywhere 18:14 hmmmm you can't just push non-trivial commits without approval because you gave two hours notice 18:14 nrzkt we talked about the approach to do and it's approach to do. 18:14 sfan5 taking about PR does not suffice 18:14 hmmmm where is this conversation, i can't see it anywhere 18:14 nrzkt and it's a trivial fix :) 18:14 hmmmm it's not trivial. 18:14 sfan5 you need explicit approval 18:14 hmmmm this changes functionality, and in a bad way. 18:14 sfan5 and no it's not trivial 18:14 hmmmm in fact i'm about to -1 this commit because it's the wrong approach 18:15 hmmmm you shouldn't try to do anything non-trivial on crash 18:15 nrzkt okay then, what is good ? for a compat issue 18:15 nrzkt the good approach cannot be used with compat 18:15 hmmmm when an application crashes, it is in an undefined state where anything could possibly happen 18:15 nrzkt the good approach is to have a proper packet to sent to client and handle it. Here we use the compat way. 18:15 nrzkt this is not the final way, it's the compat 0.4 way 18:16 nrzkt here we don't handle minetest core crash 18:16 nrzkt the only path where the message is sent, if you read the PR correctly is when there is: Lua fatal error => exit and proper shutdown => exit 18:16 nrzkt not coredump 18:17 nrzkt coredump is not the PR goal. 18:17 hmmmm well 18:17 hmmmm I suppose this is okay 18:18 nrzkt and also, another proper thing we should add for future protocol is a TOSERVER_PING/TOCLIENT_PONG to handle the crash over Udp 18:18 hmmmm it's only handling uncaught exceptions, and not deeper bugs like memory corruption or memory access violations 18:18 hmmmm fine, +1 18:18 nrzkt thanks. 18:18 hmmmm but you can't just lie to us that you had approval from other people first 18:18 hmmmm that's a huge no-no 18:19 nrzkt this approach was discussed, then, i thought it's a go to code pr and review :p 18:19 hmmmm an idea is not the same as its implementation 18:19 nrzkt for coredump i dont think we could notify client without PING/PONG packets 18:20 hmmmm when a code review is done, the actual code written is reviewed as well as the approach taken 18:20 nrzkt PING/PONG can also permit to have timeouts clientside 18:22 hmmmm don't take this personally, but you are way too commit trigger-happy 18:22 hmmmm code isn't going to spontaneously combust if it isn't merged within a day or two 18:24 kahrl_ I thought there were already pings in the protocol 18:24 kahrl_ the lower-level one 18:24 kahrl_ are they not used? 18:25 nrzkt no problem :) 18:26 nrzkt kahrl_ : no atm if you server crash client stays ingame 18:26 sfan5 they are used 18:26 sfan5 but the client doesnt disconnect 18:26 nrzkt something is missing clientside then 18:26 sfan5 indeed 18:27 nrzkt i will push it now 18:28 nrzkt pushed 18:37 kahrl_ I see that Client::deletingPeer(timeout=true) is getting called in this situation 18:37 kahrl_ so all that needs to happen is that that method actually does something 18:44 kahrl_ something as simple as https://gist.github.com/kahrl/f58cce9dd468045c8fa4 might work 18:44 kahrl_ (I've tested that it works in this situation, but not yet that it won't break other situations) 22:52 crazyR would someone please document the tabheader[] formspec feild int he wiki please