search

Yellow-Dog-Man / Resonite-Issues

Issue repository for Resonite.
https://resonite.com
134 stars 2 forks source link

Driving a field with a different value that is a destroyed slot crashes session #1438

Open mpmxyz opened 6 months ago

mpmxyz commented 6 months ago

Describe the bug?

When a slot field is driven and its value is changed to a destroyed slot the session is crashed. (i.e. from reading a dynamic variable or Store)

To Reproduce

  1. Store a slot reference in a DynVar/Store
  2. Destroy the slot
  3. Connect a read from the variable to the input of a drive. Example object: resrec:///U-TheAutopilot/R-7c3bb0a2-6165-44c9-8edb-ebf07c46da31 2024-03-03 14 56 55
  4. destroy the top cube
  5. connect the Read Dynamic Slot to the Reference Drive<Slot>

Expected behavior

Drive target should be assigned null or the destroyed object but there shouldn't be a crash.

Screenshots

No response

Resonite Version Number

2024.3.1.1178

What Platforms does this occur on?

Windows

What headset if any do you use?

Desktop

Log Files

ANONYM - 2024.3.1.1178 - 2024-03-03 15_56_00.log

Additional Context

No response

Reporters

No response

Nytra commented 6 months ago

Related probably to https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1296#issue-2116694353

mpmxyz commented 6 months ago

Semi-related as you could also recreate this bug with a Store. It just needs more steps to follow through as you first have to initialize the variable with an impulse, delete the slot and then connect the drive.

Nytra commented 6 months ago

Yes I think it's actually a very generic problem with slot references not being nulled when destroyed, causing a bunch of crashes in different scenarios

mpmxyz commented 6 months ago

The question is if you want to null references when destroyed or if you want to ignore destroyed slots when used as an argument. I think the second option is more realistic as it is a very complex and possibly cpu/memory-consuming problem to keep track where a reference has been used. (better to just replace all x==null checks with x==null || x.IsDestroyed()) Approaching this at the data storage would also be a valid solution. (check for destroy status before returning value) But this may be against the design of keeping Protoflux separate from FrooxEngine if it needs integration into Locals and Stores.

Nytra commented 6 months ago

Doing a check for ElementExists is better as that covers the null case and the destroyed case

AlanMoonbase commented 1 day ago

Headless is constantly crashing potentially because of this, here's latest log

milenia - 2024.9.16.1105 - 2024-09-17 14_03_34.log