Time Nick Message 00:38 sofar well dammit, I fixed culling for older version, but now it's broken for latest :( 00:41 sofar ohhh man, ContentFeatures has it's own version number :((( 00:43 Fixer lol 00:45 sofar this is anything but hilareous at this point 00:46 sofar third revision of a fix :( 00:56 kaadmy hilarious* 01:00 sofar it isn't. nor will I ever spell that right ... I'm not a native english speaker. 01:04 sofar now I need to dig the servers' protocol version out in the client... somehow 01:04 sofar I don't even know if it sends it 01:12 * red-001 is making beds meshes 01:44 sofar ok, I can see the server sending the server protocol version to the client 01:44 sofar now where the heck is it stored? 02:00 frustrat1d is there a proper way to cause the digging cracking animation to happen on a node via the lua api? 02:00 frustrat1d for example, if a mob is digging a node 02:09 kaadmy not really afaik 02:09 kaadmy the crack is drawn client-side 02:13 ShadowNinja Merging #3433. 02:13 ShadowBot https://github.com/minetest/minetest/issues/3433 -- Fix world config menu ignoring `name` in `mod.conf`. by kaeza 02:21 sofar ShadowNinja: do you know if the client holds the server version somewhere? 02:22 ShadowNinja sofar: It uses the protocol version, but not the "human friendly" version. 02:23 sofar I can't find anywhere during deserialization of nodedef data what the heck it is 02:24 sofar what do you mean by "not human friendly version"? 02:25 frustrat1d thanks kaadmy. does anyone know of a mod off hand where they are simulating it with an entity? 02:54 sofar hmmmm: do you know how to get a handle on Client::m_server_ser_ver or Client::m_proto_ver in nodedef.cpp? 02:55 sofar I'm scratching my head over this... honestly I thought the client side deserialization would be using it already somewhere 02:55 hmmmm they're passed as parameters to ContentFeatures::deSerialize() 02:55 sofar void ContentFeatures::deSerialize(std::istream &is)� 02:56 sofar I don't see that 02:57 hmmmm CNodeDefManager::deSerialize rather 02:57 sofar same, only has the input stream as well 02:57 sofar void CNodeDefManager::deSerialize(std::istream &is) 02:58 hmmmm hm you're right, it's deSerializeOld that that has the parameter 02:58 sofar wrong, that's not the server protocol version 02:58 sofar that's the nodedef version 02:58 hmmmm what are you trying to do exactly? force a ContentFeatures to get deserialized with a version different than what you need? 02:58 hmmmm err than what it is 02:58 hmmmm I don't get it 02:59 sofar the problem is that some data has been serialized since version 20 or so 02:59 sofar and a recent patch by me changes it to actually use that information 02:59 sofar but if a new client connects to an old server, the client needs to disregard that data 02:59 hmmmm so you want to use the /protocol/ version to determine how to parse a ContentFeatures? 02:59 hmmmm this is incorrectly designed 03:00 sofar I have no choice 03:00 hmmmm then make a new ContentFeatures version. 03:00 sofar that would make the server incompatible with all old clients 03:00 hmmmm what you're trying to do stinks, badly 03:01 hmmmm there is a major design flaw in all of this and i don't know how to fix it without knowing all the context of your problem 03:01 hmmmm sorry I can't be of more help 03:01 sofar easy enough, the code is in these 2 PRs: 03:01 sofar https://github.com/minetest/minetest/commit/882a89d65aa78b89cfaf2af054d15cc4c94ad022 03:01 sofar https://github.com/minetest/minetest/commit/735e3b70596e16d04de1edcd878deec3c539c6ed 03:02 sofar I made the mistake in the second commit (735e3b7) to assume that the version number there was the server version 03:02 sofar but it's the nodedef version 03:03 hmmmm i don't quite understand why you're making backface culling a node-level option 03:03 hmmmm this has to do with the drawtype 03:03 sofar simple reason: I found that people wanted it enabled for mesh nodes 03:03 sofar and it's already being serialized/deserialized since v20 or so 03:04 sofar we have the right data, it just wasn't being used 03:04 sofar then the problem becomes: new client connects to old server, and sees values that are wrong (old servers just put "true" irregardless) 03:05 hmmmm so you want there to be an option to enable backface culling for mesh nodes in the case where the mod author knows better that it would be acceptable in this case 03:05 sofar so for mesh, firelike, liquid and one more we need to ignore it when connecting to an old server 03:05 hmmmm the drawtype determines the backface culling 03:05 sofar yes, backface culling defaults do not change 03:05 sofar it's enabled for all except the 4 special ones 03:06 sofar for those remaining 4 nodes, clients v27 will honor the tiledef setting if on the server mods enable it for nodes 03:06 hmmmm backface culling has been an independent field in a serialized ContentFeatures for a long time, correct? 03:06 sofar exceept it only had meaning in SpecialTiles 03:06 hmmmm oh 03:07 hmmmm so backface culling is an option in a serialized TileDef 03:07 sofar but it was serialized in tiles as well 03:07 hmmmm s/option/field/ 03:07 sofar yes, tileDef 03:07 hmmmm and now you want the older clients to not ignore backface culling for regular tiles 03:07 sofar inverse 03:07 sofar new clients to old servers 03:07 sofar and new clients to new servers 03:08 hmmmm so for a new client to old servers you want the new client to do what now 03:08 sofar older clients already ignore it, and they work fine 03:08 sofar so right now, due to the bug in 735.. 03:09 sofar if a new client connect to an old server, culling is disabled for mesh nodes 03:09 sofar but 03:09 sofar if a new client connect to an new server, culling is disabled for mesh nodes 03:09 sofar even if the server tells the client that it should cull the nodedef 03:09 hmmmm why is that exactly? 03:09 hmmmm new client to a new server should not ignore any of the fields 03:10 hmmmm you just change the logic in the client to not ignore them 03:10 sofar well it's because deSerialize() doesn't know it's a new server 03:10 hmmmm or is it that you want the new clients to keep ignoring the fields for old servers? 03:10 sofar the code is there to ignore it for old servers 03:10 hmmmm so the desired behavior is: ignore for old servers, don't ignore for new servers 03:10 hmmmm right? 03:10 sofar with the one bit missing... the server version 03:10 sofar yes 03:10 * hmmmm processing 03:11 sofar https://github.com/minetest/minetest/commit/735e3b70596e16d04de1edcd878deec3c539c6ed#diff-70868aa6d6b96c0c1623c761500d23c4R348 03:11 sofar that line right there (348) 03:11 sofar in that line I need "m_server_ser_ver" instead of "version" 03:11 sofar and same on line 1287 03:12 hmmmm in this situation, what I would do is add a new field 03:12 hmmmm and bump the contentfeatures version 03:12 hmmmm there really is no way to access m_srever_ser_ver there 03:13 hmmmm and add a nice big comment explaining why you added a new field instead of using the old one that was ignored by clients 03:13 hmmmm it sucks, sure, but this is the cleanest way to do it imho 03:14 sofar ok, so then 03:14 sofar say I add a "use_tiledef_culling" bool 03:14 sofar the new server can send it, sure 03:14 sofar but the old version never does? 03:15 hmmmm right 03:15 sofar I can't just read a value that's never sent 03:15 hmmmm so from the new client's perspective, if the field doesn't exist, that means it's false 03:16 hmmmm sure you can 03:16 hmmmm see that try { } catch (SerializationError ... block? 03:19 sofar hmmm 03:57 sofar hmmmm: ok, yes, that works out. 04:04 sofar hmmmm: #3608 04:04 ShadowBot https://github.com/minetest/minetest/issues/3608 -- Backface culling once more: We don't know the server vers. by sofar 04:53 est31 in this situation, what I would do is add a new field 04:53 est31 and bump the contentfeatures version 04:54 est31 I dont think that bumping the contentfeatures version is neccessary or useful here 04:54 est31 after all you want to spare a bump of the network protocol version, right? 04:55 est31 but bumping contentfeatures version requires a bump of the network protocol as well 04:55 est31 bc the contentfeatures version isn't negotiated at the connection 04:56 est31 but instead the server has to know it for sure 04:57 est31 #3608 is a bit different, it looks like some kind of a hack so that one doesn't have to pass through the used network protocol version internally in the client 04:57 ShadowBot https://github.com/minetest/minetest/issues/3608 -- Backface culling once more: We don't know the server vers. by sofar 04:57 est31 bc idk 04:58 est31 so probably its a great thing to do if you want to avoid having to bump the network protocol version 04:59 est31 but 1. the PR still keeps the protocol version bumped and 2. I dont think that not bumping protocol version is worth the extra byte sent 05:00 est31 its not a great thing to do, except you want to avoid bumping the protocol version at all cost 05:03 est31 A better hack in my opinion would be to send the boolean value + 1 over the network 05:04 est31 Then if its 0 at the reciever side you know server doesn't support it, if its 1 its false, if its 2 its true. 05:09 est31 but I do admit that I dont really see the beauty in having separate contentfeatures version, at least not this way, where it bases on network protocol version anyway. 05:16 est31 but yeah this code stinks bad https://github.com/minetest/minetest/pull/3608/files#diff-70868aa6d6b96c0c1623c761500d23c4L348 05:17 est31 version is not network proto version 05:17 est31 but contentfeatures one 05:18 est31 and this code stinks too https://github.com/minetest/minetest/pull/3608/files#diff-70868aa6d6b96c0c1623c761500d23c4L358 05:18 est31 This should have been caught by review 05:19 est31 so my fault. 05:21 sofar est31: no worries, I never properly tested that version value either 05:21 sofar est31: now that I started doing that when I caught the new error, it all fell through 05:22 sofar est31: this is why I don't mind not being a core dev for a looong time - I'm coding too fast for my own good still, at this point ;) 05:24 est31 okay... probably raising the contentfeatures version is most reasonable indeed 05:25 est31 @ least its most consistent with the past practice 05:25 est31 but idk, parts of the approach is still flawed 05:26 est31 e.g. this comment https://github.com/minetest/minetest/pull/3608/files#diff-70868aa6d6b96c0c1623c761500d23c4R392 05:26 est31 why should that happen? 05:26 est31 you have to support three versions now? 05:26 est31 one where it doesn't get sent, one where it gets sent using the outdated version, and one where it gets sent via the new version? 05:27 sofar the outdated version never sends it 05:27 est31 additional copypasta in order to have a "correct place" for stuff? 05:27 sofar the problem is that the bool doesn't get read until after all tiledefs are read 05:29 sofar I also made a huge error in passing drawtype to deSerialize() in deSerializeOld that got unnoticed 05:30 sofar I'm not anywhere proud of this patch either 05:30 sofar but, this gets it correct for now 05:30 sofar maybe we can make it prettier 05:30 est31 good idea 05:30 sofar but the whole damn problem has been that there's been data sent and received for many versions that's been wrong 05:31 sofar this would have never happened if tiledef.backface_culling was properly set to false in older versions 05:31 sofar that's the root of the problem 05:31 sofar TL:DR if you serialize unused data, better serialize it right 05:32 sofar I hope there's not more damage like this lurking :) 05:44 ShadowNinja Does #3347 look good to y'all? 05:44 ShadowBot https://github.com/minetest/minetest/issues/3347 -- Fix jumping at node edge by ShadowNinja 05:49 est31 wrote a comment on your pr sofar 05:50 est31 sorry SN dont really know much about collision handling code 05:55 ShadowNinja est31: Neither do I, but it seems to work somehow :-P 05:56 sofar code looks a lot cleaner, if you ask me. other than that, I have NFC 05:56 sofar :) 06:08 sofar oh 06:09 sofar I've discovered a bug in porting.h 06:11 sofar and I know what the right fix is as well 06:11 est31 ? 06:11 sofar we're not using a monotonic clock for POSIX 06:12 sofar IOW ntpd skew could cause time to go backwards 06:12 sofar causing all sorts of lag on the server 06:16 est31 okay... 06:16 est31 what is the proposed fix? 06:17 sofar so to keep it fully compiling on systems that do not have clock_gettime()... 06:17 sofar I'll have to see if I can detect runtime which clocksource is available I think 06:17 sofar in any case, we'll want to use CLOCK_MONOTONIC_RAW 06:18 est31 (I don't know what you talk about but I guess its something like making it compatible to leap seconds or y2k or sth) 06:18 sofar do you know what NTP is? 06:18 est31 yes 06:18 est31 time synchronisation over network 06:18 sofar ok, so on a normal server ntp adjusts your time very often, but little amounts 06:18 sofar if you have a bad clock, then it adjusts it more often 06:19 sofar if those adjustments adjust the clock forward (clock is slow) then probably nothing happens 06:19 sofar if your clock is fast, then the time gets set backwards 06:19 sofar in that case, you'd see the server sleep too long between steps, possibly timer calculations roll over backwards, etc. 06:20 sofar with CLOCK_MONOTONIC_RAW, that problem disappears 06:20 sofar because the clock will (for the process) always appear to go forward no matter the ntp adjustments 06:21 est31 so it stops until the time got right again when the clock gets reset? 06:21 est31 or does it only slow down or sth 06:21 sofar it never slows down 06:22 sofar the process continues to see it's own version of time 06:22 sofar note that the monotonic clock doesn't start at 1970-1-1 06:22 sofar it starts at the process start 06:22 sofar it's like a private clock that is not affected by NTP 06:23 est31 okay 06:27 sofar too bad OSX is such a disaster 07:58 hmmmm [11:54 PM] I dont think that bumping the contentfeatures version is neccessary or useful here 07:58 hmmmm right, i made a mistake saying that but i guessed that sofar would probably see the comment right above the try catch block saying that you don't need to bump the CF version by adding things here 07:59 hmmmm so I didn't bother mentioning it 09:03 everamzah https://forum.minetest.net/viewtopic.php?f=10&t=10539&p=205530#p205441 09:07 nrzkt2 everamzah, not related with this IRC channel 09:07 everamzah ok sry 09:07 everamzah my mistake, then 13:30 RealBadAngel hi 13:30 RealBadAngel https://github.com/minetest/minetest/pull/3610 13:30 RealBadAngel should be pretty complete, ive added the missing timers and cleaned the code 13:36 sfan5 https://github.com/minetest/minetest/pull/3610/files#diff-65f34680878a6bd86f3a59ebc0c06c6dL2278 13:36 sfan5 you added some whitespace 13:36 VanessaE RealBadAngel: items now rotate nicely in the inventory, but it still flickers while changing pages in UI etc. 13:36 VanessaE (there's still a measurable delay in flipping pages, that is) 13:37 VanessaE (though it does seem to be faster) 13:37 RealBadAngel meshes have to be created 13:38 RealBadAngel the process is faster than getting inv textures but still takes some time 13:38 RealBadAngel in UI its more visible because theres shitload of items on a single page 13:39 VanessaE RealBadAngel: you need to reset the rotation counter when you stop the mouseover rotation as well 13:39 VanessaE the yaw counter I mean 13:39 VanessaE mouseover an item, it rotates. mouse away, it returns to its default state. mouseover it again, it begins rotating from the yaw it was at when you moved the mouse away. 13:40 RealBadAngel sfan5, fixed 13:40 RealBadAngel VanessaE, cant do much about it, timers do reset when mesh changes 13:41 RealBadAngel the function to draw them is neither part of the hud or formspec, its used by both 13:41 VanessaE not a timer, I mean there's a counter that reports the current (actual) yaw, that should be reset on mouseout. 13:41 RealBadAngel yaw changes with time 13:42 RealBadAngel timers are reset when you hover/select/drag another mesh than before 13:43 RealBadAngel if you hover the same as before, timers wont reset, so yaw too 13:45 RealBadAngel i cant do anything with that because of both hud and formspec menu design 13:45 VanessaE ok. 13:45 RealBadAngel formspec doesnt even have global timers for hovered things 13:46 RealBadAngel thats why tooltips for items are not delayed 13:47 VanessaE suggestion: if it's a mesh node, don't angle it like you do with a block. 13:47 RealBadAngel no can do 13:47 VanessaE no? 13:47 RealBadAngel stairs... for example 13:48 VanessaE hm 13:48 VanessaE well, see what it does to e.g. an ilights light. 13:48 RealBadAngel to what? 13:50 VanessaE it angles the light and rotates around that new center, rather than rotating around the center of the object itself. maybe a node def field should be added to fine-tune the camera location, roll, etc. for some nodes. 13:50 RealBadAngel that could be a solution 13:50 VanessaE it's not a major issue, just a detail I noticed is all 13:52 VanessaE (seems to me that just specifying the X/Z location for the rotation axis, and its X/Z pitch, would be more than enough. distance/rotation/etc of the camera would be overkill) 13:52 RealBadAngel something like default_inventory_rotation = (x, y,z) 13:52 VanessaE something like that yeah 13:52 RealBadAngel atm default is as we had for cubes 13:53 VanessaE so that there's just enough to make some model rotate about its own center 13:53 RealBadAngel center doesnt change 13:56 VanessaE anyway this looks good so far 13:58 RealBadAngel shall i add that def field now or maybe later on? 13:58 RealBadAngel btw, inventory cubes are also obsolete with it 13:59 VanessaE default glass ^^^^ 13:59 RealBadAngel removing them from water, glass etc will be necesary 13:59 VanessaE why DOES glass still use the inventorycube thing anyway? 13:59 RealBadAngel idk 14:00 VanessaE (moreblocks' glasses don't use it) 14:00 VanessaE hm, point of note: transparent objects probably should not use backface culling in the inventory model 14:00 VanessaE look at moreblocks glass (which is a real cube, not an inventorycube), compare to framed glass 14:01 RealBadAngel ive set culling to on, but can disable it at all 14:01 RealBadAngel that doesnt really matter here 14:02 VanessaE well I'm just saying that a transparent block like glow glass probably ought to show all 6 sides :) 14:02 RealBadAngel you can test it, its at the end of wieldmesh.cpp 14:02 RealBadAngel line 540 14:02 * VanessaE tries... 14:03 RealBadAngel in game you cant see all glass faces anyway 14:04 VanessaE right, but in the inventory it seems like it would make sense to see them 14:04 RealBadAngel but you can if using connected glass 14:04 VanessaE particularly because of the new rotation 14:04 VanessaE in-game you can't see all the glass faces because the streaks would make everything obscure, as I understand it 14:05 VanessaE interesting. 14:05 VanessaE that flag had no effect. 14:07 VanessaE (neither on the wielded item, nor in-game, nor in the inventory) 14:09 * VanessaE shrugs. what you've made here is a damn sight better than what we had. 14:10 VanessaE I wonder if the inventorycube thing can be made into a simple no-op (just passing the referenced textures straight through)? 14:22 RealBadAngel ah 14:22 RealBadAngel i know why, its for extruded only here 14:23 VanessaE ah, yeah we don't need that for an extruded item 14:26 RealBadAngel also, killbith noticed that already, items do look way better now 14:26 VanessaE yes, they do 14:26 RealBadAngel theyre displayed in actual screen resolution 14:26 VanessaE guess all that upscaling-for-inventory code can be dispensed with also 14:27 RealBadAngel idc about it, i just take window defined and use it as a viewport 14:27 VanessaE look fore references to "gui_scaling_filter" 14:27 VanessaE -e 14:27 RealBadAngel that will scale all other elements propapbly 14:27 VanessaE we don't need this now, with your mesh-based inventory 14:28 VanessaE that ^^^ scales all inventory images/cubes/etc during (or after?) render-to-texture 14:28 RealBadAngel need to take a look 14:28 RealBadAngel this code makes many things obsolete indeed 14:29 RealBadAngel btw i think i have figured how to reset rotations for hovered/grabbed ones 14:30 VanessaE oh good 14:30 RealBadAngel will try if its gonna work, i hope it will 14:30 RealBadAngel some good ideas come with time 14:31 RealBadAngel i had problems with makin timers reset at all, so ive put this code on hold for a week or so 14:31 RealBadAngel today idea just blinked and solution was here ;) 14:55 luizrpgluiz what is the probability of version 0.4.14 out this year? 15:04 Amoebaa hi, I'm guessing this is a better place to ask this question: is anybody specifically working on changes to the minimap? 15:04 Fixer luizrpgluiz, just download new builds from sfan or krock or whatever 15:04 Amoebaa I had a pretty simple change in mind, and am wondering how it would be recieved 15:07 Amoebaa basically, adding a simple depth indication to the radar mode by showing the aircount for the above mapblock in blue, the current mapblock in the current green, and the aircount for the mapblock below in red 15:08 Amoebaa I love the minimap, but am irritated that radar mode doesn't give any idea whether a shallow opening is above or below 15:10 Amoebaa I should be able to code this myself, but would like to check that there aren't plans for major changes in the minimap that would make this moot 15:11 red-001 RealBadAngel made the minmap iirc 15:11 red-001 you should ask him 15:13 RealBadAngel Amoebaa, how would you like to indicate that? 15:16 Amoebaa as I noted above, using the red and blue colors 15:17 Amoebaa by the command on line 357 in minimap.cpp ( c.setGreen ), I'm guessing doing the same for red and blue should work 15:19 Amoebaa so, if there's empty space in both the current and above mapblock, it would show cyan, the current and below would be yellow, and if there's space in the above and below mapblock but not in the current one, it would show purple 15:23 Amoebaa it looks like the program logic needs to be slightly changed to pass around the three values instead of just one, but I think it's doable 15:29 Amoebaa it would probably require a bit of testing to see how glaring the white is in large open areas, but I think it'd be mostly an improvement 15:29 RealBadAngel you will loose "radar" feeling 15:29 RealBadAngel maybe a third mode then? 15:29 everamzah when i need to know whether to mine upwards or downwards using radar mode, i just head in either direction and watch how the minimap changes 15:30 Amoebaa yeah, I've gotten to used to going to the edge of multiples of 16 and jumping up and down 15:30 RealBadAngel VanessaE, ive updated the PR, timers do properly reset in all cases 15:31 Amoebaa it just seems a bit dumb, or at least funny... 15:31 VanessaE RealBadAngel: ok 15:31 Amoebaa and yeah, I agree it would lose some of that "radar" feeling 15:32 Amoebaa but my basic question still is: there aren't any major changes currently planned to the minimap? 15:32 everamzah "frustrating" is the word i might use 15:32 Amoebaa if not, I'll putter around with this and see how it looks, maybe submit something in a few days... 15:32 red-001 sofar add an on_place callback to doors:hidden to check is there a door under it 15:33 red-001 mesecons can still break doors 15:33 RealBadAngel rather no plans atm 15:33 VanessaE RealBadAngel: looks better now but I wonder if the timer should reset when you grab an item? (left click that is) 15:34 VanessaE (but still reset it when dropping the item) 15:35 VanessaE s/should reset when/shouldn't reset when/ 17:17 RealBadAngel VanessaE, ouch THAT is im afraid i cant do 17:17 RealBadAngel those are two different timers 17:17 VanessaE ok 17:17 VanessaE (20 minutes later: VanessaE, I figured out that timer issue do try it now) 17:17 VanessaE ;) 17:17 RealBadAngel :P 17:18 RealBadAngel dont count on it this time ;) 17:18 VanessaE hehe 17:23 VanessaE btw, it works VERY well with HDX. 17:23 VanessaE page flipping is only slightly slower than default textures now (used to be hugely slower) 17:29 VanessaE well mostly. hard to describe - put a yellow signs_lib sign on the inventory and watch it rotate. you can see bright, vertical lines flicker across the face of it, and it changes "resolution" as the rotation approaches 90 degrees to the camera. 17:30 VanessaE seems to happen with any extruded item regardless of its resolution 17:31 VanessaE (look at carbone mobs' rat for example - it's not yet supported by HDX, so it's the regular low-rez rat image that originated in 0.3.x) 17:32 RealBadAngel its fault of wielded (extruded) meshes 17:32 RealBadAngel im reusing them 17:32 RealBadAngel but i will see if i can do anything with it 17:32 VanessaE ok 17:32 VanessaE so it's not unique to my box then 17:32 RealBadAngel no, its general flaw of extruded meshes 17:33 VanessaE ok 17:33 RealBadAngel way too many invisible planes 17:33 VanessaE ahh 17:33 VanessaE didn't someone say you needed to use irrlicht's mesh weld call for that? 17:33 RealBadAngel hmm 17:34 RealBadAngel i remember that there something like createMeshCopyWelded or similar 17:34 RealBadAngel i didnt knew whats that for 17:34 VanessaE might be useful here 17:34 RealBadAngel will try it 17:35 RealBadAngel brb 17:36 VanessaE this code basically makes the old render-to-texture code obsolete now, doesn't it? 17:40 RealBadAngel ofc it does 17:41 VanessaE ok, so what makes the inventory flicker when changing pages? 17:41 VanessaE I was told before that this was due to render-to-texture 17:41 RealBadAngel yes 17:41 RealBadAngel now theres also a small delay because of meshes 17:42 RealBadAngel they have to be created and stored 17:42 RealBadAngel making a copy of mesh is way faster 17:42 VanessaE ok 17:42 VanessaE it might be prudent to work on that 17:42 RealBadAngel but still, each page of UI means 80 meshes 17:42 VanessaE flicker between pages doesn't look very good :) 17:43 RealBadAngel aw cmon, its almost instant by now 17:43 VanessaE not in HDX ;) 17:43 RealBadAngel comparing to total blackouts? 17:43 RealBadAngel well, HDX shouldnt make ANY difference 17:43 RealBadAngel it doesnt care bout textures used 17:43 VanessaE it makes a difference, but it's not much now. besides, it's only for the first few pages, after which I guess most of the meshes have been generated. 17:44 RealBadAngel it should take the very same time as for 16px 17:44 RealBadAngel hmmm 17:44 RealBadAngel maybe not 17:44 RealBadAngel we do copy then more extruded 512x meshes 17:44 VanessaE yes. but like I said, the difference is small 17:44 VanessaE it's far better now with your PR than without. 17:45 RealBadAngel that was the point from start 17:45 VanessaE I'm just trying to address the flickery, choppy way that new meshes are fed to the formspec 17:45 RealBadAngel i wonder how much it would take to actually "preload" all the meshes 17:45 RealBadAngel same way we did that before with textures 17:46 VanessaE I would avoid that. 17:46 VanessaE it would take a drastically long time I think 17:46 RealBadAngel its way faster process than with textures 17:46 RealBadAngel maybe it would be acceptable after all 17:47 VanessaE RAM usage was respectable, btw - Dreambuilder + HDX256 = about 5 GB after 10 minutes of farting around in-game. 17:47 RealBadAngel wanna try? 17:47 RealBadAngel ah that 17:47 VanessaE that's with mesh cache disabled. 5GB is around what I'd expect from that combination. less is better, of course. 17:48 VanessaE sure I'll give pre-loading a tryu 17:48 VanessaE -u 17:50 RealBadAngel talking bout ram usage 17:50 RealBadAngel can you compare it? 17:50 RealBadAngel when using hdx it should spare you some ram 17:50 RealBadAngel throw 512 at it 17:51 VanessaE I can't run 512. that takes too much RAM, but 256 takes around 5GB now. before, 6-8 GB (variable) 17:52 RealBadAngel so this earned you 1-3gb or mem? 17:52 VanessaE anyway I just did a quick unscientific test: using your PR as it stands now, loading DB takes 21 seconds without HDX, and 42 sec with (a few seconds of that is server set-up time). That's rather faster than upstream, but I don't recall by how much. 17:53 VanessaE let me try it without your PR 17:55 RealBadAngel ok 17:57 VanessaE ok, I'm wrong about both. 17:57 VanessaE DB + HDX startup time and RAM usage are comparable between upstream and your PR 17:58 VanessaE maybe I'm thinking of celeron55's farmap PR. that DOES increase RAM usage. 17:58 VanessaE anyway, the benefit here is clear: your PR makes things definitely faster in-game, and looks nicer 17:59 RealBadAngel ram usage, tell me about it... :) 17:59 RealBadAngel ah 17:59 RealBadAngel you did ;) 17:59 VanessaE yep. 18:00 RealBadAngel i was hoping for some gain 18:00 VanessaE sorry to say, no gains in that department :) 18:00 VanessaE or I should say, thankfully no gains (as in increases ;) ) 18:00 VanessaE it's all good. 18:02 RealBadAngel hmm i do have an idea 18:02 RealBadAngel lemme try something 18:02 VanessaE uh oh... 18:03 RealBadAngel nah, wont work ;) 18:03 VanessaE heh 18:03 VanessaE ok 18:03 RealBadAngel forget it ;) 18:04 RealBadAngel i was thinkin about not cloning the meshes but reuse them 18:04 RealBadAngel but i do need to set textures in their materials 18:05 RealBadAngel or can i? 18:05 RealBadAngel hrmmm 18:05 VanessaE one thing at a time :) 18:05 RealBadAngel thats a good question, why not to set the texture when displaying a mesh? 18:05 VanessaE you still have to code the jump-zoom and glow effects we discussed :D 18:06 RealBadAngel those i will leave for the already merged code 18:06 VanessaE ok :) 18:06 RealBadAngel i bet that spirit will block 'em ;) 18:06 VanessaE I can't for the life of me think of the name of the zoom effect :-/ 18:07 RealBadAngel but definitely those can go into the forks 18:07 RealBadAngel tiny things that make things look lovely 18:10 RealBadAngel with working timers adding such things is just a matter of design 18:27 RealBadAngel i can see that even spinning is way too much for the spirit 18:27 RealBadAngel i dont even wanna try what will happen to real lighting 18:28 RealBadAngel forking now 18:28 VanessaE oh come on :PO 18:28 VanessaE :P 18:29 RealBadAngel theres nothing to talk about, see comments 18:29 RealBadAngel do you actually realize how much im gonna change with lighting and the stuff? 18:30 RealBadAngel if spinning is way too much i just dont wanna waste my time 18:30 VanessaE I do. 18:30 est31 go on, seeing you do a fork isnt sth bad IMO 18:30 VanessaE but as long as it remains within the "soul" of minetest it's fine 18:31 RealBadAngel i dont wanna go that far as other forks did, i just wanna minetest be a modern game 18:31 VanessaE est31: but in this case hje 18:31 VanessaE he's talking about his meshes-in-inventory PR 18:31 VanessaE which works and looks pretty nice 18:32 RealBadAngel word "nice" is not welcome here anymore 18:32 VanessaE RealBadAngel: nah, "nice" is welcome. "overengineered" isn't :D 18:33 RealBadAngel are spinning cubes overengineered? stop items on the ground too then 18:34 VanessaE I was trying to say that your code doesn't fall under the "overengineered" clause :) 18:34 VanessaE it's nice. fix that issue with the vertical stripes I mentioned and merge it. done. :) 18:35 RealBadAngel i highly doubt if i can do anythin with it, its how the meshes are done. maybe if i write another extrusion code 18:36 RealBadAngel well, frankly i do have already one, but its working only for 16px, and cant be any fast with 512px for example 18:38 VanessaE just relax and take a break, you'll figure it out 18:40 RealBadAngel whatever, im merging it, let it be the start 19:09 est31 sofar, seen my comment in #3608? 19:09 ShadowBot https://github.com/minetest/minetest/issues/3608 -- Backface culling once more: We don't know the server vers. by sofar 19:11 sofar yes, I'm fighting 3 kids here atm, will need some time to get to all the comments I got overnight 19:11 est31 oh ok 19:11 est31 take your time 19:13 * VanessaE hands sofar a lion-tamer's whip and chair to defend against the aforementioned kids :) 19:17 sofar well two are now watching Sesame Street and one is playing with command blocks in Minecraft 19:17 red-001 victory? 19:20 red-001 game#602 is quiet trivial could someone review it? 19:20 ShadowBot https://github.com/minetest/minetest_game/issues/602 -- Add access privilege that allows players to bypass protection. by red-001 19:29 everamzah with the recent discussion about players overriding priv checks, i can't help but worry that player's will lose things out of their locked chests. or am i being paranoid? 19:30 sofar you are being paranoid 19:32 kaeza could somebody point me in the right direction as to where to look at? https://forum.minetest.net/viewtopic.php?f=11&t=3905&p=205588#p205539 19:33 kaeza in particular, look at fireglow's response a few posts down 19:37 est31 ask fireglow to include server log at infostream level 19:38 est31 it will contain messages like "Couldn't convert wstring 0x" 19:38 est31 "into UTF-8 string" 19:39 est31 but most likely its because the server and client think differently of what wstring means 19:45 kaeza est31, setting LANG env var (which was unset) seems to have fixed the problem 19:46 kaeza but I'm not sure if this would be a bug in the engine or not 19:50 everamzah i get that error by using the shout mod 19:56 fireglow :) 20:14 est31 but I'm not sure if this would be a bug in the engine or not 20:15 est31 I'm pretty sure it is 20:15 sofar monotonicity 20:15 sofar is that a word? 20:15 kaadmy unlikely ;) 20:15 est31 idk, I'm no native speaker 20:15 sofar http://www.thefreedictionary.com/monotonicity 20:15 sofar seems it is :) 20:16 kaadmy heh 20:17 kaeza monotoniburg for the german speakers (?) 20:18 Fixer hauptvermessunsabteilung! 20:19 kaadmy ^i'm hoping that's a joke ;) 20:23 fireglow it's not =) 22:36 est31 wft 22:37 est31 wtf* 22:37 est31 collisionMoveSimple has non const references 22:37 est31 I'll modify it so that it doesnt have them 23:04 kaadmy wtf you made a typo! 23:07 est31 here https://github.com/est31/minetest/commit/59893823ca3e6f65dd7c4ad6c931012556208576 23:07 est31 When I hear nothing for two hours, I'll merge it. 23:09 est31 what the hell 23:09 est31 man 23:09 est31 thats bad 23:09 est31 I think I'll fix that as well. 23:12 est31 ah okay seems to be problem of my pr 23:12 est31 ermm commit 23:12 est31 @ least I hope... :/ 23:15 est31 https://github.com/est31/minetest/commit/61f84da1b56505601a4df69125c2020d57b1842c 23:15 est31 okay updated 23:15 RealBadAngel est31, screenshots of that crafting being broken? 23:16 RealBadAngel preferably before and after 23:17 RealBadAngel btw, ive updated PR a few minutes ago 23:28 est31 RealBadAngel, uploaded screenshots 23:33 est31 even newer version of my commit https://github.com/est31/minetest/commit/60e5c48ddea3393c59b02b41dc9ec2160d0f9055 23:33 est31 just a bit of style fixeas 23:33 est31 fixes* 23:40 Fixer RealBadAngel, found funny report, acacia leaves are not waving -> https://github.com/minetest/minetest_game/issues/802 is this interesting for you? 23:42 RealBadAngel propably waving flag is not set in node def 23:42 RealBadAngel est31, fixed, pushing it shortly 23:44 Fixer looks like slabs and panels has different lightning 23:45 kaadmy Fixer: yup 23:45 Fixer vs normal blocks 23:45 kaadmy they don't have the smooth lighting 23:45 Fixer yes 23:45 Fixer you could be right 23:45 Fixer maybe* 23:45 kaadmy ^ SSAO would fix most of that problem 23:49 RealBadAngel fixer, ive solved that issue in the PR already 23:49 Fixer damn you are good 23:49 RealBadAngel loading mesh doesnt set mesh color 23:50 RealBadAngel in code we do set it to (255,255,255,255) 23:50 RealBadAngel loader sets some other values propably 23:50 Fixer does it fix ingame lightning difference, or only in inventory? 23:51 RealBadAngel in game we do set mesh vertices colors no matter what 23:51 RealBadAngel so it cant be related 23:51 RealBadAngel difference in game comes from the fact mesh is not a cube (which have different light on each face) 23:52 RealBadAngel nodeboxes on the other hand have one lighting, for the inner of the node 23:52 RealBadAngel same as meshes 23:53 RealBadAngel thats fault of our lighting system, not the meshes 23:53 RealBadAngel real lighting (at least on the surface) will fix it 23:53 Fixer hope so 23:57 sofar was anyone else asking about the new mesh doors breaking mesecons_doors? 23:57 sofar in case they were: I have a PR pending to mesecons to integrate the new API and fix it...