Daggerfall Workshop Forums

my experience is that it works like said in the code example in the docs: https://docs.unity3d.com/ScriptReferenc ... ycast.html

you provide a bitmask of layers for use in Physics.Raycast that's why you invert your "ignore layers" (the docs say "A Layer mask that is used to selectively ignore Colliders when casting a ray." which can be interpreted in both ways or said differently it does not specify if it is a whitelist or blacklist just that it is used to specify behavior)

update: ah I see the concern now: there is no inverting the mask in PlayerActivate.cs. There is also no shifting like 1 << layerPlayer
so maybe just a lucky coincidence from setting in line 82: it might end up with a value something similar to how it should look like imo

Thanks guys, I'll take another look at this soon.

Nystul wrote: ↑Mon Jun 25, 2018 9:52 am so maybe just a lucky coincidence from setting in line 82:

That's the most insidious type of bug, the one that works due to coincidence, but breaks when you start doing something slightly different!

Most definitely! It would be nice to have an answer for behaviour to be inverted in that case, and perfectly happy for it to be my mistake.

Edit: Have updated this now to below, and everything still working fine on my end. The player is able to activate everything normally, and raycast is not blocked by own capsule. Happy to chalk this up to my error, and appreciate the catch.

Interkarma wrote: ↑Mon Jun 25, 2018 9:10 pm Most definitely! It would be nice to have an answer for behaviour to be inverted in that case, and perfectly happy for it to be my mistake.

Edit: Have updated this now to below, and everything still working fine on my end. The player is able to activate everything normally, and raycast is not blocked by own capsule. Happy to chalk this up to my error, and appreciate the catch.

Code: Select all

playerLayerMask = ~(1 << LayerMask.NameToLayer("Player"));

Not completely followed this discussion, so can I just ask if all uses of layer mask need reviewing in light of this?

It's just that one case where mask not properly inverted.

Things are finally starting to fall into place. It was a few bugs on top of one another that I had to unravel (mostly my stuff).

One thing I've realized I need, though, is a more reliable way to determine when I should show my UI window, and when to hide it. Currently I've been doing this by checking to see if the game transitions from an unpaused to a paused state, but for some reason this is only working once. I'm checking with InputManager.Instance.IsPaused.

Is there a better way I should check to see when it's time to display the UI? Maybe checking the number of windows in the stack, and if it's >1 pop it up?

I think that should work. The only window that sits constantly at bottom of stack is the HUD.

Failing that, we could probably setup a way for you to capture a global event or something when windows are pushed/popped against stack.

I solved it! It turns out this was happening:

* Upon initialization, DaggerfallUI.Instance.CustomMousePosition is in a default position

* The user opens the UI via AcitvateCenterObject--this is normally done with Mouse0, but in my case I add that Action from my VR controller

* The user interacts with the UI. As the controller moves, it updates the CustomMousePosition

* Once the CustomMousePosition is over the exit button in the Inventory (for example), the user clicks. Normally this is done with Mouse0, but I changed BaseScreenComponent:568 to look for "VRTrigger" as well, a new Input axis that looks for the touchpad down

* The UI closes

* The user goes to open the inventory window again (clicking on another treasure pile, for example). The above steps happen, BUT CustomMousePosition is still located over the exit button from last time, and usually (but not always) the click event is handled before the CustomMousePosition is moved by the moving controller

This usually results in the Exit button being clicked and the window Popping off the stack before you can even see what's happening. But sometimes the UI displays normally!

My current workaround is to move the CustomMosuePosition to 0,0 in the controller when it's not intending to handle UI events.

What a frustrating bug! Great work chasing that down.