Forum rules - please read before posting.

NavMesh absorbing mouse clicks

Hi, I'm just getting started with Adventure Creator so I'm probably doing a lot of goofy stuff.

I'm currently converting my game to Adventure Creator so it can be cross platform. In my game the main character has a phone that he can use, the phone appears over the screen and interaction with the scene needs to be disabled until the phone is switched off. That's the easy part. Action on inventory object use -> Engine, Manage Systems -> Interactions and Movement disabled. The phone is a GameObject not a UI or Menu.

I noticed that clicks on the buttons weren't being handled by their scripts in certain parts, eventually I realised it was only where the nav mesh is. The way I solved it in a script is to disable the PolygonCollider component, and then re-enable it:

KickStarter.sceneSettings.navMesh.GetComponent<PolygonCollider2D>().enabled = false;

And this works, you can see it here:

My question is, how would you guys solve this? Including the implementation of the phone.


  • Welcome to the community, @GrahamHayes.

    If the Movement system is disabled, then it doesn't sound right that clicks are becoming absorbed.  From the AC side of things, all movement detection should be disabled in that case.  It may, however, be your script that's the source of the problem - in that the click-detection code for the phone itself is also accounting for objects placed on the NavMesh layer.

    So far as implementation goes, the phone itself certainly looks do-able with Unity UI - though the fact that all the sub-pages occur within the same menu would be a little tricky to get linked to a single AC Menu.  If I were building something like that from scratch, I'd approach it using Unity UI - but if it's already implemented and working, I probably wouldn't unless there was an issue with not.  One advantage of relying on a UI-based Menu is that all clicks made within the user-defined RectTransform boundary field will be "consumed" by the Menu itself.

    If you stick with a custom GameObject implementation, also be aware that you can run AC ActionLists through script as well - just call their Interact() method - so you can have AC perform tasks as part of your phone's interface regardless.
  • edited September 2018
    Thanks for the welcome Chris! 

    Each button has its own BoxCollider2D plus a script with the following code for handling the mouse click.

    private void OnMouseDown(){

            string str = "";
            switch ({
                case "PhoneMsg":
                    str = "MessagesApp";
                case "PhoneQiri":
                    str = "QiriApp";
                case "PhoneSave":
                    str = "SettingsApp";
                case "Default":
                    str = "none";

            if(str == "none"){
                print("no object");

            Transform t = transform.parent.parent;
            GameObject obj = t.Find(str).gameObject;

    I've also placed the phone in its own sorting layer, if that makes any difference.

    Thanks for your advice on the implementation, as some interactions with the phone can trigger dialogue it'd probably be best to stick to GameObjects.

  • SOLVED. (hopefully)

    I now believe this was occurring due to overlapping colliders and after doing some digging there's little rhyme or reason for which one gets the mouse event.

    In this image you can see a mini game I'm working on where you are presented with three options as three separate drawings, there are several hotspots that were getting the mouse click instead of the mini game. The solution was to remove BoxCollider2D and replace with BoxCollider (which I guess has priority), there are no issues now and I don't have the hacky turn off the NavMesh call in my scripts anymore. 

  • Only 2D colliders should be detectable in 2D games - changing your Hotspot colliders shouldn't be the answer.

    What may be necessary instead is to change your script's Script Execution Order so that it calls before AC's StateHandler (from which all of AC's Update functions run).

    That you've disabled the Interaction and Movement systems should mean that such a workaround isn't necessary - though your code snippet doesn't show how you're checking for input.
  • I don't actively do a check, the individual buttons have a collider and a script with the OnMouseDown (as above).

    I've reverted the phone buttons back to BoxCollider2D to demonstrate it not working.

    First I show where the walking area is, I also highlight a drinks cabinet.
    The walk area then blocks the blue button, and the drinks cabinet blocks the purple button, when I move out of the bounds of their colliders the phone gets the input.

    This shows how I've constructed the phone, what the inspector looks like, and the action list on clicking on the phone in the inventory. The script component is only the above code.

    I will look into Script Execution order if I have any issues using the 3D collider but I foolishly made lots of these screens and mini games.

    Now I check for input using the following:

     if (Input.GetMouseButtonDown(0))

                int mask = LayerMask.GetMask("Phone");
                RaycastHit2D[] hits = Physics2D.RaycastAll(Camera.main.ScreenToWorldPoint(Input.mousePosition),, 0, mask);

                foreach(RaycastHit2D hit in hits){

                    if (hit.collider.CompareTag("QiriNote"))
                          DO STUFF

    I have to use RaycastAll because the screens overlap, although more LayerMasks would solve that. Without the LayerMask it would still hit the colliders in the game such as hotspots or the NavMesh, which is why OnMouseDown() was so inconsistent.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.