Time Nick Message 00:08 MTDiscord at this point, adding the tech debt of another server-sent-client-side-setting is miniscule and is vastly outweighed by the benefit of fixing engine bugs now and for the next several years until 6.0 00:40 MTDiscord SSCSM hopefully isn't gonna be a 6.0 thing; removing serverside APIs in favor of cleaner SSCSM APIs is what's gonna be a 6.0 thing 01:28 MTDiscord If you add each such feature with the miniscule debt as you say, it will grow eventually from the miniscule one up to the vast one some day is what the engine actually has now. And btw bad implemented APIs are generally error-prone, because it becomes harder to modify the existent code and orient in that (like the Irrlicht's animated meshes, their bones, mapblocks meshgen, generic cao, sounds handlers and multiple other parts), so it 01:28 MTDiscord could be explained by that why there's a such high bugs count 01:29 MTDiscord If you add each such feature with the miniscule debt as you say, it will grow eventually from the miniscule one up to the vast one some day is what the engine actually has now. And btw bad implemented APIs are generally error-prone, because it becomes harder to modify the existent code and orient in that (like the Irrlicht's animated meshes, their bones, mapblocks meshgen, generic cao, sounds handlers and multiple other parts), so it 01:29 MTDiscord could be explained by that why there's a such high bugs count 01:36 MTDiscord I think you're right in that this is definitely technical debt. But I would disagree about whether it is worth going into this particular technical debt. 01:36 MTDiscord Technical debt is incurred for much the same reasons as real debt: Because you need the money not sometime in the future, but now. 01:37 MTDiscord We want to deliver some important features to game developers that need them now. 01:37 MTDiscord And sometimes that means going into technical debt, despite knowing that a much better solution will eventually exist using SSCSM, the formspec replacement, or similar, because we don't want to wait on that. 01:38 MTDiscord I agree that at the same time, we must not lose sight of the bigger goals however. 01:40 MTDiscord But I think the technical debt incurred here is low interest. It isn't the spaghetti kind where everything is intertwined, a hydra where for each bug you fixed, two new bugs pop up. It's just one relatively nicely separated API feature that does a particular thing. It will require some work when a proper feature is implemented in the future, but it shouldn't be nearly as messy as e.g. skeletal animation. 07:41 MTDiscord Do the important features, I just expressed my opinion here because I saw the potential hazard in making such decision which the community has already actually stumbled upon with. 07:47 MTDiscord Under the technical debt I meant you refuse to do a proper long-term API now in swap to the simplicity and quickness of the implementaion and thus you auto get the debt in the form of the necessity of the refactoring such APIs afterwards waiting for them the dependencies like the SSCSM 08:19 rubenwardy Waiting for the long term solution only works if the long term solution actually happens 14:41 SFENCE According to ObjectLabel function problem. I get an answer, and looks like it is a problem on our side. 14:42 SFENCE Interactions with OpenGL ES 14:42 SFENCE This extension specification uses non-suffixed names for new entry points, types, and tokens. This is correct for implementations against OpenGL. However, when implemented in an OpenGL ES context, all new entry points, types, and tokens are given KHR suffixes. 14:42 SFENCE Cite: https://registry.khronos.org/OpenGL/extensions/KHR/KHR_debug.txt 14:43 SFENCE So, we are loading glObjectLabel for GLES also. But for GLES we should load glObjectLabelKHR. 15:22 sfan5 hmm 15:46 SFENCE Verified that switching to glObjectLabelKHR fixes a problem. May I do separata PR for this, or keep it as part of #15451? 15:46 ShadowBot https://github.com/luanti-org/luanti/issues/15451 -- Make Luanti buildable for iOS (iPhoneSimulator). by sfence 16:35 sfan5 separate PR is good 18:03 sfan5 @zughy can you test #15829? 18:03 ShadowBot https://github.com/luanti-org/luanti/issues/15829 -- [no sq] Fix shadow performance regression due to force update by sfan5 18:03 sfan5 (i'm too lazy, sorry) 18:47 [MatrxMT] on it 18:57 [MatrxMT] sfan5: it works, thank you 19:03 sfan5 great 19:13 SFENCE ObjectLabel fix #15830 19:13 ShadowBot https://github.com/luanti-org/luanti/issues/15830 -- Fix ObjectLabel OpenGL ES issue. by sfence 22:33 MTDiscord can I have a review on #15567, please? 22:33 ShadowBot https://github.com/luanti-org/luanti/issues/15567 -- [no sq] Implement player:get_point_dir() and player:get_point_screen_pos() by grorp 22:38 MTDiscord I recently split the first commit (refactoring stuff) off into #15800 to make it easier to get reviewed, but tbh I think the original PR is not big enough to justify that (+201, -71 lines) 22:38 ShadowBot https://github.com/luanti-org/luanti/issues/15800 -- TouchControls: touch_use_crosshair, dig/place simulation refactoring by grorp 22:39 MTDiscord so I would be more happy if someone could just review 15567 23:06 MTDiscord actually, new idea: planning to merge #15800 with 1 approval rule thing later 23:06 ShadowBot https://github.com/luanti-org/luanti/issues/15800 -- TouchControls: touch_use_crosshair, dig/place simulation refactoring by grorp