Time Nick Message 12:33 MTDiscord Are people already aware of the attachment regressions that happened sometime after 5.3, or do I need to file a bug for them? I tried searching GH and didn't find anything, but I also know that I'm bad at guessing the correct search terms... 12:34 sfan5 first time I hear of anything like that 12:35 MTDiscord IIRC I first observed the bug in 5.0: when a player with attached entities traveled outside your loaded area, then back in, entities attached to their body became detached and would remain hovering at the place where they became loaded instead of following in around that player's body. 12:36 MTDiscord They were finally fixed in like 5.1 or 5.2 by hecks who had to do some kind of ridiculous exhaustive search of parameters for the things because attachment behavior is apparently insanely fragile... 12:36 sfan5 oh that, don't think that's new 12:37 MTDiscord Er, no wait, maybe hecks fixed the jiggling attachments bug, and maybe it was SmallJoker who fixed the coming undone bug? 12:37 sfan5 possibly 12:38 MTDiscord Either way, it was working perfectly in at least 5.3, and I think it was very good (minor/cosmetic issues only) in 5.1 and 5.2. Now it's back to sometimes-entirely-broken in at least the last version of 5.5-dev before the irrlicht fork hit, since I can no longer build MT as-is and haven't had time to go through the work of setting up w/ the new irrlicht yet. 12:39 MTDiscord I think it MAY be broken in 5.4-release, but it's one of those annoying heisenbugs that only breaks when not being observed by somebody who can actually do anything about it. 15:21 MTDiscord Yeah nah I’ve been seeing that too 15:23 MTDiscord Worked fine between 5.4 15:24 MTDiscord However I have a feeling it’s active object range sending having fun 16:53 MTDiscord interesting, there is ugly warnings on irrlicht strings 16:53 Pexin I have fairly technical question about the UnknownKeycode exception currently defined entirely in keycode.cpp 16:53 Pexin I can move the class declaration to the .h file, OR I can add try+catch inside the existing keyname_to_keycode() which may slow input processing on touchscreens. 16:53 Pexin Anyone know if there's a particular reason it isn't declared in .h already? 16:57 MTDiscord it's not in header in order to prevent exposure, originally, i think 16:58 Pexin exposure from..? 17:00 MTDiscord other c++ code 17:00 MTDiscord sfan5: nice with irrlicht 1.9 fork used all my keys are working properly in inputs ? 17:00 Pexin like to prevent a name conflict? 17:00 MTDiscord nop, to prevent direct use 17:01 MTDiscord it's just a way to hide objects to prevent using it in wrong places in code 17:01 Pexin well I need to use it, so I dont know whether to make it publically accessible or risk (possibly) bogging down touchscreen users 17:02 Pexin well, or i could just write an extra wrapper function 17:17 sfan5 moving the exception to the header file should be fine 17:17 Pexin sfan5: ok, thanks 17:20 MTDiscord sfan5: i'm looking if we can put all irrlicht_changes folder inside irrlicht direct 17:20 MTDiscord it sounds possible but some parts are tied to minetest utils. Which mean we may push utils to irrlicht, for some functions 17:21 MTDiscord EnrichedString is the one blocking me currently. I'm thinking about changing it to an interface 17:21 MTDiscord this will be the proper thing i think 17:21 sfan5 since many are tied with MT I don't think it makes sense to move all of them 17:22 MTDiscord no, but CGUITTFont is clearly a good candidate 17:22 MTDiscord i'm thinking about MT generics, not the MT specifics 17:22 MTDiscord i mean for example no interest to push rendering logic etc ? 17:30 MTDiscord hmm it should be trickier haha 17:30 MTDiscord will retry with more vanilla export then 17:35 MTDiscord sfan5: how we ask users on devel branch to update ? they must update both irrlicht & minetest at the same time right ? if they forgot one it's not fine, right ? 17:36 sfan5 during development users should just do both 17:36 MTDiscord okay perfect, here is one trivial one: https://github.com/minetest/irrlicht/pull/20 17:36 sfan5 when it comes to releasing we can bump the revision number in irrlicht and check that inside mt 17:37 MTDiscord its friend is there: https://github.com/minetest/minetest/pull/11090 17:37 MTDiscord this file can be safely owned by irrlicht ? 17:40 MTDiscord ah yeah obviously without merging irrlicht the minetest build fail ? 17:44 MTDiscord merging #11089 17:44 ShadowBot https://github.com/minetest/minetest/issues/11089 -- Drop old text input workarounds by sfan5 18:36 sfan5 ty 20:33 Krock *ahem* will merge #11007, #11017, #11038 and #11064 in 10 minutes 20:33 ShadowBot https://github.com/minetest/minetest/issues/11007 -- Scale mouse/joystick sensitivity depending on FOV by ryvnf 20:33 ShadowBot https://github.com/minetest/minetest/issues/11017 -- Check for duplicate login in TOSERVER_INIT handler by EliasFleckenstein03 20:33 ShadowBot https://github.com/minetest/minetest/issues/11038 -- Builtin: Italian translation by Zughy 20:33 ShadowBot https://github.com/minetest/minetest/issues/11064 -- Builtin: Make join/leave messages, and /profiler messages translatable by Wuzzy2 20:42 Krock merging 20:43 Krock nerzhul: duplicate in "TOSERVER_INIT" was possible because the other check was performed much later 20:46 Krock done 21:13 Pexin should I be worried that github threw a list of failed checks at me when i submitted my PR? that can't be normal, right? 21:14 sfan5 yes