Time Nick Message 00:38 hmmmm alright, first off, why is TOCLIENT_HUD_BUILTIN_ENABLE that 00:38 hmmmm why isn't this a more general TOCLIENT_HUD_FLAG_UPDATE 00:38 hmmmm i don't get why it needs to be so specific 00:39 hmmmm why is there an id field and why is it a u8 which is completely inconsistent with the rest of the hud packets 00:39 hmmmm why are the flag checks in game.cpp and not in hud.cpp? why should game.cpp be concerned with that at all? 00:40 hmmmm and then to add yet another dash of inconsistency, drawHotbar gets passed player->hud_flags for whatever reason 00:40 hmmmm but not the others 00:41 hmmmm then look at that, you have both a flags field and a bit enum field 00:41 hmmmm why did you commit this as-is, celeron 00:41 hmmmm now i need to waste my time to go and fix it 00:44 RealBadAngel https://github.com/minetest/minetest/pull/684 00:44 RealBadAngel im done with engine part, now coding Lua side for it 00:46 hmmmm wow that's really tight looking code 00:47 RealBadAngel my first commit with ZERO deletions ;) 00:57 RealBadAngel hmmmm, any objections about glasslike? 00:57 hmmmm no 00:58 RealBadAngel ok, i will pull craft recipes for new glass types in half an hour or so 00:59 VanessaE hmmmm: seen pilzadam's comment about the new alpha glass? 00:59 RealBadAngel need to prepare also textures 00:59 hmmmm if he has something to say about it that he wanted me to see, he can tell me it directly 00:59 VanessaE he did :) 01:00 hmmmm i saw nothing of the sort 01:01 RealBadAngel hmmm, could you merge the drawtype then? we (me and VanessaE) will work on common 01:01 hmmmm in a bit 01:03 RealBadAngel btw, maybe make streaks on glass with some alpha now? 01:03 hmmmm what? 01:03 hmmmm don't use the alpha channel feature 01:04 hmmmm maybe sometime later when transparency sorting is fixed without shaders 01:04 RealBadAngel ok 01:04 RealBadAngel but i will try how it could look like 01:05 VanessaE hmmmm: can't find it now, but basically it was a rehash of what you already knew. 01:05 hmmmm the only reason why i added it was because, in the vast majority of cases, it looks acceptable 01:05 hmmmm then why did he repeat it? 01:05 VanessaE guess he felt the need to comment :) 01:06 VanessaE with shaders, it just doesn't work at all. without, you get water alpha conflict 01:06 hmmmm with shaders it does work, i tested it 01:08 VanessaE Apr 24 2013 06:47:29 this new "use_texture_alpha" is unusable; with shaders enabled it doesnt work at all and without shaders its extremly glitchy above water 01:08 VanessaE there it is. had to grep through my logs...and that was just today. 01:09 VanessaE I have to wonder if his video card even handles shaders 01:47 hmmmm does anybody have any objections to this? https://github.com/sapier/minetest/commit/8931f8c466a685518b3a4b85ae0d2e77ff1d8b29 01:48 RealBadAngel i dont 01:48 RealBadAngel http://i.imgur.com/CC188lQ.png 01:49 RealBadAngel how do you like it? 01:49 hmmmm looks nice 01:49 RealBadAngel wooden framed glass (clean + streaked) and to the right steel-framed 01:50 RealBadAngel clean is made using obsidian glass 02:09 hmmmm hm 02:09 hmmmm hey kaeza 02:10 hmmmm you know, i was looking at TOCLIENT_HUD_BUILTIN_ENABLE and i couldn't help but to want to generalize that a bit more than it is 02:11 kaeza1 hmmmm, hm? 02:11 hmmmm let's talk about hud 02:11 hmmmm every feature ends up eventually having a flags field, let's face it 02:12 hmmmm now it seems that the structure of your packet has a u8 as an id whereas other hud commands have u32 ids 02:12 kaeza1 hmmmm, that's because there are'n many builtin items 02:12 kaeza1 aren't* 02:12 hmmmm of course 02:13 hmmmm but you also don't have many flags for them 02:13 hmmmm you have only one for each - i guess we can call it "is_visible" 02:13 hmmmm now let's be honest here 02:14 hmmmm there aren't going to be many attributes that all builtin hud items have in common 02:14 hmmmm what if we dropped the id field completely and had a flag for each hud item's visibility instead? 02:14 hmmmm and this flags field describes the player's entire HUD 02:26 hmmmm i guess not :/ 02:26 VanessaE he'll return. wireless glitch probably. 02:26 Exio his is using a 3g (or 2g?) 02:26 VanessaE Exio: 3g I think. 02:27 Exio i mean, maybe his network is working in 2g-mode and that can be the why of the timeouts :P 02:27 VanessaE no idea. 02:30 RealBadAngel https://github.com/minetest/common/pull/38 02:31 hmmmm so it seems prestidigitwhatever is attempting to reel me into an e-argument with him 02:32 hmmmm that guy's really lookin' for a fight 02:34 RealBadAngel so all the code for new glasslike is here 02:35 VanessaE RealBadAngel: see pm's. this code should not be merged yet. 02:35 VanessaE sorry guys, I gotta speak up on this. 02:42 RealBadAngel hmmm, the thing VanessaE is talkin about is another feature for core part 02:42 RealBadAngel this lua code can be merged as-is 02:48 EduardeCalibal Hey, how I serialize user data? 02:48 EduardeCalibal :-o 02:50 EduardeCalibal I am working in a function to copy constructions from a game to another but the metadata is lost, if I store the metadata in the table the serialize function give me a error... :-/ 03:00 VanessaE ok, here's an idea then. 03:00 VanessaE regarding the framed glass 03:01 VanessaE swap the order of the two textures - place the "glass surface" first, followed by the frame. 03:01 VanessaE make the new drawtype respect that order. 03:01 VanessaE then push engine *and* common to upstream. 03:01 VanessaE changes thereof I mean 03:01 VanessaE then we can work on the expanded version later on 03:02 VanessaE this way no changes need to happen on the Lua side, so modders will not get as pissed :) 03:07 VanessaE my idea for the future of this is: [04-24 22:45] images = {"glass_streaks.png", "top_bottom_bezels.png", "left_right_bezels.png", "top_bottom_edges.png", "left_right_edges.png"} 03:07 VanessaE (RBA talked in private already) 03:08 VanessaE basically, pieces of the two bezel images would be projected over the nodeboxes for those parts of the glass that have one or more visible corners, while the two "edges" images would be cut apart and used to tile up/down/sideways along 2-or-more-node runs of a frame 03:09 VanessaE that way corner images don't get tiled all over the place and break the intended seamlessness of the surface. 03:11 kaeza sorry, been having network problems tonight. They seem to be fixed now 03:12 Exio hmmmm: ^ 03:17 VanessaE where top/bottom/left/right are relative to a single face as viewed straight on 03:18 VanessaE so much for him having fixed his connectivity issue. 03:36 kaeza I guess they were not fixed after all... 03:36 VanessaE [04-24 23:18] so much for him having fixed his connectivity issue. 03:48 hmmmm kaeza, like i was saying earlier before you dropped, what if we removed the ID field from the packet and just left it as a flags field for the HUD in general 03:48 kaeza hmmmm, can you explain the idea in more detail? perhaps the API could use a table, and the protocol a simple u32 03:48 kaeza ah 03:49 hmmmm so do you approve? 03:49 kaeza hmm 03:49 hmmmm it'd simplify the packet a bit and make it more generalized 03:49 hmmmm for things other than setting hud elements to visible/invisible 03:50 kaeza I'm not sure about that 03:51 kaeza I think this will complicate things 03:51 hmmmm why's that? it'd be the opposite, i'd be removing a field from a packet 03:53 kaeza give me a sec while I try to connect from Linux 03:55 kaeza there 04:00 kaeza so... do you have something in mind for the API? 04:00 kaeza something sane? 04:01 kaeza remember that Lua is bad with bitfields 04:02 hmmmm don't we have bitop now? 04:02 VanessaE luajit has. 04:02 VanessaE lua vanilla doesn't. 04:02 hmmmm i thought we agreed to add bitop to vanilla lua 04:03 VanessaE we did,. 04:03 VanessaE . 04:03 hmmmm grr 04:03 VanessaE I was beginning to wonder why that hadn't been added yet. 04:03 hmmmm that's RBA's area 04:03 hmmmm but anyway that doesn't even matter 04:03 VanessaE I think it is safe to say he's been a bit..busy 04:03 hmmmm flags in lua, see register_ore() 04:04 hmmmm i settled on a comma-delimited string of flag names 04:04 kaeza that could be an option 04:04 hmmmm anyway i'd be the one changing this kaeza 04:04 hmmmm so don't sweat 04:04 hmmmm and an added advantage to this is you wouldn't need to send more than one packet to disable the hud elements 04:04 kaeza yeah, whatever 04:04 kaeza go on 04:06 kaeza I may as well not have bothered to add it 04:09 hmmmm sorry 04:10 hmmmm just trying to make things 100% optimal 04:14 hmmmm i would've changed it all anyway when eventually the builtin hud elements become not-built-in 04:14 Exio hmmmm: small thingy - mapgen_v6.cpp:271-275, can't that get changed to a return rangelim? :P 04:15 hmmmm (which requires a good way to do client-side prediction which we don't yet have) 04:15 hmmmm yes it can be 04:15 hmmmm the reason why it's not is because that's taken directly from the 0.3.x mapgen 04:15 Exio ah 04:19 kaeza hmmmm, the current system makes it so you can disable individual items without regard to other items 04:19 kaeza what you propose is to set the entire thing with one call 04:19 hmmmm that shouldn't really be too much of a problem from lua 04:20 hmmmm you can keep track of what you've already disabled 04:20 hmmmm and if it's not, i can just add a mask parameter too 04:20 kaeza in the current scheme, a mod can disable the crosshair to show it's own with an image HUD item 04:20 hmmmm yeah about that though 04:20 hmmmm there's been a demand for an image crosshair that's client-side only 04:21 kaeza so... complicate thing 04:21 kaeza +s 04:22 kaeza I'd agree with using a table though 04:22 hmmmm i don't know, it seems like people are going bonkers over minor details like that 04:22 kahrl can't the crosshair (in its current state) be moved to lua? 04:22 hmmmm we already have a way to do an image for a crosshair 04:22 hmmmm yes it can be 04:22 kahrl if it uses a texture client can override it 04:22 kaeza when the field is true, the item is shown, when false, it's hidden, and when nil, it's unchanged 04:23 hmmmm sure 04:23 hmmmm that's not hard to do 04:23 hmmmm that's just the lua bit of this 04:23 hmmmm so you want me to add a mask too. simple enough 04:26 kaeza as I said, do whatever you want to 04:26 kaeza I'm not touching any engine-related changes from now on 04:26 hmmmm what why not 04:29 kaeza because I don't know how to write "100% optimal" code, and may as well not bother trying to do so 04:29 hmmmm noo 04:30 hmmmm it's just because this was rushed without much feedback 04:30 hmmmm besides, there's room for improvement for everything 04:30 hmmmm i'm sorry, i didn't mean for you to take it the wrong way 04:31 hmmmm i guess i'm a bit of a neat freak... when it comes to pieces of code that i mostly did myself, i get over-protective about it and i feel like everything needs to be perfect 04:31 kahrl kaeza: it's not like minetest is 100% optimal code... 04:31 hmmmm but the rest of it is like "nah, not mine, i don't give a crap" 04:31 kaeza kahrl, IKR :P 04:35 hmmmm so kaeza, please don't stop on writing code for the core 04:35 hmmmm besides, the other things you added were 100% perfect, i didn't change anything at all with that 04:35 kaeza hmmmm, if you think this will be easier for the modder, then do it 04:36 hmmmm well of course it's not going to be easier for the modder, it just makes the code cleaner and reduces the number of packets needed to be sent 04:36 kaeza the protocol is not of importance here, because this will be done mostly on load 04:36 hmmmm well 04:36 kaeza err... not *very* important 04:36 hmmmm this will be easier for the modder as well because you'd be able to do all of this with a single call 04:37 hmmmm i plan on using the table idea 06:02 VanessaE weird error, and I didn't think to take a screenshot of it - tonight's commits may cause a REALLY WEIRD drawtype confusion when used on a server that's a couple days old 06:03 VanessaE many things became either plantlike or raillike 06:03 VanessaE until I restarted the server to make it current with the client 06:04 VanessaE (particularly if the object was a nodebox or already plantlike) 06:09 VanessaE oh shit 06:10 VanessaE it's happening on older servers 06:10 VanessaE current git cannot be used on anything older than a couple of days 06:10 VanessaE current git *client* that is 06:10 VanessaE major regression 06:12 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_1070719285.png 06:13 VanessaE those are supposed to be slabs, this house has existed for several months. Also note the torch near the bottom right of the image, and the window shutters at the right 06:18 VanessaE my last known good build was 3 days ago, commit 37e6d135 06:21 kaeza minor idea: being able to save JPEG screenshots 06:21 VanessaE jpeg for a screenshot? blasphemy. :) 06:22 kaeza VanessaE, for some, a ~80 KB jpeg file is better than a ~1MB png file :) 06:22 kaeza (both for disk space and network) 06:22 VanessaE 746kB :) 06:23 kaeza not so much difference 06:25 kaeza anyway, I can't come up with new ideas 06:26 VanessaE well 06:26 VanessaE it's okay if things need tweaked after you come up with an idea 06:27 VanessaE that's how collaborative programming works :) 06:27 kaeza yep I know, I was just a bit pissed off for something unrelated and over reacted 06:28 kaeza I think the change in HUD API may be better after all 06:28 VanessaE well I dunno that I'll actually be using that, but who knows 06:29 kaeza I can prolly code it in a few hours (like I did with my last commit) bu hmmmm said he wants to do it 06:31 kaeza BTW, I saw flowers are now in minetest_game 06:31 VanessaE not yet 06:32 kaeza ah yes, it was a pull request :P 06:32 kaeza ...or did I misread that? 06:32 VanessaE damn it why can't there be someone on right now who can fix this? 06:32 VanessaE ok, a user on my server who is running 0.4.6-old-and-crusty ;) from the main website says some stuff on the server (which is at git HEAD at the moment) looks "flat" 06:37 darkrose o.0 06:37 VanessaE rewinding back to commit 36747794[...] 06:42 VanessaE ok, current git client cannot be used with a server of that commit or older for sure. 06:43 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_1072572201.png 06:44 VanessaE this is NOT what those structures look like. 06:44 VanessaE looks fine if I connect with a client from the same build. 06:48 VanessaE that 0.4.6-rusted-out ;) user on my server says everything looks normal now. 08:20 celeron55 ummm 08:20 celeron55 VanessaE: that could be a somewhat serious problem 08:20 VanessaE I would say so. :) 08:20 celeron55 has someone modified ContentFeatures? 08:21 VanessaE the first screenshot (brick house, stone-brick roof) was on redcrab.suret.net:30401 (which I think is still late 0.4.4) while using client from git HEAD 08:21 VanessaE I'm not sure, but I do seem to recall seeing some discussion about *possibly* doing so 08:22 celeron55 it seems like no 08:22 celeron55 zero changes since 0.4.6 08:23 celeron55 (i was first wondering whether my usage of git is just broken, but there just weren't any results 8D) 08:24 VanessaE could that new drawtype RBA added be at fault? or the alpha thing hmmmm put in? 08:24 VanessaE those are the only two I coul deven begin to suspect, since I don't know the engine that well 08:26 celeron55 oh no 08:26 VanessaE ? 08:26 celeron55 i hadn't pulled minetest/minetest since yesterday or so 08:26 celeron55 this is due to RBA's framed stuff 08:26 VanessaE shit 08:27 celeron55 RealBadAngel: fuck 08:27 celeron55 and shit 08:27 VanessaE guess I wasn't far off when I suggested not to merge it yet :D 08:28 VanessaE (but for a completely different reason) 08:28 celeron55 RealBadAngel: you should realize you are dealing with network serialization 08:29 kaeza celeron55, any comments on changing the HUD API as hmmmm said? 08:30 celeron55 also hmmmm committed this, screw that too 08:50 VanessaE "celeron55 authored in a minute" 08:50 VanessaE time travel much? ;) 09:00 VanessaE celeron55: I think that's got it. 09:08 VanessaE seems good, new build posted on my thread. 09:24 celeron55 kaeza: my comment is that don't be concerned about hmmmm 09:25 celeron55 he really pisses anyone off unless you know that it's the only way he is able to talk 8) 09:25 celeron55 i do think that hmmmm's suggestions are more about overcomplicating stuff than making them cleaner 09:26 celeron55 also, bitfields in lua are bullshit 09:26 kaeza heh 09:26 kaeza that's what I told him 12:20 EduardeCalibal celeron55, I need help, I converted userdata from the get_meta function to tables and stored in a file, when I retrieve this data and set back to nodes with meta:from_table() the game instaltly crash. How I will solve this? 12:21 EduardeCalibal Detail, this work if I only store in a table and transfer back to another node. I think I lost the 'userdata' status of my data and now I need convert back but I don't know how... 12:22 PilzAdam this is the wrong channel for modding questions 12:22 EduardeCalibal Ops, sorry. 12:22 PilzAdam go to #minetest or #minetest-mods and ask your question there 12:23 EduardeCalibal Well, the game crash then still a mod question? 12:23 PilzAdam it would also be helpful if you show us your code 12:23 EduardeCalibal Ok. 12:23 PilzAdam the game crashes if mods are wrong, so yes, its still a modding question 13:58 celeron55 hmmmm: i request you to (per each situation) either not be so overly controlling about things or alternatively just do things yourself 13:59 celeron55 even if you don't care a tiny bit about niceness, think about it in terms of productivity 14:01 celeron55 and i request you to do those decisions early, not after you have already talked yourself into being the only one who can ever do it in an acceptable way 14:04 celeron55 kaeza's code is good enough for our standards 14:04 celeron55 if you draw the line elsewhere, you will have to adjust it 14:45 RealBadAngel hi all 14:45 RealBadAngel celeron55, whats wrong with my pull? 14:46 Exio check the order 14:50 RealBadAngel ? 14:51 PilzAdam RealBadAngel, you broke compatibility to old clients by adding NDT_GLASSLIKE_FRAMED in the middle of the NodeDrawType enum 14:51 PilzAdam so you basically changed the numbers for half of the drawtypes 14:51 RealBadAngel holy shit 14:52 RealBadAngel i didnt realize it, i just inserted it next to glasslike 14:52 PilzAdam generally always append to enums, dont insert 14:53 RealBadAngel this was the last thing for me to do 14:53 RealBadAngel i just copied all the stuff takin glasslike 14:53 PilzAdam "everything else done? – lets break something >:)" :-p 14:53 RealBadAngel and made entry next to it 14:54 RealBadAngel tested it, all worked fine 14:54 RealBadAngel pushed to my git, reget, compiled again 14:54 RealBadAngel so double checked, then pulled to main 14:55 RealBadAngel sorry, it was not intentional 14:55 RealBadAngel also i asked vanessae to get the sources from my git and test it before pulling 14:56 RealBadAngel she said no, im only downloading sources from main tree 14:56 PilzAdam you dont have to explain yourself 14:56 PilzAdam things like that happen 14:56 PilzAdam just dont do it again 14:57 RealBadAngel but things like fuck, shit, you should know makes me sad 14:57 kaeza it's kinda hard to spot these things when testing 14:57 RealBadAngel when im extremaly caerefull postin anythin 14:58 kaeza because that bug was unrelated to the spirit of the change, you had no way to see that 14:58 PilzAdam hmmmm, use_texture_alpha doesnt work with shaders enabled for me. with this https://github.com/PilzAdam/common/commit/fb04d3f0ba5cec84757b84e437aaff2bd1a234b6 the alpha is ignored and with normal drawtype its not drawn at all 14:58 PilzAdam (with shaders enabled) 14:59 PilzAdam (the texture is 0 14:59 PilzAdam (the texture is 20% transparent) 14:59 RealBadAngel i can see its fixed already 15:00 RealBadAngel thx celeron55, i learned something new again 15:01 kaeza to tell the truth, enums are kind or a blessing and a curse at the same time 15:02 PilzAdam RealBadAngel, what do you think: https://github.com/PilzAdam/common/commits/flowers 15:02 RealBadAngel regarding VanessaE proposal of rotating textures to make frames beveled at corners 15:02 PilzAdam http://ompldr.org/vaTd2bA 15:02 RealBadAngel definitely will not be made, because: 15:02 RealBadAngel a) its an effect only for 64x or higher texture packs 15:03 RealBadAngel b) will double computations needed to make those fancy corners 15:03 RealBadAngel c) will require insane ammount of textures to make it properly 15:04 RealBadAngel in case of default 16x16 game textures we are talkin about rotating 1 (sic!) pixel textures 15:04 RealBadAngel i definitely refuse to code this eyecandy 15:06 kaeza PilzAdam, that's great 15:06 RealBadAngel PilzAdam, im ok with it 15:06 kaeza It's finally a way to get wool in vanilla game 15:06 RealBadAngel but hold on 15:07 RealBadAngel the screenshot is from actual usage of the mod? 15:07 PilzAdam yes 15:07 RealBadAngel are there not TOO many flowers out there? 15:07 Exio PilzAdam: it works for me with a 50%~ transparent image 15:08 RealBadAngel i can see only flowers around and almost no grass at all 15:08 PilzAdam RealBadAngel, its just a region with many flowers 15:09 PilzAdam there are also regions without anything, with grass only, grass and a few flowers, only a few flowers and no grass, etc. 15:24 RealBadAngel ah so, then no objections at all 15:24 RealBadAngel we need flowers 15:37 celeron55 i'm mostly worried that somebody will some day commit something that modifies such an enum that gets saved on disk 15:38 celeron55 we might need to start handling the on-disk saving by first documenting format changes, then implementing them 15:39 celeron55 but it's hard as of now because what gets saved on disk is bit of a mess; stuff that is able to break things propagates from quite high up into there 15:39 celeron55 that's actually why this exists https://github.com/celeron55/minetest-worldtest 15:41 celeron55 somebody should probably automate that on a server that reports somewhere publicly 15:44 celeron55 also the map patch that it uses for 0.4.1 and 0.4.3 won't work in current versions 15:44 celeron55 actually server patch 15:47 hmmmm [10:04 AM] kaeza's code is good enough for our standards 15:47 hmmmm mine too 15:47 hmmmm but this isn't about code, it's about the manner in which the feature is carried out 15:48 hmmmm i just think it's more ideal to send a _single_ packet describing the entire state of the builtin hud (or maybe hud in general) rather than have 4 separate sends that do exactly one thing each 15:48 celeron55 that means the server always has to fully know the previous state 15:48 celeron55 it may or may not be what we want, that's a design question 15:48 hmmmm at first, sure 15:48 hmmmm but i mentioned that i'd add a mask field as well 15:49 hmmmm eliminating that problem 15:49 kaeza that just adds complication to the code 15:49 kaeza instead of making it cleaner 15:49 hmmmm a single bit operation? 15:50 celeron55 well, make the patch and show us before merging, that'll make everything clear 15:50 hmmmm sure, i need to actually write it first 15:50 hmmmm i just got home 15:50 hmmmm now let's see the shader problem 15:50 celeron55 don't do bit operations in lua though; it's tasteless and unclean 15:50 hmmmm i fear that the way i did the per-pixel alpha blending in the shaders is wrong 15:51 hmmmm no, no, we've already decided that we're passing a table with true/false 15:52 hmmmm so for example, flags = {wielditem=true, crosshair=false, somethingelse=false} would create a mask that modifies the bits wielditem, crosshair, and somethingelse, so the latter two are set to false while the first is set to true, and no other bits are affected 15:52 hmmmm it's clean from the lua side and the code side as well since it's so simplistic 15:52 celeron55 and also, don't add any unreasonably low limits like 32 for amounts of things in the hud 15:52 hmmmm it also avoids needing an enum 15:52 hmmmm erm 15:52 hmmmm 32 things for the builtin hud 15:52 celeron55 for the builtin hud, 32 is fine, yes 15:52 kaeza that's another thing for consideration IMHO 15:53 hmmmm about that 15:53 kaeza my code allows up to 256 items 15:53 hmmmm i believe that the builtin hud items won't be lua-ized for quite some time 15:53 hmmmm and if they do, it'd be a large enough change to warrant changing all of these things as well 15:53 celeron55 true, maybe never 15:53 hmmmm so it doesn't matter too much 15:53 celeron55 but they must be disableable for special usage 15:54 hmmmm that they are 15:55 hmmmm as an aside, more than 32 HUD items is kind of ridiculous 15:56 kaeza maybe 15:56 hmmmm we might need to set a limit to the number of total hud items per player so the client isn't bogged down with this crap. but then again, there are other more effective ways for a server to kill a client 15:56 celeron55 we need to provide for hacks that come from the lua side, just because it's nice to let people to do things via hacks if we don't have resources to implement them properly 15:57 celeron55 it feeds innovation which is good 15:57 kaeza hmmmm, that's not the job of the engine 15:57 kaeza if mods define 1284194 hud items it's the fault of the player for using so many mods 15:58 kaeza (I mean, the server owner) 15:58 celeron55 well, one million hud items is kind of an overstatement 8) but anyways 15:59 hmmmm one of these days i'm going to write a mod that spams the player with porn banner ads and annoying sound ads 15:59 RealBadAngel '640K is more memory than anyone will ever need.' 15:59 kaeza hmmmm, don't give me ideas :P 15:59 hmmmm "5 cars is more than anyone will ever need" 15:59 celeron55 there's barely one million pixels on the screen (well, usually two million) 8) 15:59 hmmmm trufax^ 16:00 celeron55 of course you could draw each pixel with a single hud element 16:00 kaeza I'm going to show jordan4ibanez that you can show dancing cats on the HUD 8) 16:00 celeron55 i wonder how that'd perform 8D 16:01 kaeza celeron55, think of the average internet user installing search bars into IE :) 16:01 hmmmm you know, when i first brought up the potential for abuse in that manner, somebody in #minetest actually said that it'd be a great way for minetest servers to be ad-supported 16:01 * hmmmm cringes 16:02 celeron55 well i don't care if somebody does that 16:02 celeron55 some people seem to tolerate ads and if that's the kind of thing they want, whatever 16:03 hmmmm and then when there's finally client-side lua, there'll be an adblock plus for minetest 16:03 celeron55 minetest is eventually going to become an operating system 16:03 celeron55 it's unevitable 8D 16:04 Exio emacstest 16:04 Calinou minemacs 16:05 Calinou includes: "RMS Block" 16:05 hmmmm sure, add the built-in webbrowser that somebody was proposing 16:05 Exio and then mt will have everything but a game 16:06 celeron55 then people will invent something like using terasology inside minetest, just like some people use vim in emacs 16:07 Calinou JVM in minetest 16:07 Calinou ^ we need that 16:08 hmmmm agh 16:08 hmmmm pilz is right 16:08 hmmmm i think it's because i didn't convert to RGB correctly 16:09 hmmmm i'm sure there's a simple way to get translucency with shaders working 100% 16:10 PilzAdam hmmmm, I prefer "Adam" 16:10 hmmmm right now the unsolved problem is that the backface for the other texture isn't drawn, so if you have something like lava flowing in behind a translucent block, you might not see it at certain angles 16:10 hmmmm okay 16:10 hmmmm i can't get used to that but i'll try 16:11 Calinou and in other angles, it will look like the lava is in front of it :P 16:11 Calinou even notch can't code real transparency sorting that accounts that 16:11 hmmmm if shaders are disable 16:11 hmmmm disabled 16:12 hmmmm notch isn't really that great though 16:12 hmmmm but yes, this is a definite calling to implement transparency sorting. anybody have any ideas? 16:12 RealBadAngel PilzAdam, can you push the recipes and defs for glass? 16:12 PilzAdam RealBadAngel, no 16:12 RealBadAngel why? 16:12 PilzAdam Im not sure about it 16:12 RealBadAngel what makes you think so? 16:13 PilzAdam I would be fine with adding it to the build game 16:13 RealBadAngel this is just content 16:14 RealBadAngel i dont see a poin in limitin it to just build game 16:14 PilzAdam its just a complete useless node 16:14 PilzAdam we alread have glass 16:15 RealBadAngel we do have different kinds of stones 16:15 RealBadAngel bricks etc 16:15 PilzAdam its just there for decoration, and so its useful for build game, but nor for survival 16:15 RealBadAngel why glass shall be one and only? 16:15 RealBadAngel survival means also gather resources and make your world better 16:16 PilzAdam yes, but this glass goes too far 16:16 RealBadAngel with limiting possible targets you take off half of the gameplay 16:16 PilzAdam really? this glass is half of the gameplay? 16:17 Exio i'm a survival player - and i like the idea of "amazing builds" what are built when manually-gathered resources 16:17 RealBadAngel i spent almost a month building automated tree farm in minetest survival single player game 16:17 RealBadAngel which required tremendous logic to control all the stuff 16:17 RealBadAngel just for fun building it 16:18 RealBadAngel and you call glass 'too much"? i should fire up mc now and make some screenshots of my singleplayer world just for you 16:18 RealBadAngel to show you what survival means 16:18 PilzAdam Im not against adding more resources for survival players, but Im against making the same node slightlty different for decoration purposes 16:19 PilzAdam and bricks and stone are not the same node slightly modified 16:20 RealBadAngel i wont agree to limit it to just one game mode, i will release the glass in technic modpack then 16:20 PilzAdam really? you want it in all game modes or not at all? 16:21 RealBadAngel who plays build game?? 16:21 hmmmm pilzadam, is this supposed to be the desired translucency of ice? http://ompldr.org/vaTd4Yw 16:21 RealBadAngel im not 16:21 PilzAdam hmmmm, ummm.... yes? 16:21 hmmmm what's the ummm for 16:21 hmmmm why not just say yes 16:21 hmmmm but okay 16:22 RealBadAngel pull request is cancelled 16:22 hmmmm that was simple, all i had to do was transform the alpha channel too 16:22 PilzAdam I guess you just took the image from the commit I linked? I just have made it randomly transparent and wasnt able to test it in-game 16:22 hmmmm well with that image i was able to see that it didn't work properly 16:22 PilzAdam so the "ummmm" just says "I will look at it if the engine code work" 16:23 kahrl it looks deceptively simple, so it might be wrong, but I might have fixed the "Meshbuffer ran out of indices" problem 16:23 kahrl http://codepad.org/GjdCbsds 16:23 kahrl shall I make a pull request? 16:24 hmmmm wait 16:24 hmmmm 'might have fixed' 16:24 kahrl I only tested it with allfaces nodes 16:25 hmmmm i thought the problem was that there were too many for that single buffer and you'd need to allocate a new buffer 16:25 kahrl I know the fix won't work with nodeboxes that contain more than 65535 indices, but I don't know if there are any 16:25 kahrl yes, that's what it does 16:25 hmmmm i don't see any allocations though 16:26 kahrl if the for loop finds no valid meshbuffer, it allocates a new one below 16:26 hmmmm ah. 16:26 hmmmm makes sense... this doesn't leak any meshbuffers, right? 16:26 kahrl it don't see any reason it should 16:26 kahrl I* 16:27 hmmmm sorry, just sorta paranoid about memory leaks because we just wrestled with so many of them 16:27 kahrl I know, I've been guilty a few times in the past :( 16:27 hmmmm sure, make a pull request - thank you for the fix, and welcome back 16:29 PilzAdam so, what about this one? https://github.com/PilzAdam/minetest/commit/05af955a3741f49fa3e04611ac717c57fba3e935 16:29 kahrl actually it will work with ridiculously complex nodeboxes 16:30 kahrl since those call collector->append for each box separately 16:30 hmmmm https://github.com/minetest/minetest/commit/ddd2b18321a6dad82c4618bfb8f797579d4d6666 16:30 kahrl PilzAdam: :) 16:31 hmmmm heh, i was going to do that 16:31 hmmmm you made a separate branch for that!? 16:32 PilzAdam I always push to branches 16:32 PilzAdam I push it now 16:32 hmmmm wow :)! look at the commit logs 16:33 hmmmm it's not flooded with kwolekr anymore 16:34 PilzAdam hmmmm, wielditem and inventory image of ice look awesome now! 16:34 hmmmm kool 16:34 PilzAdam the actual nodes above water are still too glitchy :-/ 16:35 hmmmm there's a call to fix that 16:35 hmmmm i don't think i'll be the one to do it 16:35 Exio https://github.com/minetest/minetest/pull/662 - what about this? 16:35 * PilzAdam looks at kahrl 16:36 PilzAdam Exio, seems ok to me 16:37 Exio (and random fixes what are in the pull request page - https://github.com/minetest/minetest/pull/648 https://github.com/minetest/minetest/pull/670 ?) 16:38 PilzAdam has someone tested the serverlist thing yet? 16:39 hmmmm the first one ought to be tested first, since the last time we merged something that modified build-related things it totally messed things up 16:39 hmmmm the second one, celeron seems skeptical of but i believe it's good to merge 16:42 kahrl https://github.com/minetest/minetest/pull/686 16:43 PilzAdam tested sapiers collission thing, works fine 16:44 PilzAdam I would like to merge it, any objections? 16:44 thexyz don't you think we should add kahrl to the minetest team? 16:44 hmmmm that's sorta celeron's job 16:45 thexyz well, I have all needed permissions at github to do that 16:45 hmmmm besides, he might want to stay as an additional contributor because honestly minetest is a huge time sucker 16:45 kahrl ^ 16:45 thexyz okay 16:46 kahrl I don't always have as much time as this week, sadly 16:47 kahrl and I don't really play minetest very often 16:48 RealBadAngel PilzAdam, https://github.com/RealBadAngel/technic/commit/4b0aef17a0d7a834adf31b26fb0418eaca7ea958 16:48 RealBadAngel and sidenote, techinc will go game mode. 16:50 hmmmm hah 16:50 hmmmm i don't play minetest ever 16:50 RealBadAngel i do 16:51 RealBadAngel and i code to improve my gameplay 16:51 RealBadAngel and i dont play build at all 16:53 RealBadAngel if common and minetest_game is goin to be mc twisted and with limited to minimum content its not my game mode simply 16:53 RealBadAngel thus my mods will not support them too 16:54 hmmmm woah wait a minute 16:54 hmmmm https://github.com/minetest/minetest/commit/e703c5b81f87550e636ebb1ebb1eb64027a44687#L1L2116 16:54 hmmmm builtin hud enable/disable wouldn'tve worked anyway, look at the bug 16:54 PilzAdam https://github.com/minetest/minetest/commit/88ffb3f73bb16c6680ee10a8e804a699e366edd8 16:54 hmmmm err nevermind 16:55 hmmmm i could've sworn the flag field was a u32 16:55 hmmmm :) dumb dumb me 16:56 RealBadAngel goin to take a nap after work, laters 16:56 Calinou i don't play minetest ever 16:57 Calinou hello linus torvalds, do you still read code? 16:58 hmmmm huh? 16:58 hmmmm erm anyway 16:59 hmmmm i've noticed a recent trend where people add client events for things that do not require client events (such as setting a number for a player) 16:59 hmmmm presumably this is done for thread-safety, except the client event queue isn't thread safe anyway 17:00 hmmmm ...and it happens that the client's connection is handled in the game loop 17:03 PilzAdam why wasnt object <-> object collision added to the changelog for 0.4.6? 17:17 kaeza1 [13:54:43] builtin hud enable/disable wouldn'tve worked anyway, look at the bug 17:17 kaeza1 wut 17:17 hmmmm no nevermind 17:17 hmmmm that was just me being stupid.. i could've sworn that flags was a u32 17:18 kaeza1 ah I see 17:18 hmmmm in that case the code wouldn't work because values are big endian and it would always read 0 17:18 kaeza1 nope 17:19 kaeza1 it uses readU8() 17:19 hmmmm well, yeah, i see that.. 17:19 kaeza1 the only u32 there is player->hud_flags 17:19 hmmmm oh, that's where i got u32 from 17:19 hmmmm why is there that inconsistency? 17:20 kaeza1 inconsistency? 17:20 hmmmm well, yeah, if you send a u8 but it's actually a u32 in the structure 17:20 kaeza1 erhm... because of speed? 17:20 hmmmm 3 more bytes? 17:21 hmmmm i'd be way more worried about latency 17:21 kaeza1 anyway, I'm used to use 32-bit types even for things that count from 1 to 10 17:21 kaeza1 wut 17:21 kaeza1 the packet uses 2 u8's 17:21 kaeza1 one for id and one for the enable/disable flag 17:21 hmmmm erm 17:22 hmmmm from what i got, you said "i used a u8 when transferring it over the network because a u8 is faster to send than a u32, because there are less bytes" 17:22 kaeza1 yep 17:23 hmmmm but what i replied was, "but that doesn't matter, because 3 extra bytes in the same packet isn't very much, what would be noticably slower is latency on the other hand" 17:23 kaeza1 wait wait wait 17:23 hmmmm i didn't say all of that though, i compress what i say usually 17:23 hmmmm i already talk too much 17:25 kaeza1 ehrm... what I mean is I don't waste space in the packets when it's not needed 17:25 kaeza1 let me rephrase that 17:25 kaeza1 I don't make packets bigger than they need to 17:26 kaeza1 but when computing the flags, I use an u32 17:27 hmmmm that could be misleading though, somebody adding more flags might've thought later on that they have 32 flags to work with and not 8 17:28 hmmmm and then in order to add more flags you'd have to bump the protocol version 17:28 kaeza1 ummm... I don't get what you mean 17:28 kaeza1 the bit to set/unset is selected by the 'id' field 17:28 kaeza1 (which can go up to 255) 17:28 hmmmm but what if builtin hud items had more than 8 attributes someday 17:28 kaeza1 the flags field is just a boolean 17:29 hmmmm that is misleading 17:29 kaeza1 ... 17:29 kaeza1 define 'attributes' 17:29 hmmmm if the flags field is merely a boolean, then it should be is_visible or whatever and not marked as "flags" 17:29 kaeza1 I think we are not in the same channel 17:29 hmmmm attributes, flags 17:30 hmmmm details about the hud item that may be described with a "yes" and "no" 17:30 hmmmm being visible is one such detail 17:30 kaeza1 hrm... I don't care about other attributes 17:30 hmmmm exactly 17:30 hmmmm but i do 17:30 kaeza1 and celeron neither 17:31 hmmmm and making such a change to the protocol that's shortsighted would necessarily result in a protocol change later on if you do need to change it 17:31 hmmmm not caring about other things is okay if it won't break compatibility later on 17:31 kaeza1 well, again, do what you must and overcomplicate the stuff 17:31 Exio he wants a general and super-long-term solution 17:32 VanessaE [04-25 12:21] pilzadam, is this supposed to be the desired translucency of ice? http://ompldr.org/vaTd4Yw <--- make it more transparent. 17:32 PilzAdam VanessaE, its unusable anyway, so we dont get transparent ice yet 17:32 hmmmm vanessae, i fixed my part of the code... i asked if that's how transparent he intended it to be 17:32 PilzAdam s/unusable/too glitchy above water/ 17:32 hmmmm and i disagree, it's totally usable with shaders enabled 17:33 PilzAdam VanessaE, you use a not run in place installation, right? can you test this: https://github.com/minetest/minetest/pull/648 ? 17:33 hmmmm but that's the thing, without shaders it's definitely broken when around other transparent nodes 17:34 hmmmm the reason why i added it is because people could still benefit from it in most other cases. but i wouldn't recommend default usage of it in its current state 17:34 PilzAdam hmmmm, the water under the ice disappears sometimes with shaders, at big lakes covered with ice thats not good 17:34 hmmmm that's another issue, but it's much more minor in comparison 17:35 hmmmm and with a high enough alpha (like what ice has now), you wouldn't notice it 17:36 PilzAdam you do notice it in big lakes, thats the problem 17:36 hmmmm just don't use the feature at this point 17:37 PilzAdam yes 17:37 hmmmm when we add transparency sorting, then we'll flick the switch on 17:37 * VanessaE catches up 17:38 hmmmm minecraft has the same issues we do, if you looked at the april fool's release, it does have colored glass as well but the reason why it's not in the game is because it's too buggy to be usable around other transparent nodes 17:38 hmmmm but the difference between us and minecraft is that nodes are defined in lua 17:38 Jordach and we have a working mod api 17:39 hmmmm so if people want cool stuff that has a bug with it, they can 17:39 VanessaE hmmmm: "how transparent" -- gotchya. 17:39 Exio mod api? it'll get released for 1.3, er, 1.4, er, 1.5, er 1.6! 17:39 Exio 17:39 VanessaE (he should *still* make it more transparent though) 17:40 VanessaE PilzAdam: sure, I'll try that pull in a little bit 17:41 VanessaE hmmmm: got a link to a commit I can use to test the current state of alpha code? 17:42 PilzAdam VanessaE, engine is already upstream and here is the transparent ice: https://github.com/PilzAdam/common/commit/fb04d3f0ba5cec84757b84e437aaff2bd1a234b6 17:43 VanessaE ok 17:44 VanessaE bringing those two in now. 17:48 VanessaE favorites list works now. 17:49 Exio Zeg9 already tried it 17:49 VanessaE I don't see any effect on the ice. No alpha for me. 17:51 VanessaE (with or without shaders) 17:52 PilzAdam VanessaE, have you updated the engine? 17:52 PilzAdam serverlist fix merged 17:54 VanessaE PilzAdam: yep, applied those two patches to their respective repos and did a git pull on both. 17:55 VanessaE wait, I know why 17:55 VanessaE forgot to actually apply your alpha ice. 17:56 PilzAdam http://en.wikipedia.org/wiki/Facepalm 17:56 PilzAdam :-p 17:56 VanessaE :P 17:58 VanessaE ok, ice works. 17:58 VanessaE it still needs to be a *little* more transparent (maybe by another 20% at most) 17:59 VanessaE re: server list... too bad it doesn't store passwords. 18:00 VanessaE for me, the ice looks better *without* shaders btw 18:00 VanessaE the alpha is perfect then 18:01 VanessaE (other than the already-discussed z-sorting issue) 18:03 VanessaE with shaders, the faces behind another alpha item (e.g. water) disappear, so ice in water looks like just a 2D surface on top, and any ice under the water is invisible from above 18:03 VanessaE but I guess that's known. 18:03 VanessaE that applies to dropped ice entities too btw 18:04 VanessaE I'd have to say though, on land it looks pretty good 18:05 VanessaE even clouds seem to be layered behind it like they should be 18:06 VanessaE backface culling needs to be disabled for these sorts of nodes though 18:07 VanessaE or at the very least, make sure the upper faces are also removed 18:11 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_1113776348.png 18:12 VanessaE that's two stacks of two ice blocks diagonally adjacent, with a single ice block in the space behind/between them. If you pan the camera down so that the middle block disappears, the upper face of it is still visible. 18:12 VanessaE but I guess you knew that. 18:18 VanessaE interestingly, the alpha works with HDX's ice texture also -- but that texture doesn't have an alpha channel. 18:21 Calinou it always works 18:22 Calinou it's not done on texture, it's done on engine... bad for textureability :/ 18:24 VanessaE That's what I thought (I don't always follow the conversation too well) 18:27 hmmmm when you say "the alpha works", you mean "turns whatever it is into a shadowy, translucent block"? 18:28 VanessaE yep 18:28 VanessaE see the above screenshot 18:28 hmmmm that's not a bug 18:29 hmmmm you're simply using it in a manner that is not intended 18:29 VanessaE heh 18:29 hmmmm i guess the regular textures don't _have_ alpha channels 18:29 VanessaE I didn't say it was a bug, per se. :) 18:29 hmmmm or they're set to some default like 128 18:29 VanessaE actually, the regular ice texture has an alpha channel, but HDX's one does not. 18:30 VanessaE it's no big deal, I'm just relaying my observations is all. 18:41 rubenwardy sokomine: https://gist.github.com/rubenwardy/b5cd1a01049e0c935ecf 18:41 rubenwardy damn 18:54 proller need to commit, any objections? https://github.com/proller/minetest/commit/aa31c1663695aba28f48facea08de2158b71676d 18:55 PilzAdam proller, the change in indev mapgen seems rather random to me 18:56 proller 200 cause core dump 18:56 proller 150 - not 18:56 PilzAdam oh 18:56 proller its very rare 18:57 proller need to better debug, but this small fix helps 18:58 proller its like at generating cave larger than loaded area, and something goes wrong 18:58 proller will commit! 19:29 VanessaE regarding the favorites list, can we please make that store passwords (well, hashes thereof)? It's about useless otherwise :-/ 19:31 sapier no use to create a hash if it's used directly to authenticate player 19:31 VanessaE well what does the client send to the server? surely not plaintext?? 19:31 sapier as far as I know its plaintext 19:32 sapier but I'd have to look in code to be sure 19:32 VanessaE ewwww 19:32 sapier did you think minetest has any security features? ;-) 19:33 kahrl it sends the hash 19:33 sapier it does? wow 19:33 VanessaE kahrl: oh good. in that case, store the hash in the favorites list 19:33 sapier salted hash? 19:33 kahrl not sure. it didn't use salt when I last check, might have been added since then 19:34 kahrl checked* 19:35 sapier I doubt ... but I'll have a look ... still if password is directly hashed without salt fetched from server it's useless to improve security 19:35 sapier if it's not salted you can use rainbow tables 19:35 kahrl it's salted with the player name 19:35 VanessaE sapier: better to use an unsalted hash than plaintext. 19:36 sapier no in fact it's no difference 19:36 VanessaE which one takes longer to break? 19:36 kahrl although dictionary/bruteforce attacks are still possible for weak passwords 19:36 sapier none 19:37 kahrl or reusing the hash for a different server if you learn it 19:37 sapier it's more difficult to fetch network communication than to break unsalted hash 19:37 VanessaE well since it's salted, the point is moot 19:38 sapier true 19:38 VanessaE I call the favorites list useless because a single click automatically joins that server...which if you need a password (like 90% of the ones out there), means you immediately get a permission denied. 19:38 VanessaE (I talk good English, really I does.) 19:38 sapier so at least passwort is difficult to fetch ... but logging in without authentication is still as simple as reading network traffic 19:39 sapier so maybe a "enter password" dialog should be added? 19:40 VanessaE no 19:40 VanessaE we already have a password entry field 19:40 sapier not everyone wants his password saved 19:40 VanessaE just store the damn password hash and send it to the chosen server -- like every other login-capable application is capable of these days. 19:40 kahrl add a 'save password' checkbox/config setting? 19:40 VanessaE fine, so provide a checkbox, "[X] Save Password" 19:40 VanessaE ninja'd by kahrl. :) 19:41 sapier good enough 19:41 celeron55 well, pretty much any human-written sha1 hashes are very fast to crack with proper tools 19:41 sapier I just don't want my password/hash saved automaticaly without having a choice 19:42 celeron55 because sha1 is optimized for speed 8) it really is just for a tiny bit of protection from the worst script kiddie server admins 19:42 sapier celeron if player/pwd hash is sent without encryption to server this can be read by attacker and used directly so no need to crack it 19:42 celeron55 sapier: of course it can be 19:43 celeron55 i once wrote a proposal of how to improve this thing in a simple way to overcome that 19:43 celeron55 i wonder where that is, hmm 19:44 celeron55 it's here: http://c55.me/minetest2/wiki/doku.php?id=dev:slight_authentication_improvement 19:44 sapier I don't know your proposal so I can't tell anything about it. generally speaking I always have doubt if someone implements security features her/himself instead of using proven existing solutions 19:45 celeron55 (the bottom of that page isn't written by me) 19:45 sapier this suggestion seams to be at least a full security level better than current solution 19:46 kahrl agreed 19:46 kahrl for the hash function maybe use PBKDF2? or is that outdated already? 19:47 sapier hmm I assume sha2 is fine for minetests security level ;-) 19:47 celeron55 anything of which we can easily get hold of a small portable properly licensed implementation 19:47 ShadowNinja celeron55: That sounds good but the salt would have to be random every time 19:47 sapier but maybe use 256bit 19:47 celeron55 sapier: no, sha is not fine 19:47 kahrl BSD license would be fine so we could use OpenBSD's implementation 19:48 kahrl http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libutil/pkcs5_pbkdf2.c?rev=HEAD 19:48 celeron55 unless you use it eg. by recursively running it over itself like 1000 times; but that's pretty much what pbkdf2 does, but it takes possible problems that come from it into account 8) 19:48 sapier isn't openssl license quite free? 19:48 sapier ohh .. openssl and windows 19:49 celeron55 ShadowNinja: that would mean storing a plaintext password on the server 19:49 ShadowNinja Just using a stronger hash won't work, you can just send the hash without determining the password 19:49 celeron55 ShadowNinja: it's not how password security is done 19:49 sapier "properly licensed" implementation as primary argument for a security algorithm sounds wrong to me 19:50 celeron55 sapier: haha what 19:50 celeron55 if you are serious in what that implies, go to hell 19:50 VanessaE this is all still offtopic though. 19:50 sapier there are few correct implementations out there but hundreds of wrong, if you only consider license you most likely will get one of the later 19:51 celeron55 "properly licensed" = "compatible with lgpl"; and we make no exceptions to this 19:51 celeron55 sapier: these days the world is full of good MIT/BSD implementations of everything, especially of security stuff 19:51 sapier is openssl license really incompatible to lgpl? 19:52 ShadowNinja No, the server would send a random salt or the client would generate a salt only good for that connection, the client would use that salt with the password and the server would then use that salt to check it, an attacker wouldn't be able to enter because the salt would be different for each connection. 19:52 VanessaE celeron55: fuck it, go all out and pull stuff from that one hardened distro, I forget which one it was :) 19:52 VanessaE (I keep thinking netbsd) 19:52 ShadowNinja Tails? 19:52 celeron55 ShadowNinja: ah that way; i think that's usually called a nonce 19:55 sapier server stores hash of playername+pwd 19:55 sapier sends salt to client 19:55 sapier client hashes salt with hash of playername+pwd 19:55 sapier server can check result 19:56 ShadowNinja Exactly 19:56 ShadowNinja Would that work? 19:56 kahrl how will the initial password be set, by the way? 19:56 sapier same as now 19:56 celeron55 sapier: i don't care about openssl's license; openssl is terrible anyway 8) 19:57 sapier salt to client 19:57 sapier hmm 19:57 sapier you're right 19:57 celeron55 sapier: also, the license is incompatible with almost anything because of their naming clauses 19:57 sapier I doubt that out lawyers don't even stop us from linking openssl to our products 19:58 celeron55 kahrl: if that nonce stuff is used for regular auth, the first time needs to be as in my proposal 19:58 VanessaE brb 19:58 celeron55 we don't need even 1% of what openssl contains anyway; better use some more minimal library 19:59 sapier do what you believe to be good still I strongly suggest to be very carefull when deciding for a library 20:00 sapier your suggestion won't solve the initial problem celeron 20:00 sapier I don't see a solution to fix the problem with initial password setting 20:02 celeron55 i don't think that old proposal of mine would be particularly good; but i also think that your mindset to security will not result in anything useful either 20:03 sapier I just wanted to stop this discussions, I've told my concerns, decision what to do isn't mine 20:03 sapier I'm realistic enough to know my only possibilities are either accept the decision what ever it will be or leave ... for now I don't feel like leaving 20:04 celeron55 i do have like 1000x more experience in cryptography (due to work) than when i wrote the current authentication stuff and would write proper encryption for login without using the most bloated of libraries out there 20:04 celeron55 but it's once again a matter of where i want to put my time in 20:04 celeron55 s/would/could/ 20:05 celeron55 but 20:06 sapier it's been bad for some time now it won't be a problem to stay like that for som months ... I just want to stop/slow down changes in wrong direction 20:06 celeron55 in any case, in any proper implementation, there are only two options for logging in onto a server without entering a password: storing plaintext passwords on the client, or a proper private/public key authentication system 20:07 sapier true and proper private public key seams to be a little bit overkill for minetest 20:07 kahrl hmm? 20:07 celeron55 the first is what web browsers do when they ask whether you want them to remember a password 20:07 celeron55 sapier: well maybe or maybe not; it's quite easy when you know what you're doing 20:07 kahrl can't you store the hashed password (salted w/ username) and use that as the basis for whatever fancy authentication scheme you use in the network protocol 20:07 sapier yes ... that's where this discussion started, I wanted to have choice if client stores password or not 20:08 celeron55 kahrl: yes; but from the standpoint of the protocol, that's the plaintext password 20:08 kahrl as long as it's only stored on the user's machine and not sent over the network I wouldn't worry 20:09 kahrl user is responsible for his machine security 20:09 kahrl and it's better than storing the plaintext password 20:09 sapier as any mod can send this password :-) 20:09 kahrl not if you read the mod's code ;) 20:10 celeron55 well, in any implementation that does no have an encrypted network protocol, it must go in an unencrypted and unhashed form to the server when the player registers or sets a new password 20:10 sapier I don't wanna read that argument anymore as noone does this 20:10 kahrl I do. Argument refuted ;) 20:10 sapier lol I'm sorry but I don't believe you ;-) 20:11 kahrl but I don't install hundreds of mods either 20:11 kaeza soon: Fortknoxtest :D 20:11 kaeza (C) 2013 Sapier 20:12 sapier kaeza if ANY other person would think at least a little bit about security I wouldn't have to stand at a that extreme position to get at least a little bit really included ;-) 20:13 sapier if you summarize about medium value of security positions found in minetest community (including my extreme position) you'll have what I personaly think needs to be done ;-) 20:13 kaeza meh 20:14 sapier but something completely different, is there any chance to trigger a travis build? 20:14 kaeza I don't care what you do, but just don't get in anyone's way with your mod security 20:14 kaeza now, I go back to code 20:15 sapier kaeza have a look at commits of last 3 months I believe I don't stand in anyones way 20:16 sapier hmm ... considering collision box commit maybe I do stand in someones way :-P 20:17 kaeza well... the benefit may outweigh the problems 20:18 sapier lol you won't realize benefit if by my pressing to add security features your computer will be saved by malware ;-) 20:19 sapier but I still don't understand how travis system works is anyone here who does? 20:20 celeron55 it's set up by thexyz 20:20 sapier I assume I'll have to setup a vm containing gcc4.6 to find out if my patches work then 20:26 kaeza hmmmm, misc: /home/diego/src/minetest/src/main.cpp:1694:28: warning: 'dtime' may be used uninitialized in this function [-Wuninitialized] 20:27 kaeza err.... wrong line 20:27 kahrl kaeza: I saw that warning but it's a false positive 20:28 kaeza kahrl, I know, I just like a compilation to go with as less warnings as possible 20:29 kaeza even if stuff is harmless 20:29 celeron55 sapier: by the way, the insecure file and lua function restrictions are still on the list of things i want to merge as soon as they are made in the way that i see as good; ask me some day if there's something unclear about that 20:30 celeron55 i think i did try to explain that a while back 20:30 sapier I've put them "on hold" until the scriptapi changes are included. Is there any particular thing missing? 20:31 sapier Imho I've already added your suggestions, maybe I didn't understand everything correct? 20:32 sapier btw if we allow loading of debug module any "local func" will be useless as you may access any part of stack by using debug functions even local variables of other files 20:34 celeron55 i think #495 is quite on the right track; i'll try to find the time to test it once you have painfully rebased it again 8) 20:35 sapier thx ... I'll do that after the scriptapi patch is merged ... my time is limited too so merging to current just to merge to scriptapi later isn't quite a thing I want to do 20:36 sapier as noone is eager to have security included I think setting priorities this way will be fine 20:36 PilzAdam sapier, can you add a param to object definition to disable object <-> object collision for it? falling items stopping you is pretty annyoing, especially in the TNT mod (wich creates tons of them) 20:37 celeron55 we have good security included in our user's heads and distribution channels currently, so there's nothing to worry about 20:37 sapier hmm non solid objects shouldn't stop you pilzadam 20:37 celeron55 but once the game can download mods by itself from a repository, then this must have been in place and well tested for a while before that happens 20:38 PilzAdam sapier, the only way to disable it currently is set physical = false, but that also disables node collision 20:39 sapier true.. hmm I'll have to think about it ... imho adding a real collision system would be correct way to fix this but it's a lot of work 20:39 sapier with "real collision system" meaning some sort of "realistic" crashes 20:40 kaeza just add void *p = NULL; *p = 0; 20:40 kaeza there you have a reaalistic crash :D 20:40 sapier hmm I believe nothing will happen if you add this 20:40 sapier ohh first is a declaration 20:40 sapier ok ok 20:41 sapier realistic collision system would mean adding some sort of mass to each node ;-) if that was added collision s could be calculated quite easy ... but I'm not sure if this is a feature that is really wanted? 20:42 sapier any opinions about it? 20:42 kahrl if that means physics would be less glitchy I'd be for it 20:43 kahrl as long as it's reasonable in terms of performance 20:44 kahrl < is allowed to complain because he added some of the glitches in the first place 20:46 sapier there will be a performance impact as it's adding additional calculations but imho this should be less than impact of o<->o collision 20:48 celeron55 well a properly optimized actual physics library shouldn't really take more resources than what MT's naive stuff takes now 20:48 celeron55 but there would be problems in such 20:48 sapier true but adding this is really lots of work ;-) 20:48 celeron55 eg. player movement has become very finely tuned along the years 20:49 celeron55 porting it to some library would be painful 20:49 celeron55 also such a library would imply that we add proper support for rotation on every axis 20:49 celeron55 and whatever 20:50 celeron55 not a small thing in any way 20:50 kahrl I don't think player movement would have to be 100% identical 20:50 kahrl just make sure jumping up hills/stairs is not annoying, support sneak ladders and things like that 20:50 VanessaE jeez, I mention the need to store a password in the favorites list and it morphs into a whole discussion on network security.7 20:50 VanessaE heh 20:50 celeron55 no, but there are some things in place that make it much better than without those things 20:50 VanessaE -7 20:50 celeron55 and those things aren't really standard physics library stuff 20:51 kahrl yeah, I don't think just using any external library would work without investing lots of extra work 20:52 sapier can someone merge this fix: https://github.com/minetest/minetest/pull/613 20:52 celeron55 if i did start MT from scratch, i would use a physics library; but now it's a wholly different situation 20:58 hmmmm :( 20:59 hmmmm my authentication idea is nonsense 20:59 hmmmm and it's not really mine either 21:00 hmmmm erm, the next level of security above that one would be SRP 21:00 hmmmm and then above that is the server sending the client polymorphically modified authentication modules that the client executes and returns the result of 21:00 hmmmm and so on 21:01 hmmmm if you really think minetest password security is that important, perhaps you should use SRP, but that would require us to add libgmp as a dependency and it's easily another source file worth of code 21:01 hmmmm but if it's that important to you...... besides, it's your time, not ours 21:01 sapier lol ... and me is called overcomplicated ;-P ... btw who will protect client about malicious servers if server sends executable code ;-) 21:02 hmmmm the obvious answer to that would be for us to buy a key from verisign and authenticate binaries with it 21:03 sapier true .. who starts collecting money? 21:03 hmmmm we'd use the donations that are typically put toward hosting 21:04 hmmmm it was a joke though, don't get any ideas 21:04 sapier I think this might be an option once all of the other security issues are fixed ... but that won't be for quite some time ;-) 21:05 hmmmm SRP seems to be good enough for large commercial games 21:05 celeron55 oh SRP 21:05 celeron55 this seems worth investigating: http://freecode.com/projects/tinysrp 21:08 hmmmm SEMinetest 21:08 sapier i wonder when this battery will be depleted it told 7 minutes left 30 min ago :-) 21:08 celeron55 looks pretty good; no bloated dependencies and builds right away in no time on this linux box 21:09 celeron55 and the tarball has just a flat bunch of source files and few others 21:09 sapier recent release 2001? 21:11 hmmmm it includes its own big number library? 21:11 celeron55 it has a "stripped-down version of openssl" which actually means it basically has a few of it's bignum source files and some hash function 21:12 sapier and openssl from 2001 should be checked for fixes that have been aplied to that code in openssl until now 21:13 celeron55 i wouldn't guess there would be considerable bugs in '01 openssl's bignum stuff, but it's worth checking though 21:19 celeron55 the most recent fixes that have a chance of mattering are at 0.9.6->0.9.6a (2001-04-05) 21:20 celeron55 if 0.9.6a isn't used in there, that's easy to backport :P 21:21 sapier are you sure 0.9.6a is maintained anymore and issues of later versions aren't present in 0.9.6a too? ;-) 21:22 hmmmm the only way we'd know is with a complete source code audit 21:22 celeron55 i'm sure any remaining issues in heavily actively used base code of openssl would have been found in 12 years 8) 21:22 sapier this last minute of battery power already lasts for half almost 15 minutes :-) 21:22 hmmmm let's go for it! 21:22 celeron55 http://members.tripod.com/professor_tom/archives/libtinysrp-0.7.5.tar.gz 21:23 celeron55 there's just 6k SLOC anyway 8) 21:23 sapier I've already done 10 audits this month no need to do another one 21:26 kahrl tinysrp is based on srp-1.7.1 which doesn't support SRP-6. is that a problem? 21:27 hmmmm i believe so 21:27 hmmmm also just an aside, if we're really doing SRP, you better go all-out and use SHA512 22:04 VanessaE since pilzadam's already gone... flowers got added to common and are included via game.conf in build and survival - any particular reason minetest_game doesn't also use them? 22:29 kaeza hmmmm, I mean to not be interrupted by misc stuff in there 22:29 hmmmm oh 22:30 hmmmm i'm trying to find another packet that only modifies the local player and nothing else 22:31 Exio if you see any what does that - tell me 22:31 Exio it'll be useful for looking for some code i want to try 22:31 hmmmm nope 22:31 hmmmm it seems to be quite reasonable 22:32 hmmmm basically you see packets processed like this: 22:32 hmmmm if it modifies some client data structure, it'll just change it right there in the packet handler 22:32 hmmmm if it modifies a variable in the_game(), such as camera rotation or whatever, it'll use a client event for that 22:33 hmmmm for example, TOCLIENT_HP, TOCLIENT_MOVEMENT, TOCLIENT_MOVE_PLAYER, etc. 22:36 hmmmm why do people not line things up 22:36 Exio k, thanks 22:36 Exio and, line things up? what? 22:36 hmmmm this is probably just my OCD but people who don't line assignment operations up are truly worse than hitler 22:37 hmmmm who did the physics.... 22:42 khonkhortisan what're line assignment operators? 22:42 khonkhortisan or rather, the absense of? 22:42 hmmmm player.cpp:63 22:42 hmmmm you might not want to look, it will probably cause eye damage 22:43 khonkhortisan BS? I've dealt with it already 22:43 hmmmm it's a bunch of BS 22:43 hmmmm 12 of them 22:45 Exio taoki's code iirc 22:45 khonkhortisan If you're not careful, you'll get a line like this m_vertices[i].Pos.rotateXZBy(atan2(ppos.Z/BS-m_pos.Z, ppos.X/BS-m_pos.X)/core::DEGTORAD+90); the positions really should be in the same units but they weren't at that specific place 22:46 Taoki Which code exactly? Doesn't sound like me 22:46 Exio https://github.com/minetest/minetest/blob/master/src/player.cpp#L64 22:46 khonkhortisan #define BS (10.0) 22:46 khonkhortisan "to disallow plain casts" 22:46 Taoki Ah, that. Those are the defaults for the physics settings 22:47 hmmmm that doesn't bother you? 22:47 hmmmm look at how they're all over the place 22:47 Taoki What? What's all over the place, and what should bother me (if you mean my code)? 22:47 khonkhortisan To set a variable: variable = number * 10; to get a variable: result = variable / 10; 22:47 hmmmm the assignment operations 22:48 hmmmm it's like you walk into a classroom and the desks are scattered everywhere 22:48 Taoki I think they were meant to be modifiers to the defaults. Don't remember exactly why I did them, nor what's wrong about them 22:48 hmmmm whatever 22:48 khonkhortisan They are there to get in your way 22:49 khonkhortisan We should just overload = to multiply or divide by BS 22:49 Taoki Oh. I think they where there to not break compatibility with clients that didn't have the new physics code 22:49 Taoki Or servers. Since if those default values wouldn't be there, clients would get no physics on old servers and be stuck 22:50 Taoki hmmmm: ^ 22:50 Taoki If you have a better way to prevent that, you can change the initializations, if it doesn't change how things work otherwise. You can even remove them if you wish, since the physics have been in for a long time and connecting to the previous server version should work 22:50 hmmmm khonkhortisan: lol 22:50 hmmmm taoki, no that's not what i was saying at all 22:50 Taoki But it would break compatibility with servers under that change 22:51 hmmmm apparently the assignments not being lined up does not phase you in the slightest 22:51 Taoki ok. Still can't get it, sorry. Prolly cuz I'm a bit tired too. But I remember those definitions were necessary 22:51 Taoki ah. You'd prefer they were all in one line? 22:51 hmmmm n... no 22:51 hmmmm in one column 22:52 hmmmm but i already did it 22:52 hmmmm http://pastebin.com/qpwY3kfC 22:55 Taoki Aah. You meant using tabs to keep the values in order. Yes, that does look better... I didn't notice it 22:55 hmmmm not tabs, spaces 22:55 hmmmm for lining operators up, use spaces 22:55 Taoki I usually add tabs there, but whatever works 22:55 hmmmm i don't get how somebody can't notice that 22:55 hmmmm doesn't it hurt your eyes a little? 22:56 khonkhortisan I put four/five spaces before my if to line up with my elseif/else if 22:56 Taoki It does look better like that. But there are cases where I don't notice such detail 22:56 Taoki I agree it's preferable though, and good to correct 22:57 Taoki I do try to always keep code clean and readable. But some things slip past me too :P 22:57 hmmmm i do small things like that if i'm working somewhere with code looking like that and it bothers me enough 23:01 hmmmm khonkhortisan, if i recall correctly, you mentioned that the crosshair is a pixel off in each direction 23:02 hmmmm let's see... according to http://irrlicht.sourceforge.net/docu/classirr_1_1video_1_1_i_video_driver.html, the beginning and ending positions are inclusive 23:02 khonkhortisan Yes, It doesn't draw the end pixel 23:02 hmmmm so let's assume displaycenter is (50, 50) 23:02 khonkhortisan Or draw at all if the start and end are equal 23:02 hmmmm it draws from (40, 50) to (60, 50) 23:02 hmmmm that's 20 pixels 23:03 hmmmm which is an even number 23:03 hmmmm are you absolutely sure? "Draws a 2d line. Both start and end will be included in coloring. " 23:04 khonkhortisan Shouldn't it be drawing 21 pixels? 10 left, the center, 10 right? 23:05 hmmmm hmm 23:05 hmmmm suppose we had a really small screen with a resolution of 2x2 23:05 hmmmm what would the displaycenter be 23:05 Exio 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 23:05 Exio between 40 to 60 23:05 hmmmm oh 23:05 hmmmm :/ he's got me 23:06 hmmmm so you're right, it should be drawing 21 pixels, and indeed it does 23:06 hmmmm but you said it was still off 23:06 khonkhortisan I'm seeing 10 left, 1 center, and 9 right when I take a screenshot 23:06 kahrl I always thought rendering details like that were dependent upon the video driver 23:06 khonkhortisan Also 10 up, 1 center, 9 down 23:06 khonkhortisan They are. 23:06 hmmmm kahrl, not when it says it explicitly in the irrlicht documentation 23:06 khonkhortisan it's drawing from displaycenter-10 to displaycenter+10 23:06 khonkhortisan and it ends up lopsided 23:07 kahrl hmmmm, might have been some guy testing it only on selected hardware and writing it into the docs 23:07 hmmmm so anyway according to game.cpp:1418, displaycenter is screensize.X / 2, screensize.Y / 2 23:07 hmmmm so our display center would be (1, 1) 23:07 hmmmm if we take displaycenter to be a literal coordinate, that'd be the right bottom pixel 23:08 khonkhortisan topleft 23:08 hmmmm er 23:08 hmmmm top left? 23:08 hmmmm how do you get that, lol. 23:08 Exio 0,0 0,1 1,0 1,1 23:09 khonkhortisan I did some tests at low coordinates with draw2DLine 23:09 hmmmm X = 0 is at the right, though? that's hard to believe 23:10 khonkhortisan X is ltr, Y is ttb 23:10 hmmmm right 23:10 hmmmm so it would be top right 23:10 hmmmm not top left 23:10 khonkhortisan left. 23:10 hmmmm erm 23:11 kahrl could antialiasing have an effect? 23:11 khonkhortisan -Y 23:11 khonkhortisan -X +X 23:11 khonkhortisan +Y 23:11 hmmmm so if kahrl is right on this and i suppose he is, it's something out of our control anyway and we shouldn't have to worry about it 23:11 khonkhortisan The lines are solid. I hope it's not antialiasing. 23:11 khonkhortisan I want to draw black outlines around the cursor and/or only draw the center pixel once so the alpha value is correct 23:12 kahrl use an image? 23:12 khonkhortisan If for some reason the image isn't there the crosshair loses its outline again 23:14 Exio with https://github.com/minetest/minetest/pull/653? 23:15 hmmmm do people still want that ^? 23:15 hmmmm there's the HUD API now... 23:15 hmmmm since i'm doing hud things i'd throw it in 23:15 Exio #306 with support for changing crosshair_color/alpha. and updated to the actual code. 23:15 Exio crosshair_color/alp`ha 23:15 Exio alpha * 23:16 Exio i personally use pink/purple crosshair/selectionbox 23:43 kaeza hmmmm, some people want per-player textures, but I'd prefer it to be server-side as it is with the HUD API 23:43 kaeza (I mean local textures) 23:43 kaeza err... whatever, you get what I meant 23:44 hmmmm hmm 23:44 hmmmm this is a rather controversial topic... i'd rather get a vote on it 23:44 kaeza actually... I think both can coexist 23:47 kaeza derp 23:47 kaeza the selection box could've made configurable as well 23:48 kaeza meh 23:48 kaeza perhaps a per-client one (assuming there's none currently) 23:51 Exio kaeza: ? 23:51 Exio selectionbox_color? 23:52 kaeza Exio, just talking to myself 23:52 kaeza I know about that one ;) 23:53 hmmmm if i am going to do this, i'll merge that pull request as-is 23:54 hmmmm does anybody have a problem with this? https://github.com/EXio4/minetest/commit/b5e7d9bd419f96706006247ff6c74d2c34317061 23:56 kaeza looks good