Pixel Crushers Forum

Hi,

Something annoying is happening in my game, and I wonder whether it is intended behaviour - and if so, if there is a built-in way to change it. It's easiest to explain with a screenshot: There are two relevant usables in this scene (ignore the TrashSlotPaperBall2 and the TrashSlotScarf near the top): the center collider has a usable which triggers a cinemachine camera transition to focus on this screen, and the four outer colliders revert to the standard camera shot when clicked. This is essentially a way to focus on the screen and zoom back out by clicking next to it.

Now, the issue is that the onUse of the external colliders is always called on mouseUp, which is likely intended behaviour and is usually fine. However, in this case it often happens that one is adjusting the volume slider (circled in red) and in doing so, moves the mouse over the rightmost collider. Then on mouseUp, the usable's onUse is triggered and the camera zooms out of the screen, which is unwanted behaviour.

Essentially what I need is for the onUse not to trigger on mouseUp, if the previous mouseDown happened over a UI element. This feels like something that may have a built in solution, so I thought I'd ask here first. If there is no built-in solution, what approach do you suggest? I suspect modifying the Selector class would be my best bet?

Hi,

Yes, make a subclass of Selector, and override IsUseButtonDown(). I think something like this should work:
I think it makes sense to also add that same check to the Selector class itself, so I'll add it in version 2.2.21.

Hi Tony,

Thanks for the info. I have an update for you, since you mentioned including this check in the next version: a similar check is actually already performed, just not in the IsUseButtonDown, but in the Selector class's Update method. Using only the check you mentioned won't do the trick, since that checks whether the pointer is over a UI element at the time of release, when my problem was that the click started over a UI element, but was released when the pointer had moved away from the UI.

In any case, I did some more digging and it turns out the problem was not caused by DSFU code, but rather by a custom PlayerController we had written ourselves. We manually call the Usable.onUseUsable method there in certain cases, and the "started over UI" check had to be incorporated there as well.

So I'm not sure an update to DSFU is needed at all.

Got it. I'll double check the code in Selector then. It could be that, as you write, I didn't remember already adding a check for that.