search

Neos-Metaverse / NeosPublic

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

Creating TouchValueOption with type of FrooxEngine.User crashes the game #349

Closed ProbablePrime closed 4 years ago

ProbablePrime commented 4 years ago

Similar to value field with FrooxEngine.User.

The moment i hit create on this i knew I would crash but still would be good to add guards for other users.

Thanks!

TehTurk commented 4 years ago

Likewise. Realized when I made it but didn't think of it much then, but also did this with valueuseroverride. Because you really can't create users or at least the type, would be neat if we had some sort of dummy user, or bot user created on any type of interaction like this as a failsafe?

Frooxius commented 4 years ago

Thanks, I'll have a look! It's probably uncaught exception of trying to make an invalid type somewhere within t hat. It might tricky though as there are more complex validation rules.

@TehTurk I'm not sure I understand. What kind of failsafe do you mean? There's ReferenceUserOverride which works with Users.

The main problem here is that ValueUserOverride is specifically for value types. You're not creating user, but you're making a type that references them.

TehTurk commented 4 years ago

Ah okay! Didn't realize user types and value types would be that vastly different. When I posted the comment I thought users were an inherent type like slot or anything else.

What I originally thought and meant, was the ability to generate dummy users, (Since we can only get them from people when signed in) for testing situations or otherwise for NPCs and the like. And have that behavior be a failsafe. (But that wouldn't make sense or apply correctly type wise)

Frooxius commented 4 years ago

Users are sync elements, similar to Slot so they can be referenced by the reference variants of the components. ReferenceUserOverride instead of ValueUserOverride.

Generating dummy users would be covered by this: https://github.com/Frooxius/NeosPublic/issues/239

Frooxius commented 4 years ago

Oh also closing this issue, since there is now a protection against using unsupported generic type for this component.

shiftyscales commented 4 years ago

A similar issue has come up, discovered by Elektrospy. He created a ValueMultiDrive with a FrooxEngine.Mesh type, and it locked up Neos. I've replicated the issue in the log below. SHIFTY-PC 1_25_2020_4_06_30_PM.log

TehTurk commented 4 years ago

This is due to the Mesh not being a Value Type I'm guessing. Froox did add some protection against this but it might be due to being a different component, so it might have different depends in the code.

Frooxius commented 4 years ago

I'll add a type check for this component too, thanks!