Time Nick Message 09:04 Krock y5nw: "would need to be considered different keys even if they get the same keycode" << this is already the case now. The key processing priorities are specified by `KeyCache::populate`. 09:06 Krock event.KeyInput.Char is the printable character and event.KeyInput.Key is not dependent on modifiers from what I can see. 09:09 [MatrxMT] Krock: I know. My point is that you would need to support a new case in addition to the existing one. 09:13 Krock y5nw: sorry, I do not understand what you mean by "a new case". In either way, it seems the only way to skip SDL_IME_ProcessKeyEvent would be to patch the program memory, which is beyond sanity. 09:14 Krock so going with scancodes is probably - after all - the best solution. 09:17 [MatrxMT] Krock: if we have / on shift-7 we would need to consider differentiating the "/"/Shift-7 key event from the event where you only press the "7" key (they would have different keychars but the same EKEY_CODE) 09:19 [MatrxMT] It's largely a secondary consideration though since it would be very hacky to work around IMEs already. 17:22 sfan5 particle collision detection seems to be weirdly inefficient 17:23 sfan5 (8% of the client run loop) 17:40 sfan5 add_area_node_boxes should really run block-wise 17:53 sfan5 might be costing 5-10fps 17:55 sfan5 (this is a scene with rain particles and it doesn't reach full fps even without, so any extra work is noticeable) 18:12 MTDiscord Particle collision detection could possibly be related to the incorrectly large particle bounding box, maybe? 18:16 sfan5 good idea, but it doesn't use that box 18:23 MTDiscord doesn't particle collision detection have the same performance problems as entity collision detection 18:24 sfan5 yes 18:24 MTDiscord okay, then it boils down to the fact that we're using an unnecessarily large bounding box rather than a ray with some margin and no spatial indexing for entities 18:25 MTDiscord the former we have PRs for, implementing the latter could potentially reuse selectionbox raycast code 18:25 sfan5 the box is the particle size 18:26 sfan5 if it's small enough sure we can use a ray 18:26 Desour collision adds 1 node length in each direction 18:26 MTDiscord hence why i'm saying "ray with margin" 18:26 Desour which is especially bad for small boxes, like particles 18:26 Desour (see `collisionMoveSimple`) 18:26 MTDiscord we have to add this margin because we allow large collision boxes 18:27 MTDiscord we could try to optimize for the common case of small boxes however 18:27 MTDiscord similar to what was attempted for raycasts 18:27 MTDiscord (but had to be reverted) 18:29 MTDiscord How come one of the glTF tests failed on MacOS for #15408? 18:29 ShadowBot https://github.com/minetest/minetest/issues/15408 -- Collision: more accurate computation with acceleration and long dtime by kno10 18:29 MTDiscord are you sure it's a gltf test that's failing? 18:29 Krock @josiah_wi It's probably again the biome test 18:30 MTDiscord yeah, most likely #15598 18:30 ShadowBot https://github.com/minetest/minetest/issues/15598 -- Random ARM macOS CI failures 18:30 Krock > Test assertion failed: biome->name == expected.name 18:30 Krock the glTF errors are intentional and good 18:30 MTDiscord Yep, it's the biome test. 19:55 sfan5 there are definitely a bunch of mods misusing use_texture_alpha 19:56 sfan5 if you bind skipping the transparent ClientMap render pass to quicktune you can see some perfectly opaque rails, door disappearing. also some untinted glass panes 21:04 sfan5 there are like two or three nested maps inside ItemStackMetadata, man 21:06 MTDiscord name and shame? if there mt-mods ones, can have those fixed pretty quickly 21:11 sfan5 advtrains, homedecor, ilights, pkarcs_doors3 21:14 MTDiscord ilights uses clip, should it not? as for homedecor its used across 22 files, would have to go through all of those i guess 21:16 sfan5 server mods may be outdated, idk. 21:17 sfan5 ilights:lights_on is in the transparent render pass. for no reason.