Enforce minimum scale for user root

[gentlecolts]

Is your feature request related to a problem? Please describe.

There are very few if any cases where it is a good thing for a user to scale beyond a certain limit, and as I accidentally found out last night, there are very easy cases to make which can render an entire session unusable as a result of such

Describe the solution you'd like

Users should not be able to be shrunk beyond a minimum volume. This should be a reasonably small value, as small as possible while still retaining functionality. This constraint should apply to user root global scale, and does not need to go further, as there may be cases where certain avatars may wish to, for example, flatten on a given axis.

I would suggest that this constraint be applied on any attempts to read user root scale, ex: in case where some error occurs and the slot containing users becomes zero-scale. In this particular failure case, there may also be implications for position as well, and if the engine is not already handling this, perhaps it'd be wise to fail position to 0,0,0.

Describe alternatives you've considered

the incident that caused me to submit this ticket was pure skill issue on my part, an alternative would be for me to simply get good, however i feel like this has broader comfort and safety implications and should be addressed as such.

Ultimately the intent of this ticket is addressing the failure case where sufficiently low scale can cause a user to become unable to act in any way, and respawning is not always a sufficient solution, if there are other means of addressing this core problem, that's fine too

Additional Context

I was making a funny gag item that shrinks users and accidentally disconnected some wires without considering the consequences when I was making a change, resulting in it continuously setting every user's scale to 0. At this scale, it becomes impossible to interact with anything in-world, making it impossible to undo this mistake. This kind of case is trivial to reproduce and subsequently exploit by a bad actor should one wish to grief other users

Requesters

zangooseoo

[ko-tengu]

I like this idea and think it should be able to be set similar to the default avatar scale or added to that component as a general option.

It is also worth noting the existing Locomotion Permissions component that allows you to set this per world once someone knows about it, but having a user setting as a safety net is an useful consideration.

[ProbablePrime]

The Component: LocomotionPermissions can restrict someone's scale, in your own worlds you can set the MinScale property to prevent scaling below a certain scale.

However, the default value for this is 0 which effectively means there is no restriction.

If we were to change default value, we'd need a good absolute minimum value, before negative experiences start to occur as I don't want to restrict those who like being small.

I think @shiftyscales can help with a sane value for this.

[ProbablePrime]

Correction, the default value in new worlds will be set to: 0.05f for non-builders

Shifty, is this value reasonable, or could we raise it a little?

[gentlecolts]

If we were to change default value, we'd need a good absolute minimum value, before negative experiences start to occur as I don't want to restrict those who like being small.

Oh yeah definitely agree. In my mind this value was "as small as possible without having too much of a problem with floating point error", but a more "realistic" number's probably fine too

[ProbablePrime]

I tested this at 0.01 and there's some floating point issues, these go away at the default value of 0.05.

So my current proposal is to raise the default minimum to 0.05 for all roles in the default permission set.

This value could be overwritten on a world by world basis. Lower values are possible but I noticed graphical issues that weren't the traditional floating point symptoms but did cause flashing or glitching of textures and lighting which are unpleasant to look at.

[Frooxius]

We specifically have the default limit for non-builders. The assumption here is that if someone is a Builder, they already have full control over the world, so they're unbound.

However other part of this is - the permission is for the user scaling themselves, not for other things in the word scaling them. We can't make assumptions on what the world or gadget requires - perhaps it has a reason to change their scale.

If user is building something, it's their responsibility to enforce whatever limits they need.

[gentlecolts]

If user is building something, it's their responsibility to enforce whatever limits they need.

I don't think I 100% agree with this when you factor in the social aspect of the platform. While I certainly agree with using caution when it comes to constraining what users can do, Resonite isn't just a development tool, and the builder of a world doesnt have 100% control over what's in it, and in fact may not even be the person hosting the world. In the case I illustrated in my original post, that was just an during-development accident, but one that cost me some amount of work, and made the session I was in no longer usable. It also made me think of how much worse that could have been if it wasn't just me by myself making a dumb 5 minute toy.

[Frooxius]

@gentlecolts My problem with that is that this is that with building, there's a million different ways to mess things up. This is just one of them. Addressing all of them individually like this is not really feasible and it's just going to be endless attempts at trying to patch things out ad-hoc, only for users to find different ways to do it. And we'd end up with a patchwork of things as a result.

When you're building, you have to take certain amount of responsibility for what you're doing, since you're given very powerful tools. That means that you can shoot yourself in a foot with them.

There are approaches that are more generalized for stuff like this, like hard permissions, which will provide more generalized barriers on what can interact and modify stuff and such.

I think in this case we should provide mechanism to suspend ProtoFlux in the world in some way. Perhaps with this: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2008 ?

[gentlecolts]

I think that'd be a good addition actually (alongside the other proposal of changing the default for LocomotionPermissions). A general purpose ability to suspend protoflux would solve a lot of problems way beyond the scope of this ticket, and it feels kind of like an equivalent to noscript in browsers, I like that ticket

[shiftyscales]

Shifty, is this value reasonable, or could we raise it a little?

I personally have an avatar that is a "borrower" (like from the movie Arrietty) and sits right around 0.05 scale. I would not want to see these defaults adjusted at all, @ProbablePrime- as there is still reason to go smaller still- I routinely do- while building worlds I will often get extraordinarily small for high level of precision while moving gizmos, etc- even smaller than 0.05 as some areas in my world are scaled so a 0.05 scale user feels like they are at 1 scale- and there is still need to have room to scale below that.

I don't want there to be a limit at all- at least for builders by default. If a particular world/experience requires higher limits they can be set on a per-world basis already. I don't think this is something that should be adjusted globally/by default at all.

I tested this at 0.01 and there's some floating point issues, these go away at the default value of 0.05.

It also isn't as simple as this, because there is a high dependency on whether you are using a SteamVR or Oculus native headset as far as what a "usable" value would be. Both runtimes react very differently, and produce different issues.

Likewise- users have different tolerances to the floating point imprecision/rendering issues, so there isn't a good 'one value fits all' option here. (E.g. this also has dependency on whether or not the user has an AvatarRenderSettings component, and what values they have that set to.)

For a majority of cases where this might be an issue, gestures such as the emergency respawn still works if a user needs to get back to a normal scale and can't access their UI/scale themselves back by other means.

Functionally the solutions I see to the problem case presented in this issue would be #2008 as @Frooxius highlighted, and by extension, the hard permission system (#1103) which could selectively prevent the scale nodes from executing for as long as would be needed to recover the world/object.

[TisFoolish]

Personally I think a minimum should be added, but it should be very near the edge of when floating point inhibits using your dash, your context menus, scaling, etc. If a user, like shift, wants to go to a super micro size, one that is at the edge of unusability, they should be able to.

Having some floating point wiggliness is fine, the op isn't about not letting users experience that. The op is about preventing users from making themselves so small that they're unable to interact with anything but gestures.

Speaking about gestures, the emergency respawn gesture requires knowledge of it (gestures in general have terrible discoverability), the ability to physically do the gesture, and you have to remember it during a period that might be causing some users to panic.

[shiftyscales]

but it should be very near the edge of when floating point inhibits using your dash, your context menus, scaling, etc.

That was what I was getting at above, @TisFoolish - there isn't a single value that would work for all users as there are a ton of variable factors that play into that.

Speaking about gestures, the emergency respawn gesture requires knowledge of it (gestures in general have terrible discoverability), the ability to physically do the gesture, and you have to remember it during a period that might be causing some users to panic.

There are other existing issues that focus on gesture accessibility, e.g. #541. Discoverability of those could also be improved by other issues, e.g. #539.