Time |
Nick |
Message |
04:00 |
|
MTDiscord joined #minetest-dev |
05:09 |
|
MTDiscord joined #minetest-dev |
05:21 |
|
ivanbu joined #minetest-dev |
10:34 |
|
TenPlus1 joined #minetest-dev |
10:35 |
TenPlus1 |
Hi folks o/ does anyone know what's up with ContentDB, am getting "Internal Error" when adding a release ?!? |
10:37 |
sfan5 |
ping rubenwardy |
10:37 |
TenPlus1 |
hey sfan5 |
10:38 |
rubenwardy |
Release link? |
10:39 |
rubenwardy |
If you delete a broken release I can't inspect it |
10:39 |
TenPlus1 |
clicking + button to make new release, adding info, click save and task failed "unknown server error" |
10:39 |
TenPlus1 |
just made one |
10:40 |
rubenwardy |
Hahaha |
10:40 |
TenPlus1 |
? o.O |
10:40 |
rubenwardy |
When reading min_version_version=5.1, ContentDB is matching both 5.1 and 5.10 |
10:41 |
rubenwardy |
I'll need to fix this, it's a CDB bug and not due to your mod |
10:42 |
TenPlus1 |
Ouch! hope it's an easy fix |
10:59 |
TenPlus1 |
will check back in laters o/ |
11:15 |
MTDiscord |
<y5nw> Regarding #14964: is it acceptable to limit the use of scancode to the SDL device and continue to use keycodes for non-SDL devices? |
11:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/14964 -- Use scancodes for keybindings by y5nw |
11:40 |
|
\o` joined #minetest-dev |
12:05 |
|
proller joined #minetest-dev |
12:14 |
proller |
type rename again ready to merge to 5.9.0 + https://github.com/minetest/minetest/compare/master...proller:minetest:minetest32double?expand=1 nothing broken, just types |
12:16 |
[MTMatrix]_ |
<grorp> y5nw: other Irrlicht devices don't support scancodes and we don't want to invest more work into them, so that's the only sensible option |
12:59 |
|
fluxionary joined #minetest-dev |
13:58 |
|
SFENCE joined #minetest-dev |
14:17 |
|
SFENCE joined #minetest-dev |
14:37 |
|
SFENCE joined #minetest-dev |
15:08 |
|
SFENCE joined #minetest-dev |
15:56 |
sfan5 |
if you have a game nested in a modpack server startup will fail without an error message |
15:57 |
sfan5 |
great waste of time until I found this out |
15:58 |
|
SFENCE joined #minetest-dev |
16:01 |
sfan5 |
at least in docker, it doesn't reproduce outside of it |
16:01 |
sfan5 |
?! |
16:32 |
|
SFENCE joined #minetest-dev |
17:04 |
|
SFENCE joined #minetest-dev |
17:33 |
Krock |
sfan5: to approve one or not, that is the question. |
17:33 |
Krock |
:3 |
17:39 |
|
SFENCE joined #minetest-dev |
17:46 |
|
SFENCE joined #minetest-dev |
18:03 |
|
SFENCE joined #minetest-dev |
18:37 |
|
SFENCE joined #minetest-dev |
18:58 |
|
SFENCE joined #minetest-dev |
19:09 |
|
SFENCE joined #minetest-dev |
19:51 |
sfan5 |
merging #14945, #14974, #13987, #14883 in like 5m |
19:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/14945 -- DOCS: state that `initial_properties` are shared between entity instances by Zughy |
19:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/14974 -- Fix chance/probability wording in lua_doc.md by kno10 |
19:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/13987 -- [pls do not squash :3] Allow limiting object observers by appgurueu |
19:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/14883 -- Fix comment and alpha test node oopsies from #14852 by Desour |
20:11 |
MTDiscord |
<luatic> sfan5: squashed what i wanted to squash in #13987 |
20:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/13987 -- [pls do not squash :3] Allow limiting object observers by appgurueu |
20:13 |
sfan5 |
merged |
20:26 |
sfan5 |
if modders are lurking here I'd love to know if #14954 is considered useful |
20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/14954 -- [manual merge] Bulk LBMs by sfan5 |
20:29 |
MTDiscord |
<warr1024> In abstract, yes, definitely |
20:30 |
MTDiscord |
<warr1024> I might have specific questions though, like whether I can rely on the positions all being within a single mapblock per call, or whether you'll batch calls acrossm multiple mapblocks. |
20:31 |
MTDiscord |
<warr1024> I'd actually kind of like to have Active Node Modifiers and Loading Node Modifiers that fire once per mapblock and don't have a node list (they run on any mapblock in the correct state). Of course we'll call then whatever Node Modifiers since they operate on blocks, to be consistent with whatever Block Modifiers that operate on nodes. |
20:38 |
sfan5 |
(it's all in a single mapblock) |
20:48 |
MTDiscord |
<herowl> Tbh I see it being quite useful. |
20:49 |
MTDiscord |
<mistere_123> same, yes. |
20:49 |
MTDiscord |
<herowl> BTW, why did you tag it as [manual merge]? |
21:02 |
sfan5 |
so it could be squashed nicer |
21:04 |
MTDiscord |
<warr1024> I just wish I could have one call per mapblock loaded or active ... and I don't necessarily want to need to guess which kinds of nodes will exist within that mapblock. |
21:05 |
[MTMatrix]_ |
<Zughy> sfan5: when core devs approve feature requests the label is "concept approved"; since #14990 closes an issue previously approved, the label is the same and I don't have to assign it to you. On the contrary, if there is no concept approved issue, then it's "Supported by core dev" and the dev wins a self-assignment |
21:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/14990 -- Reject most commands if sent via an unreliable packet by red-001 |
21:05 |
MTDiscord |
<warr1024> There may exist mapblocks containing nothing but air, nothing but water, or nothing but stone, so there's no single node name I can supply for nodenames that will ensure I get to see each mapblock that gets loaded. I could give every definition a "group:all" or something, I guess, but it still feels wrong that C++ will spend time building a list of every node position in the mapblock when I only need that in some cases. |
21:13 |
Mantar |
I think "all" should be a standard engine name for "give me everything" |
21:17 |
|
YuGiOhJCJ joined #minetest-dev |
21:25 |
MTDiscord |
<warr1024> yeah, the idea of making group:all a standard thing is kind of nice |
21:26 |
MTDiscord |
<warr1024> though, if I want to be notified about every node, I don't really need to be told about each one, it's enough to tell me about the mapblock and I can infer all the node positions that apply from that. |
21:35 |
sfan5 |
" I just wish I could have one call per mapblock loaded or active " I proposed generic state change callbacks for mapblocks in some lbm-related issue |
21:35 |
sfan5 |
please absolutely don't invent a group:all and use it, most code written to deal with single nodes is not written to deal with everything at once |
21:36 |
sfan5 |
here it was -> https://github.com/minetest/minetest/issues/14723#issuecomment-2148224322 |
21:41 |
MTDiscord |
<warr1024> loaded_blocks and active_blocks would totally work for me |
21:41 |
MTDiscord |
<warr1024> sounds simple |
21:42 |
MTDiscord |
<warr1024> I really don't mind polling those and generating my own events if I want something event driven. In many cases though I actually won't want that, I'll want the lists. |
21:45 |
Mantar |
I was specifically thinking of minetest.get_nodes_in_area(), which would be nice to get all nodes in an area, but it's currently not possible |
22:03 |
sfan5 |
uhhh, sounds like you want vmanips |
22:03 |
sfan5 |
"please give me all node tables" isn't something you want to do for 9000 nodes |
22:06 |
Mantar |
who said 9000 nodes? I'm thinking a block of 27 or so |
22:09 |
sfan5 |
we had a PR for bulk_get_node, it was rejected because it's not any faster than calling get_node repeatedly |
22:10 |
Mantar |
faster would be nice, but I was mainly thinking of convenience ¯\_(ツ)_/¯ |
22:10 |
MTDiscord |
<exe_virus> Shout-out to red-001. No idea who you/they are, but thanks for the review on the spatial map merge. Lots of good things there |
22:32 |
|
panwolfram joined #minetest-dev |
22:33 |
MTDiscord |
<wsor4035> Old minetest community member iirc |
22:33 |
|
\o` joined #minetest-dev |
23:02 |
MTDiscord |
<exe_virus> Interesting, why review mine haha, but hey I'll take it |
23:05 |
|
Eragon joined #minetest-dev |
23:27 |
|
\o` joined #minetest-dev |