I get null references when i kill an enemy mostly and not always also sometimes can exist even during combat.
when i take that out : if(!GetComponent().CanMoveTo(combatTarget.transform.position) && !GetIsInRange(combatTarget.transform)) {return false; }.
i get not errors also the errors i get is that :
Seems that is the solution going to try it by tomorrow. Then re insert my custom stealth system and if everything works fine then gg š«“š«“š«“.
Youāre on the right track! Youāre going to want to null check the CombatTarget before you get to this line. If it is false, then we know by definition that we cannot attack the character.
Theory question that I expect not solution but theory answer. Would be able if you go deep into an programming language into the low level code, make null reference restore themselves but still get a debug error but without breaking the game?
In C#, no. Once itās been destroyed, thereās no bringing it back. If itās just a matter of the code losing the reference, but with the object still there, you could search for it.
If Destroy() is called, it will be tagged as destroyed and Unity will always treat it as null until the Garbage Collector finishes the job and re-allocates the memory. If you try to access an object that has been marked as destroyed, Unity will always treat it as null or a missing reference and throw an exception. Even if you had a clever low level solution, you would have no guarantee how before the Garbage Collector frees up itās location and something else goes in itās place (and you would have no way of knowing that this had happened!).
Otherwise, as long as some object maintains a reference to an object (say a cache), it is safe from the Garbage Collector, and you could try to re-aquire it, either from the cache or by searching with FindObjectByType.
So it could happen only in low level languages like c++ ? Or you have to Go even lower?
Fixed the problem i added that target == null at attack behavior at first also made a double null check at update ( maybe the second null check isnt neccesery but i doubt it will matter ? So brian whats your oppinion on this?
I do. And the image is practically black on my screen, and not animated.
Fixed sorry for my delay i try to implent a new StealthSystem 
Context always matters (and of course, as I mentioned in another thread, code formatted text over screenshots).
The 2nd screenshot is the Update() method, which is actually called before the 1st paste, AttackBehaviour.
In the Update() method, youāre actualy checking the target twice, once at the beginning, and once in the range check. Since youāre blocking at the beginning of the method, no further null checks on Target are required for the remainder of the method (Unity is, by default, NOT multi-theaded). This means you can remove the target!=null from the if statment and simply use
if(!GetIsInRange(target.transform))
Theoretically, AttackBehaviour() is only called in Update(), and at the point that it is called, target has already been null checked. Your screenshot confirms 1 referenceā¦ so theoretically, a null check is not required here.
Well i completely forgot about here and did it on stealth system, yeah i got nullphobiaš after all that nulls I got during my training, but i will remove the one that makes double null check .
Itās a good phobia to have.
The inventor of the null pointer regrets introducing nulls, and once referred to it as his āBillion Dollar Mistakeāā¦ (I think heās missing a 0)ā¦ Nulls can lead to wasted energy.
My general rule of thumb is if it can be null, then it must be null checked. This rule applies on a per-method basis unless it is in a coroutine. If itās in a normal method, Unity doesnāt do true threading, so unless you call a method that can make it null, youāre generally safe. If itās in a coroutine, then it may need to be null checked after every yield return instruction (because you have no idea whatsoever what may be happening between your yield return instruction and control being returned to the coroutine.
If he didnāt interfere nulls then what would happened if target didnāt exist? How the rest of a code could work?
Generally, if the reference turns out to be null, then youāll want to exit the coroutine (yield break;)
No i mean the invetor of null. If Never implant nulls how things would work
Oh, thatās a good questionā¦ and the answer may have been even worse. No matter what, weāre always faced with the notion that our data is no longer valid.
Couldnāt be a low level implant that if something was null return or break so would ignore the remaining thing?
Then youāre just obscuring the nullā¦
In truth, null references can be valuableā¦
For example, in Fighter, we simply use the existence of a target to serve as the mechanism to know you have a targetā¦ Thatās pretty powerful.
In methods where things shouldnāt be null, a null reference can lead us to hunt down that conditionā¦ simply exiting gracefully isnāt always the answer there (I often pop a Debug when something is null so I know I need to hunt down a null reference somewhere).