Proximity selector costing a lot

[Strig]

Hello, we're doing a few reworks on our game's systems and we recently found this out while testing our FPS count during gameplay:

Zx2XRif1tj.png (16.69 KiB) Viewed 321 times

Basically, due to the Update in the Proximity Selector, the game sometimes slows down a full 20 FPS. We're trying to make the game run as smoothly as we can, so if possible we'd like to change this.

Is the Selector this costly due to a setting we need to check? We also noticed that the Update method is overwritten by other scripts, so maybe that's also contributing to the slowdowns?

For reference, here's how the Proximity Selector is configured in our Player character:

Captura de Tela (92).png (49.64 KiB) Viewed 321 times

Thanks in advance!

[Tony Li]

Hi,

Selector and ProximitySelector are optional helper components, not required to use the Dialogue System. If it's causing any concern, you can swap it out for a different interaction script.

However, it shouldn't cause that kind of FPS drop. Are there any related errors or warnings in the Console window?

Does the FPS drop happen only in the frame that you initiate conversations? BTW, are you even using ProximitySelector to interact with Usables? Use Key and Use Button are unassigned.

[Strig]

No, as far as I'm aware there aren't any warnings - unless they're hidden by the Dialogue System's own debug warnings.

To answer your other questions, we adapted the Selector to obey our internal input system - to put it simply, there's an interaction trigger called by the player's input components and that trigger calls the Proximity Selector's UseCurrentSelection. This is, in part, so we can use both our current Keyboard and Controller inputs.

We were thinking about enabling the Proximity Selector only when in contact with an interactable object's trigger, since it's not being used most of the time. Is that a good solution? Or should we try to swap it for another interaction script, as you suggested?

[Tony Li]

This is the entirety of ProximitySelector.Update:

Code: Select all

        protected virtual void Update()
        {
            // Exit if disabled or paused:
            if (!enabled || (Time.timeScale <= 0)) return;

            // If the currentUsable went missing (was destroyed, deactivated, or we changed scene), tell listeners:
            if (toldListenersHaveUsable && (currentUsable == null || !currentUsable.enabled || !currentUsable.gameObject.activeInHierarchy))
            {
                SetCurrentUsable(null);
                OnDeselectedUsableObject(null);
                toldListenersHaveUsable = false;
            }

            // If the player presses the use key/button, send the OnUse message:
            if (IsUseButtonDown()) UseCurrentSelection();
        }

Nothing in there should cause a framerate drop unless you've overridden IsUseButtonDown() in a subclass? Maybe your IsUseButtonMethod() method is having problems?

We were thinking about enabling the Proximity Selector only when in contact with an interactable object's trigger, since it's not being used most of the time. Is that a good solution? Or should we try to swap it for another interaction script, as you suggested?

If you're already detecting interactable object's triggers, then there may be no need for ProximitySelector at all. The purpose of ProximitySelector is to detect interactable objects' triggers and, if the player presses an input, send an "OnUse" message to the detected trigger.

If you're detecting interactable objects some other way, you can get rid of ProximitySelector and just send "OnUse" yourself:

Code: Select all

detectedUsable.OnUseUsable();
detectedUsable.gameObject.BroadcastMessage("OnUse", transform, SendMessageOptions.DontRequireReceiver);

[Strig]

It worked fine! We used our own interaction component to call OnUsable, as you said. For anyone who stumbles upon this thread and is curious, here's a basic hierarchy of an NPC in our game after this:

NPC (Parent, with our Interactable Component)
> Colliders
- Physical Collider (Collisions)
- Dialogue Collider (Trigger)
> Dialogue
- Dialogue Components (with Usable and corresponding DIalogue System Triggers)

Basically, our Interactable Component now calls the Usable directly, which then calls the Dialogue System Trigger, as expected.

Thanks for the help! Also, our Interactable Component used BetterEvents in Odin as a replacement for the usual Unity Events, we were wondering if you were interested in making DS compatible with that too.

(https://odininspector.com/community-too ... eplacement)

[Tony Li]

Hi,

Thanks for summarizing your solution!

I'll give some thought to BetterEvents. Maybe a scripting define symbol in a future release.