Time Nick Message 03:32 yh1986 hmmmm、est31: the basic cause of all-red graphics with shaders(android) is that "vVertexColor" in file "COGLES2Solid.vsh", r is actually 03:35 yh1986 'r' is actually day light, 'g' is actually night light, 'b' is actually light source. 03:38 yh1986 the shaders for android is uncompleted compared to the shaders in pc, 06:36 hmmmm https://github.com/kwolekr/minetest/commit/656575b59d4f0d67452cca7409c9064f690f038c 06:56 hmmmm https://github.com/kwolekr/minetest/commit/b246812455737b2d0337dec905ba0256adefd105 07:08 Etzos Can someone take a look at https://github.com/minetest/minetest/pull/2679 ? The bug seems to prevent the game from running. 07:47 kilbith hmmm, updated MT today and it refuses to run now : http://pastie.org/10175243 07:50 Etzos Already reported in issue #2678. I found and fixed the error in PR 2679. 07:50 ShadowBot https://github.com/minetest/minetest/issues/2678 -- ugly server crash on, "hud_add" d720fd5 builtin/game/statbars.lua:49: in function initialize_builtin_statbars 07:50 kilbith nore, you can check it please ? 07:52 nore the code looks fine, but I haven't tested it yet 07:58 nore Ok, confirmed the bug, and checked that the fix works 07:58 nore I'll merge it, since it is very high priority 07:59 nore and the fix is simple enough 07:59 kilbith thanks nore 15:26 est31 about https://github.com/minetest/minetest/commit/b246812455737b2d0337dec905ba0256adefd105 15:27 est31 hmmmm, perhaps add an option to completely omit identation? 15:27 est31 right now having zero means to use single tabs 15:28 est31 perhaps make zero mean have no identation, and -1 means to use single tabs 15:28 hmmmm does it really matter 15:28 est31 no 15:29 * est31 should do those srp cleanups to do more higher prio work 15:30 est31 what are your plans for client side modding running hmmmm? 15:30 VanessaE ShadowNinja: that change needs to wait for 0.5 imho. we can't be breaking shit so readily. 15:30 hmmmm i don't know but i have a lot of stuff to do 15:32 est31 VanessaE, the security patch or the patch to make mods non-global ? 15:32 VanessaE est31: the non-global opne 15:32 VanessaE one* 15:32 hmmmm are we really going to call it 0.5.0 15:32 VanessaE the security patch at least already has enough side-work ahead of it to stop it breaking mods more or less. 15:33 VanessaE hmmmm: well whatever we call it, though 0.5 makes about as much sense as anything else (as long as it isn't 0.4.x) 15:33 hmmmm it needs to be 1.0.0 if we want a chance at fixing our versioning scheme so minor version numbers actually mean minor version numbers 15:34 VanessaE if a proposed patch is gonna break anything, imho it belongs in that "let's break it all" version. 15:34 VanessaE 1.0.0 sounds better but then we get into that discussion we had before about confusing users (1.0.0 == 1.0 in a user's mind) 15:34 VanessaE (0.4.x = 4.x, etc) 15:35 est31 its their problem if they can't read a 0 at the start 15:35 VanessaE agreed, but if we can do something simple to prevent it in the future, why not? 15:36 est31 yea therefore 1.0.0 is better than 0.5.0 15:36 est31 and with client side modding, we are ready for 1.0.0 15:36 VanessaE what happens when we reach 3.0.0? 15:36 est31 then most users aren't 13 anymore and dont play minetest 15:37 est31 those who played it since 0.4.* 15:37 VanessaE and a whole NEW batch of 12-13 year olds comes in. 15:37 VanessaE and they still see the old 0.3.x versions from time to time either by someone talking about them or some idiot repo maintainer who doesn't update, etc. 15:37 VanessaE besides, it's not just kids 15:38 VanessaE it's adults who do that too 15:41 est31 perhaps make a poll, and let people decide 15:44 rom1504 and then name the 1.0.0 version "Hurr Durr I'm a sheep" 15:45 kahrl that other voxel game even has a single version number, in some cases, referring to to three *different* versions, and I don't see much confusion about it 15:45 kahrl and they certainly have their share of 13-year olds 15:46 VanessaE kahrl: probably because they didn't start with a 0 :P 15:46 est31 "Nyan, Nyan, I'm a Rainbow cat" 15:46 kahrl they actually did 15:46 VanessaE they did? 15:46 kahrl but then went through the 1.* cycle three times so far :) 15:47 VanessaE exactly 15:47 kahrl yes, Classic 15:47 VanessaE I guess the 0.x series wasn't widespread enough to matter, then 15:48 VanessaE in any case it should just not have a chance to confuse users is all I'm saying 15:48 rom1504 or you could go straight to 10.x to avoid any confusion and mischecking of program versions ;) ;) 15:48 VanessaE rom1504: what is this, Microsoft? :P 15:48 rom1504 windows yeah :D 15:48 est31 release a new major version every 6 weeks 15:49 est31 and start with 216 15:49 VanessaE ok now I gotta ask...why 216? :) 15:49 est31 its the systemd version on ubuntu :p 15:49 VanessaE oh heh 15:49 VanessaE how about 4607 then? :) 15:50 est31 oh sorry 15:50 est31 they use already 219 15:51 est31 413 sounds nice too 15:51 VanessaE heh 15:51 celeron55 i don't think this 0./1. confusion thing is nearly as significant as you're making it sound like 15:51 VanessaE celeron55: it's not INsignificant, though 15:52 VanessaE with the number of times I've had to correct someone about the leading zero, ...well... you get the point 15:52 celeron55 that doesn't mean they would be confused if the non-zero version actually did exist 15:53 VanessaE you'd be surprised :) 16:21 hmmmm :) 16:22 hmmmm I managed to delete 60 lines of code last night 16:22 hmmmm oftentimes, the most productive kind of changes are when you're able to remove code 16:35 ShadowNinja VanessaE: The namespace patch is completely non-breaking. 16:37 ShadowNinja What mods should do is return their namespace in addition to seting the global and recomment that anyone using their API switches. After waiting a reasonable amount of time for people to update their API usage the global can be removed. 16:39 ShadowNinja (you could of course immediately switch completely and break compat, but that's the mod's fault) 16:40 est31 for me its change for the sake of change, nothing more 16:44 VanessaE ShadowNinja: ok. 17:05 hmmmm hey est31, are we waiting on anything for the SRP pull request?? 17:07 est31 yes me cleaning up csrp-gmp 17:07 est31 I'm on it right now hmmmm 17:07 est31 but yes it got a bit stalled 17:08 est31 so my plan is to merge the code, but first not enable it because the packets are not finalized 17:08 hmmmm oh 17:08 hmmmm in any case I was wondering what m_authstate was 17:08 hmmmm you never explained the meaning behind that variable 17:08 est31 m_authstate is more an enum 17:08 hmmmm but it's an integer... 17:09 est31 yes because we have to be generic from auth mech to auth mech 17:09 est31 this is where a class based model would make some profits, I admit. 17:10 hmmmm well I think I should clarify on my rant about over-structuring code 17:10 hmmmm the overstructuring is very bad in things that are small and should be small 17:11 hmmmm but when you have a certain amount of internal mechanism state, and then several methods which have behaviors differing on the type of mechanism, it's kind of a good idea to have the whole base class/derived class thing there 17:11 hmmmm it's natural here 17:11 hmmmm whereas it wouldn't make sense to have drawtypes as a base class/derived class kind of setup 17:12 hmmmm it has to do with the amount of overhead justifying the additional structure 17:14 est31 what would the class based model cover? 17:15 hmmmm well first, the base class would be AuthMechanism or AuthMethod (the latter rolls off the tounge easier since it's only 3 syllables) 17:15 hmmmm this would basically abstract away each time you have if (authmechanism == AUTH_MECHANISM_THING) { ... 17:16 hmmmm in any case you certainly don't need to do this, i'm just saying it would make sense here 17:20 jin_xi heyho if you like removing code, someone please review/help with the particles stuff. 17:20 jin_xi ie see if the approach taken is plausible at all or if a different approach is needed, like subclassing (particlesystem)scenenode 17:21 jin_xi comments about style and capitalizations not needed at this point, and it needs to be said at all 17:22 jin_xi ...shoulda been ...and its kinda sad it needs to be said 17:45 rubenwardy Code style is important for maintainability. 17:48 est31 man what I dont understand is how this stuff works 17:48 est31 I mean valgrind sais everything was freed 17:48 est31 but I cant find the call where it was freed 17:48 est31 I mean its just not there 17:49 est31 ahhh 17:49 est31 dammit I found where 17:50 est31 it was an array with a specified length inside a struct 18:26 est31 hmmmm, what do you think, should I remove that unsigned char stuff too? 18:26 est31 and make it char only? 18:27 hmmmm if it's a "buffer" containing some kind of "data", it should be a void * 18:27 est31 ok 18:27 hmmmm if it's actually being interpreted as individual bytes, then that's an implementation-specific detail and the cast should be inside of the function 18:27 hmmmm i.e. 18:28 hmmmm void *memcpy(void *dst, const void *src, size_t len) { 18:28 hmmmm const uint8_t *s = (const uint8_t *s)src; 18:28 hmmmm then do all your operations on s 18:29 hmmmm yes, that will be optimized away, so it's not like you're saving anything for using the parameter directly 18:29 hmmmm to add to that, whenever there's a length parameter of some kind, use size_t. not int. please for the love of god, use size_t 18:29 hmmmm this is what size_t was created for 18:30 hmmmm it is part of the official C89 standard 18:30 hmmmm I see scrappily coded interfaces that take char * and int for a buffer and frankly it's annoying for several reasons 18:31 est31 whats best for writing data? 18:31 hmmmm the biggest being that you have to add extra things like casts or unsigned-to-signed conversions that really aren't appropriate in the first place, just to stop compiler warnings/errors 18:31 est31 void ** ? 18:31 hmmmm what do you mean 18:32 est31 I mean the method should return something 18:32 est31 but in c you have only one thing to return 18:32 est31 so you have to pass an argument 18:32 est31 which type should that be? 18:32 hmmmm prefer to not allocate memory for the caller unless what you're returning is variable length 18:33 hmmmm i don't know man, this all comes down to nuance and it's quite subtle 18:33 hmmmm it mostly comes down to experience in seeing which kinds of interfaces work and which don't in terms of amount of friction generated when using it 18:33 est31 yea 18:34 hmmmm but if you have to add casts everywhere just to use the damn API, there's a sure sign the interface sucks 18:36 hmmmm that being said, generally when returning a new value, then no, void * is not a good choice 18:37 hmmmm the idea behind void * as input parameters (and even output parameters when the buffer is user-provided) is flexibility 18:38 hmmmm when you, the interface, allocates and returns some kind of thing, it's usually best to have this in a pre-defined format. the user is going to have to know this anyway to delete it if they're using C++ new[] and delete[] operators. 18:38 est31 you cant delete[] something that has been malloced 18:38 hmmmm of course 18:39 hmmmm but the user shouldn't ever be calling delete[] or free() directly on your library's output 18:39 hmmmm you have that srp_free() function or whatever, correct? only use that 18:39 est31 yes 18:53 est31 error: invalid conversion from ‘void*’ to ‘char*’ 18:53 est31 Do I really have to cast after malloc? 18:54 hmmmm i have no context whatsoever 18:54 est31 I have a variable of type char* 18:54 hmmmm why not just pastebin the code? http://fpaste.org/ 18:54 est31 then I'm assigning that variable = malloc(uvlen); 18:54 hmmmm oh yes 18:54 hmmmm with C++, casting rules slightly changed 18:55 hmmmm you cannot implicitly convert void * to any pointer type any longer, so casting the result of malloc() is necessary 18:55 hmmmm however you can still implicitly convert any pointer type TO void... thankfully 18:56 * est31 wonders why there are separate char and void types altogether 18:56 hmmmm in traditional C, there was no void keyword 18:56 hmmmm malloc returned char *, memcpy took char *, everything was char 18:57 est31 that sounds very good 18:57 hmmmm but that didn't work because on some platforms, the sizes of pointers to different types were different, which made this conversion impossible 18:58 hmmmm and even if they were all the same size, you'd have to do all this nonsensical casting 18:58 hmmmm so in ANSI C, void * was defined to be a pointer that can fit any data pointer type 18:58 hmmmm this way you can have code like: 18:59 hmmmm unsigned long hash[5]; SHA1_Finalize(&context, hash); ... just as well as unsigned char hash[20]; 18:59 hmmmm you wouldn't need to cast the input parameter 19:00 hmmmm likewise, it made constructs like: int *foobar = malloc(50 * sizeof(int)); /*allocate 50 ints*/ free(foobar); 19:00 hmmmm possible 19:01 est31 ok that sounds good 19:01 hmmmm you don't care what the type of pointer is to. it's just a pointer to SOME kind of data 19:01 hmmmm until you actually start to use this data 19:02 hmmmm get it? 19:02 est31 yes 19:03 est31 so why did c++ make this stricter again? 19:04 hmmmm because there are some CS types who blindly believe that less implicit type conversions necessarily make the language 'safer' 19:05 hmmmm it only made it half-way stricter: void * -> type * conversions cannot be implicit, but type * -> void * still can 19:06 hmmmm even if they made both conversion directions explicit-only, void * would still not only have value, but be necessary 19:06 hmmmm because there's that problem where pointer sizes might differ 19:06 hmmmm take for example the Cray 1 19:06 hmmmm ints were stored in a different part of memory than chars were 19:07 hmmmm they made the int storage much larger because the designers figured they would be using more integer types in computation than characters for text, and they had different address spaces altogether 19:07 hmmmm so sizeof(int *) > sizeof(char *), believe it or not! 19:08 est31 lol 19:08 hmmmm the traditional C compiler with no void * fails here, because malloc() returned a char * 19:08 hmmmm and addresses would get truncated 19:08 hmmmm so they had to write an int * version of malloc 19:15 est31 I'm keeping the lengths int, because the buffers wont exceed 1024 MB :p 19:15 est31 and its even more porting hassle 19:15 est31 because I've two versions of that file 19:15 est31 and the diff is small, but not non-existent 19:20 hmmmm what do you mean 1024mb 19:20 est31 you know, at the position where the length overflows 19:20 hmmmm the max value of an int you're guaranteed is 32787 19:21 est31 even that isnt exceeded 19:21 hmmmm well okay, it's YOUR library... just saying that's horrible practice 19:21 est31 yea ... 19:22 est31 is there any advantage to store something in unsigned char* other than char* ? 19:22 est31 its horrible 19:22 est31 one is char*, the other data is unsigned char* 19:22 est31 and having to write unsigned bloats the code up 20:35 hmmmm if its bytes you want, you should look into u8 or uint8_t 20:35 hmmmm i recommend u8 because csrp can define them if they haven't been defined elsewhere 20:37 hmmmm yes, there's a difference here. you want to treat the chars as plain bytes of data, but if you do any kind of operation on that character that may implictly upcast the datatype to a higher capacity one, you'll get bugs because it'll sign extend if the value is over 127 20:39 hmmmm a hilarious and subtle bug is when somebody passes a char * as a buffer for "bytes of things". one of the fields in this blob of bytes happens to be a bitfield. they do a right bitshift as part of an operation to extract a value from a byte, and unwittingly performs an arithmetic shift instead due to signedness 20:39 hmmmm i've seen this particular scenario happen more than a couple times 20:41 est31 oh 20:42 hmmmm another one is when somebody does a hex dump on said bytes: 20:42 hmmmm for (int i = 0; i != len; i++) printf("%02x ", data[i]); printf("\n"); 20:42 hmmmm "why does it print out ffffff84?? for some characters" 20:42 est31 shouldnt that int be a size_t? 20:42 hmmmm yes 20:43 est31 otherwise it will be an endless loop 20:43 hmmmm i'm taking on the persona of a newb though who uses char * and int to specify a buffer 20:43 hmmmm no, how would that be an endless loop? 20:43 est31 because i!=len always 20:43 est31 when len > maximum int 20:44 hmmmm you'd get a warning for that 20:44 hmmmm but yeah 20:45 hmmmm est31, you should read this sometime https://www.securecoding.cert.org/confluence/display/c/CERT+C+Coding+Standard 20:46 hmmmm https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637 20:48 est31 btw why does it print that then? 20:49 hmmmm because it's signed 20:49 hmmmm that's a variadic parameter so it gets promoted to an int, and thus gets a sign extension 20:49 est31 ah 20:49 hmmmm to fix that you'd have to explicitly cast data[i] to (unsigned char), or, you know, make data an unsigned char pointer :) 20:53 est31 dammit now I'm using size_t and its segfaulting 20:55 est31 how weird 20:56 est31 I mean, how did it work before? 20:56 hmmmm it happens 20:57 est31 but know the reason now 20:57 est31 thats why I asked how it worked before 20:58 est31 because... it can't 21:04 crazyR_ is it possible to get the info that gets sent to the serverlist withosome sort of function or namespace 21:05 est31 for the client or server crazyR_? 21:05 crazyR_ or maybe get the online servers list from within lua(ingame) 21:05 crazyR_ server 21:05 est31 there is a method to give the server list within mainmenu lua 21:06 crazyR_ can you remember which method is used im currently trawling thought the code, but think i may have missed it 21:06 est31 its a httprequest 21:07 est31 https://github.com/minetest/minetest/blob/9527984dbcfc0a6cc7aa0470430cb6c3aa4103ba/src/serverlist.cpp#L195 21:08 est31 crazyR_, ^ 21:09 crazyR_ thanks 21:12 crazyR_ think it may ust be eaiser to parse the data i need from here: http://servers.minetest.net/list 21:12 crazyR_ cache it for 5 mins at a time 21:12 est31 you can use luasocket like the irc mod does 21:12 est31 and then make an http request 21:13 crazyR_ i know. thats what i use vurrently for my api system. thanks 21:13 est31 what you need it for? 21:13 crazyR_ just for a ingame infomation dashboard. 21:15 crazyR_ hmm actually. why am i over thinking it again 21:15 crazyR_ most of the inof is available via settings. others throught parsing players online etc etc. lag via the server status 21:24 est31 so I think this is it 21:25 est31 srp patch ready to merge, if it builds 21:25 * est31 doing last test whether it works, then deactivates protocol v25 21:26 est31 it doesnt :( 21:32 est31 ouch 21:32 est31 current network code really has some problem 21:32 est31 right now, I can send carefully crafted packets to the server to make it restart 21:33 est31 This isn't the cause of my error, but an interesting side note 21:36 est31 what we have to do is either catch exceptions or add some other mechanism 21:36 est31 that basically does the same as the exceptions do 21:36 est31 with explicit checks and so on 21:37 est31 when I have time I do a PR with the exceptions 21:37 est31 later on we can do the explicit checks too 21:47 est31 ok works again 21:48 VanessaE has there been any movement yet on allowing backface culling to be specified as a node property? 21:50 hmmmm nope 21:50 VanessaE ok. 21:51 hmmmm right now there's nobody working on graphics anything 21:52 est31 whatever happened with RBA :( 21:53 hmmmm absolutely no idea 21:53 VanessaE he got too busy to mess with MT anymore. 21:53 VanessaE at his day job, that is. 21:53 hmmmm i want to work on the shaders 21:53 hmmmm i want to work on the mapgens, i want to work on lighting 21:53 hmmmm i want to work on everything but alas I can only do one thing at a time 21:53 hmmmm agh 23:51 est31 hmmmm, I think #2620 can be merged now 23:51 ShadowBot https://github.com/minetest/minetest/issues/2620 -- SRP based login by est31 23:55 est31 paramat, why that new PR? 23:56 paramat will push trivial update soon #2680 23:56 ShadowBot https://github.com/minetest/minetest/issues/2680 -- Conf.example: Update recommended maximum cloud radius to 26 by paramat 23:56 paramat further testing shows 26 is the maximum without clipping 23:57 est31 ok then merge it 23:57 est31 +1 23:57 paramat :)