What Makes A GameObject Fully Instanced?

[rustic thistle]

First, follow the large code blocks instructions.

!code

[west hare]

Posting code

📃 Large Code Blocks

Use links to services like:
https://paste.mod.gg/, https://hastebin.skyra.pw/, https://paste.ofcode.org/, https://paste.myst.rs/

📃 Inline Code

Surround code with three backquotes. Not quotation marks.
To format as C#, add cs to the first line:
```cs
// Your code here
```
Add a comment with a line number if there is an error message.

[azure void]

Like this?

[rustic thistle]

Yes

[azure void]

An example of what I mean.

[rustic thistle]

You seem to be subscribing to a static event for grabbing.

[azure void]

The purpse of that code is to decouple from the player the original code for that was PlayerScript.Instance.InspectPosition

Now it just passes the players inspectPosition which is where the object lerps too, in front of the player.

[rustic thistle]

Doesn't seem like it helps at all. Just makes the code more confusing. Definitely not the right use case of statics.

Anyways, it seems like the issue happens on exiting inspect mode, so you should add logs or breakpoints and debug the flow.

Seem to me like all the objects are subscribing to player actions is the main culprit, but you'll need to debug it properly to confirm it.

        if (exitInspect != null && exitInspect.WasPressedThisFrame())
        {
            isInspecting = false;
            onExit = true;
            lerpTime = 0f;
        }

This snippet specifically seems like something that would be true for all the intractable objects.

[azure void]

Static Action events in Unity is a well documented powerful decoupling tool and is referred to as the observer pattern. As for your other advice I'll look into it thanks.

[rustic thistle]

No. A random use of static events does not make your code better. It makes it worse. This is definitely not a good use case for a static event.

[azure void]

I appreciate that but this is not on topic and doesn't help my question at all.

[rustic thistle]

It would make sense if the events you're subscribing for are are global events throughout the program.
A player script is definitely not something that should be raising such events.

Suit yourself. Just saying that it makes your code less readable, extendable and debuggable. Something that programming patterns, like observer pattern is supposed to improve(if used correctly and in the right context).

[sick gate]

Basically this part is subscribing every worlditem to your interaction and will fire that event for every worlditem. And as dlich said, even with that short script it is already confusing, hwo you set it up. Why does a worlditem have control over the inspection input at all? Its like creating tires with engines in it, so every tire can drive on its own... you really should 1. listen to dlichs advice about static events. they are meant to be observable for an entire runtime best case or at least a specific scenario while your player is just a reference in that scenario. You are mixing up dependencies and responsibilities in your worlditem script where they do not belong.

[jolly skiff]

In addition to the static event issue, the if(onexit) in Update() will be run on every object

[sick gate]

~~Also mixing up states like onExit, which are set to false in one script but true in another. I hope you get, what I mean. ~~ Forget this line, I saw the = true later.
You are just controlling to many things in two many places

yeh, was just trying to figure out, where it might be set to true. I the heck dont know