Issues with Hotspot Vicinity

10FingerArmy

Hi,

Did I mention I love AC? I switched my input now to direct control (mouse moves the camera, keyboard the player) and hotspot detection by vicinity, nearest only. That is awesome! Three problems though:

• The hotspots are detected through walls even if the "Don't show behind colliders" is set. Are there other settings I need to check?
• If an interaction (e.g. look) triggers "Walk to marker and face" then the character moves forward but not sideways or to the marker anymore. The navigation path draws correctly in the editor but the character is simply not going there. In direct mode without mouse moving the camera and hotspots with mouse over it works just fine.
• The third person camera works great but the wall detection seems to be not perfect. If I move very close to a wall with the character and then move the camera along the wall I can see behind it. Is there a way to ensure no clipping issues occurr or at least to specify a min distance from colliders to account for some safety?

Any help highly welcome :-) I can post screenshots if needed.

Cheers, Robert

ChrisIceBox

• The
  hotspots are detected through walls even if the "Don't show behind
  colliders" is set. Are there other settings I need to check?

This isn't something that's currently possible, but I will have a look to see if it can be implemented.  For now, you'd have to use Triggers to disable Hotspots that shouldn't be detected when the player isn't in the correct room.

• If
  an interaction (e.g. look) triggers "Walk to marker and face" then the
  character moves forward but not sideways or to the marker anymore. The
  navigation path draws correctly in the editor but the character is
  simply not going there. In direct mode without mouse moving the camera
  and hotspots with mouse over it works just fine.

Sounds like a bug.  So the only difference is literally just the "Detect Hotspots" setting?

• The
  third person camera works great but the wall detection seems to be not
  perfect. If I move very close to a wall with the character and then move
  the camera along the wall I can see behind it. Is there a way to ensure
  no clipping issues occurr or at least to specify a min distance from
  colliders to account for some safety?

Only by moving the colliders themselves, or using colliders especially for the camera.  But if you find a separate Third Person camera asset, it wouldn't be too hard to integrate it - just add the "_Camera" component to it, and AC will recognise it.

10FingerArmy

Making hotspots not detected autoamtically even if in vicinity mode would be awesome as that would save a lot of time!

Concerning the walk to marker: I finally found the reason but not the solution. In my interaction menu I have attached a keylistener (very simple for now, see below) and assigned hotkeys to the menu actions (e.g. q for look). When I click the look icon with the mouse, navigation works fine. If I press q navigation is broken, the action list is executed nicely though. Is there some check in the walk to marker coding that reacts to key presses?

if (Input.GetKey(keyCode)) {

   button.onClick.Invoke();

}

Would it be hard to add a "min distance from colliders" option to the third person camera to automatically create an offset to ensure a player cannot lurk behind walls?

ChrisIceBox

No, there isn't.  But if the player's movement towards the hotspot is being cancelled, it should be doing it through the PlayerMovement script's StopMovingToHotspot function (around line 769).  Try putting in a Debug.Log inside it to see if you can trace back the source.

I'll consider such a distance option.

10FingerArmy

Hi Chris, good news. I found the problem with using hotkeys. It happens because when pushing the button it can potentially trigger the interaction twice (pushing it very shortly makes everything work correctly) which calls endPath again and cancels the navigation but still executing the rest correctly. I added a delay now in my click hotkey script which solves this but I think it is a bug in AC as it should not react in such a way that the navigation gets thrown off by executing it twice in short succession. What do you think?

ChrisIceBox

You'd have to post the full script and explanation for how you use it for me to have any kind of response - as it is, you're interacting with AC in a way that wasn't intended, so without seeing exactly what you've done I can't say what this is down to.

10FingerArmy

Sorry my fault. Here we go!

* Unity UI interation menu

* Appears on hover over hotspot

* Allows to click on 4 actions

* Clicking works fine

* Instead of only clicking I want to also allow to push a button (which would actually be a nice AC feature!)

* The script below is attached to each button

* When pressing the associated key extremly short it works fine

* When pressing the key with what I would call normal speed the interaction will be called again since Unity will send another keypress event

* AC will then do it's logic after pressing the button again and will not detect that the interaction is already executing

* It will cancel the navigation path and the player stops moving

* The rest of the interaction is executed correctly

Do you need any additional information?

using UnityEngine;

using UnityEngine.UI;

using System.Collections;

public class ClickWithKey : MonoBehaviour {

    public KeyCode keyCode;

    private const float WAITPERIOD = 2f;

    private Button button;

    private float lastClick = 0f;

    void Start() {

        button = GetComponent<Button>();

    }

    void Update() {

        if (Time.time - lastClick > WAITPERIOD && Input.GetKey(keyCode)) {

            button.onClick.Invoke();

            lastClick = Time.time;

        }

    }

}

ChrisIceBox

Try Input.GetKeyDown instead of Input.GetKey.  That's causing it to run every frame.

10FingerArmy

I am sure there are many workarounds. My point was: shouldn't AC react correctly no matter how often I throw the event at it?