Time Nick Message 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 rubenwardy you see why we banned you 09:14 MTDiscord 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 Now go clean it up in -dev 15:23 MTDiscord 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 16:32 MTDiscord 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 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 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 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 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... 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 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 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 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 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 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 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 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 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 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 sfan5: imagine a world where on modern hardware, no transparency sorting is needed 21:49 MTDiscord 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 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 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 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 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 ah heh. i saw all the dev-related talk happening here so i assumed this was -dev :P 21:57 MTDiscord 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 posted in -dev, restarted the timer 22:15 MTDiscord 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 02[git] 04appgurueu -> 03minetest/minetest: Improve deprecation error messages 13a14320f https://github.com/minetest/minetest/commit/a14320fc446991018f82a7900c2b0d126971a7f0 (152024-02-12T21:58:26Z) 22:22 MinetestBot 02[git] 04paradust7 -> 03minetest/minetest: Allow using VBOs for meshes all the way down to 4 vertices (#14366) 13e2ccd14 https://github.com/minetest/minetest/commit/e2ccd14c0526adf88fa56dfcfd0e998492b01b03 (152024-02-12T22:20:48Z) 22:22 MinetestBot 02[git] 04cx384 -> 03minetest/minetest: Rename `MINETEST_SUBGAME_PATH` to `MINETEST_GAME_PATH` (#14351) 137901087 https://github.com/minetest/minetest/commit/790108746678cf48023eb98e17644d3364e37486 (152024-02-12T22:21:19Z) 22:26 MinetestBot 02[git] 04kromka-chleba -> 03minetest/minetest: Fix liquid falling if in "float" group (#13789) 136c8ae2b https://github.com/minetest/minetest/commit/6c8ae2b72a6aa69055edbfc870b48e70078adaaf (152024-02-12T22:24:54Z)