Bug Can't Debug a Script, animation change problems

My player start from mid air and hit Start platform to jump from. All the jumps are fine but not first one. I know my skills and could tell this is questionable coding involved here from my part but also there's a bug for sure.

While somehow my patch to the problem where first jump animation does not change into a jump one from idle it so happens only to Android Build and not in the Editor. Somehow in the editor my patch is working, while on built version it doesn't. Which makes it hard to find and fix as I need to build again and again to see if tweaks finally solve the issue at hand. Which is tedious and pointless. How it's possible for something to work in Editor but don't work in final build?

 

There are about ten billion different ways. Almost anything can fail between target architectures.

I won't list them. Google if you care.

That's just down to debugging. NOTE: wild guessing in the dark IS a form of debugging, but it is highly sub-optimal.

Experimenting (or guessing) as the result of data obtained from actual runs is where the real debugging happens.

Time to start debugging! Here is how you can begin your exciting new debugging adventures:

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 names of the GameObjects or Components involved?
- 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.

Visit Google for how to see console output from builds. 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 for 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)" - Kurt Dekker (and many others)

Note: the

print()

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

 

When there's someone of the staff that actually care for customers I will keep rolling the conversation with him. Buffoonery like "When in doubt print it out" are quite the cake icing when we talk about engine inconsistency.

By the way the code runs on the PC I keep tabs how to develop further. If I can't use the way it shows running as a base how it will behave on the real device then why I bother.

And as I stated it runs the way I want in the Editor, not on real device.

EDIT: What I noticed in Editor it skips over the idle animation by pressing jump, which doesn't happen on the real device, not until the mentioned idle animation runs at least once. Which is the odd thing here, why something that's running at same speed in Editor and Real device can run like that?

 

It's well understood there's differences between the editor and a build. The editor is effectively a simulation of how it might play when deployed, but a simulation is never 100% accurate to the real thing. Even play mode in the editor on PC, and deploying a PC build will have potential differences, potentially causing bugs if you're not careful/don't know what you're doing.

There are many particularly non-deterministic things that will changed when your project has been compiled, assets compressed, etc etc, and deployed to a platform that runs on hardware that may be completely different to the hardware it was built on.

So with no code and no other information of how your project is set up, all that can be said is: you need to debug what is not happening as expected on your target platform.

 

I suspected that there were something I put on a timer, as it seemed like a timed event, if player waits long enough on real device then first jump is alright. Which I found the Unity Editor has no issue of interrupting the Idle animation, but on the device if you wait after it rolled out the idle animation at least once, then it works alright and jump animation follows the jumping itself.

In a way it's a bug. It's just one of those that need solutions on my end more than solving them in the engine for each architecture on a case basis. I can only guess and release new builds one after another until something make it go away. It's not something that's not working in the editor and can debug it to find the culprit, just the opposite, it's something that's working just fine there it's on the device that's the problem, I can't hook the device do to shaky USB connection and downloading every build from the cloud to test it out. This is another problem here.

 

Well we'd love to help you, but we can't with the very little information provided so far. We don't know how you're animating your character, we don't know how you're managing the states (whether you're using the old or new animation methods), and we haven't see any relevant code to the former.

As Kurt mentioned supposition is probably the least useful form of debugging. There are more effective methods, of which Kurt has described a number of.

 

The issue were in two adjacent clips in the animator that for some reason had a connection between them and positioned so closely next to each other that at first glance you can't say there's one. When I deleted that extra faulty connection it started behaving properly again.

My apologies, frustration is a feeling my Asperger isn't able to filtrate properly and this lead to needless anger.

Given it wasn't in the code if I wouldn't notice this connection it could take who know how much time before I realize the problem. So it's not a bug.

I had few hours break on looking too hard in it and it presented itself. Somehow forums help even though exact solution isn't pointed out.

Thanks for the help!

 

Only a tiny tiny tiny fraction of the average modern game's surface is actually code.

Almost anything can break a game, and almost anything can cause inconsistencies between builds of your game.

Note: this is software we're talking about. Software is like that.

You do understand that is just basic Troubleshooting 101, right?

To me there is nothing more frustrating than to waste time looking where a problem can trivially be shown to NOT exist by simply printing something out. What could be easier?!