Time Nick Message 00:04 hmmmm est31: still no m_authstate? 00:04 est31 ? 00:04 hmmmm what does m_authstate == 0 mean and how about == 1? 00:09 est31 ah 00:10 est31 dammit 00:10 hmmmm no i'm really curious 00:10 est31 not needed 00:10 hmmmm :) 00:11 * est31 removes it 00:16 paramat now pushing 2680 00:16 est31 I need it serverside 00:16 est31 not clientside 00:17 est31 or do I? 00:18 est31 there is nothing breaking when I call srp_verifier_verify_session without having set other variables before 00:18 est31 just failing to compare with the supplied M 00:19 est31 of course there is the slight chance that the memory garbage ver->M is (its uninitialized after all) can be of some previous login 00:19 paramat done 00:19 est31 or guessable by the attacker 00:19 est31 eg its 0s everywhere 00:19 est31 which then enables everybody to log in without knowing the password 00:20 est31 uh, that isnt good 00:20 * est31 needs that 00:47 est31 ah dont need it after all 00:47 est31 bc the chosen_mech has to be set 00:48 est31 thats enough 00:59 est31 ok then hmmmm do you +1? 01:01 hmmmm you're missing header guards even 01:01 hmmmm come on man =/ 01:02 est31 all this #ifdef ABC_H stuff? 01:02 hmmmm est31, would you agree for me to do some refactoring after the fact?? 01:03 est31 yes ofc 01:03 hmmmm what you have is 85% there but i'd rather not drag your PR down with more mediocre details 01:05 est31 so you mean its functional, just style issues? 01:05 hmmmm a little of obth 01:05 hmmmm both 01:07 hmmmm btw did you ever add in a comment explaining SudoMode? 01:07 est31 multiple times yes 01:08 est31 added include guards to auth.g 01:08 est31 h* 01:08 hmmmm ahh okay i see them 01:08 est31 "// The authentication methods we can use to enter sudo mode (=change password)" 01:08 est31 "... for sudo mode handling (auth mech generic way of changing password)." 01:09 hmmmm so wait, why is it called sudo mode again 01:09 est31 its like when you do sudo 01:09 est31 you authenticate do something and deauth 01:09 est31 sudo is nice and short 01:10 est31 I dont want to name it password_change_mode 01:10 hmmmm i don't know about you, but in general people don't like 'nice and short' 01:10 hmmmm people like 'immediately obvious and descriptive' 01:10 hmmmm i dunno, I never thought password changing should require entering into a 'mode' 01:10 kahrl passwd in unix doesn't use sudo anyway, it uses setuid 01:11 hmmmm i'm really nervous about just merging as-is, because protocol changes can't be fixed after the fact 01:11 est31 its disabled 01:11 hmmmm i'm mostly looking at the flow and which fields are sent 01:11 est31 protocol version 24 is used 01:12 hmmmm for example 01:12 est31 and if people want srp, they edit networkprotocol.h and set the define to 25 01:12 hmmmm TOCLIENT_ACCEPT_SUDO_MODE and TOCLIENT_DENY_SUDO_MODE 01:12 hmmmm those are two opcodes for basically a yes/no response of the same message 01:12 est31 yes 01:13 hmmmm we have a 16 bit command field, right? 01:13 est31 a good thing to improve the deny packet is by adding a reason 01:13 est31 lemme check 01:13 hmmmm you can trivially make a field optional 01:14 est31 I dont see how it would be simpler 01:14 est31 bikeshedding for me 01:14 hmmmm not necessarily simpler, just more organized 01:14 hmmmm but this does make it simpler because look 01:15 hmmmm you only change state in a single packet, not one or the other 01:15 est31 there is both TOCLIENT_ADDNODE and TOCLIENT_REMOVENODE 01:15 est31 can be fixed by sending a single flag there too 01:15 hmmmm doesn't addnode also have metadata 01:15 est31 optional 01:15 hmmmm you don't need to repeat past mistakes 01:16 est31 I still dont get why you want to unify it 01:16 hmmmm think of it in terms of RPC 01:16 est31 how would you name it? 01:17 hmmmm each of these packet pairs are a function call and function result 01:17 est31 TOCLIENT_ACCEPT_OR_DENY_PASSWORD_SET_MODE ?? 01:17 hmmmm the client makes a call on the server, the TOSERVER_WHATEVER, and the server sends back a TOCLIENT_WHATEVER_RESULT 01:18 hmmmm but instead what you have is 01:18 hmmmm TOSERVER_WHATEVER 01:18 hmmmm and it could return one of two responses 01:19 est31 so you want to move network code to your RPC like design pattern? 01:20 est31 Issue is, where do you set the 0 line? 01:20 hmmmm no, i'm just saying that's the model that protocol have at a very high level 01:21 est31 we already have two different packets for denying and granting access 01:21 est31 and the deny packet can be sent middle in the authentication process 01:21 est31 when the client does something unexpected 01:21 est31 the accept only at the end 01:22 est31 I'm ok with you changing it 01:23 hmmmm what's up with is_empty?? 01:23 est31 some server owners want to restrict passwords to non-empty 01:23 hmmmm why is that necessary exactly? 01:23 hmmmm okay 01:24 est31 its even announced in the serverlist if I remember right 01:24 est31 freeminer even uses that to display a small lock icon in the client serverlist 01:24 est31 interesting sense of security 01:25 est31 you can let the server "check" every proposed password to be hash("") 01:25 est31 but that requires it to exeture harh() 01:25 est31 hash()* 01:25 hmmmm that wouldn't work with SRP. 01:25 est31 it will 01:26 hmmmm you need to do extra stuff. 01:26 est31 yes 01:26 est31 because once we make hash() hard to execute, the server will do lots of computation for nothing 01:26 est31 "nothing" 01:27 est31 and if people are smart enough to lie with is_empty, then its their fault to have an empty password 01:27 est31 right now they can lie too 01:27 est31 or not 01:27 est31 also the u8 flag is nice to have for future extensions 01:28 est31 like when we want to add a stronger hash mechanism 01:29 est31 other issues :D 01:30 est31 ? 01:30 hmmmm you know the more i think about it the more i wonder about SRP_FIRST 01:30 est31 better name? 01:30 hmmmm well, that of course, but it's not really a different authentication method 01:31 hmmmm it's the same SRP, just using it to do something different 01:31 hmmmm that other game i wrote an SRP implementation for has its own separate set of create new account/change password packets 01:31 est31 so you want new packets again lol 01:31 hmmmm not necessarily 01:32 hmmmm i'm thinking about which approach could be better 01:34 est31 An auth mechanism is something that the client can use to show to the server "hey I want to get associated to the following username" 01:35 est31 and if we have other mechanisms than srp, the client perhaps wants to upload their public key 01:35 est31 or they want to say "use this google account name to log me in in future" 01:38 est31 A change I would agree with would be to make TOSERVER_FIRST_SRP more generic 01:38 est31 perhaps call it TOSERVER_CREATE_ACCOUNT 01:38 est31 it then has a field showing for which auth mechanism it is 01:38 est31 and then a std::string logindata 01:38 est31 depending on the auth mechanism 01:39 est31 then, for the srp case, its a salt value and a verification key value 01:43 hmmmm and what does AUTH_MECHANISM_LEGACY_PASSWORD actually do? 01:43 hmmmm i get what it does in theory, but i look at the code and it seems to me like it's all the same as AUTH_MECHANISM_SRP 01:43 est31 yes 01:43 est31 / SRP based on the legacy hash 01:43 est31 networkprotocol.h line 913 01:44 hmmmm so the only difference here is that it uses the legacy hash as the password when generating the verifier, I guess?? 01:45 est31 yes 01:46 hmmmm in any case 01:46 hmmmm FIRST_SRP is not a mechanism 01:46 hmmmm it's a flag 01:47 hmmmm a mechanism is like you said, private key authentication or whatever 01:48 est31 correct 01:48 est31 every mechanism is a flag 01:48 hmmmm that's how it's set up 01:48 est31 yes 01:48 hmmmm but strictly speaking it does not function as a separate mechanism for authenticating a user 01:48 est31 why 01:48 hmmmm you're still using SRP 01:49 est31 do you speak about FIRST_SRP or LEGACY_PW 01:49 hmmmm what does "42" do in sendInit()? 01:49 hmmmm I speak of FIRST_SRP 01:49 est31 FIRST_SRP doesnt do SRP 01:49 est31 it does SRP_ENROLLMENT 01:50 est31 perhaps a better name 01:50 est31 not FIRST_SRP 01:50 est31 but ENROL_SRP 01:50 est31 but ENROLL_SRP 01:50 hmmmm it does stuff related to SRP 01:50 est31 yes 01:51 hmmmm to me, at least, an "authentication method" is some method that has a set of methods to it 01:51 hmmmm such as "how do I create an account for ?" 01:51 hmmmm or "how do I change my password for ?" 01:51 hmmmm and "I want to log in using this method" 01:52 hmmmm this would work for SRP, this would work for LEGACY_AUTH, but this abstraction wouldn't hold true for FIRST_SRP 01:52 hmmmm you can't log in with FIRST_SRP 01:52 hmmmm so it's not a method of logging in 01:52 est31 yes it is 01:52 hmmmm you can actually complete a login with FIRST_SRP?? 01:52 est31 the connection isnt closed after FIRST_SRP 01:52 hmmmm yea it's not closed 01:52 hmmmm but the user is authenticated, or not? 01:52 est31 once the packet is sent you can start playing 01:53 est31 yes 01:53 est31 its like when you go to a newly discovered island and say "this is now my islanf" 01:53 est31 then its your island 01:53 hmmmm and now you said that creating a new account and changing password is the same because they both use FIRST_SRP 01:53 est31 you don't have to buy it from anybody 01:53 hmmmm but there is a difference 01:54 est31 changing passwords is something different 01:54 hmmmm the conditions of authorization for FIRST_SRP when creating a new account is that the previous account does not exist 01:54 hmmmm the conditions of authorization for FIRST_SRP when changing a password is that the previous password matches 01:54 est31 so? 01:57 hmmmm for creating an account, you only ever need to send your salt, verifier, and username. 01:57 hmmmm for changing an account password, you start out SRP by sending A and username 01:57 hmmmm those are two entirely different packets! 01:57 est31 ah 01:57 est31 I see now 01:57 hmmmm I don't know man 01:57 hmmmm I just feel like it's structured in a rather non-intuitive manner 01:57 est31 changing a password has two steps 01:58 hmmmm right, the request, then the proof 01:58 est31 1. authenticating with the old password 01:58 est31 2. setting the new password 01:58 est31 for 1, we can use everything 01:58 est31 like AUTH_MECHANISM_LEGACY_PASSWORD 01:58 est31 for 2 we use AUTH_MECHANISM_FIRST_SRP 01:58 est31 currently AUTH_MECHANISM_FIRST_SRP is the only supported mechanism for step 2. 01:59 hmmmm is LEGACY_PASSWORD used each time? 01:59 est31 no 01:59 hmmmm just the first time 01:59 est31 AUTH_MECHANISM_SRP can be used too 01:59 hmmmm I mean during the regular course of operation 02:00 hmmmm so the user has a legacy password 02:00 hmmmm wants to authenticate 02:00 hmmmm how does the user know that the password is a legacy password? 02:00 est31 if sb doesnt change their password nothing will happen no 02:00 est31 they will stay at the legacy password 02:01 hmmmm do you think the legacy password should get upgraded to an SRP verifier? 02:01 est31 that info is sent on TOCLIENT_ something 02:01 est31 again a byteflag 02:01 est31 TOCLIENT_AUTH_ACCEPT 02:01 est31 u32 : supported auth methods for sudo mode 02:01 est31 (where the user can change their password) 02:02 hmmmm so walk me through this logon sequence 02:02 hmmmm I am a user with a legacy password 02:03 hmmmm I am trying to connect to CoolServer with SRP enabled 02:03 hmmmm what do I say in particular that indicates i want to change this to SRP? 02:03 hmmmm what does the server tell me? 02:04 est31 there is no method for somebody who wants to upgrade without doing the sudo mode thing 02:05 hmmmm okay, so the user enters sudo mode 02:05 est31 then the user sends FIRST_SRP packet 02:05 est31 and has SRP 02:06 hmmmm how does a client request sudo mode? 02:06 est31 network/clientiface.h has a very nice ASCII art overview 02:07 est31 seen it? 02:07 hmmmm yeah 02:07 est31 the client just starts authenticating 02:08 est31 e.g. with BYTES_A 02:08 est31 thats this part of the ascii art: "any auth packet which was allowed in TOCLIENT_AUTH_ACCEPT" 02:08 hmmmm unless I'm mistaken, doesn't the ASCII chart say that the client starts sudo mode by sending TOSERVER_FIRST_SRP? 02:08 est31 no, thats the way it exits 02:09 est31 I should perhaps document TOCLIENT_DENY_SUDO_MODE 02:10 hmmmm i'm... sorta confused 02:10 hmmmm maybe some others should see what they think about it all 02:10 est31 ok 02:10 hmmmm i'm not saying it doesn't make sense, because it clearly does - it works, it's just that i can't figure it out right now 02:13 est31 np 02:45 hmmmm wtf 02:45 hmmmm the player's hand is now invisible 02:45 VanessaE eep 02:45 est31 perhaps due to that wielditem fix 02:45 est31 ? 02:46 hmmmm nope 02:48 hmmmm it's 3a8e734 02:48 hmmmm thanks shadowninja. 02:48 hmmmm two major bugs with this patch so far 02:49 ShadowNinja O_O 02:50 hmmmm i see the problem 02:50 ShadowNinja What'd I do? 02:50 hmmmm you made a series of horrible copy/paste errors leading to crashes and hidden textures 02:51 hmmmm ShadowNinja: look at check_v3f. 02:53 ShadowNinja Ah, pos.Z set twice, with Y ignored. 02:53 ShadowNinja Sorry :-( 02:54 hmmmm don't apologize to me, apologize to minetest! 02:57 hmmmm i'll fix it if nobody else will 03:29 est31 the android app xabber also used versions like 0.x.y before, and after 0.10.something they decided to continue with 1.0.5 03:29 est31 or 1.0.2 03:47 hmmmm lol 03:47 hmmmm novatux's randomized github avatar looks like a man with a moustache 04:06 hmmmm https://github.com/kwolekr/minetest/commit/df96746b4fba988b781e6a94b7771a67976feccc 04:18 hmmmm will push if nobody has complaints.. 04:51 hmmmm pushing... 04:51 est31 pushing in 15 mins https://github.com/est31/minetest/commit/33c11415bf9f05192c104c4bb38f579824addfa5 04:52 hmmmm a PacketError is when a packet does not have enough data in it for its type, correct? 04:57 hmmmm phew 04:57 hmmmm so I'm done for now with my unit test spike 04:58 hmmmm maybe sometime in the future when I'm motivated, i'll add a convenient way to take voxelmanip snapshots and then compare node-to-node for things such as schematic/ore/decoration placement 04:58 hmmmm also would be nice to do mapgen heightmaps, bulk liquid transform queue insertion, light calculations 04:58 est31 is mapgen deterministic? 04:58 hmmmm yes 04:58 est31 nice 04:59 hmmmm i can't test the mapgen directly because it... changes... 04:59 hmmmm one minor change would require you to update all the unit tests 04:59 hmmmm maybe for mapgen V6 we could have tests because that one's not supposed to change 05:02 VanessaE hmmmm: build failure: http://pastebin.ubuntu.com/11020323/ (works fine at 33c11415) 05:03 hmmmm I am going bonkers 05:03 hmmmm this is a slightly different manifestation of the same problem with the commit not too long ago 05:04 hmmmm for now, just add #include "util/numeric.h" to that file 05:04 est31 have you found out where the file is included? 05:04 hmmmm i ddidn't do that i'm going to do it now though 05:09 hmmmm heh 05:09 hmmmm mg_schematic.h -> mg_decoration.h -> mapgen.h -> nodedef.h -> client/tile.h -> util/numeric.h 05:11 est31 lol 05:11 hmmmm it's not a freebsd problem, it's a server-only-compilation problem 05:12 est31 ok 05:12 est31 somehow on freebsd it doesnt compile the server 05:13 est31 where is the #ifdef server ? 05:13 hmmmm no it doesn't compile the server by default ever since shadowninja's changes 05:13 est31 not nice 05:13 hmmmm so 05:13 est31 I guess I have some outdated config then 05:13 hmmmm although it might cut down linking time by half 05:13 hmmmm it causes me to miss out on these kinds of compilation errors 05:13 hmmmm :( 05:14 est31 test_schematic.cpp:119:23: warning: comparison between signed and unsigned integer expressions 05:14 hmmmm for remediation though, I'll strategically add an #include "util/numeric.h" in nodedef.h 05:14 est31 also on 101 and 82 05:14 hmmmm wtf I didn't get that warning :( 05:14 hmmmm clang needs to be more verbose i think 05:14 hmmmm are you using gcc? 05:14 est31 yes 05:14 hmmmm are there ANY other warnings 05:14 est31 no 05:14 hmmmm kk 05:15 est31 what wonders me a but 05:15 est31 bit* 05:15 est31 because I wanted to fix a warning I've caused 05:15 est31 now its gone 05:16 est31 ah 05:16 est31 because it only has problems in release builds 05:17 est31 so you merge your build fix then I merge my warning fix 05:18 est31 bisectors should get a small surface as possible 05:22 hmmmm yeah go ahead 05:22 est31 no you first 05:22 hmmmm i did 05:22 est31 ok 06:12 est31 hmmmm, what was that std hashmap again thats basically hashmap < list < T > > ? 06:16 hmmmm what do you mean 06:16 hmmmm std::unordered_map? that's C++11 06:17 est31 I want to construct a handler hashmap for settings, where you can register handlers that get called when that specific setting name gets changed 06:17 est31 now you could have multiple handlers in theory 06:17 est31 I want to use it first for c++ code only, but its planned to have lua later 06:17 hmmmm i had a different approach in mind 06:18 hmmmm instead of expanding settings callbacks, make settings fast 06:19 est31 ? 06:19 hmmmm with atomic operations and memory barriers, settings can for the most part be atomic 06:19 hmmmm no lock, no map, etc. 06:20 est31 so? 06:20 est31 do I interfere with your multithreading plans :p 06:21 hmmmm they're both ways of approaching the problem 06:21 hmmmm you want to modify the way the interface works by adding callbacks everywhere 06:22 hmmmm but it never does fix the underlying issue of using too much time for something as simple as settings 06:23 est31 yes 06:24 est31 but polling is bad 06:24 est31 pushing is better 06:24 hmmmm there is no polling 06:24 est31 With clouds, its easy because they are recreated every time 06:24 hmmmm it just reads the value 06:25 hmmmm well 06:25 hmmmm i would have no problem adding a settings callback for clouds, i suppose 06:25 est31 I think it can be used at other parts too 06:27 est31 for clouds, polling is perhaps even not that bad 06:27 est31 we are recreating them from scratch every time every way 06:27 est31 every render* 06:27 hmmmm that's not necessarily a good thing 06:27 hmmmm don't aggravate the problem 06:28 est31 just at other places people might have very different setups 06:28 est31 between two values for a setting 06:28 est31 so they could do of course polling, then compare with a variable 06:28 est31 but that isn't nice, is it? 06:30 hmmmm compare with a variable..? 06:30 est31 yes 06:30 est31 store the last result 06:30 est31 then compare it with that 06:30 est31 if match, then nothig changed 06:30 est31 else, fun begins 06:30 hmmmm yeah but what's the point 06:31 est31 with "fun" being the stuff inside the callback 06:32 est31 whats the point then? 06:32 hmmmm you're just reading some values from settings 06:32 est31 so the major performance hurdle for settings is that it requires locks? 06:32 hmmmm not necessarily 06:33 hmmmm it's that the locks are highly contended, and that it uses a std::map, and that it reparses the string value every time 06:33 hmmmm for something that really should be as simple as reading a memory location 06:34 hmmmm if reading settings wasn't so heavy, then we'd be able to have them inline with the rest of the code and never have to cache settings 06:34 est31 meh perhaps settings retrieval should base on some cool id instead? 06:34 est31 and then have an enum? 06:34 hmmmm basically, yes 06:34 est31 or is there some preprocessor hack for that 06:34 hmmmm there's nothing really wrong with an enum 06:35 est31 yes if code needs it at some place, we can still have a map for the exotic stuff 06:35 hmmmm right 06:35 hmmmm other people also had this idea 06:35 est31 eg for lua mods 06:35 hmmmm i think it was called 'core settings' 06:36 est31 and did it face opposition? 06:36 hmmmm no, i don't think so.. 06:36 est31 so what was the problem why it didn't get implemented then? 06:37 hmmmm lack of time? i don't know 06:38 est31 ok, future thing I may work on: backporting the utf8 fixes of xyz 06:38 est31 other future thing* 06:38 est31 any ideas why that hasn't been done? 06:38 hmmmm no clue 06:39 est31 there is one problem however 06:39 est31 current chat packets send wstrings 06:39 est31 this is horrible of course 06:39 est31 I mean its like depending on machine endianness 06:40 est31 just people might have gotten accustomed to it 06:40 est31 and fear the change 06:40 est31 now I wonder whether to simply break and send unicode 06:40 hmmmm ? 06:41 hmmmm sending a std::wstring is not sensitive to endianness at all 06:41 est31 yes 06:41 est31 but sensitive to the machines local encoding 06:41 est31 so it doesnt break always like with endianness 06:41 est31 (endianness breaks always when they dont match) 06:42 est31 but it still breaks when computers have different local encodings 06:42 hmmmm maybe in the init packet the server can report which code page it sends wide strings as 06:42 est31 oh no 06:42 est31 too complicated 06:43 est31 I mean it is possible to send unicode for "modern" servers and clients 06:43 est31 and wstring for all before 06:46 est31 but its more complex than breaking 07:23 est31 getting gazillions of warnings in gcc 5.1 07:24 est31 but at least they are colored 07:24 est31 yaay 07:24 est31 (gcc 5.1 turns on colors by default) 07:26 est31 mostly -Wdeprecated-declarations ones 07:28 est31 out of some reason leveldb doesn't like being compiled by gcc 5.1 07:28 est31 perhaps its problem of my setup options 07:29 est31 perhaps its leveldbs fault 07:29 est31 either way color is nice 07:29 * est31 will get it onto the system in october yaay ! 08:59 kilbith ok, the client crashes when you wield a mesh node with >6 tiles : http://pastie.org/10177446 11:22 est oooh I'm doing some ninja tricks to kill repetition 11:22 est or, expressed better, to avoid it 11:23 est because currently there isn't 14:46 est hmmmm, http://pastebin.ubuntu.com/11026990/ 14:47 est this is one of a gazillion warnings on gcc 5.1 usage 14:47 est and I wonder whether its my config being broken or minetest :) 14:47 est ideas? 14:51 sfan5 est: nope, irrlicht marked those methods as deprecated 14:52 est so you say its config? 14:52 est (my config) 14:55 sfan5 no 14:55 sfan5 it's what irrlicht decided 14:55 est irrlicht versions dont change 14:55 est only the compiler 14:56 est and gcc -v changes too 14:56 est gets much much shorter 14:56 est also I dont apply my distro patches 14:56 est vanilla gcc 15:44 hmmmm we want reverse compatibility with older versions of irrlicht 15:44 hmmmm can we just add -Wno-deprecated-declarations?? 15:45 hmmmm hmm, how about this: http://pastie.org/10177446 15:46 hmmmm I sense a general trend that assertions are overused. the vast majority of these things should be treated as invalid input, not some kind of internal inconsistency... 15:47 hmmmm adding assert() everywhere in your code does not automatically increase its correctness. usually it's wrong. 15:47 est its better than just continuing 15:47 est isnt it? 15:47 est whatever 15:48 hmmmm right, eating rat poison is better than shooting yourself because at least with the former you won't inadvertantly hurt others 15:48 Sokomine hmmmm: there still seems to be a minor bug regarding minetest.find_nodes_with_meta how shall i report it? github, here, msg? 15:48 hmmmm sokomine, do not private message people 15:48 hmmmm make a github issue 15:49 hmmmm first why don't you just talk about the error. it might not be a real error 15:52 est why do we lock the mutex in Settings::exists ? 15:52 est i mean its only there for writing isnt it? 15:53 hmmmm writing can modify the std::map internals 15:53 est then however it isn't deployed consistentyl 15:54 Sokomine i've opened an issue now. https://github.com/minetest/minetest/issues/2682 it's minor. checks could be done in lua if the node really is inside the volume defined by the two positions 15:55 hmmmm yes, it pads out to a block 15:56 hmmmm is that really that bad? 16:01 est man this turns out to be copy paste hell 16:01 est if we really want type dualism... 16:02 est setDefault setGroup setGroupDefault setBool setS16 setU16 setS32 setU64 setFloat setV2F setV3F 16:02 est and so on and so on 16:02 est and thats only the setters 16:02 est every single one has to be overloaded (in theory) 16:03 hmmmm huh? 16:03 hmmmm we do not do overloading of any type unless it's very helpful 16:03 est about the settings thing you proposed 16:03 est whatever 16:04 hmmmm i know you love for code to be expressive and minimal 16:04 est even if you dont want overloading, its a huge mess 16:04 hmmmm but most others working on minetest don't like that 16:05 Sokomine hmmmm: so find_node_with_meta is not restricted to the area given? i can certainly live with that. it just needs to be documented then 16:05 hmmmm well i can fix that i guess 16:06 Sokomine that would be breat :-) 16:06 Sokomine er, great... 16:10 ElectronLibre To whom it may interest : https://github.com/minetest/minetest_game/pull/502 ( game#502 ) 16:10 ShadowBot https://github.com/minetest/minetest_game/issues/502 -- Created TNT mods namespace by LeMagnesium 16:14 est and overloading in this case is good 16:14 est because we dont have to do stupid casting comparisons 16:15 est so the compiler knows ahead of time 16:39 * est wonders whether to use a vector or a pointer array for the fast access container 16:44 est a vector wont use more space either I guess... 16:47 est ok I know where it does use more space 16:47 est for the non-default list 16:48 est but whatever 17:19 hmmmm what would be really helpful is if somebody could go through all the instances of sanity_check(), assert(), and the like, and replace instances of these that are triggered by server or client network input with an error instead (such as failing inside of that function) 17:19 hmmmm this is a very big pressing issue that I would do myself but I've got things to do today 17:26 hmmmm https://github.com/minetest/minetest/commit/f1ccfd3c3d7d626087f70b8c5798110cd28b248a 18:37 Krock hmmmm, please change ">= 6" to "> 6" in https://github.com/minetest/minetest/commit/f1ccf 20:01 Calinou https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fminetest.net&tab=desktop 20:01 Calinou minetest.net does not allow gzip compression 20:01 Calinou also images could be optimized 20:03 celeron55 i'll look into gzip, but none of the others are worth the effort 20:05 Calinou “optipng -o7 -strip all *.png; jpegoptim -s *.jpg” does everything in a folder 20:05 Calinou :P 20:07 Warr1024 optipng is pretty good, but advpng does a better job with compression 20:08 Warr1024 you have to be careful with image optimizers though, as they make some assumptions 20:08 Warr1024 like that completely-transparent pixels' RGB information is not important, despite ^[noalpha used for fast leaves. 20:12 sfan5 Warr1024: advpng just performs better becasue it uses a custom deflate compressor 20:12 sfan5 also it sounds like advpng would take a very long time to compress stuff 20:25 Warr1024 if compressing stuff on the fly, yeah. 20:25 Warr1024 ideally, mod and texture pack authors really should do their own compression beforehand 20:27 Warr1024 for server admins wanting to cut down on client connect time, it should be simple to provide a script that does some image pre-compression, that only has to run once ever per image. 21:02 hmmmm there really is a memory leak 21:02 hmmmm people without swapfiles will notice it 21:02 sfan5 i never noticed a memory leak 21:03 sfan5 maybe that's because i have 8GB RAM 21:25 hmmmm you won't notice it unless you look at VIRT in top 21:25 hmmmm it keeps getting swapped out so it seems to you that minetest is only using about 100mb 21:25 est31 hmmmm, about https://github.com/minetest/minetest/commit/f1ccfd3c3d7d626087f70b8c5798110cd28b248a 21:26 est31 can this error be raised by a client? 21:26 hmmmm eah i made a typo 21:26 hmmmm can you fix the >= 21:26 hmmmm or somebody else 21:26 est31 ah I see 21:26 hmmmm it still works, it'd just have an annoying error every time somebody has exactly 6 materials 21:26 est31 in fact I was starting to comment about another issue 21:26 est31 because errorstream logging is bad when the client can trigger it 21:27 hmmmm the material count is set in the itemdef 21:27 est31 because its sent to all clients 21:27 hmmmm no, no, that code runs on the client only 21:27 est31 ok then 21:27 hmmmm this is wieldmesh.cpp 21:27 est31 ah 21:27 hmmmm it's not compiled with the server at all 21:27 est31 yea lol 21:27 * est31 should have looked 21:27 est31 then its good 21:28 hmmmm but the point remains 21:28 hmmmm this is an example of an entire class of errors 21:28 est31 yes 21:29 hmmmm people add assertions to their code, but forget that a remote server or client is providing the input causing this abnormal condition 21:29 est31 but server being able to take down client is not *that* bad 21:29 hmmmm and there are a lot of these 21:29 hmmmm not that bad, but still quite nasty 21:29 est31 yes 21:29 hmmmm this is a shit task i'll admit, but it's an important one 21:29 est31 not good practice at all 21:30 hmmmm to go through all of the asserts/sanity_checks and make sure the remote peer can't trigger it from their input 21:30 est31 you know when I read some server packets, then I see checks here checks there, and on client side? its assuming the server did the right thing 21:30 est31 (separate issue though) 21:30 hmmmm people tend to forget this is a multiplayer game 21:31 est31 I'll first do the settings thingy then focus on the utf8 backporting 21:32 est31 settings turn out to be quite hairy though 21:33 est31 abstracting out the defaultsettings to both provide an enum and default value initialisation was the easy part compared to that 21:40 Wayward_One I just got this error when unchecking damage on the singleplayer menu: http://pastebin.com/4hFPauLP 21:41 est31 Wayward_One, known 21:41 Wayward_One ah, ok 21:41 est31 and there is a PR somewhere 21:41 est31 #2586 21:41 ShadowBot https://github.com/minetest/minetest/issues/2586 -- Fix some bugs in mainmenu tab_singleplayer and tab_server by fz72 21:49 est31 hmmmm, what do you think is the preprocessor hack ugly or nice? https://github.com/est31/minetest/commit/4129674ad8446ada991b842041d0bcae775cd738 21:49 est31 (for me its the latter ofc :p) 21:50 est31 the commit doesnt work at all, only the preprocessor hack is set up 21:50 est31 and the MTSetting enum is populated 21:50 est31 automatically 23:56 hmmmm est31, i probably wouldn't do that myself but it certainly is nice 23:57 hmmmm the builtin settings are really too cumbersome and large to write to like 3 different places 23:58 hmmmm instead of MTSettings I think I'd call it CoreSettings or whatever it originally was, that sounds pretty nice and it's also game name independent which some people like 23:59 hmmmm also setting_instead sounds wtf 23:59 hmmmm normally you'd name that something like mtsetting_value or something