Time |
Nick |
Message |
00:13 |
|
BuckarooBanzai2 joined #minetest-dev |
00:17 |
|
panwolfram joined #minetest-dev |
00:48 |
|
v-rob joined #minetest-dev |
01:09 |
|
wsor joined #minetest-dev |
02:00 |
|
v-rob joined #minetest-dev |
02:08 |
|
v-rob joined #minetest-dev |
02:28 |
|
olliy joined #minetest-dev |
02:28 |
|
queria^clone joined #minetest-dev |
02:33 |
|
queria^clone joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
06:02 |
|
calcul0n joined #minetest-dev |
06:07 |
|
appguru joined #minetest-dev |
06:38 |
|
v-rob joined #minetest-dev |
06:45 |
|
appguru joined #minetest-dev |
07:02 |
|
appguru1 joined #minetest-dev |
07:54 |
|
v-rob joined #minetest-dev |
10:12 |
|
erle joined #minetest-dev |
10:13 |
|
HuguesRoss48 joined #minetest-dev |
10:57 |
|
proller joined #minetest-dev |
11:15 |
MTDiscord |
<oneplustwo> hi erle |
11:19 |
|
proller joined #minetest-dev |
11:27 |
|
proller joined #minetest-dev |
11:45 |
|
jonadab joined #minetest-dev |
11:53 |
|
dzho joined #minetest-dev |
12:03 |
erle |
oneplustwo what? |
12:04 |
MTDiscord |
<oneplustwo> just saying hi |
12:04 |
erle |
oh okay |
12:04 |
MTDiscord |
<oneplustwo> bwahahaha |
12:47 |
|
proller joined #minetest-dev |
13:57 |
|
Fixer joined #minetest-dev |
14:12 |
|
qur joined #minetest-dev |
15:43 |
|
Fixer_ joined #minetest-dev |
15:57 |
sfan5 |
merging #12150, #12141, #12124 in 5m |
15:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12150 -- Fix the documentation of InvRef:get_lists() and clean up code by Desour |
15:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12141 -- Optimize swapping nodes with equivalent lighting by TurkeyMcMac |
15:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12124 -- Store vector metatable in registry by TurkeyMcMac |
16:19 |
|
v-rob joined #minetest-dev |
16:30 |
proller |
and this plz https://github.com/minetest/minetest/pull/11910 |
16:41 |
MTDiscord |
<luatic> nope |
16:45 |
|
v-rob joined #minetest-dev |
16:47 |
MTDiscord |
<Jordach> sfan5 how legal is it for me to develop and implement my own voronoi cell class in MT for my own mapgen |
16:55 |
erle |
legal? |
16:55 |
sfan5 |
very legal? |
16:56 |
sfan5 |
cool idea btw |
16:59 |
MTDiscord |
<Jordach> I mean it already works but doesn’t have dual mode triangulation, edge detection etc |
17:00 |
MTDiscord |
<Jordach> I can roughly iterate against 32k cells before mapgen starts tanking performance |
17:00 |
MTDiscord |
<Jordach> I developed a river algo that uses a vertice system that shrink wraps onto terrain |
17:01 |
MTDiscord |
<Jordach> I’ve had good results with perlin rivers but having them go uphill isn’t nice and even the most obscure fixes doesn’t work either |
17:03 |
MTDiscord |
<Jordach> Here’s a few experiments |
17:03 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/747163566800633906/958411101068988416/unknown.png |
17:03 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/747163566800633906/958411113479938078/unknown.png |
17:03 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/747163566800633906/958411127400845423/unknown.png |
17:03 |
MTDiscord |
<Jordach> I also fixed the 300m ocean issue but generating pseudo continents |
17:05 |
MTDiscord |
<Jordach> On average you will see mountain ranges in the 2km region |
17:10 |
MTDiscord |
<Jordach> Still got to implement cliff regions where needed |
18:17 |
|
appguru joined #minetest-dev |
18:24 |
|
v-rob joined #minetest-dev |
19:06 |
|
Fixer joined #minetest-dev |
19:10 |
|
Desour joined #minetest-dev |
20:07 |
|
appguru joined #minetest-dev |
20:48 |
|
proller joined #minetest-dev |
21:24 |
|
proller joined #minetest-dev |
21:31 |
|
v-rob joined #minetest-dev |
21:57 |
MTDiscord |
<exe_virus> Interesting, looks great for a flight sim |
22:30 |
MTDiscord |
<Jordach> the world is using a unique heightmap implementation that doesn't use 3d noise |
22:30 |
erle |
jordach, what's your river model? |
22:30 |
erle |
if it shrinkwraps, wouldn't that mean the rivers could flow upwards? |
22:31 |
MTDiscord |
<Jordach> originally that's the case with perlin and is unfortunately unsolvable |
22:32 |
MTDiscord |
<Jordach> however i'm using voronoi point generation (and not relaxing the points) to list vertices, then use noise + height controls to modify the rivers width and depth |
22:32 |
erle |
do you have inland lakes? |
22:32 |
MTDiscord |
<Jordach> that can be arranged with the river vertice trees |
22:32 |
MTDiscord |
<Jordach> i just mark certain ones after the fact |
22:33 |
erle |
how tile-able is your implementation anyway? can you start generation at any point? |
22:33 |
|
panwolfram joined #minetest-dev |
22:33 |
MTDiscord |
<Jordach> i can indeed start where-ever i need to |
22:33 |
erle |
or does it need a defined start or some outer shell? |
22:33 |
erle |
nice |
22:33 |
MTDiscord |
<Jordach> i actually solved that voronoi problem down to an x, y input only |
22:33 |
erle |
release when? |
22:33 |
MTDiscord |
<Jordach> soon™️ |
22:38 |
MTDiscord |
<exe_virus> Makes me want to put time into a lua only mapgen |
22:39 |
erle |
exe_virus you may want to team up with cora, she is working on some multi_map shenanigans |
22:39 |
erle |
(stash a shit ton of lua mapgen layers in the map) |
22:40 |
MTDiscord |
<exe_virus> Well, I'm thinking a multi threaded lua backend mapgen that uses multiple lua states |
22:40 |
erle |
has anyone of you a solution to mapgen griefing? |
22:41 |
erle |
my main problem is that the lua stuff gets called again on a) incompletely generated mapblocks b) map downloads c) whatever |
22:41 |
erle |
so say i have a hole in a bedrock layer made by a lua mapgen |
22:42 |
erle |
and then i make a map download and load it again, it will be papered over |
22:42 |
erle |
because the lua mapgen is run again! |
22:42 |
erle |
or at least part of it |
22:45 |
MTDiscord |
<Jordach> fun fact mapgen griefing seems to not occur on fast CPUs |
22:45 |
MTDiscord |
<Jordach> i wonder if it has anything to do with MUTEX lockking |
22:47 |
erle |
it depends on which kind of mapgen griefing actually |
22:47 |
MTDiscord |
<Jordach> Lua |
22:47 |
MTDiscord |
<Jordach> the original algo for the C++ one was written entirely in Lua |
22:47 |
erle |
the one that i can reliably reproduce on my thinkpad t60 under high load is the stone clouds |
22:48 |
MTDiscord |
<Jordach> IS THAT WHAT FUCKING DOES IT |
22:48 |
erle |
? |
22:48 |
MTDiscord |
<Jordach> is this by chance on carpathian |
22:48 |
erle |
i have witnessed it on v7 |
22:49 |
MTDiscord |
<Jordach> because i modified the carpathian CavesNoiseIntersection() function and noticed it started generating it |
22:49 |
erle |
the easiest way to see it is to go to a huge empty space generated by lua mapgen |
22:49 |
erle |
for example, mcl2 end |
22:49 |
erle |
and have computer be under high load |
22:49 |
erle |
for some reason, as long as the load is high you get the stone clouds |
22:50 |
erle |
it happens everywhere, but it's ofc harder to catch in the overworld, because it seems to be limited to the contour of the v7 mapgen |
22:50 |
erle |
and they are generated before cavegen griefs the map it seems |
22:50 |
erle |
because sometimes they have holes filled with air |
22:51 |
MTDiscord |
<Jordach> I've noticed the same issue with Carpathian's cave gen |
22:51 |
erle |
so how did you modify the caves noise intersection thing to make them appear? |
22:52 |
MTDiscord |
<Jordach> basically i've heavily modified their noise and algorithm to constrict caves at higher heights and widen them at lower heights |
22:52 |
MTDiscord |
<Jordach> matching similar behaviour in real terrain |
22:52 |
erle |
and then you got stone clouds? or you got mapgen griefing by cavegen, where it makes holes in things you have placed? |
22:53 |
MTDiscord |
<Jordach> it's something to do with it's "in cave detection" |
22:53 |
MTDiscord |
<Jordach> it detects the column as open then puts stone down |
22:54 |
erle |
i think the simplest way to get stone clouds would be to make a mapgen that fills the entire map with some airlike material, then search where stone and air are generated |
22:54 |
erle |
i think kay27 once made a thing where he had a 3d grid of nodes being generated with a lua mapgen |
22:54 |
erle |
and some of the grid intersection nodes were missing |
22:55 |
erle |
it was good evidence of mapgen griefing |
22:55 |
erle |
i hope it can be solved, because while i have a solution to the stone clouds, it's super stupid |
22:55 |
MTDiscord |
<Jordach> i believe the stone cloud problem can be solved far easier |
22:55 |
erle |
basically i chose some common material and replace the stone layers with them on_generated |
22:55 |
erle |
tell |
22:56 |
erle |
like in nether it becomes netherrack |
22:56 |
MTDiscord |
<Jordach> if the world is basically a heightmap |
22:56 |
erle |
stone clouds are surrounded by air? they get turned into air |
22:56 |
erle |
well, tell |
22:56 |
MTDiscord |
<Jordach> or a cave map, you could theoretically re-iterate the area at a cost (or batch process it by divide and conquer skipping air) |
22:56 |
MTDiscord |
<Jordach> and just double check the stone is gone |
22:57 |
erle |
well i am basically making sure it is, but |
22:57 |
erle |
the problem remains that this process will run *again* some time later maybe |
22:57 |
erle |
replacing all the user-placed stone in the area with air or netherrack or whatever |
22:57 |
MTDiscord |
<Jordach> well this can be done as part of C++ mapgen |
22:57 |
erle |
so far i haven't found a good enough solution |
22:57 |
erle |
yeah, what i am saying is c++ mapgen is faulty and racy |
22:58 |
MTDiscord |
<Jordach> i believe i "have" a solution that might help it |
22:58 |
erle |
kay has been saying that for a while and several people advised him to please not reimplement the whole logic in lua |
22:58 |
erle |
but he claimed to have bad experiences with minetest coredevs so he is not fixing c++ mapgen any time soon |
22:59 |
MTDiscord |
<Jordach> basically minetest caves already know of the maximum height they can work to in engine |
22:59 |
erle |
you can look in mcl5 to what lengths he goes to try to limit mapgen griefing, it's not pretty and it works somehow |
22:59 |
erle |
but it's very fragile |
22:59 |
erle |
uh what? |
22:59 |
erle |
cavegen griefing basically happens underground |
22:59 |
MTDiscord |
<Jordach> basically the generateTerrain() function present in all mapgens returns a height value |
22:59 |
erle |
mcl* end and nether are underground |
23:00 |
MTDiscord |
<Jordach> anything higher than it is generally considered ungenerated |
23:00 |
MTDiscord |
<Jordach> or underwater |
23:00 |
erle |
yeah so? |
23:00 |
MTDiscord |
<Jordach> basically cavegen is stupid and for reasons unknown, ignores the fact it's generating above ity |
23:00 |
erle |
ity? |
23:01 |
MTDiscord |
<Jordach> basically function goes brr |
23:01 |
erle |
i fail to see how that helps. are you saying that for underground mapblocks it could be that cavegen ALWAYS thinks it's time to punch holes? |
23:01 |
MTDiscord |
<Jordach> even though it's got arguments not to |
23:01 |
MTDiscord |
<Jordach> yes |
23:01 |
erle |
hmmm |
23:01 |
erle |
any idea how to make it behave then? |
23:01 |
MTDiscord |
<Jordach> basically if you're adding a layer |
23:02 |
MTDiscord |
<Jordach> onto an existing mapgen like v7 or carp |
23:02 |
MTDiscord |
<Jordach> it'll shove the caves in as it pleases |
23:02 |
MTDiscord |
<Jordach> only singlenode is unaffected |
23:03 |
MTDiscord |
<Jordach> in otherwords rather than using on_gen directly, consider using minetest.after with a 0 delay |
23:03 |
MTDiscord |
<Jordach> it'll run the generation on the next tick |
23:03 |
erle |
wait what hmmm |
23:03 |
erle |
it's that easy? |
23:04 |
MTDiscord |
<Jordach> just pipe the vmin, vmax etc args into an after |
23:04 |
MTDiscord |
<Jordach> they shouldn't theoretically expire |
23:04 |
erle |
i believe it when i see it |
23:04 |
MTDiscord |
<Jordach> isn't it weird af that i know more about mapgen shenanigans than paramat |
23:05 |
erle |
not weird, haven't seen paramat in a while? |
23:05 |
erle |
also everyone has their special topics |
23:05 |
erle |
i remember how hard it was to convince people that yes you can explode tnt in invisible mapblocks |
23:05 |
MTDiscord |
<Jordach> his fixes usually involve popsicle sticks and hot glue |
23:05 |
erle |
bc they are just invisible, they are simulated server side |
23:06 |
MTDiscord |
<Jordach> yeah i've noticed the all black world bug |
23:06 |
MTDiscord |
<Jordach> happens a lot when c_air isn't propagated |
23:06 |
MTDiscord |
<oneplustwo> What does it mean for a mapblock to be invisible? |
23:06 |
MTDiscord |
<oneplustwo> Unloaded? |
23:06 |
MTDiscord |
<Jordach> basically the whole thing is content ignore for no actual reason |
23:06 |
erle |
oneplustwo, it will not be sent to the client basically |
23:06 |
MTDiscord |
<oneplustwo> Is it intended? |
23:06 |
MTDiscord |
<Jordach> there does seem to be a race issue |
23:06 |
MTDiscord |
<Jordach> because my mapgen when it goes wrong by one digit causes them |
23:07 |
MTDiscord |
<oneplustwo> So it's a bug, not a feature. |
23:07 |
MTDiscord |
<Jordach> i suspect the on generated multithread patch is the source for these issues |
23:07 |
erle |
oneplustwo i guess it is intended in the way that by making the map border permanently unloaded, you get mod compat for free |
23:08 |
MTDiscord |
<Jordach> this is a massive hunch because others had concerns it may introduce issues |
23:08 |
MTDiscord |
<Jordach> even if it's not being used |
23:08 |
MTDiscord |
<oneplustwo> Why do you get mod compatibility for free? |
23:08 |
erle |
oneplustwo basically mods have to deal with unloaded mapblocks anyway. if the behaviour at the map border was anything else than “permanently unloaded” you'd need special code for that so your mods don't explode once they encounter the map border |
23:09 |
MTDiscord |
<Jordach> well content ignore or nil is what minetest returns to mods that attempt to access mapblocks that aren't actively loaded |
23:09 |
erle |
basically, the behaviour is carefully engineered so that most mods will not cause problems |
23:09 |
erle |
there are a few caveats of course |
23:09 |
MTDiscord |
<oneplustwo> So this "feature" is only intended to happen at the map border? |
23:10 |
MTDiscord |
<oneplustwo> Oh, I think I understand now, nvm. |
23:10 |
erle |
most importantly, any mod coder who thinks that a mapblock will *eventually* load should go back to minetest bootcamp |
23:10 |
erle |
i have seen code like that, where someone just blocks until a mapblock loads |
23:10 |
erle |
it's stupid for all kinds of reasons |
23:10 |
erle |
the most important one being that well, it blocks forever at the map border |
23:11 |
erle |
also by having an outer shell you get neat structure placement |
23:11 |
MTDiscord |
<Jordach> when i was implementing voronoi cells as v3s16s (the .Y field is used as an informational bit) i wasn't using floating point operations to determine the cell |
23:11 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/747163566800633906/958503769396621322/unknown.png |
23:12 |
erle |
oneplustwo if you ever wondered how you can have half a structure at the map border, the secret is that it is half inside an unloaded area |
23:12 |
MTDiscord |
<oneplustwo> So when you say that you can explode tnt in invisible mapblocks, you mean that you can both place the node and get it to produce the tnt entity? |
23:12 |
erle |
unloaded on the client, that is |
23:12 |
MTDiscord |
<Jordach> yues |
23:12 |
MTDiscord |
<Jordach> it happens "off screen" but the server still knows about it |
23:13 |
MTDiscord |
<Jordach> like green screen ninjas |
23:13 |
MTDiscord |
<Jordach> the effect is still performed, but it's not visible to clients |
23:13 |
erle |
well, easiest way to prove the existence of nodes and entities in invisible map parts is to a) place rails there (you can do that using vanilla client) b) go on the rails with a minecart |
23:13 |
MTDiscord |
<oneplustwo> So basically the server has access to some mapblocks near the border, while the client doesn't. |
23:13 |
erle |
because entities will be rendered there, jordach you are wrong about it being entirely invisble |
23:14 |
MTDiscord |
<Jordach> by ninjas i meant world changes |
23:14 |
erle |
ah yeah |
23:14 |
MTDiscord |
<Jordach> not that entities can be rendered, because i've had raycasts go beyond c_ignore mapblocks |
23:14 |
MTDiscord |
<Jordach> and still function as intended |
23:14 |
erle |
i once went to the world border of clamity and made an invisibe water source |
23:14 |
erle |
invisible, well … in reality it was just a corner with 2 adjacent water sources |
23:14 |
erle |
take water out of the corner, it gets replenished |
23:15 |
erle |
also some fun-lover wrote their name outside of the map using enchantment table book entities on oysterity server |
23:16 |
MTDiscord |
<Jordach> entities have no real limit so to speak |
23:16 |
MTDiscord |
<oneplustwo> So the client just can't view what's going on in the invisible mapblock, but it can interact with it? |
23:17 |
erle |
oneplustwo, you need to trick server-side code into doing stuff there |
23:18 |
MTDiscord |
<oneplustwo> So the engine by default doesn't allow interaction with the invisible mapblocks, but mod code can help you bypass that? |
23:21 |
MTDiscord |
<Jordach> yep |
23:21 |
MTDiscord |
<Jordach> remember minetest as a client can only see what the server sends it |
23:26 |
erle |
there is an example |
23:26 |
erle |
exception |
23:26 |
erle |
you can trivially place nodes in invisible mapblock space |
23:27 |
erle |
it's fun to race this thing btw. i once managed to explode part of a mapblock after it had been c++ generated, but before the lua code had replaced all of the stuff. |
23:28 |
erle |
it's *very* hard to reproduce though |
23:28 |
erle |
the result was a crater that was half-dirt-with-grass |
23:28 |
erle |
i think |
23:29 |
MTDiscord |
<oneplustwo> Interesting. |
23:29 |
erle |
regardless, it's trivial to figure out that minetest is not exactly threadsafe, just compile it using tsan |
23:30 |
erle |
not only will it slow to a crawl, you get tons of warnings |
23:30 |
erle |
(the “slow to a crawl” part is 100% tsan's fault) |
23:31 |
MTDiscord |
<oneplustwo> " Typical slowdown introduced by ThreadSanitizer is about 5x-15x." |
23:31 |
MTDiscord |
<oneplustwo> Yep |
23:31 |
erle |
oneplustwo, easiest way to place nodes in invisible space is to noclip out there and target the outer shell of a node adjacent to invisible space |
23:32 |
erle |
for various reasons that should be entirely obvious it would be extremely stupid to make this impossible, but let's not go there ore some gremlins get ideas and chew off the wings of the plane |
23:32 |
MTDiscord |
<oneplustwo> I thought you said the server prevents that by default? |
23:32 |
erle |
take some entity-rendered node and you'll see |
23:33 |
erle |
i wrote some stuff on the top clamity world border using duped ender chests |
23:33 |
MTDiscord |
<oneplustwo> So it would work with an entity-rendered node, but not a "regular" node, right? |
23:33 |
erle |
nah, the regular node is still there |
23:34 |
erle |
fleck used to hide his loot in invisible space by using pistons to push it there or get it back |
23:34 |
MTDiscord |
<oneplustwo> Wait, so can the client interact inside an invisible mapblock? |
23:34 |
erle |
only in a very limited way, as far as i can see. you can place nodes. |
23:35 |
erle |
i devised something using hoppers to hide stuff in invisible space |
23:35 |
erle |
i also made a nether portal that was half in invisible space hehe |
23:36 |
MTDiscord |
<oneplustwo> So you can't do stuff like access metadata in an invisible mapblock? |
23:36 |
erle |
look you can't do anything there |
23:36 |
erle |
to the client it's all ignore |
23:36 |
erle |
for good reasons |
23:38 |
MTDiscord |
<oneplustwo> How can you place a node then? |
23:38 |
erle |
i told you |
23:38 |
erle |
target the outer part of a node in visible space |
23:38 |
erle |
the part that is bordering invisible space |
23:38 |
erle |
or just use /setblock in mcl* game lol |
23:38 |
MTDiscord |
<oneplustwo> No, I mean ignoring the client logic. |
23:39 |
erle |
since you are a known cheater, i am pretty sure you can figure out how to place any node anywhere? |
23:39 |
erle |
wasn't there some waspsaliva command for it? |
23:39 |
MTDiscord |
<oneplustwo> Yeah, sure, trivial with a csm, no? |
23:39 |
erle |
try it |
23:39 |
erle |
i bet you find funny edge cases |
23:40 |
erle |
though i must warn you, if you place a node too far out, mods like observer crap their pants, but i'm not sure if it is an engine bug. |
23:41 |
MTDiscord |
<Jordach> basically the minetest network protocol is more like the x11 protocol than an actual game protocol |
23:41 |
MTDiscord |
<Jordach> theoretically with luasockets you can link up singleplayer instances |
23:41 |
MTDiscord |
<oneplustwo> Wait, so what server-side code trickery is required then? |
23:41 |
MTDiscord |
<Jordach> yes |
23:41 |
MTDiscord |
<Jordach> the server can do what it pleases |
23:41 |
MTDiscord |
<Jordach> the clients just have to accept it |
23:42 |
MTDiscord |
<Jordach> mods are server side and are thusly immune to client side behaviour |
23:42 |
MTDiscord |
<Jordach> that includes CAO/SAO |
23:42 |
MTDiscord |
<Jordach> just because it's not visible or rendered on the client doesn't mean that existence suddenly ends |
23:43 |
MTDiscord |
<Jordach> also >tsan |
23:43 |
MTDiscord |
<Jordach> that's like using a M1 Abrams to go to race at an F1 circuit |
23:43 |
MTDiscord |
<oneplustwo> ik, but i don't see what is meant by server-side code trickery. seems more like tricking the client into interacting in an ignored area to me |
23:44 |
MTDiscord |
<Jordach> yes because the client is dumb as rocks |
23:44 |
MTDiscord |
<Jordach> for all the server knows it may not even be a minetest client |
23:44 |
MTDiscord |
<Jordach> ie passes the "duck test" |
23:44 |
MTDiscord |
<oneplustwo> Just make a "client" that sends the required packets manually XD |
23:45 |
MTDiscord |
<oneplustwo> That's what people do to DOS MT servers, right? |
23:45 |
MTDiscord |
<Jordach> if it looks like minetest, makes a sound like minetest, it probably is minetest |
23:45 |
MTDiscord |
<Jordach> the server cannot verify if the client is of minetest/minetest or a fork |
23:45 |
MTDiscord |
<Jordach> or even a shell script that simulates a client |
23:47 |
erle |
there are several non-minetest clients |
23:47 |
MTDiscord |
<oneplustwo> Even if the entirety of minetest was redesigned, would it even be possible to identify a "real" client from a shell script? |
23:47 |
erle |
there is this one python script that exposed the state machine bug |
23:47 |
erle |
oneplustwo a) no b) it is a strength of minetest that the client is hella dumb |
23:48 |
MTDiscord |
<Jordach> dumb clients means a lack of dealing with two separate lua threads that need to cross communicate and share data |
23:48 |
erle |
i think almost everyone who advocates for client side mods on grounds of “better prediction” has not ever read up on the design of distributed network applications |
23:48 |
erle |
a good starting point is roy fieldings phd thesis |
23:48 |
MTDiscord |
<oneplustwo> Better prediction? |
23:48 |
MTDiscord |
<oneplustwo> Better prediction of what? |
23:49 |
erle |
better client side prediction |
23:49 |
MTDiscord |
<Jordach> my position on SSCSM is that clients can change what ever the fuck they want to locally, but have no influence on the server state |
23:49 |
MTDiscord |
<Jordach> think a CAO in place of the traditional wield item |
23:49 |
erle |
the argument i have witnessed the most for server-sent client side mods (an endevour which i think is tremendously stupid) is that then the server can send code to better predict client side changes |
23:50 |
erle |
for example, advanced trains going around curves |
23:50 |
MTDiscord |
<oneplustwo> What part of the client is attempted to be predicted? |
23:50 |
MTDiscord |
<oneplustwo> Or is the client trying to predict stuff from the server? |
23:50 |
erle |
currently, movement prediction for entities is a straight line |
23:51 |
erle |
i.e. it gets jerky if you have less packets than one every frame or so? |
23:51 |
MTDiscord |
<Jordach> Replacing it with curves might be a start |
23:52 |
erle |
regardless, the solution is, of course, to a) never have state you want to sync back to the server, as jordach said b) communicate the prediction in a format that is context-free, regular or calc-regular |
23:52 |
MTDiscord |
<oneplustwo> Is that why when there are massive lag spikes in a server, the animals start moving in a straight line into walls comically? |
23:52 |
erle |
i.e. whatever hints the server sends to the client must not be more complex than what a deterministic pushdown automaton can evaluate |
23:52 |
MTDiscord |
<Jordach> Yes because clients don’t know |
23:52 |
MTDiscord |
<Jordach> If clients don’t see they don’t do |
23:53 |
erle |
otherwise you have a halting problem in movement prediction code |
23:54 |
MTDiscord |
<Jordach> I’ve experimented with the idea of syncing Lua states with my boomer shooter |
23:54 |
erle |
coincidentally, a lot of the people who shout the loudest for server-sent CSMs to make movements in their mods more fluid can't actually write performant lua code ;) |
23:54 |
MTDiscord |
<Jordach> Basically my problem is that the display protocol that MT uses can’t handle lots of things going on before turning to a pile of dog shit |
23:54 |
MTDiscord |
<oneplustwo> Wait, they want servers to be able to send csms to the client? |
23:54 |
erle |
jordach curves are it, yes. my idea was to borrow from svg path syntax. you don't need to predict more than a second or so in the future anyway under normal circumstances. |
23:54 |
MTDiscord |
<Jordach> The alternative is to use singleplayer mode and network the states like Doom or Quake does |
23:55 |
MTDiscord |
<oneplustwo> That sounds like a possible security risk? |
23:55 |
MTDiscord |
<Jordach> Not really |
23:55 |
erle |
jordach see here https://forum.minetest.net/viewtopic.php?p=406922&sid=8b5ccea4579c67f7b8f6df5f5188b64a#p406922 |
23:55 |
MTDiscord |
<Jordach> CSMs are already sandboxes |
23:55 |
erle |
it is a huge security risk |
23:55 |
MTDiscord |
<oneplustwo> Can't the sandbox feature be disabled though? |
23:55 |
MTDiscord |
<Jordach> As long as users can reject or download and inspect them ie join the server twice to use them |
23:55 |
erle |
basically, no one knows how to securely sandbox code that is more complex than … what a deterministic pushdown automaton can evaluate, see above. |
23:56 |
erle |
i.e. if you can parse it with a) a regex b) by counting matching opening and closing braces/parenthesis c) a regex + length fields |
23:56 |
erle |
then you are good |
23:56 |
erle |
anything more complex is a nightmare |
23:57 |
MTDiscord |
<Jonathon> sscsm is no worse than servers already exploiting bugs in minetest clients |
23:57 |
erle |
oh, it is much worse. |
23:57 |
MTDiscord |
<Jonathon> "coincidentally, a lot of the people who shout the loudest for server-sent CSMs to make movements in their mods more fluid can't actually write performant lua code ?" well, neither can you |
23:57 |
erle |
at least the current bugs can all be fixed |
23:57 |
erle |
but any SSCSM thing would be there to stay forever |
23:58 |
MTDiscord |
<Jordach> If you really want SSCSM implement it yourself for LuaSocket multiplayer games |
23:58 |
erle |
Jonathon the most you can prove with that argument is that i am a bad lua coder, which i will be freely admit. it's an attack on the messenger, not on the message. |
23:58 |
MTDiscord |
<Jordach> Most of the architecture in my boomer shooter is all in memory which means minetest only needs to add client side entities |
23:59 |
MTDiscord |
<Jordach> The server doesn’t need to give two shits about a tracer object but rather care if it’s valid or not |
23:59 |
erle |
jordach have you looked into waspsaliva code for inspiration? |
23:59 |
MTDiscord |
<Jordach> No I’m not 13 years old and have delusions of being the best griefer evar!!1 |
23:59 |
erle |
waspsaliva has a bit of clientside enhancements to minetest |
23:59 |
erle |
come on lol |