| Time |
Nick |
Message |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:19 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:38 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:45 |
|
Yad joined #minetest-dev |
| 05:44 |
|
calcul0n joined #minetest-dev |
| 06:25 |
|
Baytuch joined #minetest-dev |
| 06:48 |
|
nrz_ joined #minetest-dev |
| 07:30 |
|
appguru joined #minetest-dev |
| 09:11 |
|
Alias joined #minetest-dev |
| 09:16 |
nrz_ |
sfan5: new callbacks and new Lua state specific for emerge callbacks ? ? |
| 09:43 |
|
erle joined #minetest-dev |
| 09:52 |
|
HuguesRoss joined #minetest-dev |
| 09:54 |
|
HuguesRoss joined #minetest-dev |
| 10:02 |
|
proller joined #minetest-dev |
| 10:37 |
sfan5 |
the latter |
| 11:03 |
|
behalebabo joined #minetest-dev |
| 11:06 |
rubenwardy |
fuck github for the "force pushing resets updated_at" thing |
| 11:06 |
rubenwardy |
it's so annoying |
| 11:30 |
erle |
what exactly is annoying about it? |
| 11:31 |
rubenwardy |
it breaks sorting in the PR list |
| 11:31 |
erle |
well, in my experience, a force push is interesting from a “should i look at this again” POV (which is why i sort by updated) |
| 11:31 |
rubenwardy |
a force push _to master_ resets the last updated of all PRs |
| 11:32 |
erle |
oof |
| 11:32 |
erle |
wait why would anyone ever |
| 11:32 |
erle |
but yeah |
| 11:32 |
rubenwardy |
wouldn't be so bad if they had statuc_changed_at or something (where status = open / closed / merged) |
| 11:32 |
rubenwardy |
so I can sort PRs by merge/close date |
| 11:33 |
erle |
indeed |
| 11:33 |
rubenwardy |
also last_changed or something for the patch |
| 12:18 |
|
proller joined #minetest-dev |
| 12:36 |
|
proller joined #minetest-dev |
| 12:42 |
kilbith |
well shit github is translated now |
| 12:42 |
|
Warr1024 joined #minetest-dev |
| 12:55 |
kilbith |
https://i.imgur.com/rvO0eV7.png |
| 12:55 |
kilbith |
need to finish this |
| 13:40 |
erle |
kilbith looks nice. odes it keeps the area forceloaded? |
| 13:41 |
erle |
kilbith also could this be used like a HUD element? think “back mirror for car” |
| 13:41 |
erle |
like the one where you view the direction you are coming from |
| 13:49 |
kilbith |
I still have to work on the area forceload (Emerge?) |
| 13:49 |
kilbith |
HUD element, yes that's the plan |
| 13:50 |
kilbith |
but I'm thinking at an abstract camera class whose GUI and HUD inherit from |
| 13:51 |
erle |
kilbith, look at minetest.forceload_block() and minetest.forceload_free_block() |
| 13:51 |
kilbith |
I only want the client to be involved here |
| 13:52 |
kilbith |
in any case I'll need some cooperation |
| 13:54 |
kilbith |
I also wonder if camera position == world position |
| 13:54 |
erle |
i doubt you will be able to do a security camera mod well if the client needs to be in range |
| 13:54 |
kilbith |
yes true |
| 14:14 |
|
Yad joined #minetest-dev |
| 14:20 |
sfan5 |
why not delegate the responsibility to load the relevant blocks to mods that'd be using this feature? |
| 14:24 |
erle |
sfan5, can't do that if kilbith is merely providing additional cameras on the client, can you? |
| 14:24 |
erle |
to me it looks like a variant of the freecam thing that fleckenstein (?) made for dragonfire |
| 14:25 |
erle |
if you have it active you can move the camera freely among the map parts loaded on the client |
| 14:26 |
rubenwardy |
This looks like a scripting feature? Like, you'd use it for a CCTV node or smth |
| 14:26 |
rubenwardy |
It's not just force load but also client loaded |
| 14:26 |
erle |
anyways, it begs the question: how does a client get a map update for something outside of its view range? can the server just send that? |
| 14:30 |
sfan5 |
erle: last time I checked security cameras don't fly |
| 14:31 |
sfan5 |
in other words I don't expect the client to have direct control over where those additional cameras point |
| 14:32 |
sfan5 |
well perhaps look direction, but not movement |
| 14:33 |
kilbith |
<sfan5> why not delegate the responsibility to load the relevant blocks to mods that'd be using this feature? |
| 14:33 |
kilbith |
I've considered that |
| 14:33 |
rubenwardy |
Anyway, it makes sense to do this in multiple stages. It's fine for the first version to require the client to be nearby the camera, and then later versions to support loading areas etc |
| 14:35 |
sfan5 |
on second thought multiple cameras totally breaks the "the client needs to know only about blocks/objects/changes near it" assumption so cooperation of the server is absolutely needed |
| 14:36 |
rubenwardy |
Yeah |
| 14:36 |
erle |
sfan5 security cams don't fly. i just wanted to point out that the effect of freecam and what kilbith builds is the same in the end: you can use it to look behind walls or so, because the client actually knows what is there, but remote viewing is impossible. |
| 14:36 |
rubenwardy |
Also, was wondering how occlusion culling is done - could be issues if it's scene graph based |
| 14:37 |
erle |
stuff like ”inside the box” could very well use that, the boxes are small enough, after all. |
| 14:37 |
sfan5 |
transparency sorting won't work, at least |
| 14:38 |
sfan5 |
(you'd have to do it once for each camera position) |
| 14:38 |
erle |
that's far from “won't work”, given that the workload increases linearly only |
| 14:39 |
erle |
if i am not mistaken, every client-side approach to additional cameras imposes similar penalties |
| 14:52 |
kilbith |
also thinking at `player:set_active_camera(cam)` to create cutscenes |
| 14:54 |
|
Fixer joined #minetest-dev |
| 14:57 |
kilbith |
drawing on node is also entirely possible as I can set a RenderTarget to a ITexture |
| 14:58 |
kilbith |
so we could entirely imagine a scene drawn on a screen node |
| 15:00 |
erle |
mirror mirror on the wall, how would such a camera texture appear in a cam scene after all? |
| 15:04 |
rubenwardy |
users are getting irr::core::list compile errors when compiling 5.5.1, there needs to be a fixed version for irrlicht in the README.md |
| 15:16 |
Pexin |
"security cameras" don't fly, but drones do. how about a remote-controlled robot mod the player sends into a radiation zone to make it safe to re-enter? |
| 15:44 |
sfan5 |
rubenwardy: I suppose people don't read the release notes |
| 15:45 |
sfan5 |
even better cmake should detect compatibility and error out |
| 18:20 |
|
x2048 joined #minetest-dev |
| 18:46 |
|
Krock_ joined #minetest-dev |
| 18:49 |
|
paradust_ joined #minetest-dev |
| 19:19 |
sfan5 |
merging #12414, #12396 in 10m |
| 19:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/12414 -- Mapblock Mesh BspTree: Increase the depth of block-level splits by x2048 |
| 19:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/12396 -- Sanitize player position and speed server-side by sfan5 |
| 19:46 |
|
Taoki joined #minetest-dev |
| 20:49 |
|
x2048 joined #minetest-dev |
| 20:53 |
sfan5 |
the gitlab CI sure is slow, 25 minutes for something that takes 8 minutes on github |
| 20:54 |
rubenwardy |
I don't see any caching |
| 20:54 |
sfan5 |
neither does github |
| 20:54 |
rubenwardy |
ah |
| 20:55 |
sfan5 |
pushing a commit to fix the pipelines, just -4 +4 lines |
| 20:57 |
rubenwardy |
at my old job, we used Azure Pipelines. Something much simpler than what we do here took 35-50 minutes |
| 20:58 |
rubenwardy |
well, it was also running on a windows worker so I suppose that checks out |
| 21:00 |
|
proller joined #minetest-dev |
| 21:05 |
|
kaeza joined #minetest-dev |
| 22:02 |
Zughy[m] |
this "completed/not planned" issue difference on GitHub is so annoying and imho not necessary |
| 22:03 |
Zughy[m] |
Some core dev put a "Possible close" on an issue and, instead of just closing it after 30 days, I'm supposed to understand whether is "Possible close" because it was completed or because it's not planned. And if I make a mistake, then some user points that out to me (Iike it's already happened in these days) |
| 22:04 |
Zughy[m] |
Like if I didn't have enough work to do already |
| 22:16 |
erle |
i maintain that “possible close” without a comment is not helpful because it is used for widly different purposes, like “does this bug still exist?” or “is this even important?” or “does anyone understand this?” |
| 22:19 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:34 |
|
behalebabo joined #minetest-dev |
| 22:55 |
paradust |
fyi irc/discord bridge has been down for a while now |
| 22:59 |
|
Warr1024 joined #minetest-dev |
| 23:00 |
kilbith |
good thing |
| 23:00 |
kilbith |
it has gotten much less noisy |
| 23:05 |
Zughy[m] |
should I close #10221 as not planned or does any core dev want to remove the "Possible close" tag? I'm uncertain considering rubenwardy comment |
| 23:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/10221 -- Increase get_gametime precision |
| 23:10 |
erle |
you added “possible close” yourself, so you should know what you meant with it ig |
| 23:11 |
Pexin |
sub-second precision timers persisting between game loads seems.. inherently unreliable for any real world case |
| 23:13 |
Pexin |
maybe I'm misunderstanding "persistence" there |
| 23:33 |
erle |
uh what |
| 23:34 |
erle |
Pexin imagine exiting the game only to load it back up |
