| Time |
Nick |
Message |
| 00:00 |
|
Calinou joined #minetest-dev |
| 00:00 |
|
ssieb joined #minetest-dev |
| 00:01 |
|
Taoki joined #minetest-dev |
| 00:03 |
|
Noisytoot joined #minetest-dev |
| 02:26 |
|
queria^clone joined #minetest-dev |
| 02:30 |
|
queria^clone joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:00 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:27 |
|
Extex joined #minetest-dev |
| 06:34 |
|
ssieb joined #minetest-dev |
| 06:44 |
|
olliy joined #minetest-dev |
| 06:58 |
|
ssieb joined #minetest-dev |
| 09:36 |
|
Fixer joined #minetest-dev |
| 09:43 |
|
tech_exorcist joined #minetest-dev |
| 10:05 |
|
specing_ joined #minetest-dev |
| 10:11 |
|
calcul0n joined #minetest-dev |
| 10:14 |
|
tech_exorcist joined #minetest-dev |
| 10:42 |
|
proller joined #minetest-dev |
| 10:49 |
|
proller joined #minetest-dev |
| 12:42 |
|
Fixer_ joined #minetest-dev |
| 15:32 |
|
Thomas-S joined #minetest-dev |
| 15:32 |
|
Thomas-S joined #minetest-dev |
| 15:34 |
|
Thomas-S joined #minetest-dev |
| 15:34 |
|
Thomas-S joined #minetest-dev |
| 15:53 |
|
Extex joined #minetest-dev |
| 16:29 |
|
proller joined #minetest-dev |
| 16:36 |
|
longerstaff13 joined #minetest-dev |
| 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 |
| 16:55 |
|
ivanbu joined #minetest-dev |
| 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 |
<josiah_wi> 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:05 |
|
calcul0n_ joined #minetest-dev |
| 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 |
<GreenXenith> 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 |
<GreenXenith> Unfortunately FOSS communities arent known for attracting a ton of artistic talent .. good art isnt cheap to make (effort-wise) |
| 18:37 |
MTDiscord |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> what voxel game |
| 18:46 |
MTDiscord |
<GreenXenith> 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 |
<GreenXenith> 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:53 |
|
Extex joined #minetest-dev |
| 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 |
^ <sfan5> 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 |
<Jonathon> 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 |
|
longerstaff13 joined #minetest-dev |
| 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 |
<Jonathon> 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 |
<Jonathon> i like how one of those has possible close on it |
| 19:40 |
MTDiscord |
<Jonathon> 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 |
|
proller joined #minetest-dev |
| 19:45 |
sfan5 |
sure, say when you're ready (also ping nrz) |
| 19:45 |
MTDiscord |
<Jonathon> 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 |
<Jonathon> ^ninja'd |
| 19:47 |
nrz |
cannot we have new maintenainers for official default game to add more features ? ? |
| 19:47 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> We probably need acceptable entity performance first of all |
| 19:55 |
MTDiscord |
<Jonathon> 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 |
<luatic> 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 |
<luatic> get_objects_inside_radius |
| 19:56 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> Not if we continue using a linear search |
| 19:58 |
MTDiscord |
<luatic> 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 |
<luatic> I was hoping libspatial could to the job for me, but can't find any proper docs |
| 19:58 |
MTDiscord |
<luatic> 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<u64, Entity*> and it was sufficiently fast to have 1000 players and thousands of NPCs loaded in meory working |
| 19:59 |
MTDiscord |
<luatic> sfan5: and how did it turn out? |
| 20:00 |
sfan5 |
there's a bug somewhere because it eventually segfaults |
| 20:00 |
MTDiscord |
<ElCeejo> 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 |
<luatic> 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 |
<ElCeejo> 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 |
<luatic> 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 |
<luatic> Most pathfinders do it node-based, which is actually pretty wrong. |
| 20:02 |
MTDiscord |
<luatic> Node collisionboxes may have holes, may be larger than one node, etc |
| 20:02 |
MTDiscord |
<luatic> 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 |
<luatic> And then the entity collisionbox isn't a point either. Most pathfinders assume points though. |
| 20:03 |
MTDiscord |
<ElCeejo> 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 |
<ElCeejo> 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 |
<luatic> 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 |
<ElCeejo> I would love to contribute my implementation but it's in lua |
| 20:04 |
MTDiscord |
<luatic> At least in 3D. In 2D it can be done pretty fast. |
| 20:05 |
MTDiscord |
<luatic> Ceej: Stop whining, Lua isn't all that slow. It's a constant factor in the end. Maybe start optimizing complexity? |
| 20:05 |
MTDiscord |
<ElCeejo> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> No, not really. It's only really helpful if velocity remains mostly constant. |
| 20:09 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> I thought the relay transmitted Discord usernames? |
| 20:13 |
Krock |
<MTDiscord> <luatic> I thought the relay transmitted Discord usernames? |
| 20:13 |
MTDiscord |
<luatic> Yeah it does |
| 20:13 |
|
appguru joined #minetest-dev |
| 20:13 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
| 20:57 |
|
proller joined #minetest-dev |
| 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 |
|
tech_exorcist joined #minetest-dev |
| 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 |
<luatic> UGH |
| 21:23 |
MTDiscord |
<luatic> That R*-tree uses table.insert / table.remove for insertion and removal |
| 21:24 |
MTDiscord |
<luatic> Well, that's probably acceptable for a maximum of 20 children per node |
| 21:24 |
MTDiscord |
<luatic> 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 |
<luatic> 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/ |
| 22:03 |
|
asdflkj_sh joined #minetest-dev |
| 22:32 |
|
specing joined #minetest-dev |
| 23:04 |
|
AliasAlreadyTake joined #minetest-dev |
| 23:27 |
|
Taoki joined #minetest-dev |
