Time Nick Message 00:37 RealBadAngel im debbuging now what getNodeNoEx returns and i keep getting strange things 00:40 RealBadAngel what is content = 29 ? 00:47 RealBadAngel nvm, found out 00:57 hmmmm the 30th node that you registered 8) 01:02 RealBadAngel i was dumpin the content on direction i had problems 01:02 hmmmm sooo 01:03 RealBadAngel in fact at the very beginin (just loaded the world) it shows there 127 - content ignore 01:03 hmmmm any objections to the use texture alpha channel? 01:03 RealBadAngel its ok with me 01:03 hmmmm there are two problems with it though, and i'd really like to document them beforehand, where would i do that? 01:04 RealBadAngel on dev wiki? 01:04 hmmmm i guess, but i was thinking more like on github 01:04 hmmmm do i just create two bug reports? 01:05 hmmmm and refer people to those if they complain? 01:05 hmmmm do i put the known problems in the lua_api.txt? 01:06 RealBadAngel maybe put link to wiki in doc and then later on when problems are solved remove it? 01:06 hmmmm i guess 01:08 RealBadAngel about my problem, content ignore is just one thing, second is when i put node at the border of the block, only nodes in this block are updated 01:08 RealBadAngel neighbourin block is not updated 01:09 RealBadAngel so effect in both cases is the same, but reasons are different 01:10 hmmmm why not just connect with content ignore too? 01:11 RealBadAngel that fixes first reason 01:11 RealBadAngel but not the second 01:11 RealBadAngel when im placing the node 01:11 hmmmm yeah, you'll have one less problem though 01:12 RealBadAngel i guess autoconnecting nodes shall force update the neighbour if it is in another block 01:13 RealBadAngel but this should be done on_place, not in render code imho 01:14 hmmmm then why not do it there? 01:15 RealBadAngel if i put such trigger in mesh update thread i could cause chains of forced updates 01:16 RealBadAngel in fact i need to do that only once 01:17 RealBadAngel simple punch on ANY node in non updated block fixes the connections 01:17 kahrl what if you change addUpdateMeshTaskWithEdge to update all 6 adjacent meshes instead of only 3 of them? 01:19 RealBadAngel but then updating the neighbours will trigger the update for their neighbours and so on 01:20 kahrl no 01:20 kahrl it calls addUpdateMeshTask 01:20 kahrl it's not recursive 01:21 RealBadAngel if not then i will try to do so 01:22 RealBadAngel ah 01:22 RealBadAngel that will really help imho 01:23 RealBadAngel it add check only to - direction 01:23 RealBadAngel and problem i noticed on ALL + directions 01:25 RealBadAngel yikes! it works :) thx kahrl :) 01:26 RealBadAngel shall i post client.cpp change to addUpdateMeshTaskWithEdge as separate patch? 01:27 hmmmm yes 01:27 RealBadAngel ok, i will do so in a few minutes 01:27 hmmmm kinda wonder what the rationale behind making it only update 3 directions is now 01:27 RealBadAngel will make this with loop and table 01:27 RealBadAngel 6 same pieces of code in a row looks stupid 01:28 hmmmm i made it look nice in calcLighting() 01:28 kahrl yeah, use g_6dirs 01:29 kahrl hmmmm: I think this piece of code is really old... 3 directions used to be enough 01:30 hmmmm hrm 01:30 hmmmm RBA, do you want to commit your thing first, or shall I? 01:30 hmmmm it's going to cause a conflict either way i bet 01:32 RealBadAngel i can see same code down below in addUpdateMeshTaskForNode 01:33 RealBadAngel also only 3 directions 01:33 hmmmm i wouldn't change it if i were you 01:33 RealBadAngel why? 01:34 hmmmm the 3 directions is sufficient for that, evidently 01:34 hmmmm doing more work than is necessary is bad 01:34 hmmmm if your thing works with the one modification, i'd leave the other thing be 01:34 RealBadAngel ok, at least if it pops up i will know where to look ;) 01:34 hmmmm yeah 01:34 hmmmm hope it doesn't though 01:35 hmmmm i mean doesn't that put twice as much work on the mesh update thread? 01:36 RealBadAngel if it does i guess we have to live with it, because it is ablosutely necesary imho 01:37 kahrl the difference is 3 more mesh updates when the client sets or removes a crack 01:38 RealBadAngel so no big deal 01:38 hmmmm er 01:38 kahrl maybe 01:38 hmmmm okay :) 01:39 kahrl I remember that I coded the crack stuff into the animation system so that cracks didn't eat all performance on celeron's hardware 01:40 kahrl before then, every time the crack texture changed, there were 4 mesh updates 01:41 kahrl now it is only when the crack is added or removed 01:42 hmmmm now hold on a minute, when you say update, does it mean the entire mesh for that mapblock is regenerated, or is the existing mesh modified? 01:43 kahrl yeah regenerated 01:44 kahrl nowadays changing the crack texture only modifies the existing mesh 01:44 hmmmm sounded painful before 01:44 kahrl it was =) 01:49 kahrl I keep stumbling upon mapblock_mesh.cpp:1365 01:50 kahrl should I try to implement the suggestion there? people seem to run into that limit somewhat often 01:50 kahrl (for irc log SEO: FIXME: Meshbuffer ran out of indices) 01:53 RealBadAngel go on, its really needed 01:54 RealBadAngel i started with it but im still learnin stuff related to meshes 01:56 RealBadAngel moretrees makes you hit that limit in no time ;) 01:59 kahrl I thought moretrees was mostly L-system stuff? not complex nodeboxes? 01:59 kahrl or how does it hit the limit? 01:59 RealBadAngel huge amount of leaves 02:00 kahrl ok true, that's a lot of allfaces nodes 02:14 RealBadAngel https://github.com/minetest/minetest/pull/680 02:14 RealBadAngel i need a coffee 02:15 RealBadAngel thx to it i will be able to pull NDT_GLASSLIKE_FRAMED tommorow, need just to clean it and write some docs 02:16 RealBadAngel not the coffee ofc, but the fix above ;) 02:17 hmmmm why not commit it? 02:18 RealBadAngel you know why ;) 02:18 RealBadAngel you do it 02:18 hmmmm no, why? 02:18 hmmmm oh 02:18 hmmmm oh come on man, learn how2use git 02:18 hmmmm i'll guide you through it if you'd like 02:18 RealBadAngel i playin with branches on technic body 02:19 RealBadAngel *im 02:19 RealBadAngel had lately to remove whole tree and build it from scratch ;) 02:19 hmmmm alright 02:20 RealBadAngel when i will be sure i wont screw something i will let you know :) 02:21 hmmmm even if you do screw it up somehow, any of us can fix it by simply force-pushing our current tree 02:21 RealBadAngel we can try tommorow with glasslike_framed 02:23 RealBadAngel btw, http://pastebin.com/vthR9T7B 02:23 RealBadAngel this is the code 02:24 hmmmm now that is scary looking 02:24 RealBadAngel hehe why? 02:24 hmmmm just look at it 02:25 hmmmm oh 02:26 hmmmm by the way, we put the opening and closing braces on the same level of indentation 02:26 RealBadAngel i havent cleaned it yet 02:26 hmmmm so like, how do you figure out all those constants? do you just sit there and figure them out one by one? 02:26 hmmmm it's nuts 02:27 RealBadAngel you mean triplets? 02:27 hmmmm that and the aabb3fs 02:27 RealBadAngel not really, nodeboxes are defined with a program 02:28 RealBadAngel i just replaced values with variable (i used this model many times already) 02:28 hmmmm ah 02:28 RealBadAngel to make it scalable 02:28 RealBadAngel and triplets are selfexplainin 02:29 RealBadAngel you look at the g26dirs, look at the direction 02:29 RealBadAngel and put there rule nr 02:30 RealBadAngel so its really easy to define which nodes you want to check 02:32 RealBadAngel thx to im not checkin unwanted nodes in 3x3x3 box 02:32 RealBadAngel so just 18 instead of all 26 02:36 hmmmm oh shoot 02:36 hmmmm i hate it when you're right 02:37 hmmmm you were right about the on-draw tile colorizing being tough to do 02:37 hmmmm i just realized that finalColorBlend works on verticies, not on the actual tile 02:38 RealBadAngel node stored in the world shall carry just two more tables to do all the fancy stuff 02:38 RealBadAngel nodeboxes and tiles 02:38 RealBadAngel ofc only if modified 02:39 RealBadAngel and then nodeboxes animation, texture changin, whatever will be child's play 02:39 hmmmm ....:( 02:40 hmmmm okay, forget about all the shader crap, i don't need it anymore 02:40 hmmmm the only solution here is to really just generate all those different textures 02:40 hmmmm so this would reduce the number of nodes needing to be defined, but won't help the number of textures at all 02:40 RealBadAngel ALSO important side effect we cut nodes count by hundreds 02:41 RealBadAngel if not thousands like on VanessaE's server 02:41 hmmmm the biggest benefit here would've been cutting the number of textures 02:41 hmmmm it's still very attractive though 02:41 RealBadAngel wires - 1 node instead of 64 02:42 RealBadAngel same apply to mesecons 02:42 hmmmm huh 02:42 hmmmm hold on a minute 02:42 RealBadAngel pipes, frames 02:42 hmmmm if you combine some other param2 with this, you'll have less than 64 colors 02:42 RealBadAngel all stairsplus nodes 02:42 hmmmm facedir takes up 5 bits 02:42 hmmmm which leaves only 3 for color 02:43 hmmmm so how many different colors of stairsplus are there? 02:43 RealBadAngel colors? 02:43 hmmmm yeah 02:43 RealBadAngel stairsplus is about nodeboxes, not different colors 02:44 hmmmm then how would this help stairsplus nodes 02:44 RealBadAngel simply. if you can define on the fly a nodebox 02:44 RealBadAngel and insert it into world 02:45 hmmmm well that's not what i was planning at all 02:45 RealBadAngel then why predefine dozens of them for each wanted material? 02:45 RealBadAngel but this is connected 02:45 hmmmm right 02:45 hmmmm the same concept can be applied 02:45 RealBadAngel because same applies to textures 02:45 RealBadAngel so no more 2 furnaces 02:45 RealBadAngel just one and change the texture just 02:46 hmmmm but let's see 02:46 hmmmm erm 02:46 hmmmm so you need 8 or less types of stairs for each material? 02:47 hmmmm corner in, corner out, regular stair, half slab, that's 4 different shapes of stairs 02:49 RealBadAngel there are more pieces 02:49 RealBadAngel microblocks, panels, etc 02:49 hmmmm oh yeah but a microblock is different and it's used in recipes iirc 02:50 hmmmm for obvious reasons, you won't be able to specify a certain param2 for craft recipes, that's getting ridiculous 02:50 RealBadAngel no need to 02:51 RealBadAngel all modders need is an ability to modify nodeboxes and tiles on the fly 02:51 hmmmm mm 02:51 RealBadAngel give that to them and you will see miracles in a few weeks 02:52 hmmmm would you like to do this? 02:52 hmmmm or should i 02:52 RealBadAngel by now i dont know where to start 02:53 RealBadAngel im not familiar with how the nodes are stored 02:53 hmmmm well gosh, i know where, scriptapi_content.cpp 02:53 hmmmm 8) 02:53 RealBadAngel hehehe 02:53 RealBadAngel lemme finish mesh drawtype and you go for it 02:53 hmmmm alright 02:54 hmmmm let's see what we're going to have to do 02:54 RealBadAngel imho node shall have kinda flag "modified" and then read tables not from definition but from stored node 02:55 hmmmm first we'd have to wrap all facedir operations in (x & 0x1F) 02:55 hmmmm or is that already done 02:55 RealBadAngel ive put such and somwhere 02:56 hmmmm a lot of caution would need to be put into making sure that facedir only modifies the bits that it's allowed 02:57 RealBadAngel i will check it when i got back from work today 02:57 hmmmm k 02:57 RealBadAngel now im leaving to work, just 5 minutes left 02:57 hmmmm later 02:57 RealBadAngel next week i will have 5 days in a row free for coding 03:02 kaeza hmmmm, can you merge this one? https://github.com/kaeza/minetest/commit/ff0578d35992f4b3b28533fdf8c9c60a7acf423d 03:02 kaeza and sorry about that 03:16 hmmmm ehehe 03:16 hmmmm that's a pretty huge bug 03:18 kaeza well... no one is using the HUD thingy yet 03:18 kaeza (besides me) 03:19 hmmmm did you have a pull request for that? 03:19 kaeza nope 03:20 hmmmm it's great that others are further developing the HUD 03:20 kaeza I pushed it to the same branch, but the pull rq was already closed, so I thought it would be a waste to open another for a smallish change 03:20 kaeza ah thanks 03:20 hmmmm i felt that i would probably be the only one to add/modify it 03:21 hmmmm but i guess that's not so 03:21 kaeza I'd like to see more feedback from modders to see what more is needed 03:21 hmmmm that's what the forum is for.. they just need to start using it more 03:21 kaeza but nobody wants to play with HUDs :( 03:22 hmmmm i thought people would go crazy over huds 03:22 kaeza me too, that feature has been requested time and time again 03:24 kaeza I see it is now possible to use texture alpha. This will be great for some stuff 03:25 hmmmm it's not perfect. 03:25 hmmmm see the wiki topic on minetest.register_item 03:25 kahrl I have played a bit with huds and have one lua_api.txt suggestion 03:25 kahrl make it clearer that 'text' is where you put the texture name for image hud elements 03:27 kaeza it is 03:28 kahrl oh, I somehow missed that 03:28 kaeza https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L433 03:28 kahrl I only looked at the section at the end 03:28 kaeza err...wrong link 03:29 kaeza well, it's kinda like reusing parameters 03:29 kaeza for example, 'number' is used as statbar value, but as text color 03:30 hmmmm just being efficient 03:30 hmmmm it's better than having 1000 different parameter names 03:30 kahrl yeah it's fine. I'm just being derpy 03:33 kahrl I guess that happened because I typed /hud in less and that is case sensitive 03:34 hmmmm someone should write a manpage for minetest 03:36 kahrl "BUGS For this feature, you need to install the insects(6) mod which depends on mobf(6)." 03:37 kaeza hmmmm, isn't there one already? 03:37 kaeza doc/minetest.6 03:38 hmmmm hrm? dunno 03:38 hmmmm it's not installed for me 03:39 kaeza it only contains command line usage though 03:41 kaeza and, erhm... I don't think it's very up to date... perhaps from the 0.3.x days 03:43 kahrl there's some 0.4 stuff like gameid in there 03:46 hmmmm has anyone played terasology or blockscape? 03:47 hmmmm if so, can you tell me if there is a height limit? 04:06 hmmmm a 04:07 hmmmm this thread is very insightful http://forum.movingblocks.net/threads/height-limit.576/page-2 04:07 hmmmm indeed they use shadow masks 04:15 hmmmm erm no what am i saying 04:15 hmmmm _because_ terasology has a height limit of 256, they can use hardware lighting 04:20 ShadowNinja hmm, not sure how this works but can't you just assume that non-loaded blocks are transparent? 04:22 hmmmm of course not, we'd have light shining through caves 04:22 hmmmm all this was discussed 04:23 ShadowNinja If you were in a cave then the ceiling would most likely be loaded 04:25 hmmmm hrm. 04:26 hmmmm alright, from what i've observed, terasology has a small height limit and all of the vertical space is loaded at the same time, allowing for the use of accurate hardware lighting; but they don't use hardware lighting, they store light values for some reason even though they don't need to. it seems they are trying to move to our kind of format 04:27 hmmmm blockscape on the other hand, has no height limit at all and stores no light value 04:27 ShadowNinja Wait, it is infinite? or just crazy high? 04:28 hmmmm well, very high 04:28 hmmmm i wouldn't say it's very relevant because if it's "high enough" then they can't have the entire thing loaded at once which means they can't do the obvious thing for lighting 04:30 ShadowNinja Yes, I was just curious 04:36 kahrl how does blockscape do indirect light without storing light values? 04:39 kahrl hm, looking at some videos it seems like they don't 04:40 kahrl so shadowed areas get pitch black (+ ambient light) pretty quickly 04:40 hmmmm aaa http://forum.blockscape.com/viewtopic.php?f=10&t=3216&start=20#p13233 04:40 hmmmm what's this 04:40 hmmmm chunk type 10 "is world rotation (for the day/night cycle)" 04:41 hmmmm oh 04:41 hmmmm file chunk 04:42 hmmmm he uses the terminology "chunk" to mean chunk in the file, and "world chunk" to mean a variable-height collection of 32x32 nodes 04:42 hmmmm er 04:43 hmmmm a "world chunk" is made up of a variable number of "block layers", a "block layer" is a 32x32 collection of nodes 04:45 hmmmm so like what, do the people making these blockscape editors just not do lighting at all? 04:45 hmmmm >Heist, well, while you work on graphical stuff, I will tinker with decoding some more, cuz C# 3D stuff is too over complicated. And I wasn't able to find byte buffer in .net framework 04:46 hmmmm C# is hard for them, so I guess I shouldn't expect very good solutions from the forum 04:56 hmmmm it seems to me like they just rely on the world around them loading quick enough that nobody would notice light shining through before the shadow gets loaded 04:59 hmmmm indeed.. http://blockscape.wikia.com/wiki/Bug_List - see the second to last point 05:11 kaeza I don't understand it... blockscape has apparently awesome graphics, but does not have the basic things (which MT had from the beginning)? 07:50 celeron55 <+hmmmm> kinda wonder what the rationale behind making it only update 3 directions is now 07:50 celeron55 it's because mesh updates are painfully slow 07:50 celeron55 it's commonly the limiting factor when transferring blocks from the server 07:51 celeron55 that'll effectively halve the transfer rate in many cases now 8) 08:00 celeron55 (actually, commonly = probably only single player) 08:17 chaiman Hello 08:18 chaiman I want to ask about this: http://forum.minetest.net/viewtopic.php?id=5459 08:18 chaiman The idea is to move death screen to lua 08:19 chaiman So some kind of afterlife would be possible 08:22 chaiman Also, dead and alive should see world differently - same blocks should be rendered differently for those who are dead. 08:23 chaiman Both of this require changes to the engine to be made 08:23 chaiman So, basically, will this be added, if implemented? 08:24 kaeza hmm 08:25 kaeza I'm not very sure about the different rendering 08:26 chaiman By "different rendering" I mean rather "different texture" 08:26 chaiman the problem that can't be set in the realtime 08:27 chaiman But if it would be possible to define 2 sets of textures 08:28 chaiman then engine will check fo is_alive flag (or smth like that) and apply a different texture, which is allready in node definition 08:28 chaiman *for 08:28 kaeza well... that would require some big changes 08:29 kaeza and I doubtif it would be useful for anything else 08:29 chaiman It probably wont 08:29 kaeza but meh, I'm not the one to give the ok or no about that 08:29 chaiman Idea was to bring a new level of exploration 08:31 chaiman In MC you can build, fight, go to nether for resources aand explore there, then there are END and even after the end you may discover potions stuff etc 08:31 celeron55 that sounds quite arbitrary, you probably need to think of it in some more general way if you want to propose something to be put in the engine 08:32 chaiman @celeron55, I don't quite got your message 08:32 celeron55 put in other words, we aren't eager to put things in the engine that are not widely useful 08:33 chaiman That's why I finally came here - to convince that ghosts thing will bring joy and amusement ;) 08:33 chaiman Anyway 08:33 chaiman Suppose all above is done and the code is good 08:34 kaeza indeed they will, but not as an engine feature 08:34 celeron55 moving the death screen to lua sounds like something to consider if there is a way to implement it cleanly and robustly 08:35 celeron55 i can't say much more than that nothing will be added that is not useful for anything else than your ghost thing 08:36 chaiman It's not mine 08:36 celeron55 you need to propose general things that many will find use for that also work well for it too 08:36 chaiman So, even if it wiil be ready to merge you won't add this? 08:36 chaiman *will 08:37 celeron55 as you described it, probably not, unless it's very simple and affects basically nothing 08:38 chaiman I got your point. Thanks for your time. Bye. 08:38 kaeza being able to disable the death screen would be useful perhaps, but the different rendering not so much 08:38 celeron55 i know that making games with personality is easier if you can freely mess around with the engine, but it won't work for us in the long run 08:38 kaeza erhm 08:39 kaeza whatever 08:39 celeron55 it works for a do-once release 08:39 kahrl moving the death screen to lua seems easy enough 08:39 kaeza perhaps implemented as a formspec? 08:39 kahrl remove the SendDeathscreen calls from Server; add a scriptapi function that calls SendDeathscreen; implement the proper lua callbacks 08:40 kahrl or remove the deathscreen entirely and find some way to do it with formspec, yes 08:40 celeron55 ...plus backwards compatibility 08:40 celeron55 (if possible) 08:40 kahrl it'll be a protocol change, I suppose 08:41 celeron55 at least a new client has to support an old server; maybe not for a new server - old client combination 08:41 kaeza which reminds me, would it be useful to add methods to the hud to be able to relocate the healthbar and/or hotbar? 08:41 celeron55 (because of easiness of implementation) 08:41 kahrl new server - old client would work if implemented via formspec 08:42 kahrl unless the client is really old 08:43 celeron55 kaeza: no; maybe a simple call to hide them 08:43 kahrl and if lua just calls SendDeathscreen there aren't any server<->client compatibility problems 08:44 kaeza celeron55, we discussed this ("discussed") and adding health/hot bar completely in Lua would have problems under heavy lag 08:45 kaeza +with hmmmm 08:45 celeron55 kaeza: we really care only about compatibility between git head and the existing stable release, but if necessary new server/old client compatibility can be dropped 08:45 celeron55 ... 08:45 celeron55 kahrl* 08:46 celeron55 kaeza: well, in that case you'd have the screen full of other lag-affected bars anyway so it wouldn't really matter 08:46 kaeza okay... 08:47 kaeza good point 08:49 kaeza so I guess I need to add a new command to the protocol? 08:50 kaeza actually, this could be done with a special parameter to hud_remove() 08:50 kahrl why a special parameter if you want to move the default hud to lua? 08:51 kaeza because there won't be any move to Lua 08:51 celeron55 something like hud_remove_builtin() would probably be cleanest 08:51 kaeza I'll just disable the default HUD, and let a mod in default handle it 08:51 celeron55 some magic ids or something is kind of hacky 08:52 kaeza I mean about the protocol... I don't want to mess with that stuff if at all possible 08:52 celeron55 or actually... hud_enable_builtin(true/false) 08:52 celeron55 you can add a new message for that 08:53 kaeza okay 08:53 celeron55 you'd kind of have to modify the protocol anyway 08:54 celeron55 hell, someon has messed up the command ids once again 08:54 celeron55 so let's count in hex 08:54 celeron55 0x48, 0x49, 0x50? 08:54 celeron55 NO! this is shit 08:55 kaeza heh 08:56 celeron55 just move all of them to correct place and don't modify any protocol versions 08:57 celeron55 building on broken stuff has to stop 08:59 kaeza won't this break compat? 08:59 kaeza err... nvm 08:59 celeron55 yes it will 09:00 celeron55 but the hud implementation is still clearly only taking it's initial shape so it's prefectly fine 09:00 kaeza ok, so renumbering messages then 09:00 celeron55 so the existing ones should be 0x49, 0x4a and 0x4b, and yours will be 0x4c 09:02 kaeza should I make it so a single call enables/disables everything? 09:02 celeron55 hmm... what are the things subject to this 09:02 celeron55 the hotbar and the health bar? 09:03 kaeza yes 09:03 celeron55 i wonder if somebody would want to mess around with wielded item rendering 09:03 kaeza hmm 09:04 kahrl maybe someone wants to move it to the center for doomlike rendering 09:04 celeron55 this is trickier than it seemed 09:04 kaeza maybe being able to disable individual components would be better 09:04 celeron55 kaeza: i 09:04 celeron55 ... 09:04 celeron55 kahrl: well, i'm thinking mostly if it should be disableable, on it's own 09:04 kaeza ... 09:05 celeron55 so maybe we need some kind of a thing to disable and enable some named hud parts 09:06 kaeza right 09:06 kaeza maybe player:hud_builtin_enable("hotbar", true) 09:06 kaeza (or some variation) 09:08 celeron55 as for the api, i think that's fine 09:08 celeron55 the protocol needs a small bit of thought 09:08 kaeza that's what I meant actually 09:08 kaeza maybe this can be done in a single messane 09:09 kaeza passing first the named item, and then the flag 09:09 kaeza message* 09:09 celeron55 well i guess it'll just convert the "hotbar" and "healthbar" and "wielditem" or something like that to some predefined ids 09:09 celeron55 and put the id and a boolean in a message 09:09 kaeza there are util functions in scriptapi to convert strings to enums 09:10 kaeza this is what hud_change() uses 09:10 kaeza it converts "number" to HUD_STAT_NUMBER, and sends this to the client 09:11 kaeza I can do the same 09:11 celeron55 yeah, it's fine 09:11 kaeza one little question... what's the preferred method to send a boolean? a single char or an u32? 09:11 celeron55 u8 09:12 kaeza ah 09:12 celeron55 (=unsigned char) 09:12 kaeza yep, that's what I meant :P 09:13 celeron55 one thing i'm a bit worried about here is that there isn't really anything to facilitate any kind of mod interoperability here, but i guess someone will invent something in lua for that (just like inventory plus or so) 09:14 kaeza I've been tinkering with that actually 09:14 kaeza (Lua of course) 09:16 kaeza so, the message would be: u16 command, u8 what, u8 flag 10:07 kaeza can I add an option to disable default crosshair while I'm at it? 10:07 kaeza (I mean, as argumnt to hud_builtin_enable() ) 10:21 celeron55 guess so 10:28 kaeza ditto for the wield item 10:28 kaeza (in case someone wishes to implement wielditems as overlay images or whatnot) 10:31 celeron55 also, don't expect it to get wide usage very fast 10:31 celeron55 many features i've been implementing or overlooked the implementation of have gained use quite slowly 10:31 kaeza I know... RBA's background just got started to be used 10:32 celeron55 (overlook is a stupid word though, that sentence could mean two almost opposite things...) 10:32 kaeza but at least the stuff is there for the daring modder that wants to try something new 10:32 celeron55 yes; somebody always needs to set up the framework 10:33 celeron55 there's always a delay in the momentum that comes from adding some base feature 10:33 celeron55 people slowly realize what new things they can do 10:44 Exio kaeza: uhm, what? 10:44 Exio when you are poiting at something? 10:45 kaeza Exio, read scrollback 10:46 Exio kaeza: i don't get it - that is why i ask :P 10:46 Exio you mean a function for disabling it from lua, like you can remove and add other hud items? 10:47 kaeza that 10:47 kaeza err...no 10:47 PilzAdam this new "use_texture_alpha" is unusable; with shaders enabled it doesnt work at all and without shaders its extremly glitchy above water 10:47 kaeza Exio, you'll see soon 10:48 Calinou no transparency sorting (yet), PilzAdam, that's why it's glitchy, probably 10:48 VanessaE Calinou: I almost have an update for you for stairsplus, but I need your input on it 10:48 Calinou while we're talking about rendering stuff, it'd be nice if we have a paramtype "facedir_fixed_texture", like facedir but the texture never rotates 10:49 VanessaE ->#minetest 10:49 Calinou ah 10:49 VanessaE and I was *JUST* about to suggest that 10:49 Calinou ninja'd :P 11:00 kaeza celeron55, I will need to #include "hud.h" from player.cpp; any objections? 11:05 kaeza I can move stuff directly to player.h, but would seem out of place there 11:05 PilzAdam what stuff? 11:05 kaeza the new defines I added 11:06 PilzAdam just dont include headers just for class definitions, use "class foo;" instead 11:06 PilzAdam (in headers, that is) 11:06 kaeza nope, a bunch of #defines 11:06 celeron55 why do you need defines there 11:07 kaeza I don't want to add tons of hud_hotbar_enabled members to Player 11:07 celeron55 so what do you add? 11:07 kaeza a simple bitfield 11:08 celeron55 so you need the #defines for initializing the bitfield by default with the right bits on? 11:08 kaeza yep 11:08 celeron55 i guess just put the defines there then; not a big deal as it's the actual storage place of the bits anyway 11:08 kaeza ok 11:09 celeron55 or umm... 11:09 celeron55 do you then need to include player.h in hud.h? 11:09 kaeza I can just stick a 0xFF in there 8) 11:09 celeron55 if that is the case, then put them rather in hud.h and include it in player.cpp 11:10 kaeza ehm... I'll commit and show you 11:12 celeron55 but the thing here is that hud.h is a huge header because of the headers that are included in there; that means you will never want to include hud.h in any other header 11:13 kaeza https://github.com/kaeza/minetest/commit/ebdf0f5e67cfc97824b0237113513fd0fdc2eb03 11:14 kaeza wrong link 11:14 kaeza https://github.com/kaeza/minetest/commit/ebdf0f5e67cfc97824b0237113513fd0fdc2eb03#L5R34 11:15 celeron55 well that's what you already described 11:15 kaeza let's see... they are used in player.cpp and hud.cpp 11:17 celeron55 just let it be like that 11:17 celeron55 it's not the worst way to do it 11:17 celeron55 and there's no obvious better way 11:18 celeron55 (well, adding a small hudtypes.h header would be the trivial lightweight solution) 11:18 celeron55 (but that's kind of file count bloat then) 11:19 kaeza would be the a good option 11:20 kaeza for now lemme test if this actually works, and I'll cocentrate on the details later 11:20 celeron55 if it works, make a pull request and concentrate on using the end result :P 11:21 celeron55 (after adding reference to doc/lua_api.txt) 11:23 PilzAdam celeron55, file bloat? this is file bloat: https://github.com/minetest/minetest/blob/master/src/content_cao.h 11:23 celeron55 PilzAdam: lol 8) 12:09 kaeza f*ck yea 12:10 Calinou lol yea 12:10 Calinou should be merged in another file, because there is almost nothing in that file :P 12:11 kaeza err... almost anyway 12:11 kaeza I cannot disable the crosshair :P 12:11 VanessaE re: file bloat, heh 12:11 kaeza lol this looks like minetest-delta without wielditem 12:17 Calinou why? 12:17 Calinou minetest-delta's hud was the same as it is currently, pretty much 12:20 kaeza erhm... I meant 0.2.x 12:20 kaeza anyway 12:20 kaeza https://dl.dropboxusercontent.com/u/100008207/screenshot_1006336820.jpg :D 12:21 kaeza Calinou, https://dl.dropboxusercontent.com/u/100008207/screenshot_1006463337.jpg 12:22 kaeza I need to write docs and this thing is done 12:24 Calinou haha, timestamp 12:25 Calinou you can color text now? 12:25 Calinou or is this lua-hud only? 12:25 Calinou (/me would like to see color codes, like ^f0f8 for semi-transparent pink) 12:26 kaeza Calinou, yep 12:26 kaeza part of my misc stuff 12:26 kaeza Calinou, https://github.com/kaeza/minetest-kaeza_misc 12:26 kaeza see mods/testclock 12:27 kaeza err... testclock/ 12:35 kaeza aaaaaand pull requested: https://github.com/minetest/minetest/pull/681 12:35 kaeza celeron55, ^ 12:45 Calinou +1 12:45 Calinou useful: disable health bar when in god mode 12:45 Calinou :P 12:46 kaeza It's possible now ;) 12:47 kaeza also, who inv in top-left corner 12:47 kaeza (somehow) 12:49 kaeza s/who/draw/ 12:50 kaeza my hands are derping lately 13:58 RealBadAngel more useful: make HUD minimap 13:59 RealBadAngel hi all 14:08 kaeza hey RBA 14:08 kaeza how's it goin'? 14:14 Tracerneo RealBadAngel: yeah, it would be cool. How about map item, that will add map in HUD (and other items, like compass, changing HUD)? 14:28 celeron55 kaeza: it's in now (edited lua_api.txt a bit) 14:30 kaeza celeron55, ok, thanks ^_^ 14:35 PilzAdam any objections to change wool crafting from color + white wool to colort + group:wool? 14:36 PilzAdam -t 14:37 PilzAdam and it should also be not possible for every player to destroy other player's locked chests if they are emtpy 14:42 PilzAdam the output should be changed to one colored wool then, instead of 16 15:18 RealBadAngel 16 ->1 i agree, but dont touch players properties 15:19 RealBadAngel this way one will be able to destroy empty chest, machines etc 15:19 RealBadAngel and some chest are EXPENSIVE 15:19 PilzAdam currently everyone can dig empty locked chests 15:20 PilzAdam I want to change it so that only the owner can 15:20 RealBadAngel maybe wooden 15:20 RealBadAngel ah so i got you opposite. sure do that 15:21 RealBadAngel owned and end of story 15:21 Jordach perhaps steel chests can only be dug by the owner 15:21 Jordach even when empty 15:22 PilzAdam Jordach, we dont have steel chests 15:22 RealBadAngel maybe you :P ;) 15:22 PilzAdam done 15:26 RealBadAngel PilzAdam, for glasslike_framed i got all the code almost ready, bugs are dead 15:26 RealBadAngel i would like to discuss with you (not now, maybe later today) crafting recipes for framed glass 15:28 RealBadAngel please think about for example wooden and iron framed glass 15:28 RealBadAngel or maybe you will pop up with another ideas 15:29 RealBadAngel fyi: frame can have different textures, faces (glass) others 15:30 RealBadAngel i will be back in 4-5hrs from now on 15:30 PilzAdam *start timer* 15:30 RealBadAngel and you start thinkin ;) 15:31 RealBadAngel cya later aligator :) 18:03 sfan5 is there and easy way to clear somebody' inventory in lua? 18:05 VanessaE sfan5: http://pastebin.com/cYzT0xmm 18:05 VanessaE (traxie21 wrote that) 18:05 sfan5 I was just going to ask if :set_list("main", {}) was going to work 19:24 sapier1 did anyone try if my fixes for gxx 4.6 build do work? travis build doesn't seam to start again for additional commits? 21:37 hmmmm eh 21:38 hmmmm grr 21:40 hmmmm now i have to make another commit to fix those commits 22:00 jin_xi what is DecorationDef going to do? 22:06 RealBadAngel define plants, trees, ores that are biome specific 22:10 jin_xi oh ok, so not new stuff but a new way to define biomes 22:17 RealBadAngel exactly 23:28 Exio would decorationdef work for spawning things inside dungeons? 23:31 RealBadAngel Exio you should ask hmmmm about it, but propably yeah 23:33 Exio I didn't want to highlight him :P 23:34 ShadowNinja Exio: I think I saw that on the TODO list 23:40 Exio Add Lua callbacks for DungeonGen room placement - this comes with DecorationDef, I reckon 23:40 Exio k, thanks