| Time |
Nick |
Message |
| 00:02 |
|
Sharpman joined #minetest |
| 00:32 |
|
est31 joined #minetest |
| 00:34 |
|
est31 joined #minetest |
| 00:55 |
|
ShadowBot joined #minetest |
| 01:02 |
|
MTDiscord joined #minetest |
| 01:07 |
|
tel4 joined #minetest |
| 01:17 |
|
smk joined #minetest |
| 02:14 |
|
SFENCE joined #minetest |
| 02:31 |
|
jonadab joined #minetest |
| 03:18 |
|
Verticen joined #minetest |
| 03:54 |
|
fling joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:31 |
|
SFENCE joined #minetest |
| 06:14 |
|
gregon joined #minetest |
| 06:17 |
|
tarsovbak joined #minetest |
| 06:58 |
|
tarsovbak joined #minetest |
| 06:59 |
|
gregon joined #minetest |
| 07:12 |
|
v-rob joined #minetest |
| 07:30 |
|
calcul0n joined #minetest |
| 07:56 |
|
tarsovbak joined #minetest |
| 08:04 |
|
krocos joined #minetest |
| 08:05 |
|
vampirefrog joined #minetest |
| 08:18 |
|
tarsovbak joined #minetest |
| 08:29 |
|
s20 joined #minetest |
| 09:10 |
|
r00t_ joined #minetest |
| 09:11 |
chaosesqueteam |
I saw you banned me from your forum |
| 09:11 |
chaosesqueteam |
you piece of fucking shit |
| 09:11 |
chaosesqueteam |
Because I said that expanding the map format to 32 bit was easily possible |
| 09:12 |
chaosesqueteam |
and that I have done similar things for darkplaces (my version) expanding the max entities from 32k to 4 million |
| 09:12 |
chaosesqueteam |
you fucking pieces of shit want to fight? |
| 09:12 |
chaosesqueteam |
"Toxic behavior" |
| 09:12 |
chaosesqueteam |
you can only do such bans because you have 2 million police on your side |
| 09:12 |
chaosesqueteam |
you trans-fuck loving faggot pieces of fuckingshit |
| 09:12 |
s20 |
Something is going to happen |
| 09:12 |
chaosesqueteam |
you oppose men marrying cute young virgin girls |
| 09:13 |
ROllerozxa |
(???) |
| 09:13 |
chaosesqueteam |
(a right given by YHWH: devarim 22 verse 28) |
| 09:13 |
|
chaosesqueteam was kicked by rubenwardy: kick |
| 09:13 |
rubenwardy |
you see why we banned you |
| 09:14 |
MTDiscord |
<greenxenith> Cool, just gonna remove that |
| 09:15 |
ROllerozxa |
"you banned me from your forum, now I'm gonna show that the ban was 100% justified" |
| 09:16 |
Ingar |
+1 |
| 09:16 |
MTDiscord |
<greenxenith> Now go clean it up in -dev |
| 09:19 |
|
Bahhumbug joined #minetest |
| 10:08 |
|
est31 joined #minetest |
| 10:21 |
|
TomTom joined #minetest |
| 10:51 |
|
s20 joined #minetest |
| 11:20 |
|
tarsovbak joined #minetest |
| 11:35 |
|
fling joined #minetest |
| 11:38 |
|
fling joined #minetest |
| 12:27 |
|
proller joined #minetest |
| 12:46 |
|
acarrico joined #minetest |
| 13:07 |
|
Trifton joined #minetest |
| 13:56 |
|
gregon joined #minetest |
| 13:58 |
|
tarsovbak joined #minetest |
| 14:10 |
|
appguru joined #minetest |
| 14:24 |
|
s20 joined #minetest |
| 14:40 |
|
Bombo joined #minetest |
| 14:40 |
|
Bombo joined #minetest |
| 14:40 |
|
thelounge656 joined #minetest |
| 14:40 |
|
MisterE123 joined #minetest |
| 14:40 |
|
Pokey joined #minetest |
| 14:40 |
|
sy joined #minetest |
| 14:40 |
|
basxto joined #minetest |
| 14:40 |
|
calcul0n joined #minetest |
| 14:41 |
|
ShadowBot joined #minetest |
| 14:41 |
|
amfl joined #minetest |
| 14:41 |
|
Yonle joined #minetest |
| 14:43 |
|
Izaya joined #minetest |
| 14:43 |
|
ShadowNinja joined #minetest |
| 14:43 |
|
Leopold joined #minetest |
| 14:45 |
|
pounce joined #minetest |
| 14:51 |
|
izzyb joined #minetest |
| 15:08 |
|
appguru joined #minetest |
| 15:15 |
|
gregon joined #minetest |
| 15:23 |
MTDiscord |
<warr1024> If I change a node meta field that's marked as private (so the changed field wouldn't be sent to the client), does it still mark the mapblock as "dirty" so the mapblock is queued to send to the client? |
| 15:23 |
sfan5 |
no |
| 15:24 |
sfan5 |
i believe metadata changes are sent directly rather than by re-sending the whole block anyway |
| 15:27 |
|
s20 joined #minetest |
| 16:14 |
|
tarsovbak joined #minetest |
| 16:18 |
|
definitelya joined #minetest |
| 16:20 |
|
Alnotz joined #minetest |
| 16:32 |
MTDiscord |
<warr1024> I'd like to be able to treat a mapblock that's distant from a player as if it's close to the player (e.g. if I, as a mod/game dev, am aware of a impending teleportation). It seems like there are several components to this and only some of them are achievable. |
| 16:33 |
MTDiscord |
<warr1024> I know I can cause the server to load the mapblocks using emerge, though, I need to use forceloading to prevent them from unloading (which is a bit more expensive because I can't control whether they become active or not). |
| 16:34 |
MTDiscord |
<warr1024> I can force-send them to the client ... though, as far as I can tell, I don't have a way to prevent the client from unloading them? So I just have to keep sending them (the engine seems to be aware of whether the client already had them so I suppose there's some way this is optimized down when they already have them) and hope that the actual teleportation doesn't happen inside the race window. |
| 16:35 |
MTDiscord |
<warr1024> I don't seem to have any way to tell the client to mesh-gen the mapblocks, though, so there can still always be a glitch upon teleporting before the meshes are built and loaded. |
| 16:39 |
MTDiscord |
<warr1024> Are there things I could suggest be added to the engine that would make "seamless teleportation" feasible, like client-side forceloading or something? I have to assume it's unlikely I'll be able to do the work myself, so things that are easy wins (like player:add_pos(v)) are ideal. I don't mind having to do some work on the mod side e.g. doing the calculations to prioritize mapblocks rather than just giving the engine a heuristic tweak |
| 16:39 |
MTDiscord |
factor, though, if that's actually easier... |
| 16:50 |
|
jaca122 joined #minetest |
| 16:59 |
|
Desour joined #minetest |
| 16:59 |
|
Guest30 joined #minetest |
| 17:08 |
|
mrkubax10 joined #minetest |
| 17:10 |
Desour |
warr1024: player:send_mapblock(blockpos) exists |
| 17:11 |
Desour |
you probably don't actually need that the player has the block loaded, if you teleport them into ignore, it should be fine. the only issue I see would be that you teleport into an old block (which send_mapblock prevents) |
| 17:12 |
MTDiscord |
<warr1024> If I teleport the player into a mapblock that they don't have meshgenned, let alone not loaded, then the teleportation will be visible and the effect will be ruined. |
| 17:13 |
MTDiscord |
<warr1024> And if I didn't already know that send_mapblock existed, then I probably wouldn't have mentioned it above 😏 |
| 17:15 |
Desour |
ah yes. wasn't sure if you found some other hacky way to send mapblocks though :) |
| 17:16 |
Desour |
mapgen is quite fast btw.. every time you dig a node, meshgen happens, for example. |
| 17:16 |
Desour |
for seamless / non-recognizable teleportation, we don't have anything yet |
| 17:32 |
|
Talkless joined #minetest |
| 17:35 |
|
gregon joined #minetest |
| 18:25 |
|
v-rob joined #minetest |
| 18:45 |
|
appguru joined #minetest |
| 18:58 |
|
v-rob joined #minetest |
| 19:03 |
|
proller__ joined #minetest |
| 19:38 |
|
calcul0n joined #minetest |
| 20:08 |
|
gera left #minetest |
| 20:39 |
|
appguru joined #minetest |
| 21:37 |
celeron55_ |
well, client:meshgen_mapblock(blockpos) would seem like a reasonable idea for that purpose |
| 21:38 |
celeron55_ |
or, maybe the client could detect that no mapblocks have been meshgenned near the camera and draw an opaque overlay on top until that isn't the case |
| 21:38 |
celeron55_ |
of course, that's essentially a loading screen and some people don't like loading screens |
| 21:39 |
celeron55_ |
(even though it would take a fraction of a second) |
| 21:39 |
sfan5 |
iirc transparency sorting and shadows make the client often re-generate a mesh anyway so not sure of the effectiveness of preloading |
| 21:39 |
MTDiscord |
<warr1024> The problem with the loading screen idea is that unless you inject a bunch of random loading screens everywhere else, it becomes painfully obvious when transitions are happening. |
| 21:40 |
MTDiscord |
<warr1024> If the mesh is stale, does the client continue to display the old mesh until it's ready? Or does it block the client from rendering, or remove the old mesh, and I just haven't noticed because meshes are generated fast enough? |
| 21:41 |
celeron55_ |
well, i think how i originally wrote it was so that the old mesh is rendered until a new one replaces it |
| 21:42 |
celeron55_ |
the renderer never blocks. if something's "missing", it doesn't care, it just renders everything else |
| 21:43 |
MTDiscord |
<warr1024> Then that sounds like what I want. I want to be able to ask it to generate a mesh so there's an "old" one ready to draw. |
| 21:44 |
celeron55_ |
the existing player:send_mapblock and the suggested client:meshgen_mapblock really need a TTL (time-to-live) parameter |
| 21:45 |
celeron55_ |
the client's goal is to not have unneeded mapblocks so it will want to unload mapblocks from far-away locations |
| 21:45 |
MTDiscord |
<warr1024> In the abstract, what I want to be able to do is tell the engine that a mapblock is a certain distance away from the player, or that 2 points in 3D space have a custom distance apart, and have the engine use the smallest distance to calculate its heuristic for when it should load, activate, and otherwise prepare blocks. |
| 21:45 |
celeron55_ |
unless they are somehow specially marked, like with a server-requested TTL value |
| 21:45 |
celeron55_ |
what you are talking about is essentially multiple switchable camera positions |
| 21:46 |
celeron55_ |
the server would provide the client a list of them and they'd make sure each position is fed with mapblocks and meshes |
| 21:46 |
|
v-rob joined #minetest |
| 21:46 |
celeron55_ |
and then you could ask the client to switch the camera between them (or show multiple cameras at the same time) |
| 21:47 |
celeron55_ |
this would of course be quite resource intensive, almost like running many clients, but if it's what you want, then it's what you want |
| 21:48 |
MTDiscord |
<warr1024> What I'm talking about is that if a teleport exists between 0,0,0 and 1000,0,0 then the distance from a player at 0,0,10 to a point at 990,0,0 is actually 20, not 990.05, and it should prepare and load mapblocks accordingly. If I have to do a bit of the heuristic myself, I don't mind, but I need a way for the engine not to be surprised and caught totally unprepared when the player suddenly traverses that teleport. |
| 21:49 |
MTDiscord |
<luatic> sfan5: imagine a world where on modern hardware, no transparency sorting is needed |
| 21:49 |
MTDiscord |
<warr1024> I suppose if I could send the camera to a position different from the player, that would serve the purpose too ... but of course if I have to actually SEND the camera there, and can't have it prepare, that doesn't help much. |
| 21:49 |
celeron55_ |
i think the camera position list is the best mechanism. you'd just maintain the target positions of nearby teleports on that list |
| 21:49 |
MTDiscord |
<warr1024> After all I can already disconnect the camera from the player by using an entity as the player. |
| 21:50 |
celeron55_ |
or, well, you don't need to think of it as camera positions. just "load positions" |
| 21:50 |
celeron55_ |
load-and-meshgen positions |
| 21:50 |
celeron55_ |
basically prepared for a teleporting or fast-moving camera |
| 21:50 |
MTDiscord |
<warr1024> Hmm, so you're thinking that right now the player is sort of like a "load position" and the solution would be to just allow multiple, and mapblocks would be loaded based on how close they are to the closest load position...? |
| 21:50 |
MTDiscord |
<warr1024> that sounds like it could work well for me. |
| 21:50 |
celeron55_ |
yes |
| 21:51 |
celeron55_ |
the player's current position would be an implicit load position, and the server could provide more |
| 21:53 |
MTDiscord |
<luatic> I would like to merge / push #14366, #14351 #13789 and https://gist.github.com/appgurueu/a2e5378946f960c8761c03bfa60f80d4 in 20m |
| 21:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/14366 -- Allow VBO to be used for meshes all the way down to 4 vertices by paradust7 |
| 21:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/14351 -- Rename MINETEST_SUBGAME_PATH to MINETEST_GAME_PATH by cx384 |
| 21:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/13789 -- Fix liquid falling if in "float" group, fixes #13782 by kromka-chleba |
| 21:54 |
sfan5 |
go ahead but do it in #minetest-dev :) |
| 21:55 |
MTDiscord |
<luatic> ah heh. i saw all the dev-related talk happening here so i assumed this was -dev :P |
| 21:57 |
MTDiscord |
<warr1024> I could swear I put in a request already for "inform the engine of impending teleport" or something ... but I don't see anything, unless it was long long ago, or I worded it differently than I thought? |
| 21:57 |
MTDiscord |
<luatic> posted in -dev, restarted the timer |
| 22:15 |
MTDiscord |
<warr1024> Couldn't find an existing issue, so I posted new #14367. |
| 22:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/14367 -- Teleport-aware client-side terrain loading |
| 22:19 |
MinetestBot |
[git] appgurueu -> minetest/minetest: Improve deprecation error messages a14320f https://github.com/minetest/minetest/commit/a14320fc446991018f82a7900c2b0d126971a7f0 (2024-02-12T21:58:26Z) |
| 22:22 |
MinetestBot |
[git] paradust7 -> minetest/minetest: Allow using VBOs for meshes all the way down to 4 vertices (#14366) e2ccd14 https://github.com/minetest/minetest/commit/e2ccd14c0526adf88fa56dfcfd0e998492b01b03 (2024-02-12T22:20:48Z) |
| 22:22 |
MinetestBot |
[git] cx384 -> minetest/minetest: Rename `MINETEST_SUBGAME_PATH` to `MINETEST_GAME_PATH` (#14351) 7901087 https://github.com/minetest/minetest/commit/790108746678cf48023eb98e17644d3364e37486 (2024-02-12T22:21:19Z) |
| 22:26 |
MinetestBot |
[git] kromka-chleba -> minetest/minetest: Fix liquid falling if in "float" group (#13789) 6c8ae2b https://github.com/minetest/minetest/commit/6c8ae2b72a6aa69055edbfc870b48e70078adaaf (2024-02-12T22:24:54Z) |
| 23:32 |
|
panwolfram joined #minetest |
| 23:58 |
|
Yonle joined #minetest |
