Time Nick Message 00:02 MTDiscord and some visual inspection reveals there's a period where it loops between day and night on the same frame 00:03 MTDiscord despite that being where the dawn should be 01:37 MTDiscord more in the what the actual fucks 01:40 MTDiscord why is there so much BS trying to figure out cloud brightness 01:46 MTDiscord i'm actually gaining framerate from removing unneeded assignemnts 01:46 MTDiscord assignments and such 02:20 MTDiscord No no, I think that Navy Blue would work. It's not a blocking change though, so it can wait, just not too long because the old paint is flaking off and might be lead-based. 14:40 appguru The actual position of an attached entity is only known to the client, which knows about bones etc. Does the server use a reasonable approximation like the position of the parent entity? 14:40 appguru Or is this left to the modder? `self.object:set_pos(self.object:get_attach():get_pos())` in on_step should do the job. 14:43 appguru This might also explain a bunch of attachment issues. 14:45 MTDiscord Can you actually set the pos of an attached ent without breaking the attachment? Does that actually fix the problems, e.g. having ents left hanging when a player walks in/out of range? 14:47 sfan5 appguru: https://github.com/minetest/minetest/blob/3b842a7e021f61c119f060df5de035b71df1fe83/src/server/luaentity_sao.cpp#L147-L150 14:47 sfan5 set_pos does not even work when attached 14:48 appguru yeah I'm reading this right now 14:48 appguru it looks like the position is copied but not sent? 14:48 sfan5 correct, doing that is a waste of traffic 14:49 MTDiscord what happens when the parent object leaves the client's viewing range though? It seems like then the attached objects are just detached and left where the parent object last was, but the server-side seems to think they're still attached and moving with the parent. 14:50 sfan5 I believe that's handeled for players 14:51 sfan5 for luaentities if the parent leaves the view range, the child would too 14:51 MTDiscord For players it seems to work like a majority of the time 14:51 MTDiscord The problem is that when it doesn't work, every now and then, it breaks rather badly and there isn't really a way to fix it other than relogging. 16:48 Krock @Warr1024 attachments are indeed no longer known to the client, but the player positions are still sent manually afterwards to work around this issue 16:50 Krock https://github.com/minetest/minetest/blob/master/src/server.cpp#L792-L802 16:50 Krock the entire check is basically to reduce useless traffic, with the exception of out-of-range parents where the position of the player is still sent 16:54 MTDiscord What I've witnessed is that rarely, a player will travel into the distance, and then another player will try to follow after them later, but then encounter the ents that were attached to them just floating somwhere along the path. 16:55 sfan5 I don't we have anything handling that problem 16:55 sfan5 since nobody had done that before 16:59 MTDiscord Is that a problem that would need to be addressed specifically? Should I put an issue report in for this? 17:00 MTDiscord Particularly annoying is that it's not reliably reproducible and I don't know what, if any, specific variables affect reproducibility. It's just basically one of the last of the heisenbugs that have always in at least some degree plagued attachments forever... 17:01 sfan5 regardless of how it'll need to be fixed so please open an issue 17:04 Krock although without a way to reproduce it, it's just yet another open issue 17:07 sfan5 I think it should be pretty easy: set low player transfer distance, player 1 observes, attach object to player 2, p2 goes away, once p2 disappears from p1 object will be stuck 17:10 Krock ah. for vice-versa. where objects are unloaded after players 17:28 MTDiscord Seeing as I’m digging around in the sky again 17:28 MTDiscord Anyone up for me to nuke the current way of setting sky colours and use a proper world time blending system as seen in atmos 17:30 MTDiscord Because I can do some magic with this 17:33 MTDiscord I have no intention of using the default sky again, only the custom skyboxes, so I guess I don't have an opinion about things like time-of-day variations and such. I actually want my skybox to vary only based on player location. 17:35 MTDiscord It means I can set blending to an hourly basis 17:37 Krock sfan5: there's no log if the HUD ID does not exist 17:37 Krock modifying /hudfonts (testhud in devtest) works 17:38 Krock > 2021-08-19 19:36:30: WARNING[Server]: Unknown HUD stat type: Style (at <>/games/devtest/mods/testhud/init.lua:48) 17:57 sfan5 oh I see 18:03 sfan5 minor thing -> #11557 18:03 ShadowBot https://github.com/minetest/minetest/issues/11557 -- Allow lib/irrlichtmt to work for server builds (headers-only) by sfan5 18:03 sfan5 @Jordach is there any advantage to it that cannot be already done by server mods? 18:07 sfan5 merging #11511, #11472, #11384 in 5m 18:07 ShadowBot https://github.com/minetest/minetest/issues/11511 -- Validate staticdata and object property length limits by sfan5 18:07 ShadowBot https://github.com/minetest/minetest/issues/11472 -- Fix scaled world-aligned textures being aligned inconsistently for non-normal drawtypes by Wuzzy2 18:07 ShadowBot https://github.com/minetest/minetest/issues/11384 -- Add fwgettext util function by rubenwardy 18:15 MTDiscord Network bandwidth and clogged packet queues 18:16 MTDiscord sfan5, ^ 18:29 MTDiscord rather than updating client visuals every second or faster leaves much more room for server performance 18:33 MTDiscord basically i want to remove the stopgap feature that was set_sky_color 18:33 MTDiscord and replace it with a properly configurable 24 hour sky cycle 18:34 MTDiscord which means you can have properly configured weather 18:36 sfan5 sounds useful 18:42 MTDiscord instead of sending update packets once a step, i send it onceevery 20+ minutes 18:42 MTDiscord i can also add some extra sky features such as aurora alongside the rotating galactic skybox 18:42 sfan5 once a step is too often regardless, your fault if you do that 18:42 MTDiscord how else am i supposed to get nice blending 18:43 sfan5 well how nice does it need to be? what about every 250ms? 18:44 MTDiscord nice enough that the engine can manage it 18:45 MTDiscord even worse, is that current sky transitions are framerate dependant 18:45 MTDiscord rather than dtime 18:45 MTDiscord sky.cpp::update() is a fucking mess 18:48 MTDiscord all i'm intending on doing is taking 0-24000 time and just using an array between 0-24 18:49 MTDiscord it would also mean sky blending dependant on time_speed rather than framerate 18:49 MTDiscord since i run MT at 165fps 18:49 MTDiscord the transition periods last about a few seconds 18:50 sfan5 just make it somehow defaults to whatever sky colors we had before 18:50 sfan5 or rather an approximation of it 18:50 MTDiscord i was going to actually make a function that should it notice the presence of named sky variables 18:50 MTDiscord it'll fill the array up as intended 18:55 MTDiscord basically i'm removing all of the previously hardcoded sky features 19:00 MTDiscord if you use the current implementation, it'll just use the same six classic colours and the tints 19:00 MTDiscord the tints have had their colours moved to skyparams.h for consistency 19:07 macbuildguest Hello all, is someone out there like Jordash that can build a mac x86 dev mintest? 19:08 macbuildguest @Jordash 19:12 MTDiscord https://www.dropbox.com/sh/jt3el1tn6s1yc82/AADHR74Y1tEQDb9NKQh5Csu-a you mean these 19:20 MTDiscord sfan5, my checklist for an upgraded sky is: 19:21 MTDiscord user configurable aurora (including colour), rotating textured skybox (placed behind the regular one) 19:21 MTDiscord and a seccond one for having a local area effect 19:23 macbuildguest : ) I think so. Are these the latest? I have had changes to the mapgen settings kill a working worlds new generation (EG I think Installing and playing Hades game killed my new generation in Mineclone2)... I did a bit of reading and thought this may be a known bug and was hoping (though, I have no reason to be sure) that it has been addressed 19:23 macbuildguest in the latest dev. 19:24 MTDiscord current set the buildscript off 19:24 MTDiscord this may take a few minutes to become visible 19:27 MTDiscord linking AppleSilicon and x64 for BigSur+ 19:27 MTDiscord now building x64 for Mavericks 19:29 MTDiscord minetest-5.5.0-dev-e7b05beb7-Mavericks-Intel-LuaJIT now available 19:30 macbuildguest Thank you! I am x64 on bigsur so I should use the universal? 19:32 macbuildguest does that mean that universal is not using LuaJIT 19:37 MTDiscord if your machine is intel the mavericks one should be preferred 19:37 MTDiscord Rosetta may be fast 19:37 MTDiscord but it still loses to x64 JIT on an intel mac 19:38 macbuildguest Thanks again!!!! Side question: Anyone know how to make an existing world stop generating chunks that have only stone? :) 19:38 MTDiscord that's a mod problem that you may have installed from contentdb 19:40 sfan5 or a configuration problem, check the world creation dialog 19:52 macbuildguest Is the world creation dialog where you set parameters for a new world? How do I view that for an existing world? 19:52 MTDiscord you don't 19:54 macbuildguest :) That is what I thought... Is there a way to set/reset mapgen for existing world (editing text/lua?) 19:54 macbuildguest The mac build is working btw. 19:57 sfan5 map_meta.txt 20:27 MTDiscord you can find your minetest worlds in ~/Library/Application Support/minetest/worlds 20:28 MTDiscord Library is hidden from finder by default so press command + shift + . to reveal them