Neos-Metaverse / NeosPublic

A public issue/wiki only repository for the NeosVR project
196 stars 9 forks source link

Request: Ability to restrict a world from being hosted on a headless #1215

Open ProbablePrime opened 3 years ago

ProbablePrime commented 3 years ago

I have certain worlds which don't function on headless hosts due to host checks, or other gameplay mechanics which need the "Host User" to be an actual user.

I'd like to restrict these from being ran on headless hosts to avoid situations where I receive bug reports from headless host managers or users who cannot experience my creations due to them being hosted on headless sessions.

Frooxius commented 3 years ago

I'm not sure if this would be a good approach, as in the future Neos might depend on headless a lot more, with headless sessions being started implicitly when the user opens a world and generally the world shouldn't differentiate too much on who hosts it.

What exact behaviors does the host user need that are breaking the experiences?

ProbablePrime commented 3 years ago

Hey Froox,

Thanks.

So I have buttons and controls which are reserved for just the "Host User" this includes things like world management, Round management and other administrative parts of the world. These are designed to prevent users other than the host from pre-emptively advancing the world or its contents before everyone is ready to proceed.

This comes up a lot in exploratory or event based maps where the world host is trying to experience the map for the first time but other users rush ahead pushing buttons, dials or advancing cut scenes.

In these cases I use Host User checks to ensure the host or owner of the world is the one carrying out these actions.

On a headless host the host user is the headless user so none of these checks pass and the map cannot continue.

Unsuspecting headless host managers then add my world to the headless clusters because its cool and then I get 3am pings on Discord about my world being "Broken".

Keeping the owner in charge of what goes on in a world is my priority in these cases so any other solution in that area works too.

Electronus commented 3 years ago

Ah yes I believe our werewolf world does this as well to stop anyone but the host from actually starting the game.

Frooxius commented 3 years ago

Hmm, I think better approach for this would be to have a separate form of designation of who is able to control these settings. Perhaps having a way for headless to define "owner/admin" of the session could work well or perhaps choosing the first person with certain role level that joins (e.g. Builder/Admin).

Would that work for you? I don't really want to make worlds non-hostable by headless, because that would cause major problems in the future once certain features come, like implicit hosting (you open a world through world browser and it automatically spins up a headless for you to host it).

TehTurk commented 3 years ago

I suggested this as well as the discussion came up originally between me and Prime when I had added the Lazer Tag world too my headless to showcase things but in hindsight didn't really test it because I was a bit preoccupied at that the time and just wanted to cycle some worlds for the community. After notifying me I took it down.

I can see the issue though as having things specified to host can have it's problems at times as well and expressed this as well But there are cases where we need to code stuff around Host having control, or at least maybe a way for a User to be a Psuedo Host? It's a bit more on the sticky side of state management/session owner.

But then this also later on adds to the issue of Who owns a session in case of a Public Server as well once Public Servers are a thing for Neos.

ProbablePrime commented 3 years ago

I always assumed further advances in headless/servers would handle the host user properties differently. I'm not sure how but something more elegant than a fake "host user" i don't know.

So really the only options here are to invent a system that's basically copied from VRChat. In VRChat the first person in the world is registered as the world master(i'll use/suggest using a better term (https://twitter.com/mislav/status/1270388510684598272)). But basically the first user who joins an empty session get's registered as the "owner" of that session.

Buttons and interactions within the world then can prevent interaction based on if this person is that "owner".

As implementing this system might take some time, I guess i'll just shove a giant text object at spawn that warns users if it's being hosted on headless for now.

shiftyscales commented 3 years ago

Specific to the experiences you've made, it should be possible to code such a system into your experiences as well I would think, @ProbablePrime. In place of a host user node, you could use a ValueField that has the first non-headless user to join the session written to it. In the context of headless hosting, worlds can be set to reset while empty, so for each time the world is reset, the first user to join it will be considered as the host.

You could use any other arbitrary mechanism as well- first to press a button, or whatever other means you desire.

ProbablePrime commented 3 years ago

That was my plan Shifty thank you.

I feel we need a solution here that leaves the world creator in control when these server enhancements light up. Of course I can shove this stuff on a blueprint or similar but that doesn't feel as nice as some sort of built in solution.

I'll have to give this more thoughts.

Frooxius commented 3 years ago

I think best solution would be to have the concept of an "IsOwner", which could be a simple node, as you check the host. When hosting, host and owner would be the same, otherwise they would be determined in some other way - either explicitly through the headless config or implicitly by joining first with a certain role level or the user who starts the automatically spun up headless session.

There are few main questions though:

ProbablePrime commented 3 years ago

Your comment basically matches the "Master" concept from VRChat so users should be familiar with the concept.

Thank you for the discussion.