While debugging, a breakpoint inside an if-block is reached even when the expression insides evaluates to false. The debugger shows it is false but the block is executed regardless. What gives?
I’m no beginner to coding but I’m really clueless in this.
EDIT: I realize I’ve given no further explanation on the rest of the code, but I really can’t think of a reason any of it would affect this particular outcome. The expression does evaluate to false and by no means should this block be executed.
By the way, the Debug.Log() itself does not log anything in the console either, which is quite weird. But the rest (the Bezier and the position setting) gets executed flawlessly.
A disconnect between the compiled version of your code and the script.
Since my crossbow is in the shop and my microwave is broken, I feel like we should spend a little time investigating door #3.
How are you compiling this script? Are you saving it and trusting Unity to do it? Are you building it into an assembly from some external build process?
If the former, have you tried…ehem…turning it off and on again?
I would put a Debug.Log() befor the if statement. But i’m a beginner.
Debug.Log(pathArray.Length);
You are sending an array to the function, and calling it pathArray, If The array is 0 or 1 elements in length. then the statement if false.
If it’s false it should not run the code and you say it is running it. So that’s why I would do the debug befor the if statement.
Turning it off and on again is actually a pretty good idea, in case the object values are cached badly somehow, but also be careful of simultaneous execution of multiple copies of a script. In other words, a component on more than one GameObject (accidentally) and the one you aren’t paying attention to executing first and screwing up the tests. I would also debug that more thoroughly, without breakpoints in case the debugger isn’t handling that properly through Unity.
Actually when I tried to build the game, Unity spammed me a lot of errors about the method not having the “Rpc” prefix. I actually typoed it “Rcp” and unity went nuts because of it.
But I’m still pretty curious as why the code was actually being executed somehow. This was being tested in the Unity editor with VS2017 attached to it. The argument was indeed an array with a single element (trying to set a rotation based on it would throw me errors afterwards) and the rest of the method was executing as if it were no errors at all. Perhaps Unity decided not to compile the changes I’ve made to the code but not inform the debugger about it, but it’s strange they never threw an error about it. I think I’ll send this as a feedback. Trying to debug a code that doesn’t talk to you is a nightmare.
I’m sure what was being executed was some compile output from an older version of that script. Perhaps one in which the criterion was “> 0” instead of “> 1”.
The more clever a system gets about trying dynamically compile stuff and have everything be up to date, the complex a model they have to define around the ingest-and-build scenario. The more complex a model, the greater the chance that it is inapt in some way.
NCrunch does some similar things and has some similar problems. Sometimes it gets the state for a source file “stuck” and basically nothing can “dislodge” that state except for a complete reset of the plugin.
Resharper also does a similar thing but in a simpler way. It’s less effective but I’ve never seen the state get stuck.
I still don’t understand why the attribute annotation isn’t enough for Unity’s network code generation mechanisms. Why you also have to prefix your method names with Cmd and Rpc is beyond me. I’d ask the guy who wrote it but he doesn’t work there anymore…
How much of a “why” are you looking for? Is “because they made an arbitrary decision to couple everyone to a particular naming convention” good enough? Looking at the manual, it seems like that’s probably going to be the best you’ll ever get. They claim it is a “hint to the reader”.
This can sometimes occur if your line endings are incorrect (Mono-develop generally prompts for this). If they are, even though it shows the breakpoint for that line the actual underlying system may read it on separate line showing it as triggered for the incorrect line.
UNET is a complete mess. I have daily headaches trying to solve simple problems around it and my project is barely progressing. Documentation is as enlightening as the summaries in the IDE, error handling is non-existant, so many design limitations that force users to rewrite entire scripts to work-around.
If I ever finish this project, I’m not touching multiplayer again
It’s a garbage fest. We switched to Photon Thunder. You still have to deal with the goofy UNet constructs but their HLAPI actually works and we didn’t have to change too much of our existing code. UNet was honestly the only thing that was forcing us to not freeze our engine version so we kept upgrading and breaking other stuff in the hopes that UNet improved. Now we can just update Thunder.
