![]() ![]() Maybe it would be worth splitting into two threads, if a moderator feels, please forgive me I am noob with code and a bit dumb as well so I have to really try to break things down Barney-style, but, let me ask you if I got this more or less right: For example this would make a lot more sense:Īctually, I curious so I gonna drag my own thread a bit more off topic here. If it should be possible to call a method and for it to fail to do it's intended task, you should always notify the caller about it, so that it can react accordingly. Also, it gets harder and harder to find the source of a problem, when you don't immediately see an error message when something is unexpectedly null.īeing aware of possible exceptions and preparing for them is a good thing, but just adding if(x != null) is not a good method of preparation. The more error hiding you do, the more likely it is that the real issues never get fixed. Why was inventoryUI null in the first place? Should we assign the reference in Awake instead of Start? Did we forget to disable the player inputs between level loading? Was it destroyed as a side-effect of something? ![]() The problem with this is that you are basically ignoring the real source of the bug by hiding one symptom of it. So it's clearly better and makes for a more stable game, right?! Maybe before the != null fix, your UI manager was getting completely stuck when OpenUI threw an exception, and now the inventory just never opens. The short term benefit of doing this is that you might turn bugs that used to be game-stopping bugs into lesser bugs. So when a method is called with bad data, it just silently does nothing, instead of allowing an exception to be thrown. What happens is, they realize that NullReferenceException can happen very easily in many situations, so to "fix" the situation, they start putting these null checks everywhere. Of course that suits me because I'm a programmer, so your mileage may vary if you're specifically looking at events to do things without code.Ĭode like this is something that most programmers do a lot when they start coding, then over time they realize that it's almost always a very bad thing to do. I use events in the Inspector to hook up presentation stuff, but all of my core logic is hooked up via code. However, keep in mind that having layers or chains of these hooked up in the Inspector makes things really messy to debug. Eg: a Door might raise a DoorStateChangedEvent to announce that it is now in the open state, and a Navigator may listen to that event and then decide whether the door being open should cause it to update a path.ģ - UnityEvents are great because you can hook them up in the Inspector. Other objects are then responsible for listening to (and unlistening from) any events on other objects on an as-needed basis. Also, as a beginner it can be hard to figure out what will actually be reused.Ģ - Raise events on objects for any internal state changes which other objects might care about. It's useful to have that as a general aim, but being dogmatic about achieving it can make things more complicated than the otherwise need to be, eat up a bunch of time, etc. Note that it doesn't have to be about drag-and-drop, I most often use events in code to allow communication between objects which aren't specifically aware of one another.ġ - Don't go too nuts on being able to reuse individual bits. Click to expand.That's one way to look at it, and they're certainly useful for that. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |