| Time |
Nick |
Message |
| 00:04 |
[MTMatrix] |
<Zughy> Another reason to back my self-assign proposal and extend it for whatever PR really: https://github.com/minetest/minetest/pull/13577#issuecomment-1894699536 |
| 04:31 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:49 |
|
Farooq joined #minetest-dev |
| 06:09 |
|
Farooq joined #minetest-dev |
| 06:24 |
|
Farooq joined #minetest-dev |
| 06:34 |
|
Farooq joined #minetest-dev |
| 06:42 |
|
Farooq joined #minetest-dev |
| 09:46 |
|
Warr1024 joined #minetest-dev |
| 09:54 |
|
Farooq joined #minetest-dev |
| 09:54 |
sfan5 |
in this case we shouldn't ask for PRs to be rebased unless someone has ever looked at them |
| 10:08 |
|
Farooq joined #minetest-dev |
| 10:15 |
|
fgaz_ joined #minetest-dev |
| 10:20 |
|
Farooq joined #minetest-dev |
| 10:52 |
|
Farooq joined #minetest-dev |
| 11:06 |
|
Farooq joined #minetest-dev |
| 11:07 |
sfan5 |
anyone with macOS around who could test SDL2 with latest irrlicht? |
| 11:20 |
|
Farooq joined #minetest-dev |
| 12:24 |
|
shangul joined #minetest-dev |
| 13:51 |
|
SoniEx2 joined #minetest-dev |
| 14:04 |
MTDiscord |
<mistere_123> Will lua on each mapgen thread go into 5.9 even if it comes before fossdem? |
| 14:26 |
rubenwardy |
Are there any features that deserve a rush to release? |
| 14:26 |
rubenwardy |
Sdl is still bugged and GLTF isn't in, I'd not rush to release |
| 14:52 |
[MTMatrix] |
<Zughy> I agree with ruben, it's risky and it'd put pressure on development |
| 14:53 |
[MTMatrix] |
<Zughy> unless a reasonable amount of core devs have enough time in these two weeks to cover potential issues that might rise |
| 14:53 |
[MTMatrix] |
<Zughy> (luatic said that GLTF should cause no big issues though. Let's just mark it as experimental and the problem is done, innit?) |
| 14:55 |
|
Desour joined #minetest-dev |
| 15:02 |
MTDiscord |
<josiah_wi> I do not want a repeat of what happened with dynamic shadows. |
| 15:02 |
|
Lupercus joined #minetest-dev |
| 15:03 |
MTDiscord |
<josiah_wi> I know a lot of people have expressed excitement about glTF support, but I do not think that is a good reason to rush it. |
| 15:11 |
Desour |
if we make a release with easy to fix obvious bugs, that might lure new developers. otherwise idk why you'd want to release again after under 2 months. if you want to showcase new shiny features, take the other features we aggregated in recent years, and show them by making new mods. or even better, find ways to showcase what makes minetest actually interesting |
| 15:15 |
celeron55 |
in the case where no release is rushed, the upcoming features can of course still act as conversation points at fosdem |
| 15:48 |
[MTMatrix] |
<Zughy> re Desour "find ways to showcase etc.": the only thing I can think of for develoeprs is CDB and scripting in Lua. Because, I mean, both GUI and HUD suck, we're still stuck on OpenGL 2 and with an engine forgotten by humanity, there is no way to go from a server to another, we've still got plenty of things to dehardcode |
| 15:48 |
rubenwardy |
Minetest: Jank as a service |
| 15:48 |
|
Wuzzy joined #minetest-dev |
| 15:49 |
rubenwardy |
~~GUI replacement for 5.9?~~ |
| 15:49 |
Desour |
still, there are so many contributors in minetest, so something must be drawing us in, even if it's the suck-ness of minetest, and therefore resulting fun of being able to improve things everywhere |
| 15:50 |
[MTMatrix] |
<Zughy> for me is showing the middle finger to Microsoft whilst doing something I like, and I won't even hide it. We're racing against the most sold videogame in history, fuck them |
| 15:50 |
[MTMatrix] |
<Zughy> But I can't go to people and say "hey, do you want to use that lovely middle finger of yours? ;)))" |
| 15:51 |
Desour |
and from the users perspective there must also be interesting things, otherwise they wouldn't be here. maybe it's nice that you can do so much hacky stuff with out API, or that you can host servers where arbitrary content is sent to the client |
| 15:51 |
Desour |
haha |
| 15:52 |
[MTMatrix] |
<Zughy> oh no, trust me, I despise hacky stuff (e.g. using invisible entities to immobilise players) |
| 15:52 |
Desour |
it's FOSSdem, so showing how we encourage free licensing on forums and contentdb is also noteworthy. when contentdb migration btw? |
| 15:53 |
Desour |
"I despise hacky stuff" so stockholm didn't kick in yet for you? |
| 15:53 |
[MTMatrix] |
<Zughy> It's love and hate |
| 15:54 |
rubenwardy |
"when contentdb migration btw" what do you mean? |
| 15:54 |
Desour |
oops, s/contentdb/codeberg/ |
| 15:54 |
[MTMatrix] |
<Zughy> anyway: it'd be nice if Minetest showcased featured servers as well. Bluntly pushing for mine and CTF, can't tell about others |
| 15:55 |
[MTMatrix] |
<Zughy> Desour: oh I'm in haha |
| 15:58 |
|
pgimeno joined #minetest-dev |
| 15:58 |
Wuzzy |
ive tried multiple times to tacke #12578 but i struggle to find the cause of the bug. i know it has something to do with the shader but i fail to make any progress |
| 15:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/12578 -- Texture overlay color of items is different as wielditem than in inventory/dropped item |
| 15:59 |
Desour |
"showcased featured servers" <- when I decide if I want to play a mostly-multiplayer game, it's super important that there's actually active servers and players. so this is definitely a good idea. (I didn't play much besides devtest recently though. could push for your land though) |
| 16:01 |
Wuzzy |
about "showcased featured servers": Instant suggestion for Inside The Box |
| 16:01 |
Wuzzy |
about bug 12578 again... i have stared at WieldMeshSceneNode::setItem and this line: u32 shader_id = shdrsrc->getShader("object_shader", TILE_MATERIAL_BASIC, NDT_NORMAL); |
| 16:03 |
Wuzzy |
so whats weird the same code is also used in client/content_cao.cpp but for this, the coloriing is correct o_O |
| 16:04 |
Wuzzy |
whats doubly weird is not just that the wieldmesh is not only slightly brighter but the hue seems to be slightly off, too |
| 16:06 |
Desour |
tested. the difference is huge with the color in the reproduction steps |
| 16:06 |
Desour |
red-ish vs white-yellow |
| 16:06 |
Wuzzy |
yeah i chose a color where difference is strongest but other cases are more sublte. still, its always a noticable difference |
| 16:07 |
Wuzzy |
i guess i just need to actually start learning OpenGL to even have a chance of fixing this ;-) |
| 16:09 |
Wuzzy |
buuuut, i have a suspicion somewhere in the code the color change and/or shading is applied ... twice? but why does the *hue* change too then? |
| 16:19 |
Desour |
the object vertex and fragment shader both apply daylight ratio stuff. if I comment out the one in the vertex shader, it's fixed |
| 16:20 |
Desour |
(see client/shaders/object_shader/opengl_vertex.glsl:125) |
| 16:21 |
Desour |
it's kinda weird that the vertex color is shaded at all |
| 16:22 |
Desour |
(and it's so old-style that we're using vertex colors for this feature. a uniform would make more sense) |
| 16:31 |
Desour |
merging #11073 in 10 min |
| 16:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/11073 -- Add rotation support for wallmounted nodes in 'ceiling' or 'floor' mode by Wuzzy2 |
| 16:50 |
sfan5 |
new: #14268 |
| 16:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/14268 -- Use newer IrrlichtMt by sfan5 |
| 17:01 |
[MTMatrix] |
<Zughy> sfan5: are you trying to release a 5.9 before FOSDEM? 👀 |
| 17:08 |
sfan5 |
not specifically, right now I'm just trying to get some outstanding things on irrlichtmt solved |
| 17:37 |
sfan5 |
looking at the blockers we have that's probably also not too realistic |
| 17:46 |
sfan5 |
testing welcome btw |
| 17:47 |
sfan5 |
@luatic can I merge #14225? |
| 17:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/14225 -- Add bulk_get_node function by sfence |
| 17:48 |
Krock |
why do we need this again? the (assumed) relative positions to a node (whose surroinging nodes are interesting) have to be calculated manually anyway |
| 17:48 |
Krock |
so this only saves some Lua -> C calls, or is there more to it? |
| 17:49 |
Krock |
I'll have a look at the other PRs to give them at test. feel free to let me know about such that have priority for you |
| 17:49 |
sfan5 |
consider that a 3x3x3 cube needs 27 get_node calls otherwise |
| 17:50 |
sfan5 |
so just getting a nodes direct neighbors is relatively expensive |
| 17:51 |
sfan5 |
#13616 could use a revierw |
| 17:51 |
sfan5 |
-r |
| 17:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/13616 -- Meshgen tests by numberZero |
| 17:51 |
|
Desour joined #minetest-dev |
| 17:51 |
Krock |
I was thinking about providing fixes rule tables directly, for relative positions. In some cases that might be easier to use - then again it's less generic than an absolute node lookup function |
| 17:51 |
Krock |
s/fixes/fixed/ |
| 17:52 |
sfan5 |
and #14256 could use someone with an opinion on `IrrlichtErrorCapturer` |
| 17:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/14256 -- Return to the main menu if a shader compilation fails by HybridDog |
| 17:52 |
sfan5 |
I think performing the vector additions in Lua won't be the bottleneck |
| 17:52 |
sfan5 |
maybe more specialized APIs could make sense in the future |
| 17:53 |
sfan5 |
but I think the "get_node > bulk_get_node > VoxelManip" progression makes a lot of sense |
| 17:53 |
Krock |
fair point |
| 17:53 |
sfan5 |
anyway afk 30m and I'll merge some of the one approval PRs after that |
| 17:54 |
Krock |
hmm... I wonder how badly the VManip could possibly perform |
| 17:56 |
Desour |
the bulk node get function could probably be optimized more if the node conversion was done in lua. afaik pushnode as of now calls a lua function, but we could instead return an array of lua numbers, and call pushnode in lua, for less C->lua calls. anyways, this can happen later, having a bulk node get function api in place first is probably fine |
| 18:37 |
|
v-rob joined #minetest-dev |
| 18:39 |
MTDiscord |
<luatic> I think a "poor" API may limit us performance-wise; it'd be better to start with an API that is designed to be efficient right away - a 1.3x performance improvement doesn't seem like a whole lot. |
| 18:39 |
MTDiscord |
<luatic> But I'll have to benchmark, could very well be that my suggestions aren't as useful as I think they are. Also, while 5.9 is still in dev, I believe we'd be free to change the API? |
| 18:40 |
sfan5 |
practically yes but we try to avoid it anyway |
| 18:41 |
MTDiscord |
<luatic> I'll try to make some benchmarks soon (TM) |
| 18:42 |
sfan5 |
fwiw I think it's worth not deviating from the {name=..., param=1..., param2=...} and vector table structure even if it costs performance |
| 18:42 |
sfan5 |
for an api named [gs]et_node that is |
| 18:44 |
Krock |
perhaps we could speed up the API a bit by getting rid of the env indirection |
| 18:48 |
Krock |
nvm. there's not much to optimize. |
| 18:54 |
sfan5 |
merging #14265, #14255, #14217, #14090, #13880 in 10m |
| 18:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/14265 -- [no squash] More maintenance stuff by sfan5 |
| 18:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/14255 -- [no squash] Avoid use of select(2) by sfan5 |
| 18:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/14217 -- [no squash] Networking improvements / hardening by sfan5 |
| 18:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/14090 -- Fix out of range enum casts in deSerialize functions by cx384 |
| 18:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/13880 -- Use performant and safe data structure for active objects by sfan5 |
| 18:56 |
Krock |
I remember there were some sha256 fixes from our side - years ago. Updating the file should be fine, though. |
| 19:07 |
sfan5 |
hopefully nothing breaks now |
| 19:15 |
nrz |
i see it's lib update time 😄 |
| 19:19 |
|
susdomesticus joined #minetest-dev |
| 19:34 |
Krock |
added some more benchmark results to https://github.com/minetest/minetest/pull/14225#issuecomment-1896459828 in case anyone wonders |
| 19:39 |
sfan5 |
if anyone is looking for a free puzzle try figuring out why these tests fail https://github.com/minetest/minetest/actions/runs/7560583285/job/20586929096#step:7:271 |
| 19:40 |
sfan5 |
(warning: windows) |
| 19:40 |
Krock |
oh I've seen this one before |
| 19:40 |
Krock |
problem being I don't remember the rewason |
| 19:41 |
Krock |
possibly one of my first PRs were something in that direction |
| 19:50 |
Krock |
affected bytes: 00 00 d1 1e |
| 19:57 |
Krock |
53.53400039672852 |
| 19:57 |
Krock |
https://pastebin.com/raw/3kXdg4A9 |
| 19:58 |
Krock |
adding some tolerance (0.0001f) should fix it |
| 20:11 |
MTDiscord |
<luatic> sfan5: agreed, but we can provide a get_node_fast API or similar that returns a name, param1, param2 |
| 20:13 |
Wuzzy |
what's the difference between minetest.after(0, my_function) and minetest.register_on_mods_loaded(my_function)? (assuming i run this code at loading time, i.e. not nested within another function) |
| 20:14 |
sfan5 |
before the first server step the environment isn't initialized |
| 20:14 |
sfan5 |
and on_mods_loaded probably runs before env init |
| 20:16 |
Krock |
Wuzzy: latter still allows you to register nodes, aliases, abms and decorations |
| 20:17 |
Krock |
afterwards the NodeResolver code is run, which makes any manipulation useless. |
| 20:18 |
Wuzzy |
so minetest.after(0, ...) is basically "after the first server step"? |
| 20:19 |
celeron55 |
on_mods_loaded runs literally immediately after every mod's init has been run, nothing happens in between |
| 20:19 |
Krock |
minetest.after is run by the server globalstep (Lua side) |
| 20:20 |
Krock |
so you can either use minetest.after or do your own timings in a globalstep callback. it's the same thing. |
| 20:20 |
Wuzzy |
ah ok =) |
| 21:32 |
|
grorp joined #minetest-dev |
| 21:38 |
|
grorp joined #minetest-dev |
| 21:38 |
grorp |
luatic: can we please get rid of the Github-specific markdown "alert" syntax introduced in https://github.com/minetest/minetest/commit/a8cf10b0b523bf4c3234be29b0dd51e719cb00c1? it doesn't render nicely on api.minetest.net and it's inconsistent with the rest of the API documentation. |
| 21:40 |
grorp |
also, where was the "pushing in 5 min" message for that commit, as required by the Git Guidelines? |
| 21:41 |
grorp |
(the question mark wasn't supposed to be part of the URL) |
| 21:44 |
MTDiscord |
<luatic> grorp: Is the "pushing in 5 min" announcement really useful for tiny doc edits? |
| 21:46 |
grorp |
I guess usually not, but in this case I actually have something to complain about, so it would have been useful :) |
| 21:46 |
MTDiscord |
<luatic> grorp: True, sorry |
| 21:46 |
MTDiscord |
<luatic> I suppose I'll piggy-back the next doc / commit I make to fix this. Making a separate commit for this would seem excessive. |
| 21:46 |
MTDiscord |
<luatic> PR / commit* |
| 21:47 |
ROllerozxa |
"it doesn't render nicely on api.minetest.net" well, what if we made it render nicely :) |
| 21:49 |
celeron55 |
if a "gotcha!" syntax like that gets foothold, soon the docs are going to be absolutely littered by it 8) well maybe not |
| 21:50 |
MTDiscord |
<luatic> I think such a "gotcha!" syntax is nice, though GH's extension in particular may not be. Slightly sucks that Markdown isn't AsciiDoc here. |
| 21:50 |
MTDiscord |
<warr1024> It depends on whether we actually attempt to document every gotcha or whether it's more efficient to simply list exceptional cases where there isn't a gotcha. |
| 21:51 |
MTDiscord |
<luatic> Suggestion: Document every second gotcha, then document the gotcha that only every second gotcha is documented. |
| 21:51 |
celeron55 |
sounds perfect |
| 21:51 |
ROllerozxa |
mkdocs (or the markdown library it uses) has a markdown extension system which I assume makes it possible to shove some python code somewhere to add custom extensions to the parsing output. maybe something to look into |
| 21:52 |
MTDiscord |
<josiah_wi> The old documentation was a text file; it was not GitHub specific. Changing to markdown helped readability a lot, but I like to view this in my local web browser. |
| 21:53 |
ROllerozxa |
it's not the end of the world though, the GFM alert syntax degrades gracefully into a blockquote with a warning header... |
| 21:53 |
MTDiscord |
<warr1024> Gotcha: this gotcha left intentionally undocumented. |
| 21:54 |
MTDiscord |
<luatic> Used to be even nicer (bold note text in a blockquote) but they removed that syntax. |
| 22:01 |
grorp |
I'm not sure whether a "colorful boxes" syntax is going to result in better or worse docs. You'd have to make sure that enough continuous, non-boxed text remains to keep the docs readable. |
| 22:21 |
|
lhofhansl joined #minetest-dev |
| 22:23 |
lhofhansl |
sfan5: see #14271 (#13880 causes a seg fault) |
| 22:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/14271 -- SEGV (on Linux) with latest Minetest Master |
| 22:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/13880 -- Use performant and safe data structure for active objects by sfan5 |
| 22:26 |
MTDiscord |
<warr1024> I've considered opening an issue to ask for the creation of a minetest.segfault() API, since I need to be able to reliably trigger one to test my segfault trapping measures, but I was going to wait until it looked like there might be a shortage first. |
| 22:47 |
lhofhansl |
As a Lua API? Or triggered from C++? |
| 23:21 |
MTDiscord |
<warr1024> In my case I want a /crash chat command, so it'd need to be at least available to Lua somehow. |
| 23:25 |
|
ivanbu joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
