Time Nick Message 16:45 Krock Kind reminder that a meeting in 1h 15min. There was none last week, hence repeating now according to the reactions on GitHub 17:59 Krock ping nrz rubenwardy sfan5 ShadowNinja 17:59 sfan5 hi 17:59 Krock hello! no hurries. just pinging to make sure :3 17:59 nrz hi, i should put children to bed but i'm there async ? 17:59 ShadowNinja o/ 18:00 Krock Half a year has passed since the last meeting, so it might make sense to check what's needed for the next release 18:01 Krock I might be wrong about that half year though. it's just the last team meeting mentioned on github :) 18:02 Krock so we're at 1000 open issues again. this is fine ? 18:03 nrz i don't understand how it's possible regarding the amount of bugfixes done on this milestone ? 18:04 MTDiscord But numbers of open irrlicht issues are consistently going down which is fun to watch. 18:04 Krock fun? more like relieved. 18:04 nrz not fun, it's just the work accomplished by forking has reached his goal 18:05 Krock There does not seem to be much special in the milestone tbh. It's PRs that are needed for most points 18:06 Krock Also #6765 was added back in to improve light calculations, from what I can see. The PR looks alright, and only needs testing? I could do that. 18:06 ShadowBot https://github.com/minetest/minetest/issues/6765 -- Add more neighbors on mesh update by numberZero 18:06 Krock although I wonder whether this feature will ever be used 18:07 rubenwardy Here 18:07 Krock hello :) 18:07 Krock light artefacts or glitches are not that common any more, and barely anyone might care about this setting 18:07 Krock hence using the "simplified" version forever 18:08 Krock rubenwardy: do you remember why this PR was added to the milestone? 18:08 rubenwardy I don't 18:10 Krock too bad. it's really something that would best fit into performance optimization tweaks 18:10 Krock however since this PR defaults to performance, it might be unused forever. hence I don't see much of a point to keep it as milestone tbh 18:11 Krock 14% more CPU cycles when the PR is enabled, according to Rixer 18:11 Krock *Fixer 18:14 Krock commented. 18:14 sfan5 the glitches are common, just situational 18:15 Krock they look weird indeed. so correct visuals as baseline would be optimal, where performance-focused people would tweak the setting 18:15 Krock I guess that's the fair trade-off to fix this issue but still provide tweaking potential 18:16 sfan5 we would have a thousand settings if that was done consistently 18:17 Krock right. for such things it would more make sense to have a single setting to switch between performance, balanced or "correct" behaviour 18:17 Krock or well 18:17 sfan5 yeah that'd be possible 18:18 Krock or numeric: performance_tweak = 0 for the most correct, and performance_tweak = 100 for glitchy but fast gameplay, as percentage perhaps 18:19 sfan5 I'm okay with a single boolean setting for this; that could perhaps then be enabled by default on Android where performance matters a lot 18:19 sfan5 only 0.001% players would ever toggle it manually 18:22 Krock makes sense, yes. 18:24 Krock Next: #11040 - this looks like a generic tracking list for continuous Irrlicht workaround deprecation or fixes 18:24 ShadowBot https://github.com/minetest/minetest/issues/11040 -- Revisit Irrlicht workarounds 18:25 Krock is this a mandatory milestone for 5.5.0? 18:25 Krock i.e. important? 18:26 Krock anyway. it can be kept in the milestone. PRs might come or not; does not really matter 18:27 sfan5 it's not mandatory 18:27 sfan5 will probably become relevant anyway when hecks brings his opengl rewrite 18:27 Krock yes, right. 18:27 specing have you thought about cooperating on the engine with supertuxkart (who I'm told are also using irrlicht)? 18:28 Krock yes, they also have their own, heavily modded irrlicht framework 18:28 nrz specing, we talked about this 4 years ago and it was heavily modified for their needs then i think now... 18:28 nrz ? 18:28 Krock cooperation would be an interesting approach, but someone would have to ensure they still somehow offer the features we need 18:29 specing nrz: alright 18:29 nrz Krock: i'm not sure it's possible now, except if we can make some parts modular to have common effort 18:30 nrz ie. the input part 18:30 specing I personally do not like the engine fracturing of the foss world, because it ultimately reduces the manpower available per engine and thus features 18:30 specing and then I get told that foss games look like they're from 2000 18:30 Krock and a decision on which version control to use. I believe they have the framework within their SVN tree 18:30 nrz specing: the foss game look like is more than there is near zero graphist people doing FOSS 18:31 nrz SVN = beuark 18:31 specing nrz: graphics as in graphics stack coding or graphics as in artists? 18:31 nrz you said games looks like 2000, then i talk about artists ? 18:32 specing nrz: you talked about "graphist people" 18:32 nrz yep sorry i don't have the english terms for that ? 18:33 specing There is an artist who has his own libre first person shooter (that looks like its from 2015+) 18:33 specing based on Torque3D 18:33 specing He said that all other engines are garbage :P 18:33 Krock it would be great if the patches could be backported to the original repository but tbh sourceforge is a PITA, including SVN 18:33 Krock for now it's much easier to do our own thing in a separate project 18:34 specing I don't personally mind the "garbage looks" (I'm playing a zdoom-based game right now), but it does limit me when I'm trying to promote libre games to people outside the foss world 18:35 Krock Next: #11466 - I assume you're still busy, rubenwardy ? 18:35 ShadowBot https://github.com/minetest/minetest/issues/11466 -- Use scoped app storage on Android by rubenwardy 18:35 specing where the graphics is a sore thumb 18:35 Krock the earlier it's merged, the better, I suppose. however, there were a few suggestions which might be worth considering 18:35 MTDiscord Most of graphical garbage comes from low-quality textures and models. You can have great looking games with FOSS engines when you know what youre doing with art. 18:36 MTDiscord Unfortunately FOSS communities arent known for attracting a ton of artistic talent .. good art isnt cheap to make (effort-wise) 18:37 MTDiscord tl;dr dont blame the engine for 2000s-looking graphics 18:38 Krock nrz: do you have any opinion on #11014? Otherwise it looks like it's going to be closed 18:39 ShadowBot https://github.com/minetest/minetest/issues/11014 -- Send only relevant ItemStack meta fields to Client by EliasFleckenstein03 18:39 specing Well sure, but then again... can FOSS engines handle 2020 artwork? 18:39 MTDiscord The year doesnt determine how many polygons art has 18:39 Krock for being the wrong approach. I do like the concept, but the way/implementation really ins't that great 18:40 MTDiscord Just because UE5 wants to cater to artists that think trillions of triangles is an acceptable tradeoff doesnt mean thats how it should be done 18:43 Krock @GreenXenith However there's a vertex limit within Irrlicht I think 18:44 Krock overly complicated models cannot be loaded into Minetest 18:44 sfan5 Irrlicht does no have non-indexed rendering and indexes can only be u16 18:44 sfan5 so 64k 18:44 Krock ah okay. thanks. 18:44 MTDiscord Oh, im not saying irrlicht is a good engine in any way 18:44 sfan5 should also be moot with the opengl rewrite/redo 18:44 MTDiscord It definitely has awful technical limitations due to poor implementation 18:44 Krock just wanted to mention that for the sake of completion 18:44 nrz why are we diverging about irrlicht engine ? we are talking about releasing ? 18:45 Krock nrz: just processing the open points on the milestone and wiki/meeting points 18:45 Krock there's still many issues open in the milestone, hence I doubt a release comes anywhen soon 18:45 nrz yeah but complains aboutr irrlicht is not good is not the point of the meeting ? 18:45 nrz we do with what we have currently 18:45 Krock however, there should be a release in November to update the Play Store apk 18:46 nrz and it's sufficient for MT currently, we don't need modern engines features for our voxel game 18:46 Krock right 18:46 MTDiscord what voxel game 18:46 MTDiscord MTG isnt supposed to be the standard any more 18:46 sfan5 Krock: earlier would be better, but that release would be based on 5.4.1 anyway 18:46 sfan5 @GreenXenith devtest ;) 18:47 MTDiscord Ok fair but that definitely shouldnt be what you base features off of :] 18:47 Krock I'll just randomly assign 16 October. Let's see that the milestones are in a good shape by then 18:48 Krock and even if not, it should be a reminder to set priorities 18:48 Krock because "roughly august" is definitely over 18:49 Krock and there's still visual issues due to the dynamic shadow PR which should be resolved by then 18:49 specing Heh. So you say that you can't get artists and then an artists tells me that all foss *engines* are garbage. I guess you could use this fork to bring irrlicht or whatever you make of it on par with 2020 commercial engines 18:49 specing (minus torque3d, it was acceptable they said) 18:50 sfan5 Krock: well there's a few things blocking release; hecks OpenGL rewrite is pretty much a requirement 18:50 * specing suspects that there will be barely enough manpower to maintain it at T-20years level 18:51 Krock sfan5: to be fair, Minetest is still playable 18:51 sfan5 alternatively we could work around or individually fix the issues to get 5.5 out 18:51 Krock it surely would be nice to have that 18:51 sfan5 yes 18:54 sfan5 #11365 are #11206 release blockers for me (the android stuff can be solved separately) 18:54 ShadowBot https://github.com/minetest/minetest/issues/11365 -- Shadowmaps can not be disabled by the server 18:54 ShadowBot https://github.com/minetest/minetest/issues/11206 -- spritesheet support of sprite entities stopped working 18:54 sfan5 so we'd either need to somehow fix these so that 5.5 can be released in an acceptable state 18:54 sfan5 or wait for the opengl rewrite to fix both 18:56 Krock noted. 18:56 nrz why opengl rewrite is a requirement ? 18:56 sfan5 to disable shadowmaps shaders need to be able to be swapped out at runtime, our current system makes this impossible 18:57 sfan5 the second issue would probably be fixed "by accident" when that code is rewritten 18:57 nrz it's a new features added on this release cycle ? 18:57 sfan5 yes 18:57 Krock there's also a few workarounds in the code that could be removed afterwards (if addressed by the rewrite) 18:57 sfan5 the other option is to disable shadowmaps in the release version 18:57 sfan5 (and fix the other issues by manual investigation) 18:58 sfan5 like Krock already said releasing 5.5 would be nice because it has so many improvements so far, but I'm not sure which path we want to take 18:58 Krock I mean, the dead simple solution so far would be to remove the main menu dropdown for shadowmaps 18:58 nrz ok there is some bugs to fix, but do we have blockers ? 18:58 celeron55 disabling shadowmaps by default and allowing it to be enabled from advanced settings (not the main settings page) came to my mind also 18:59 sfan5 well yes I just named two 18:59 Krock and default to "off" so that manual modification is needed to test them, including all its resulting bugs 18:59 nrz we can disable it with an option 18:59 nrz and let people test it with a expert setting ? ? 18:59 Krock celeron55: you ninja'd me :3 18:59 nrz lol same 18:59 sfan5 if we allow users to enable them in the default config game authors will still yell at user over having no control 19:00 Krock well. it's not their fault 19:00 sfan5 s/user/us/ 19:00 sfan5 so if this is done I think the better alternative is to really disable them inside the code 19:01 nrz compile time option then,, ? 19:01 sfan5 no option at all 19:01 celeron55 it would go against our principles, yes, altough we don't really have guidelines for experimental features 19:01 sfan5 if people want shadows they can download a dev build 19:01 Krock nrz: more like replacing g_settings->getBool() with false 19:01 nrz then just go ahead 19:01 Krock where the setting is checked 19:02 nrz and move setting to advanced mode and change label to prefix with [EXPERIMENTAL] ? ? 19:02 Krock ^ if we allow users to enable them in the default config game authors will still yell at us over having no control 19:02 sfan5 we released an experimental feature with no way to disable it once (CSM) and look where that got us 19:03 Krock that's a point. even if I don't understand the game author's problem - really - it might be best to disable it entirely 19:03 nrz i don't understand why game author will complain ? what is the issue ? if people break their shadows on their client, it's their problem no ? 19:03 sfan5 https://github.com/minetest/minetest/issues/11365 19:03 nrz with a CSM feature is required for shadows ? 19:03 Krock !title 19:03 ShadowBot Shadowmaps can not be disabled by the server · Issue #11365 · minetest/minetest · GitHub 19:03 celeron55 nrz: the people who break the games with shadows will complain to the game authors 19:03 celeron55 which is a problem for the game authors 19:03 Krock ,... and that because they forgot that shadow maps are experimental 19:03 sfan5 anyway I guess I should create an issue so the possibility to hot-fix + release 5.5 instead of waiting can be properly discussed and consensus reached 19:04 nrz people will commplain about rendering issues on shadows to game owners ? they don't see the distingo between the client and the game ? ? 19:05 celeron55 my vote is on permanently disabling shadowmaps in the release, because there's no minimum release interval and a next release with shadows can be made at any time when it's actually ready 19:05 Krock nrz: don't set your expectations on users too high. 19:05 nrz don't put a CSM flavour for this setting, shadows have no sense to be disabled by servers owners 19:05 nrz Krock: sorry i have some hope ? 19:06 sfan5 games will need to be able to be disable shadowmapping, thereforce server owners can automatically do it too 19:06 sfan5 therefore* 19:06 MTDiscord people also complain when there local settings breaks a game because client settings override ones mods/games set 19:06 Krock nrz: I also don't think this server->client enforcement is needed, but better safe than sorry. disabling in C++ seems to be the go-to. 19:07 sfan5 anyway what about the meeting points 19:07 sfan5 is that all 19:07 celeron55 the thing is, the enforcement is not _really_ needed at this time, but we have to set a precedent in game authors having control over graphics 19:07 specing nrz: on the contrary, please put a csm restriction for this, it gives people more incentive to use better clients :P 19:07 Krock I'd like to know whether #11014 and #11274 should be closed 19:07 ShadowBot https://github.com/minetest/minetest/issues/11014 -- Send only relevant ItemStack meta fields to Client by EliasFleckenstein03 19:07 ShadowBot https://github.com/minetest/minetest/issues/11274 -- Fix: automatic selection / deselection of dependent mods at world configuration by kuklinistvan 19:08 sfan5 I vote close for both 19:08 Krock former for bad implementation, latter for overly complex 19:08 Krock objections? 19:08 nrz if you put that on CSM restriction, then why not all settings ? haha 19:08 nrz nop 19:11 Krock if anyone's got some time, please feel free to test #11445. It's a minor bugfix. I don't remember why I put that into the meeting points 19:11 ShadowBot https://github.com/minetest/minetest/issues/11445 -- Player death: Fix item duplication by SmallJoker 19:12 Krock joystick controls were merged. done. that's good. 19:12 sfan5 I think moving the callback to the end of the server step isn't a good solution, but I don't have a better idea 19:13 Krock well I also thought of other solutions, but doing this async in the server step seems to be the only solution 19:13 Krock because API calls might be nested in various weird ways 19:14 sfan5 though: if player death is delayed are there things that could happen after the player is alreay dead but before the callback is called? that would violate expectations a lot 19:14 sfan5 thought* 19:15 Krock on_use cannot be called by dead players, if you meant that 19:15 sfan5 no but literally anything 19:15 Krock hmm 19:16 Krock it might be possible to move the death handling code after the callback run 19:17 sfan5 http://sprunge.us/7HmteK?lua engineered example but should explain my concern 19:18 Krock oh yes! you're totally right 19:18 Krock I'll have a look at it again soon. Thanks for the input 19:18 sfan5 good luck with a solution, I couldn't think of one yet 19:18 Krock especially because do_something could be called within on_use too 19:19 Krock which exactly causes this logical problem 19:19 sfan5 next one #11367 19:19 ShadowBot https://github.com/minetest/minetest/issues/11367 -- New move code: Only snap to collision box only on fall by SmallJoker 19:19 sfan5 in principle okay IMO but I have somewhat liked to jump up to nodes with sneak pressed and snap to them in the past 19:19 Krock right. I'd like to know whether this could possibly break any mechanics 19:20 sfan5 if it's meant to fix noclipping another solution can surely be found 19:20 Krock you'll still snap, except only when going down 19:20 sfan5 for example instead of literally modifying the position modify the player velocity to keep them on/towards the edge 19:20 sfan5 that way collision detection would still apply 19:21 sfan5 (I don't know what the sneak code currently does) 19:21 Krock short: it checks for the nearest collision and snaps to its largest bounding box 19:21 sfan5 snaps the position right? 19:22 Krock yes. no velocity or acceleration involved. 19:22 sfan5 sounds bad 19:22 celeron55 i also use the sneak when jumping "glitch" to snap to surfaces upwards 19:23 Krock move_to could be used to make this movement smoother, which then again makes it more sluggish 19:23 Krock agh. move_to does not exist on localplayer 19:23 celeron55 (with knowing it was never intended to work that way) 19:24 Krock celeron55: so the correct approach in your opinion would be to snap... when? 19:25 celeron55 the correct approach is probably to snap only when falling, but it does change the movement feel once again 19:25 Krock yes right. either the issue is fixed with a slight movement change, or it's open forever with this special snap behaviour 19:25 celeron55 it's somewhat likely nobody is dependent on that behavior though, as the only capability it gives is being able to do certain movements a bit faster 19:27 sfan5 *googles "minetest speedrunning"* 19:28 sfan5 semi-related: I'm still bothered by the unconditional upwards camera smoothing that was added in 5.2.0 to cover up some sneak-related(?) thing that was deemed too bad 19:29 Krock right. I also remember one PR which made the movement feel a bit more sluggish 19:30 Krock though I thought it was a PR for regular jumping and/or staircase walking, and not sneak 19:30 sfan5 oh yeah right, not sneak 19:30 sfan5 staircase was it, it's not meant to apply to regular jumps (IMO) 19:32 Krock https://github.com/minetest/minetest/pull/10025 19:32 Krock !title 19:32 ShadowBot Apply camera smoothing to 'not touching_ground' stepheight by paramat · Pull Request #10025 · minetest/minetest · GitHub 19:32 sfan5 yea 19:33 Krock I really don't know any more. it's been too long since this PR. it might be worth to have a look at it once more again 19:33 sfan5 I tried to make it not apply to regular jumps once but failed :( 19:34 Krock it might help to preserve and check against the step_up variable 19:34 Krock or to forward this information to the collision information 19:35 sfan5 if I remember correctly I even tried that but the step_up information disappears to fast to appear any useful smoothing 19:35 Krock that aside; I don't have any other meeting points. 19:36 sfan5 I have two things I'd like to mention 19:36 sfan5 #11550 <- reviews plz 19:36 ShadowBot https://github.com/minetest/minetest/issues/11550 -- Dynamic_Add_Media v2 by sfan5 19:36 sfan5 and #11545 19:36 ShadowBot https://github.com/minetest/minetest/issues/11545 -- animated particlespawners by velartrill 19:36 sfan5 it'd be nice if someone else with an opinion could look at it and give feedback 19:37 Krock I can give a shot at the dynamic media PR. I haven't used this feature yet, hence might run into a few questions 19:38 sfan5 oh and also there are 5 PRs with "Roadmap: Needs approval" overdue, these should be closed if we can determine that they have been considered by one or two devs IMO 19:38 MTDiscord if certain pull requested are being asked to be looked at, could https://github.com/minetest/minetest/pull/11130 be looked at as well? (already has one approval) 19:39 sfan5 I'm the obvious target for looking at that again, I'll get to it eventually... 19:39 sfan5 next on the meeting list would be to look at https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+label%3A%22One+approval%22 and consider for merge 19:40 MTDiscord i like how one of those has possible close on it 19:40 MTDiscord https://github.com/minetest/minetest/pull/8448 i assume since rebased that can be removed? 19:41 sfan5 yea 19:43 sfan5 *crickets* 19:44 Krock currently checking the roadmap prs 19:45 sfan5 sure, say when you're ready (also ping nrz) 19:45 MTDiscord also, random question, minetest_game is in "maintenance mode/no new features", but for all intents and purposes is abandoned(looking at core dev involvement in issues and PR's). is this intended? 19:45 sfan5 good question 19:46 Krock it's a bit abandoned. I'd spend more time there if I had more time and motivation. it's really not supposed to stall 19:46 sfan5 I would do something once in a while if the rules wouldn't prevent me from doing so, two approvals are still required 19:46 Krock at least in terms of bugfixes 19:46 sfan5 maybe that can be relaxed to "do whatever, consult with coredevs for bigger changes" 19:46 MTDiscord ^ninja'd 19:47 nrz cannot we have new maintenainers for official default game to add more features ? ? 19:47 MTDiscord make we MTG maintainer and modlib will rise 19:47 nrz i'd like to see coherent things like achievements (there is a nice mod for that) or more inside it ? 19:47 MTDiscord s/we/me 19:47 sfan5 it was decided that MTG should receive no new features 19:47 sfan5 I would also like to see it improved which is why I considered forking it but that requires time 19:48 sfan5 the current development approach and lack of direction is not sustainable in any case, which is why freezing it was a good decision (IMO) 19:48 nrz but why no new feature ? because no more coredev involved on it ? 19:48 sfan5 one point is what I just mentioned, https://github.com/minetest/minetest_game/issues/2710 has the entire discussion 19:48 nrz maybe we can discuss with community famous people to build a new team outside of coredevs with a good direction ? ? 19:49 sfan5 sounds worth exploring 19:49 MTDiscord The problem I see that MTG is pretty bland - it is supposed to be that way, kind of a modding base - and there's little interest in developing bland stuff. 19:50 MTDiscord Mod developers are opinionated. They'll want combat, fancy mobs, and lots of other things that are out of scope for MTG. 19:51 nrz yes, mobs in mtg is always what i asked mtg devs to add 19:51 nrz but we have no real good engine for it 19:51 MTDiscord True 19:51 sfan5 if big features had realistic chances at getting merged instead of being left lying around too long I'm sure there would be more contributions to MTG 19:51 MTDiscord Entity support in Minetest is a mess 19:51 nrz i think rethinking the base on mtg close to MT can show the lack of core features for it 19:51 MTDiscord Which is a shame because entities must be used for most interesting things 19:51 Krock agh. I really don't know what to say about those "Roadmap: Needs approval" PRs. they are kind-of okay I guess? 19:52 sfan5 I don't disagree but if "kind-of okay" is the standard we end up with too many open PRs again 19:53 nrz also rubenwardy idea about bow is pretty nice, but for that we need better entities, i think more specialiazed entities types i think ? 19:55 MTDiscord We probably need acceptable entity performance first of all 19:55 MTDiscord my two bent pennies, but seems the realistic options are "do whatever, consult with coredevs for bigger changes" or clean through issues/pr's for 5.5, do a last release and then archive the repo 19:56 sfan5 @luatic which specific issue are you referring to? 19:56 MTDiscord I was replying to nrz 19:56 sfan5 yes but I'm wondering which part of entities do you think performs badly 19:56 MTDiscord get_objects_inside_radius 19:56 MTDiscord IIRC also too many drawcalls, but don't quote me on that 19:57 nrz unfortunately, i already studies this call and we cannot do better 19:57 MTDiscord We very much can optimize get_objects_inside_radius! 19:57 nrz i already improved it with profiler in the past, but we cannot really do it better 19:57 nrz if you have ideas, please PR then ? 19:57 sfan5 those are good points, for the latter you could more specifically note the lack of occlusion 19:57 MTDiscord Not if we continue using a linear search 19:58 MTDiscord nrz: My C++ is too weak 19:58 nrz then how can you said we ccan do better ? :p 19:58 sfan5 a solid data structure proposal is more important than the C++ impl 19:58 MTDiscord I was hoping libspatial could to the job for me, but can't find any proper docs 19:58 MTDiscord do* 19:58 nrz sfan5 for mob entities you mean ? 19:58 sfan5 nrz: for storing entities on the server in a way that they can be searched faster 19:59 sfan5 @luatic been there done that https://github.com/sfan5/minetest/tree/spatialent 19:59 nrz tbh, on my mangos experience (wow server), it was just a hashmap and it was sufficiently fast to have 1000 players and thousands of NPCs loaded in meory working 19:59 MTDiscord sfan5: and how did it turn out? 20:00 sfan5 there's a bug somewhere because it eventually segfaults 20:00 MTDiscord fix the damn pathfinder 20:00 sfan5 I didn't do any serious enough measurements to say anything about perf 20:00 nrz the only optimization we may do is to have per mapblock search, but if we do that you will need mapblock traversal for entities 20:00 sfan5 @ElCeejo it's fixed, open a bug otherwise 20:01 nrz or we should implement like Minecraft, map sectors 20:01 nrz and entities are owned by sectors not by the whole map, but hoenstly i don't see what kind of entity search you mean 20:01 MTDiscord I see you used an R-tree. I'm not quite sure whether that is the right tree as long as you're only concerned about points. 20:01 nrz except get_objects_in_radius 20:01 MTDiscord Oh I would open a bug about the pathfinders blatant incompetence but it would be buried beneath a pile of other bugs 20:02 MTDiscord 3d pathfinding is HARD 20:02 sfan5 @ElCeejo if you not interested in constructive actions to improve the situation please refrain from commenting 20:02 sfan5 +are 20:02 MTDiscord Most pathfinders do it node-based, which is actually pretty wrong. 20:02 MTDiscord Node collisionboxes may have holes, may be larger than one node, etc 20:02 MTDiscord Which means you can't just say "this node is penetrable" "this one's not" 20:03 sfan5 taking facedir into account would go a long way wouldn't it? 20:03 MTDiscord And then the entity collisionbox isn't a point either. Most pathfinders assume points though. 20:03 MTDiscord 3d pathfinding is indeed difficult, but even I can make a pathfinder that's useful for any box larger than 1 node 20:03 MTDiscord but it has to be lua-side which is very sub-optimal 20:04 sfan5 maybe you could contribute your implementation then if it's better 20:04 MTDiscord sfan5: It wouldn't, if you had a real spatial non-node based pathfinder. You'd first render the collisionboxes of all nodes (I can do that in plain Lua already using modlib). But the next step is the hard one. 20:04 MTDiscord I would love to contribute my implementation but it's in lua 20:04 MTDiscord At least in 3D. In 2D it can be done pretty fast. 20:05 MTDiscord Ceej: Stop whining, Lua isn't all that slow. It's a constant factor in the end. Maybe start optimizing complexity? 20:05 MTDiscord My pathfinder is by no means slow, but it's not as fast as it could be if it were done engine side 20:06 sfan5 "contribute implementation" could also mean that someone is willing to pick it up and port it C++ 20:06 MTDiscord Also sfan5, IIRC there's an R-tree which takes velocity into account, so you wouldn't have to update all moving entities every step. 20:07 MTDiscord Yes, TPR trees. The lib implements them too. 20:08 sfan5 is it really that helpful when velocity can (and does) change every step too? 20:09 MTDiscord No, not really. It's only really helpful if velocity remains mostly constant. 20:09 MTDiscord Shouldn't have forgotten about gravity. 20:10 sfan5 Krock, nrz: ping for https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+label%3A%22One+approval%22 20:10 sfan5 #11592 bugfix, mergable 20:10 ShadowBot https://github.com/minetest/minetest/issues/11592 -- Fix movement in random_input mode by NeroBurner 20:10 sfan5 #11498 feature, mergable IMO, waiting on a change 20:10 ShadowBot https://github.com/minetest/minetest/issues/11498 -- Add embedded PNG texture modifier by hecktest 20:10 sfan5 #11466 waiting 20:10 ShadowBot https://github.com/minetest/minetest/issues/11466 -- Use scoped app storage on Android by rubenwardy 20:11 MTDiscord Oh gosh can we please kill the atrocious texture modifier format? 20:11 sfan5 1) no, because backwards compatibility 2) better proposal please, there's an issue for it 20:11 sfan5 #11429, #10810, #10796 haven't looked at it, probably okay 20:11 ShadowBot https://github.com/minetest/minetest/issues/11429 -- Add no_texture.png as fallback for unspecified textures by Wuzzy2 20:11 ShadowBot https://github.com/minetest/minetest/issues/10810 -- Split liquid_viscosity to liquid_viscosity and move_resistance by Wuzzy2 20:11 ShadowBot https://github.com/minetest/minetest/issues/10796 -- Chop game background by appgurueu 20:11 sfan5 #10729 feature, mergable, missing a review 20:12 ShadowBot https://github.com/minetest/minetest/issues/10729 -- Allow Enabling The Touch UI In A Desktop Build by TheBrokenRail 20:12 sfan5 #10431 replacement merged, close this? 20:12 MTDiscord sfan5: Yeah I made that issue. 20:12 ShadowBot https://github.com/minetest/minetest/issues/10431 -- Fix long infotext letter cutoff, add ellipsis by Wuzzy2 20:12 sfan5 oh, if discord nicks weren't so weird I would know who I'm talking to 20:13 MTDiscord Would love it if 10796 finally got off my virtual chest. It's such a small PR, it could've been merged a while ago already. 20:13 MTDiscord I thought the relay transmitted Discord usernames? 20:13 Krock I thought the relay transmitted Discord usernames? 20:13 MTDiscord Yeah it does 20:13 MTDiscord It's just that I prefer luatic now 20:14 sfan5 it sure does but I've never seen you with this nick 20:14 MTDiscord But I don't really want to rename my GitHub 20:14 sfan5 #10795 looks okay, needs rebase and another approval 20:14 ShadowBot https://github.com/minetest/minetest/issues/10795 -- Fix HUD multiline text alignment by appgurueu 20:14 sfan5 (the rest I haven't mentioned) no opinion from me at this time 20:16 appguru By rebase needed you mean I have to resolve the merge conflicts? 20:19 nrz hmm it should take some time to review all things, i added my approval on #10324 at first 20:19 ShadowBot https://github.com/minetest/minetest/issues/10324 -- Split vector.new into 3 constructors by Desour 20:19 nrz for the other i already checked but it was a bit wide if i remember to gather my approval, let me recheck tomorrow 20:20 sfan5 appguru: yes 20:21 appguru Ouch android hacks 20:21 appguru we'll need android testing 20:22 sfan5 I don't know what that thing is there in the hud code, I merely simplified it 20:22 MTDiscord Can you link the PR 20:23 sfan5 #10795 ? 20:23 ShadowBot https://github.com/minetest/minetest/issues/10795 -- Fix HUD multiline text alignment by appgurueu 20:23 MTDiscord Did you remove the if (e->offset.X < -20) textfont = font_scaled; ? 20:23 sfan5 if it weren't for the huge previews on discord I'm sure you could still see it ;) 20:24 MTDiscord sfan5: The PR that caused the conflicts 20:24 sfan5 oh 20:24 sfan5 #11478 20:24 ShadowBot https://github.com/minetest/minetest/issues/11478 -- Add bold, italic and monospace font styling for HUD text elements by sfan5 20:24 sfan5 I "removed" the code you quoted but only because the android hack is now applied before font selection 20:25 MTDiscord Ah yes 20:33 rubenwardy nrz: looool, you can do better by not having a naive linear search - and using spatial partitions 20:33 sfan5 oh now I know who I forgot to ping 20:33 appguru ^ precisely 20:33 sfan5 sorry ruben 20:34 rubenwardy sorry for what? 20:35 sfan5 not pinging you on meeting-related points 20:37 appguru We need to be more consequent about our invalid input handling. Providing invalid input to load time functions - such as registry funcs - should immediately throw an error, not try to correct the values behind your back or silently catch the error and log some error messages. 20:38 appguru Because the latter two are exactly what leads to unexpected behavior. 20:38 sfan5 have we done any of the former recently? 20:39 appguru Not that I know 20:39 appguru But something like that was brought up on Wuzzy's PR 20:45 appguru Please merge the background image chopping PR BTW 20:45 appguru I have rebased the HUD text alignment fix and fixed some minor things, should be fine too 20:48 sfan5 the only "complaint" I have is that `auto wss = std::wstringstream(text);` could as well just be `std::wstringstream wss(text);` 20:48 sfan5 and I haven't tested it yet 21:01 pgimeno a love2d user sent this lib to the forum, it appears to be a pure Lua interpretation (by that I mean nothing love-specific) and maybe it can be used for get_objects_inside_radius 21:01 pgimeno https://love2d.org/forums/viewtopic.php?f=5&t=91782 21:03 pgimeno I still don't have an answer to how slow it is to modify the tree, though, and for moving entities it will obviously change often 21:09 sfan5 " insertion and deletion take a lot of effort, meaning that for a dynamic set of objects this is not a convenient technique." hmm 21:09 pgimeno yeah, that's what I don't have an answer on, "how bad is it?" 21:10 pgimeno also it's for 2D rectangles, I haven't looked into the algorithm to see how easy or hard it would be to extend it to 3D 21:15 sfan5 honestly throwing a 2D implementation at it that uses the X and Z coords would also solve most of the problems 21:16 pgimeno heh 21:23 MTDiscord UGH 21:23 MTDiscord That R*-tree uses table.insert / table.remove for insertion and removal 21:24 MTDiscord Well, that's probably acceptable for a maximum of 20 children per node 21:24 MTDiscord Still, a set would be faster 21:28 pgimeno of course that's just about the technique, the idea would be to implement it in the C++ side 21:29 MTDiscord Why can't we take the libspatialindex implementation? 21:30 sfan5 merging game#2656 and game#2885 (only translation) in 5m 21:30 ShadowBot https://github.com/minetest/minetest_game/issues/2656 -- default: Improves reading and writing to books. by orbea 21:30 ShadowBot https://github.com/minetest/minetest_game/issues/2885 -- improve zh_CN translation by ferrumcccp 21:32 sfan5 looking at my code there's one obvious limitation: you can't fetch objects by ID from the spatialthingy, you have to do a pos lookup 21:33 sfan5 the other problem is that you can't directly put pointers into the thing, this happens to work here because it's id type is large enough to hold a pointer 21:35 sfan5 s/it's/its/