erlehmann's wishlist & todos

[MisterE]

Everyone always speaks about entity movement prediction and better physics when it comes to SSCSM but neither should be SSCSM but a built-in part of the client.

I'm not arguing, but more genuinely curious: how could one implement special player physics like wall climbing with only general engine APIs and no client side scripting?

you could have a wide range of player and entity movement capabilities implemented in the engine, and then allow the server to set a table of properties that pick a specific combo of physics properties. Basically, you could expand the existing api (significantly). then it is server sent properties tables instead of server sent mods. All you have to do is anticipate a much wider range of player physics possibilities.

specifically for wall climbing, implement it as I assume the slippery group is implemented. if the player is agaist a node that there is some way to know is climbable, allow them to climb it following a set of server-sent parameters.

I would love to see a gravity-direction parameter, a separate player-vertical axis parameter, and various physics modifiers that allow you to separately control friction, the effect of control input, setting velocity instantaneously, etc. all that could be implemented if the usecases were pre-anticipated. a good way to anticipate is to examine several genres of 2d platformer and 3d games, and anticipate that someone will try to implement smth similar in minetest

[wsor4035]

could we please not add more hardcoded nightmares in the engine?

[MisterE]

he asked how it could be done without sscsm. sorry but that means a certian amount of hardcoding. Don't you realize that this would mean less hardcoding than is currently done? But it seems that that was a snide response :|
I struggle not to read that as a strawman argument or something.

I don't care how better physics control is implemented, but it does need to be implemented, with a simple and functional system, and it needs to start somewhere. if we are going to solve the sscsm problem, great! if we are going to indefinately postpone it because noone can think of a secure way to do it, then lets implement better physics control with a system that we can be sure is secure

if you hardcode some basic physics modifiers that allow you to combine them to meet most usecases imaginable, is that actually hardcoding, or is it providing a secure and simple programming language?

[Linuxdirk]

how could one implement special player physics like wall climbing with only general engine APIs and no client side scripting?

By extending the API to allow such movement and having the client perform the action and send it to the server. The server then validates and either confirms or rejects the movement action.

[sorcerykid]

However, SSCSM would still be the superior solution for interactive entity stuff (say, a mobs mod where monsters do more than just run at you randomly, but showing some "intelligence" and making interactive movements on the spot

I agree somewhat on the first part but not the second. Since all clients can interact directly with mobs (and witness the effects of those interactions), it makes more sense that the AI for mobs is entirely server side such that the server acts as centralized authority to mediate those interactions. Otherwise, every client would have to report the status of its "decisions" to the server, and if there were conflicts between other clients, then the server would somehow have to resolve those conflicts, which essentially doubles the stream of logic processing. Not particularly efficient, moreless advantageous.

About the only exception to this would be raw sensory data, such as a mob "hearing" the footsteps of a player. That obviously could be handled mor effectively by the client, since that is where the footstep sounds originate. But then again, this still wouldn't require client-side modding, only extending the network protocol to transmit such data back to the server for the actual sensory processing.

[erlehmann]

I do *not* want an autoforward that avoids danger. This removes the player from the decision loop.

And it could be quite easy to avoid though! You could make a variable or scope acquire a “taint” flag when it gets information from the game world and disable any movement for as long as that information is in used or in scope.

Oh, I misunderstood then. Although, the more CSM APIs we'd add, the more of these edge cases and "taint" flags would start popping up and making things a complicated mess.

You only need one flag per function, i.e. “Was information read from the world relevant to this?”

Autoforward? CSM could not make the player move once it knows where obstacles are.
But “adjust the direction towards my waypoint and then go that way” would still be possible.

Autokill? CSM could not make the player punch something once it knows all the entities.
But “continue punching if i click once, stop if i click a second time” would still be possible.

Autominers? CSM could not make the player dig a node once it knows one is there.
But “mine a straight shaft 2 nodes high and 60 nodes deep” would still be possible.

[v-rob]

You only need one flag per function, i.e. “Was information read from the world relevant to this?”

Another problem: suppose CSM A reads blocks in the world, and CSM B is an autodig. Do we allow CSM B to dig then? We'd need a "taint" flag per-CSM. Oops, but CSM A and CSM B are actually working together, and CSM A makes a file while CSM B reads it, allowing it to see nodes in the world. Do we need to "taint" flag files too? Maybe CSM A puts that information somewhere else than just files. It gets too complicated.

[erlehmann]

You only need one flag per function, i.e. “Was information read from the world relevant to this?”

Another problem: suppose CSM A reads blocks in the world, and CSM B is an autodig. Do we allow CSM B to dig then? We'd need a "taint" flag per-CSM. Oops, but CSM A and CSM B are actually working together, and CSM A makes a file while CSM B reads it, allowing it to see nodes in the world. Do we need to "taint" flag files too? Maybe CSM A puts that information somewhere else than just files. It gets too complicated.

No file writing while information that is tainted is in scope.

I would start with exactly one taint flag that tells if information of the game world has been read;
as long as that information is in scope, a bunch of CSM stuff would just not be permitted at all.

[v-rob]

No file writing while information that is tainted is in scope.

I would start with exactly one taint flag that tells if information of the game world has been read;
as long as that information is in scope, a bunch of CSM stuff would just not be permitted at all.

How long is "in scope"? As long as the player is nearby? While the variable is literally in scope in Lua? Both seem like bad solutions.

[erlehmann]

No file writing while information that is tainted is in scope.

I would start with exactly one taint flag that tells if information of the game world has been read;
as long as that information is in scope, a bunch of CSM stuff would just not be permitted at all.

How long is "in scope"? As long as the player is nearby? While the variable is literally in scope in Lua? Both seem like bad solutions.

As long as there is any way to compute things based on the information.

How WoW did Lua taint: https://www.lua.org/wshop08/lua-whitehead.pdf

[Desour]

How WoW did Lua taint: https://www.lua.org/wshop08/lua-whitehead.pdf

It sounds like they use a modified version of Lua.
Implementing such a thing just for CPCSMs, that aren't very popular anyways, would probably require too much work to be justified, especially as such things can easily be removed by changing a few lines and recompiling.

[x2048]

I'm not arguing, but more genuinely curious: how could one implement special player physics like wall climbing with only general engine APIs and no client side scripting?

Can this be a possible way?

The basic physics rule is already present in the engine: there are ladder and vine nodes that allow climbing.

The visual effect could be coded in the engine and declared via API in two steps:
1. On the player model define key frames for states and transition animations between states (e.g. standing, lying, sitting, flying, swimming, climbing etc.)
2. For each node define state of the model and parameters (for example, facing towards the wall while climbing).

When player moves between nodes, the engine tracks state change and animates accordingly, client-side.