Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Bug Character Controller and UnityEngine.InputSystem glitch?

Discussion in 'Editor & General Support' started by FlyFren1492, Mar 3, 2023.

  1. FlyFren1492

    FlyFren1492

    Joined:
    Jan 26, 2023
    Posts:
    3
    I'm encountering a bizarre issue. I use a character controller for the player and enemies. The player controller script uses UnityEngine.InputSystem while the enemy controller script does not. The enemy controller script doesn't have a single line of code in it that responds to player inputs. And yet, when I ran the game, I could press left or right and it would control the enemy character controller for 1 second, but ONLY left and right affected the enemy. Run, jump, up and down inputs did nothing. About a second after pressing the input, the enemy stopped taking inputs but also just stopped moving all together. I disabled the player controller script, and this no longer happened, so the issue was with the player script somehow controlling the enemy character controller despite there being no reference to the enemy script in the player script.

    BUT here's where it gets even weirder. I decided to make a copy of the player script to make changes to the new one while preserving the old one and trying to fix the problem. The only change I made so far was the name of the script and its class. The original script causing the problem was PlayCon and the copy is named PlayConNew. That's the only difference between the 2 scripts. I put PlayConNew on the player object, disabled and removed PlayCon, ran the game, and inputs no longer affected the enemy at all. I removed PlayConNew and put PlayCon back on the player object and then inputs would affect the enemy again same as before. I tried this numerous times, and the same result happened every time. PlayCon made my inputs affect the enemy, PlayConNew didn't. Literally the only difference between PlayCon and PlayConNew scripts is the name.

    But it STILL gets weirder. I then tried changing the name of the original PlayCon script and its class to PlayConTHREE. I removed the PlayConNew script and added the PlayConTHREE script (which is just the original problem script but renamed) to the player object, ran the game, and inputs were no longer affecting the enemy. I then used Ctrl+Z to change the PlayConTHREE script back to PlayCon, ran the game again with PlayCon and lo and behold player inputs were no longer affecting the enemy. Problem just magically disappeared. And I can't make the problem happen anymore.

    Again, the only changes that were ever made were to the name of the script and the class. Why would something like this happen?
     
  2. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,520
    Because software.

    Also, remember CharacterController and InputSystems have NOTHING to do with each other.

    Your solution will lie in isolating the two systems and understanding which is giving you issues.

    And welcome to debugging!

    Here is how you can begin your exciting debugging adventure:

    You must find a way to get the information you need in order to reason about what the problem is.

    Once you understand what the problem is, you may begin to reason about a solution to the problem.

    What is often happening in these cases is one of the following:

    - the code you think is executing is not actually executing at all
    - the code is executing far EARLIER or LATER than you think
    - the code is executing far LESS OFTEN than you think
    - the code is executing far MORE OFTEN than you think
    - the code is executing on another GameObject than you think it is
    - you're getting an error or warning and you haven't noticed it in the console window

    To help gain more insight into your problem, I recommend liberally sprinkling
    Debug.Log()
    statements through your code to display information in realtime.

    Doing this should help you answer these types of questions:

    - is this code even running? which parts are running? how often does it run? what order does it run in?
    - what are the values of the variables involved? Are they initialized? Are the values reasonable?
    - are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)

    Knowing this information will help you reason about the behavior you are seeing.

    You can also supply a second argument to Debug.Log() and when you click the message, it will highlight the object in scene, such as
    Debug.Log("Problem!",this);


    If your problem would benefit from in-scene or in-game visualization, Debug.DrawRay() or Debug.DrawLine() can help you visualize things like rays (used in raycasting) or distances.

    You can also call Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene manually, looking for all the parts, where they are, what scripts are on them, etc.

    You can also call GameObject.CreatePrimitive() to emplace debug-marker-ish objects in the scene at runtime.

    You could also just display various important quantities in UI Text elements to watch them change as you play the game.

    If you are running a mobile device you can also view the console output. Google for how on your particular mobile target, such as this answer or iOS: https://forum.unity.com/threads/how-to-capturing-device-logs-on-ios.529920/ or this answer for Android: https://forum.unity.com/threads/how-to-capturing-device-logs-on-android.528680/

    If you are working in VR, it might be useful to make your on onscreen log output, or integrate one from the asset store, so you can see what is happening as you operate your software.

    Another useful approach is to temporarily strip out everything besides what is necessary to prove your issue. This can simplify and isolate compounding effects of other items in your scene or prefab.

    Here's an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:

    https://forum.unity.com/threads/coroutine-missing-hint-and-error.1103197/#post-7100494

    When in doubt, print it out!(tm)

    Note: the
    print()
    function is an alias for Debug.Log() provided by the MonoBehaviour class.