Client-side validation/prediction of protection events

[Klaranth]

baijin Client-side validation/prediction of protection events before they are sent to server for rollback, nullifying block-break lag and stalking/killing people in their base. Protection and areas mods baked into game engine. Flowing liquids cannot escape protection area/ enter area.

SX btw, there's been some talk about sscsm on multiple different leves. pretty sure some of it will get through sooner or later and will allow improving client side behaviors. it looks like first steps will be just visual effects but that is what gives idea about how more complex sscsm need to work and how people will utilize it

[Klaranth]

baijin protection and areas mods have toggle to disallow setting /sethome instead of it being just on on this server (if migrating, all existing areas can already be toggled on), can be on by default but togglable

[Klaranth]

SX sethome should not work on protected areas, does it?

baijin ive lagged and sethome in protected areas before somehow, but no it doesn't, but i think it would be a great feature for the areas and protection mods

SX — 01/04/2022 and if it does is it difference between unified inventory and chat command? protection mod allows giving access so I think you should be able to make "sethome" location inside protected area not sure if it would work but I think you could even open single node for sethome and place active stealthnode inside to protect it from node placement. not sure if something can be used to remove single untargettable unprotected node surrounded by protection...

Huhhila but getting people to leave could indeed utilize such expel feature (would be nicer than the rather violent in-world options for same)

baijin if you wanted to let people sethome there you could make them stand in the concealed stealnode spot if it was labeled or like a corner

SX I can try to think about other weird solutions, like how about locking your private space first. then build jumpdrive that can send unwanted guests up to 18k edge in a way that they will cross border and get teleported to spawn

baijin or have a timer deactivate the floor so they get dumped at the edge of the map and it comes back

SX as a bonus you can send them message "warning you're entering reserved area" and possibly "warning, you're entering warzone" just need some hard to crack nodes to protect ship that is used in jd "ship"...

[SwissalpS]

with compass you can teleport to protected areas, also missions can do that too.

[Klaranth]

See also #251

[Baigle]

I mentioned client-side validation and incorporation enhancements so we don't have all our eggs in one or two baskets.

https://content.minetest.net/threads/2077/

[Klaranth]

Huhhila Semi-related ideas: Highlight/recolor area and protbox names in the UI when within 1-2 of their border. And/or formally define a border zone.

SX For area protection support it would probably be better to allow giving area ids for jumpdrive. Then when jumping and areas are explicitly defined check area boundaries and allow moving over sized areas with similar +2m to all direction limits. Would keep radius for actual jumping and areas as separate self contained functionality. Also would additionally allow excluding areas at target location so that ship wont grab areas from target when jumping next time. Basically keep complexity low and things together better while still allowing even more actual functionality without messing up platform for future updates.

Huhhila Hmm... for drone carriers, would that need full list of drone areas? Or should such areas be in a tree anyway?

SX (could even allow setting/clearing areas with digiline messages for interesting setups) Each engine of course would need its own list. Default would simply be old behavior, just move what is contained without including larger or excluding smaller. So if you use feature then yes it would need drone areas for carrier engines. If drones are not inside then jump would fail without override ability (which could be just reconfiguration with digiline messages) For setups that do not explicitly use feature it would be exact same behavior as it is currently. For area id setup another option would be to just ignore areas that are outside of radius, it is just something to decide: error or skip.

[S-S-X]

Last comment seems to have mixed up different things and additionally has nothing to do with this this issue. I think it is probably 2 new ideas instead and missing first comment(s) about jumpdrive area proposal.