| Time |
Nick |
Message |
| 03:26 |
|
lhofhansl joined #minetest-dev |
| 03:42 |
|
fluxflux joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:32 |
|
olliy joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:08 |
|
lhofhansl joined #minetest-dev |
| 08:15 |
|
Beton joined #minetest-dev |
| 09:46 |
|
calcul0n joined #minetest-dev |
| 10:35 |
|
proller joined #minetest-dev |
| 10:42 |
|
fluxflux joined #minetest-dev |
| 10:59 |
|
lisac joined #minetest-dev |
| 11:38 |
|
systwi joined #minetest-dev |
| 12:09 |
specing |
Hmm, why is there not on_neighbour_change node callback? |
| 12:10 |
specing |
s/not/no/ |
| 12:10 |
specing |
wouldn't it greatly simplify and speed up water spilling? |
| 12:17 |
sfan5 |
there's on_flood |
| 12:20 |
|
turtleman joined #minetest-dev |
| 12:22 |
specing |
sfan5: that's not what I'm asking |
| 12:22 |
sfan5 |
I didn't understand your usecase then |
| 12:22 |
specing |
I'm asking why there is no notification when neighbours change |
| 12:23 |
specing |
So, e.g. water, instead of an ABM loading the cpu would use this notification to know when an adjecent node became air |
| 12:26 |
sfan5 |
your example is badly chosen because liquid spread is not an ABM and uses a mechanism similar to the one you are describing to only start processing once a node has changed |
| 12:27 |
sfan5 |
(but that mechanism is engine internal and not available to mods) |
| 12:28 |
sfan5 |
why is there no "on_neighbor_change" in general? performance concerns, probably |
| 12:51 |
|
Fixer joined #minetest-dev |
| 15:11 |
|
Foz joined #minetest-dev |
| 17:20 |
|
lhofhansl joined #minetest-dev |
| 18:08 |
|
calcul0n_ joined #minetest-dev |
| 18:09 |
Krock |
Who would have time for a meeting tomorrow? |
| 18:11 |
Krock |
my main focus would be to deal with PRs that have one approval and those where I think that the concept is not right - hence candidates for closing |
| 18:12 |
Krock |
The alpha texture issue has not been fixed yet, hence I'm waiting with release-specific discussion |
| 18:15 |
rubenwardy |
I would |
| 18:20 |
Krock |
btw rubenwardy. is #10592 okay now? |
| 18:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/10592 -- Documentation for highest formspec_version[] and changelog by Desour |
| 18:21 |
Krock |
also #10445 |
| 18:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/10445 -- Make installer create its own Minetest folder by LoneWolfHT |
| 18:21 |
rubenwardy |
yeah, 10592 lgtm |
| 18:22 |
rubenwardy |
the code for 10445 makes sense, I don't have windows to test though |
| 18:22 |
rubenwardy |
but +1 if tested |
| 18:25 |
Krock |
well, the PR author wrote and tested it on Windows, hence very likely to work ^^ |
| 18:26 |
Krock |
thanks for the feedback. in this case I'll merge the two in 10 minutes |
| 18:26 |
rubenwardy |
cool |
| 18:27 |
Krock |
if you've got some more time, feel free to check the "One Approval" PRs |
| 18:31 |
|
homthack joined #minetest-dev |
| 18:32 |
Krock |
delaying merge, adding 10642 to the list |
| 18:37 |
Krock |
merging |
| 18:38 |
Krock |
done |
| 18:45 |
rubenwardy |
Supporting game controllers is pretty much impossible |
| 18:45 |
rubenwardy |
massive mess |
| 18:51 |
Krock |
and our weird input system doesn't improve the situation ither |
| 19:29 |
|
lhofhansl joined #minetest-dev |
| 21:08 |
|
lhofhansl joined #minetest-dev |
| 21:41 |
|
appguru joined #minetest-dev |
| 21:49 |
|
Fixer_ joined #minetest-dev |
| 22:13 |
|
proller joined #minetest-dev |
| 22:58 |
|
lhofhansl joined #minetest-dev |
| 23:18 |
|
fluxflux joined #minetest-dev |
