Time Nick Message 00:05 sapier using a reinterpret cast against adding a transition struct and quite some copy code ... I think I can live with reinterpret in one location 00:32 Sokomine are there any more changes coming today? (just want to know if it's time to undo that one unwanted "bugfix" and compile again :-)) 00:36 sapier sorry got disconnected 00:37 sapier which bugfix sokomine? 00:38 sapier well sokomine by now you're the only one (i know) who has really a problem with it. I suggest at least asking in forum and starting a poll. 00:50 Sokomine hm. that might be an option, yes. else i'll have to change it every time something is changed with game.cpp :-/ 00:51 sapier well you could write a fix adding a setting ... but I don't know how much work it is to stop player from building to other player/mobs but not to himself 02:10 VanessaE anyone awake here? 02:11 * VanessaE pokes ShadowNinja 05:50 hmmmm hrm sapier you still around? 05:50 VanessaE long gone, hmmmm 05:50 VanessaE [02-07 20:25] <-- sapier (~sapier@p5498D3D3.dip0.t-ipconnect.de) has left #minetest-dev 05:50 hmmmm ah 05:51 hmmmm i just saw that yaeh 05:51 hmmmm i need to strap down and get some substantial work done on minetest 05:51 hmmmm so much stuff to do 05:51 hmmmm i don't ever do any of it though 05:51 VanessaE want a simple one to look at? :) 05:51 hmmmm no 05:51 VanessaE haha 05:51 hmmmm i have my own things to look at 05:52 hmmmm gonna fix up the flag string BS first 05:52 hmmmm then i'm gonna do the ServerMap::emergeBlock() callback 05:52 hmmmm then i'm gonna fix up findSpawnPos 05:52 VanessaE well I think I'm gonna crash 05:53 hmmmm but before i do any of that I'd like to first fix up that horrible NULL dereference that somebody retardedly put in there 05:54 hmmmm then i have to look into celeron's custom emergequeue_limit_* parameter settings for a quick fix until I can get a real solution to looking up which blocks exist in the db already 05:54 hmmmm then i need to remove the noiseparam reading from the config file and do that in Lua instead 05:55 hmmmm then I need to finally commit my biome fixup 05:56 Guest98666 It sounds like you have quite a lot on your plate. 05:57 hmmmm i still didn't get around to the *real* unfinished work like finishing mapgen v7 and porting mapgen v5 06:10 hmmmm interesting, AsyncWorkerThread_0 gives me a failed to parse json data blah blah blah 06:10 hmmmm and then it spits out an incredibly huge amount of json 06:10 Guest98666 That's helpful. 06:16 hmmmm hmm, i don't notice any significant difference with celeron's custom block sending parameters 06:16 hmmmm in fact what i have noticed is that it gets stuck every once in a while 06:17 hmmmm but minetest as-is could benefit from more aggressive block emerge/send settings 12:15 sapier ShadowNinja: some of your recent changes managed to completely hide lua errors occuring "on_activate" 12:16 Megaf sapier, I just pulled the latest things to get you fix 12:16 Megaf now I get this error 12:16 Megaf 10:15:29: ACTION[main]: Server for gameid="minetest" listening on 67.215.65.132:30002. 12:16 sapier ok completely isn't quite right it will cause very very strange effects 12:16 Megaf 10:15:30: ERROR[main]: ERROR: An unhandled exception occurred: Failed to bind socket (port already in use?) 12:16 Megaf first, the correct IP would be 0.0.0.0 12:16 Megaf as it was before 12:16 sapier yes did you set bind_addr? 12:17 Megaf and the port is not in use, I just changed it 12:17 Megaf hm 12:17 Megaf hm 12:17 Megaf let me check 12:19 Megaf sapier, my minetest.conf doest have that thing 12:19 sapier that's strange 12:19 Megaf well, working now 12:20 Megaf sapier, git pull wont change minetest.conf, and thats good 12:20 Megaf it will just update minetest.conf.example 12:20 sapier but not a solution where did it get that address from 12:20 Megaf no idea 12:21 sapier I've heared about that issue now and then but can't reproduce it. If you manage to find out how this happens I'd be very thankfull. 12:33 sapier well ShadowNinja to make it worse it doesn't hide all errors. Seems to be a quite special case 14:09 sapier https://github.com/minetest/minetest/pull/1142 should ensure noone uses broken luajit with minetest 14:11 PilzAdam sapier, https://github.com/minetest/minetest/pull/1142/files#diff-af3b638bc2a3e6c650974192a53c7291R166 14:11 PilzAdam its menu_lua_api.txt, not lmenu_lua_api.txt 14:11 sapier oops 14:12 sapier thanks 14:12 PilzAdam an option to disable luajit is nice 14:13 sapier yes I needed it to be able to use lua debuger ... doesn't work with luajit 14:14 sapier btw on asigning this one to our buildsystem maintainer I realized this is xyz who recently quit supporting minetest :-( 14:14 PilzAdam did he? 14:15 sapier yes he revoked his membership of minetest repository 14:15 PilzAdam well, there is still the good old "2 core devs have to agree" rule 14:17 sapier ok do you agree to the fixed version? 14:17 PilzAdam sapier, s/luajit/LuaJIT/ in lnies 249 & 252 14:18 sapier ok something else? 14:18 PilzAdam I agree to the idea behind it, but Im not familiar with cmake 14:18 PilzAdam so I cant check if the code is right 14:19 sapier ok so lets wait a day or two maybe someone voloteers to test it 14:20 sapier of course I did test it too, but as always different environments may show different issues. I haven't tested windows for example 14:23 PilzAdam IIRC sfan5's win builds have LuaJIT, he could test it 14:24 sfan5 I thought yours have LuaJIT too 14:25 PilzAdam I havent used my scripts for some time now 14:25 PilzAdam there might be other problems with them already 14:26 sapier https://github.com/minetest/minetest/issues/1082 what do you think about patch 1 and 3? 14:26 sapier I'm not sure about the custom thing but I guess switching to bitset and list will improve performance 14:29 PilzAdam I guess we should think about a release 14:29 PilzAdam sapier's network fixes lead to a noticeable faster experience 14:30 sapier there's the one 0.4.9 issue left. VanessaE hasn't approved it by now. And noone else seems to test it 14:30 PilzAdam do you mean #1132 ? 14:30 ShadowBot https://github.com/minetest/minetest/issues/1132 -- 0.4.9 (sometimes) failes to connect to old as well as latest server due to missing TOSERVER_RECEIVED_MEDIA 14:32 sapier yes and #1139 14:32 ShadowBot https://github.com/minetest/minetest/issues/1139 -- Workaround for missing initialization of 0.4.9 by sapier 14:32 sapier last one is fix for 1132 14:33 PilzAdam havent we already decided to use alternative 1)? 14:33 sapier yes and 1139 is a patch doing this but it's not yet proven to work correct 14:34 PilzAdam ok, so we have to wait for that one 14:34 PilzAdam anything else that is important before a release? 14:36 PilzAdam (the milestone isnt really useful, since it seems that are more or less random issues there) 14:38 nore PilzAdam, I guess this should be fixed: https://github.com/minetest/minetest/issues/944 14:40 sapier https://github.com/minetest/minetest/pull/973 ... not important as of features but maybe from legal perspective 14:42 sapier https://github.com/minetest/minetest/pull/954 14:43 sapier https://github.com/minetest/minetest/pull/670 14:43 PilzAdam nore, the idea to have a special "slot" for stacks that are hold by the cursor comes up once in a while, but there are reasons why it wasnt done yet 14:43 nore the reasons were something about saving the player IIRC 14:44 PilzAdam also the Lua callbacks, IIRC 14:44 PilzAdam the on_take and on_place wouldnt be at the same time anymore 14:44 PilzAdam (or something like this) 14:45 sapier I guess that one isn't trivial to fix so nothing to rush in before a upcoming release ... assuming we decided to do a release ... did we? 14:45 PilzAdam what Sokomine suggests sounds like a better idea: only allow moving when the target slot is empty, or can hold the whole stack 14:46 PilzAdam nore, what makes it important to be fixed before next release? 14:46 nore because it should have been fixed far earlier... ;) 14:47 nore (or else, it will become something like the entity duplication bug that nobody will try to fix for a long time) 14:47 sapier well if there's noone willing to do it it wont be fixed 14:50 xyz kahrl: can you explain why do you call endScene here: https://github.com/minetest/minetest/blob/master/src/tile.cpp#L886? it seems to cause (little) troubles on android, when endScene() is called everything is redrawn on screen so user sees item texture in lower left corner, a moment after it's replaced with the loading screen 14:50 xyz so it kinda blinks 14:53 PilzAdam nore, also, do you know which machines remove the items in their output slots when they "update"? since the default furnace doesnt do that its not a problem there 14:53 nore PilzAdam, the circular saw from moreblocks does that 14:55 PilzAdam hmmmm, do you have anything to do that is important before a release? 14:55 hmmmm what do you mean 14:56 PilzAdam IMO we should release in the near future 14:56 hmmmm eh 14:56 hmmmm how about the end of the month 14:56 hmmmm nothing this soon, we all see what forced releases do 14:58 PilzAdam the problem of the last one was that there wasnt a long enough feature freeze IIRC 14:58 hmmmm nonsense, it ended up being a very long feature freeze 14:59 hmmmm stuff just sat around for an entire week after i wanted to originally release it 14:59 hmmmm anyway yes, there are a lot of things i'd like to do before any new sort of version 14:59 PilzAdam I havent even noticed that we wanted to realease last time 15:00 PilzAdam it was more a communication problem 15:00 hmmmm it's because we needed to fix a serious deficiency with 0.4.8 quickly and also to coincide with the holidays 15:01 hmmmm like i was saying with sapier, the REAL problem is that there's no way to give the users of specific versions patches 15:01 hmmmm so if we were able to patch 0.4.8 and push an update for that, maybe a notifier or whatever "would you like to update" then everything would work out so much better 15:01 PilzAdam the reason why Id like to release in the near future is that sapier's connection fixes lead to a noticeable faster experience 15:02 hmmmm oh 15:02 hmmmm by the way 15:02 hmmmm about version numbers, i feel that when 0.5.0 rolls around we should make it 5.0.0 instead and actually use minor/patch numbers for minor and patch versions 15:02 hmmmm this isn't unprecedented, SunOS did it before 15:03 PilzAdam the number itself doesnt matter 15:12 sapier and for what I think next version should be 0.4.10 ... but as PilzAdam said number doesn't really matter especially as we don't really use them anywhere 15:13 hmmmm well why not, we should use them anymore 15:15 sapier I don't have a problem with using version number but I don't have a problem with not using it too 15:16 sapier I'm gonna finish my detailed client info patch to support reading client version too ... this way we would have chance to notify player about outdated version 16:33 Megaf folks, is there a way to ban an IP range? 16:33 Megaf Id like to ban or block all Brazilians 16:33 sapier no 16:34 PilzAdam Megaf, Peacock has a mod for that 16:34 xyz use iptables 16:34 sapier and be sure I will not support adding things with that much collateral damage to core features ;-) 16:35 sapier and xyz is right too, for blocks beeing that static things like iptables are way more suited 16:39 Megaf xyz, that may be a good idea 16:41 hmmmm haha 16:41 hmmmm so I guess the whole BR thing is true. hue hue hue 16:42 sapier what's the br thing? 16:42 hmmmm it was a meme that BRs (brazillians) join game servers in gangs and shit everything up 16:42 Megaf They are irritating, griefer, boring 16:42 hmmmm but i guess like all stereotypes it's based in truth 16:43 Megaf hmmmm, and I am a Brazilian myself, unfortunately 16:43 hmmmm wow :( 16:43 xyz oh 16:43 Megaf and I absolutely hate this shit of country 16:43 xyz then it'll be fun when you ban all BR ip ranges with iptables and drop out of ssh connection 16:44 Megaf so please, would you let me move and live with you in another country? 16:44 Megaf :P 16:44 xyz sure 16:44 xyz move to russia 16:44 sapier well just be sure not to have a bad opinion about putin ;-) 16:45 Megaf legally, my grandfather is Russian 16:45 xyz putin is good 16:45 Megaf I mean, my great-grandfather 16:45 xyz http://russiannerd.files.wordpress.com/2012/07/2054-145008-d618b27bdae29c37836a9c24d58de821.jpg 16:46 xyz (should stop the offtopic here) 17:12 Megaf and there should be something to block everyone whos not playing the actual minetest 17:16 us_0gb What? Block us from the IRC channel? That's not nice, Megaf. Don't you like us any more? 17:17 Megaf us_0gb, nah, from minetest servers 17:17 Megaf so people need to use minetest client 17:17 us_0gb Oh, okay. 17:17 us_0gb That could be easily bypassed though. 17:23 xyz nice 17:23 xyz let's do vendor lock-in 17:23 xyz talking about double standards 17:24 us_0gb Vendor lock in won't even work with the free license anyway. People will read the code and find out what the server is looking for. 17:24 VanessaE > freeminer author 17:24 VanessaE > argues against vendor lock-in 17:24 sapier no there never will be a check for minetest, minetest is open source and will be opensource 17:25 VanessaE > irony: dripping. 17:25 us_0gb Or they will just fork, and the server won't know the fork is the not the real deal. 17:25 us_0gb What is the problem with alloing non-Minetest clients, anyway? 17:25 us_0gb *allowing 17:26 * us_0gb is still getting used to this tiny UK keyboard 17:26 * us_0gb 's fingers are too big and the keys aren't where he is used to them 17:27 * us_0gb shutters to think of how hard it would be to use a cell phone keyboard with his fat fingers 17:29 * VanessaE pokes kahrl 17:29 VanessaE you available? we have a problem. 17:31 xyz VanessaE: who are you quoting? 17:31 VanessaE xyz: not "quoting" anyone. 17:32 VanessaE (I'm using it in a different way) 17:32 xyz ahh 17:32 VanessaE in other words, to be perfectly honest, you're th last one who should be bringing up "vendor lock-in". 17:33 VanessaE +e 17:33 xyz why? 17:34 VanessaE because of your proposals in the past with freeminer being apt to become incompatible with Minetest. 17:35 VanessaE vendor lock-in is defined as getting people to use your product, and then making it such that your product isn't compatible with anything else. 17:36 xyz but it's not because i dislike mt or anything, it's because it's not worth it to keep protocol compatible while switching to enet and msgpack 17:36 xyz still the same thing as adding a client check? 17:36 us_0gb Was the goal to create incompatibility, or was that a byproduct of optimisation? There is a difference. 17:36 xyz well, feel free to believe whatever you want 17:37 xyz yes, it'll make the network much faster 17:37 us_0gb It doesn't sound like lock-in to me. 17:37 us_0gb Someone could fork Freeminer and remerge it with Minetest for compatibility. 17:38 sapier guys this is minetest-dev can you please stick back to development of minetest? :-) 17:38 xyz sure ban us 17:38 sapier noone intends to ban anyone xyz 17:39 us_0gb Development. Right. sapier, ShadowNinja asked me to tell you about the fact that my 0.4.9 client isn't sending passwords to servers. He said it might be something that got messed up in Minetest's networking. 17:39 sapier there wont be a vendor lock in core as long as I contribute to minetest, if someone adds it I'm gonna stop working for minetest. I guess lots of other core devs do think same 17:40 us_0gb I would hope so. 17:40 sapier what server version us_0gb 17:41 us_0gb 0.4.8, I think. Is there an incompatibility between 0.4.8 and 0.4.9? 17:41 sapier none I know about but we can't fix any of them 17:42 sapier 0.4.9 stable? 17:42 us_0gb Yes, the stable one in the PPA. 17:42 us_0gb But only the 32 bit client. The 64 bit one has no such issue. 17:43 sapier ok that information is quite relevant. can you verify this happens on latest master too? 17:44 sapier while we can't fix it for 0.4.9 we can fix it for 0.4.10 ... case this will be the version number :-) 17:44 us_0gb Okay, but it will take a bit while I install the build tools. 17:44 us_0gb (I'm on a new machine.) 17:45 sapier ok, I have to go soon. could you write a issue for this? case it isn't fixed yet this is a issue to be fixed 17:46 us_0gb sapier: Okay, will do. 17:50 * hmmmm pulls hair out 17:50 hmmmm how many wrappers do i have around readFlagString exactly?!? 17:50 hmmmm this is insane and i should've designed it right from the beginning 18:07 sapier *g* hmmmm it's never to late to fix a bad decision ;-) 18:07 hmmmm I am also adding some documentation while i'm at it :D 18:07 sapier most time it's just a lot of work 18:07 hmmmm // N.B. if setStruct() is used to write a non-POD aggregate type, 18:07 hmmmm // the behavior is undefined. 18:08 sapier I recently realized marking a client as active on got media message is worth nothing as old clients don't use it consistently ... their behaviour did change from time to time .. noone relized this because it didn't have any effect by now 18:09 hmmmm fantastic 18:09 hmmmm so whose idea was it to change this behavior!?? 18:09 sapier I guess I'll add a new message finaly telling server about client beeing ready 18:10 sapier this is required to fix the issue about players standing at spawn for quite some time till they're really ready 18:10 hmmmm usually there's a client initialization/login sequence for protocols after a few handshakes but the decision to use MEDIARECEIVED as the initialized marker seems arbitrary and it was clearly not designed for this task 18:10 sapier I don't know what this is used at all ;-) server doesn't do anything with this information 18:11 sapier we could also remove it as far as I see now it wouldn't make a difference 18:13 xyz oh I think I added this! 18:13 sapier the finished message has another benefit, I can send it AFTER preloading visuals and put all the nice to know but information e.g. client version in this package 18:14 sapier "non required information" 18:14 hmmmm well that's good for the per-server statistics I guess but the original idea was to send that to some centralized server like serverlist 18:14 xyz I mean, I added TOSERVER_RECEIVED_MEDIA but previously it'd just set definitions_sent to true, now it also does some crazy shit I didn't write D: 18:14 hmmmm the serverlist should tell the client about updated versions 18:15 hmmmm in addition to collecting how much each version is used 18:15 sapier what is done there is client stage 2 init the one I intend to move behind finished message 18:15 hmmmm it'd be nice if we can get an rsa signature to sign like Win32 binaries with so we can push auto-updates when possible 18:16 sapier I don't think so, e.g. if a server is running a quite old version suggestion to update may be wrong 18:16 hmmmm hmmm 18:17 hmmmm for 'controversial' settings like an auto update and so on I think it'd be a good idea to have a dialog box pop up in the GUI on first run asking about these settings 18:17 hmmmm instead of keeping it disabled and then the user would never know about them unless they look at the config file or settings or whatever 18:17 sapier we're not talking about autoupdate ... that's way more to do 18:18 hmmmm autoupdate is something that i'd like to see eventually though 18:18 sapier there could be a text in mainmenu always shown about a newer version beeing available 18:18 hmmmm it's a lot of work but then the vast majority of users who are too lazy to get patches 18:19 sapier and additionally a option to make server owners tell their users what version should be used for a specific server 18:19 hmmmm they're going to be the ones to complain about bugs 18:19 sapier how is autoupdate supposed to work on linux? 18:19 hmmmm it doesn't 18:19 hmmmm for example autoupdate for firefox works where it can but is disabled for platforms where it's too troublesome to get it right e.g. freebsd 18:19 sapier it'd be nice to have on windows, but I don't see anyone to do it anytime soon :-( 18:20 sapier while we can add the server side notification next version without lots of trouble 18:21 sapier I have to leave now maybe there are others who know additional options? 18:22 xyz just adding a notification with link to download is fine enough 18:41 VanessaE G*d damn it. internet went down for a while 18:45 us_0gb Autoupdate on systems with package managers should be handled through said package managers. 18:46 us_0gb We have that for APT-based systems with Minetest, but not for other package managers. 18:48 VanessaE regarding the client<->server init I'll say it plain: it broke with kahrl's httpfetch. someone fixed it. it broke again recently. Now some older-but-post-0.4.8 clients are not able to receive either player models, or skins, or both, randomly at connect, and people are bitching that players who were already on before they signed on are invisible to them - no player names, no skin, no model. 18:49 VanessaE and no, telling users to upgrade WILL NOT WORK. 18:49 VanessaE because many users cannot. 18:50 VanessaE I verified the no-skins/models myself with 0.4.9-stable 18:50 VanessaE and the absence of players 18:50 VanessaE there were 15 or 20 players on the server when I signed in with 0.4.9. I saw only one, and she signed on right after I did. 19:05 VanessaE so can someone please just tell me what I should do here? 19:14 proller revert some commits? ;) 19:15 VanessaE way too late for that now 19:15 VanessaE how about helping fix the problem? 19:15 VanessaE if I could help more than I do, I of course would 19:27 PilzAdam VanessaE, tried https://github.com/minetest/minetest/pull/1139 ? 19:38 VanessaE PilzAdam: indeed I have. 19:39 VanessaE PilzAdam: older clients can connect with that patch in place, but it makes the previously-discussed no-models-no-names problem quite evident then 19:39 VanessaE thing is, that problem does not require his patch 19:39 VanessaE at least not on the client 19:39 VanessaE I can reproduce the no-models-no-names glitch with an 0.4.9-stable client also. 19:44 VanessaE if I remove that patch, clients newer than when httpfetch went in, on up through git from about last week (but not newer I guess) will have a high chance if getting nailed by that grey screen/"mainlist == NULL" bug 19:44 VanessaE and thus will be unable to connect fully sometimes 20:17 xyz they can't update why exactly? 20:19 VanessaE buildcraft. 20:19 VanessaE 'nuff said? 20:19 xyz wait weren't you the one who wanted to ban those clients? 20:20 VanessaE I presume the buildcraft team (well, I guess it's just one guy?) doesn't exactly have a regular update schedule. 20:20 VanessaE at one time yeah but they make up at least half my userbase now. I'm kinda committed at this point 20:20 VanessaE (or I should be :P ) 20:20 xyz because we got them off google play thanks to dmcas lololol 20:21 xyz I think some APKs of them have update feature 20:38 VanessaE screw it. I'll roll back to 458045d49fd96cf19bdd61b2f8dbdbc0fd11b587 ... as I recall it worked fairly reliably there. 20:46 VanessaE yep, that commit seems fine. 20:46 VanessaE at least on a first try, with 0.4.9-stable. 20:46 VanessaE (0.4.9-stable for the client that is) 21:04 kahrl good morning 21:05 kahrl xyz: I didn't write that code, but there has to be an endScene to match beginScene 21:05 kahrl (I'm probably in git blame for the code because I moved it around) 21:06 xyz kahrl: I don't think it has to be there 21:07 Maxou56800 Hello 21:07 kahrl the docs are not completely clear on what beginScene and endScene do 21:07 kahrl but for beginScene: "Applications must call this method before performing any rendering." 21:07 xyz yes endScene says "Presents the rendered image to the screen." 21:07 kahrl for endScene: "Applications must call this method after performing any rendering." 21:08 kahrl so it seems pretty clear that they must be called in pairs 21:08 xyz http://irrlicht.sourceforge.net/docu/example013.html 21:08 xyz hm, I see, then is there a real need for beginScene? 21:08 kahrl well that example is structured so the RTT part happens during the on-screen scene 21:09 kahrl while our RTT code could be called at any time 21:09 RealBadAngel i have moved normal maps generation from shaders on the fly to engine and on startup, it works pretty nice 21:09 kahrl so I think beginScene is needed 21:09 RealBadAngel normals for minetest_game are generated in circa 20s 21:10 RealBadAngel and are better quality than before 21:10 kahrl unless we move enough stuff around that generateTextureFromMesh only happens during the on-screen scene 21:13 xyz hm, so wasn't there a bug before with same thing (blinking black screen) happening? how was it solved? 21:14 kahrl I'm not aware of that 21:16 xyz not aware of what? 21:16 kahrl that bug 21:16 RealBadAngel http://i.imgur.com/RxkYJ4e.png http://i.imgur.com/vVkDZGl.png 21:17 RealBadAngel how do you like the effect? 21:17 xyz I see, I remember it happening on Windows; maybe it was never fixed, maybe it's not our bug 21:20 kahrl hmm, it seems the flickering is by design (or a known sideeffect) and we should structure our code like the example you linked 21:20 kahrl see http://irrlicht.sourceforge.net/forum/viewtopic.php?t=22546 21:21 kahrl but I don't see any clean way to get to that structure 21:22 xyz ah right 21:28 xyz do we really need to call it at random times? can't those textures be generated once when connecting? 21:28 kahrl other stuff calls this function too iirc 21:28 kahrl but it might be possible 21:30 xyz well 21:30 xyz queuing is already implemented there 21:31 xyz so we just need to move 'itemdef->processQueue(gamedef);' right after beginScene and make it queue everything? 21:32 kahrl then it would deadlock if you tried calling it from the main thread outside beginScene/endScene 21:32 xyz ah right, I forgot about it 21:36 xyz it actually would deadlock no matter where you call it from (if it's main thread), bleh 21:37 kahrl right 21:39 Jordach RealBadAngel, what's worrying is that those nodes have specularity 21:40 xyz so the only entry point are getInventoryTexture and getWieldMesh and both seem to be quite static since we don't allow to modify/add definitions after the client is connected/initialized 21:41 xyz on the other hand, what if we want to allow this some day 21:41 kahrl ah, for some reason I thought there were others 21:42 xyz if we just always queue it (returning dummy image) things will only break for a frame, right? 21:43 kahrl yeah 21:43 kahrl seems to be the easiest solution 21:43 xyz or maybe no 21:43 xyz ugh 21:43 xyz i.e. in formspecs 21:44 xyz it doesn't redraw everything every frame, does it? 21:44 xyz i.e. in itemimagebutton 21:45 kahrl yeah that's a problem 21:45 xyz and who knows where else 21:47 xyz so we can just allocate ITexture* in getInventoryTexture, initialize it to dummy texture and queue; then in processQueue replace with rendered image 21:47 kahrl ItemCAO caches the result of getInventoryTexture too 21:47 xyz that sounds awful 21:47 kahrl (are those still used if you load an old map?) 21:50 kahrl overwriting the texture should work, I guess, can't think of a situation where it wouldn't 21:51 xyz can't say I like it much since it depends on Irrlicht internals 21:51 kahrl the only exception would be converting the texture to an extruded mesh, but that's only done in createClientCachedDirect anyway 21:54 kahrl the ^[inventorycube handler calls generateTextureFromMesh too 21:54 kahrl if you handle that by queuing too, you won't be able to specify any additional modifier such as ^[brighten (not sure if anyone does that) 21:57 kahrl I guess if optimize_invtex was finished, that could be used for inventorycubes... 21:58 xyz why won't that be possible? 21:59 * VanessaE mumbles something about optionally disabling extruded wield meshes :) 21:59 kahrl oh, I mean queeing it within the inventorycube handler 21:59 VanessaE (as long as you're fucking around with this stuff) 22:00 kahrl not queuing all the getTexture calls (which could break a lot of stuff) 22:00 xyz ah right, got it 22:01 xyz ugh, for now it'd be easier to queue this task and mark it as low priority, I guess 22:02 kahrl maybe 22:03 kahrl could simply comment out (beginScene and) endScene for android if it works 22:04 kahrl but it's not the correct solution of course 22:04 xyz yup 22:04 xyz I wonder what's going to happen if it's called between some other beginScene/endScene pair 22:04 xyz will it clear everything? 22:04 xyz will it leak? 22:08 kahrl they don't seem to actually do much outside of the clearbuffer/swapbuffer equivalent 22:09 kahrl and clear some random state variables of C{Null,OpenGL,...}Driver 22:30 hmmmm alright, based on the existing conventions regular mapgen flags should be just fine 22:31 hmmmm but what I did was remove the v6_* and v7_* prefixes from mapgen-specific flag parameters 22:31 hmmmm so anymore, specifying "trees, caves" in mg_flags in your config file is redundant 22:31 hmmmm they're always going to be there as per the default MapgenParams ctor 22:32 hmmmm to get rid of trees and caves you need to explicitly put "notrees, nocaves" 22:32 hmmmm so basically anybody who is using jungles in v6 right now, be aware that you're gonna have to change it to mgv6_spflags = jungles 22:33 hmmmm also same with biome blend, in order to get rid of that you have to specify "nobiomeblend" in mgv6_spflags 22:33 hmmmm I would make it reverse compatible but that makes things messier than they really need to be 22:34 hmmmm so I'm just going to add a little release note to people telling them of what they need to change in their config, or something, unless someone has a better idea. 22:34 hmmmm or maybe a little script to fix their config files and worlds 22:35 hmmmm if they don't change it, nothing *bad* will happen, it's just that newly generated areas will be missing jungles where they would otherwise be, or they get that ugly biome dithering effect between biome transitions 22:36 RealBadAngel hmmmm, i tried different way of generating normal maps, i made them generated on startup and it looks like this code will be unusable. 22:36 hmmmm what way? 22:37 RealBadAngel instead of shaders calculations per pixel, i coded texture generation in the engine 22:37 RealBadAngel and i cant connect to vanessa's server which have over 4k textures 22:37 RealBadAngel 4gb of memory is not enough 22:38 hmmmm you sure it can't just be done algorithmically better 22:38 RealBadAngel wait, now im talking about memory usage 22:39 RealBadAngel normal map to be usable has to be at least 256x 22:40 RealBadAngel anythin less looks like shit 22:42 RealBadAngel and bout the algorithm it is most common used one in games to generate such effects 22:45 RealBadAngel this is the method i am using: http://en.wikipedia.org/wiki/Sobel_operator 22:53 hmmmm https://github.com/kwolekr/minetest/commit/83bafbe08b508266d31a6a76f1ffc2cddc662390 22:54 hmmmm RealBadAngel, surely you don't need the entire texture loaded into memory at any given time 22:56 RealBadAngel currently not displayed textures are dropped? 22:56 RealBadAngel dont think so 22:57 RealBadAngel on startup every single texture is loaded into memory 22:58 RealBadAngel in nodedef.cpp 22:59 hmmmm yes but the memory that takes up 4gb like you were talking about 22:59 RealBadAngel huh, i mean amount of textures needed 22:59 RealBadAngel normal map is a texture 256x 23:00 RealBadAngel and have to be loaded into memory 23:00 RealBadAngel having 2*4500 texures is too much for 4gb machine 23:01 hmmmm oh 23:01 hmmmm yeah but what does that have to do with your thing not working 23:02 hmmmm just because it doubles the amount of textures in memory? 23:02 RealBadAngel both solutions are working 23:02 hmmmm [05:36 PM] hmmmm, i tried different way of generating normal maps, i made them generated on startup and it looks like this code will be unusable. 23:02 hmmmm you said it was unusable 23:02 VanessaE It's been my experience that it takes around 6-7 GB for that, on Survival/30001 + HDX 256 + normalmaps for everything that it supports on that server 23:02 RealBadAngel but my machine is too weak to use generated on startup one 23:02 hmmmm yes... so it can be an option, right...? 23:02 RealBadAngel could be 23:03 hmmmm so 23:03 hmmmm any comments/concerns about the mapgen flag fixup? 23:03 RealBadAngel sadly i wont be able to use that option ;) 23:03 hmmmm you've all been warned... ... ... ... 23:04 hmmmm plus it's a development version so it's not like anybody could blame me if stuff breaks 23:04 VanessaE hmmmm: no comments as long as it doesn't b0rk emergethread agin ;) 23:04 VanessaE again* 23:04 hmmmm there's no way that's happening https://github.com/minetest/minetest/commit/7f743178db2a45bd3f68ef2c9c7df6deca1f3ab6#diff-1dc3934293fad6b8769890134ac51c21R116 23:05 VanessaE of course I'm rolled back to 458045d49 on my servers, so I won't see the effects right away if something breaks, anyhow. 23:05 VanessaE oh,well that looks safe enough. 23:08 * VanessaE waits for the next "oh shiiiiiiiit..... I did THAT?" moment.. ;)