What have you named the cactus behind you?

@Unity3dCollege

3 жыл бұрын

Wow... now it needs a name. It has xmas 🎄 lights on it... anyone have suggestions?

@christianconnolly1296

3 жыл бұрын

@@Unity3dCollege Pokey Joe?

@ccristian1715

3 жыл бұрын

@@Unity3dCollege GameObject :D.

@alexanderlogunov5147

3 жыл бұрын

@@Unity3dCollege newgo I guess (from new game object)

@vladrootgmailcom

3 жыл бұрын

@@Unity3dCollege Coollider? :)

We usually use C# events when designers are not supposed to touch or change things (C# events is more natural for our coders workflow and keep it scale-able easy), when ever there's a script where 3D-artist / Designers need to handle their stuff we go for UnityEvents, you teach them quick how it works with +/- and in which order it executes, saves time for our programmers.

Really love the improvement on the tutorial presentation, really clear and visual now with the images & rectangles! The concrete examples also make it easy to understand and visualise the knowledge. Good job and I'm really excited for future tutorials of this type :)

This is literally the video I've been looking for for the last couple weeks. Perfect explanation between the use cases, did not realise you could pass parameters in a delegate, so that completely changes my understanding on how delegates work for the better!

Always answering the good questions the most people don't even know to ask.

The context menu is the most grateful thing in this video man it could save you a lot of time! thanks for this valuable information

@nikodemos71

3 жыл бұрын

Completely agree, I was mind blown seeing, I knew the "dumb" way of dragging everything to your list had to have an optimization, just didn't knew what it was xD

Great Stuff Jason! There's a lot to unpack here but it was all presented clearly and simply. You nailed the difference between C# events and Unity events for me. You also provided answers to questions I did not even know to ask. Thank You

Great topic. Myself use System event all the time and UnityEvent when it comes to UI - all the UI elements normally have a lot of predefined events and event system itself goes very smoothly with UI.

I have been working with Unity for a couple of years now. And been working on a serious project for about a year, but it's like I still learn something new every time I see one of your videos.

Omg, all your vids have been so helpful but this one is an absolute godsend for me. You deserve a medal dude. Thank you so much!

Jason! Thank you for another absolutely stellar tutorial. The education you've given me for free on KZread is something I will always be grateful for. I hope someday I'll be in the financial spot to pay you back but, for the moment, thank you very, very much from the bottom of my poor heart. Haha. THANK YOU, SIR!

I wish more people make videos like you did. This was will organized. Audio was good and clear. Thank you.

This is why I recommend your channel to everyone in my office. Great stuff !!

That Context Menu Help was amazing. Thanks a lot!

These videos are so helpful! There are so many ways to achieve things, it is always difficult to decide which approach to use. Mostly so, because it is difficult to find clear advice on when to use which approach and which not. Great!

After searching half the day this video is what finally helped me solve my problem. Thank you!

I’ve only used unity events before this video. I’m pretty code savvy so I’ll probably be using “regular” events in the future, as it sounds better. Also that data context thing you had seems super nice and very helpful (the code part at least)

Thank you for this video! Been toying around with collectibles and this definitely opens up a lot of ideas of how I'd like to set up a few things in my project.

Recently learned how to implement an Event Bus Pattern and I'm in love! What a beautiful thing! I don't have to worry about dependencies anymore.

Hey Jason, thanks so much for these videos. I'm super green when it comes to Unity so your knowledge is very much appreciated!

i recently learned how to use the new input system with the input action call back (which sends out a unity event) and i love it. i can definitely see how using that same system for other things would be super handy.

I love the tips about enhancing developer experience and editor improvements. Good job buddy!

I am building an interactive book for a theater, and it's littered with custom events, considering I didn't even know about events, this just made my life so much easier!

I love that you shared the code for this! Thanks Jason:)

This video was really high quality in all aspects. Crystal clear explanation with good editing to highlight how the code relates to the editor. Fairly clean code that reflects the fact that you've done business software for a while. I think you talk a bit too much on some other videos I've seen, meaning that you could be a bit more concise. But this video was amazing. You've got a like and a subscribe :) Keep up the great work.

i never used UnityEvents but this was super cool to see a simple example that uses BOTH (since i feel like ive seen so many examples of just explaining one or the other) made total sense, thanks :)

Thanks for this video Jason.

You can actually multi-select drag and drop onto an empty list to fill it

@bayrock1337

3 жыл бұрын

I didn't know you could add functions to the ContextMenu, so I found the example to be useful.

@user-gl1ls1jx3h

3 жыл бұрын

Note that selecting one or more objects will change the inspector, so lock it (icon on top right of inspector window) if you want to multiselect + drag

I think we could've used a discussion on performance and architectural considerations for UnityEvents vs Events. In my team we've moved away from UnityEvents for everything non-UI in order to keep our business layer better separated. Also I think we could benefit from a discussion on the differences of declaring Actiton versus event Action as both are technically possible to use.

usefull, clear, short, just perfect as usual!

Very nice things. I completely forgot UnityEvent exists, bc i didn't have the needs but it's very nice. I understood in your other answers why you didn't unsubscribe, so ok. The final trick is amazing, i never use ContextMenu stuff, really useful ! So yeah, i learn't quite a few things here ! And i'm super glad you use the things you said in your previous videos !! The list serialization and the $ quote ! Amazing !

Thanks, This quick cours helped me a lot. Looking for more new lessons.

I think a nice addition to this comparison would be UniRx too, great content :)

awesome video, thanks for this Jason!

That is a great tutorial! One thing I wish it had was the difference between "event Action" and "Action" delegate. From what I understand the difference is the "event Action" protects us from setting the OnPickup = null and prevents other classes from calling on it ".Invoke()". In any case great tutorial! I have learner a loot! Thank you for making it.

@MasterofGalaxies4628

3 жыл бұрын

As I understand it, the "event" keyword lets you register multiple functions to whatever delegate you're declaring so that they will all run when the delegate is invoked. If you don't have that keyword, I think you'll only ever be able to register one function to a delegate at a time (though I'm not quite sure I have that completely right).

Hello you are a pure teacher just like my dad he teaches Botany mostly Plants Science and you teaches Computer Science Nice to have a teacher like you Got to know about how to trigger Unity Events

Common C# convention is to use EventHandler or EventHandler as your delegate, instead of Action. Both work, of course.

@raianmr2843

Жыл бұрын

C# is way too general-purpose for opposing conventions to come to an agreement. In case of Unity, almost everyone and their moms are using Action over EventHandler unless they have reasons not to. Nonetheless, it makes more sense to set conventions project-wise and have simple guidelines language-wise.

@RenegadeVile

Жыл бұрын

@@raianmr2843 This must be a personal experience-type situation then, because I've seen EventHandler used far more than Action personally and in code snippets/articles online. I do agree it's just something you and your team need to decide on for consistency's sake.

This kind of videos are really useful thank you so much

This was super helpful. thanks!

I usually start weighing the decision for Unity and regular events by 'Does level building need to change what goes on here?' If not, regular C#. That in mind, C# events make it easier to add similarly behaving types of objects later. Plus, for bigger projects or projects that may grow more complex in the future it's cleaner and very convenient (later) to have one general or multiple specialized 'event handlers', which can be neatly done with C# events. You can bind events via an event handler easily to Unity objects or UI elements using the editor and with some experience you will create a mix'n match between the two that has projects easy and clean to extend in code or levels.

Great explanation mate.

Great video! You should also mention that Unity events are 38x SLOWER than C# events. That fact is no big deal for most things that events are used for, but if you're going to be firing events rapidly in an update or something, at 38x factor could certainly be noticeable.

@AvoidingCrisis

Жыл бұрын

Hi Luke! Do you know where I can check the performance difference? Is it in documentation or an empirical test? Thank you very much for the help

this was very helpful, thanks!

Thank you for this tutorial, I really like what are you doing, you helped me alot!)

Very helpful. Thank you.

Hello. Wery useful explanation. Thank you for that. You realy make good quality explanation video. It help me with many thinks.

Great editing!

Awesome, thanks Jason! :D

For people having issues because of the light theme: try to keep a light source behind your monitor and always follow the rule of "light themes in lightened rooms and dark themes when in dark rooms". I know this is super-obvious but way too many people ignore these for whatever reason and have absurd setups that maximize eye strain.

@0xF81

9 ай бұрын

Weird, I'm using black themes everywhere even though my room is always lightened

I use static events(Actions) in the code to decouple the ui from the respective classes, for example an OnScoreChanged event that will notify the UI text, or OnHealthChanged for the health bar. I UnityEvents for things that I want a game designer to change easily and also when I am creating menus for the game. This way I can say that when you click 'Options' you disable 'MainMenu' and enable 'Options' game object.

Love the Thumbnail 😁

I was coming for the idea. Before the video as a c# developer, would do most of the events with c# events, except visual events, or gameobject related events. Now lets see the video.

When thinking about what type of architecture to use, I find it helpful to think about the relationship between the objects along two considerations (1) is the connection a fundamental dependency between the objects (coin always affects text or text always listens to coins) or incidental to the context (a design choice for this scene, maybe different later)? For brevity, I call the former "code-based" and the latter "scene-based". (2) the direction of dependency relative to the direction of the flow of logic. That is, if A happens then B happens: is A dependent on B, B dependent on A, or A and B both dependent on C (which also knows about A and B)? Combine these considerations and you have a 2D graph. Code-based, A -> B dependency = your standard Component.Method() call. Code-based, B -> A dependency = C# Events. Scene-based, A -> B dependency = UnityEvents. Scene-based B-> dependency = those ScriptableObject events that Ryan Hipple talked about in that Unite Austin 2017 talk (or something similar). Code-based, A, B -> C = statics. Scene-based A, B -> C = Singleton. Personally, I find A -> B dependencies much easier to follow (since it matches the flow of how things happen) and use that pattern by default unless there is a compelling reason to reverse it. Also, I prefer creating reusable tools over project specific code whenever possible and making connections on the scene level, rather than hard-wiring them into the code, lends itself better to tool development. Between these two preferences, I use UnityEvents a lot. There are downsides, but most of those are fairly easy to overcome: ScriptableObjects for non-serializable static arguments, a helper script with serializable classes for all the commonly used dynamic arguments, and then writing custom scripts with standard, code-based dependencies when UnityEvent lists start getting long and including lots of related items.

Awesome Video Thank #Jason it helps me a lot in my project

Nice videos!! Thanks

I think this misses the main reason you use UnityEvents vs Events which is an architectural one regarding coupling. UnityEvents (that are configured in the GUI) reach outwards into the app and execute methods, and are tightly bound to the scene graph. Events dispatch things blindly, and someone from above must subscribe. This is the first fundamental difference. The second is that UnityEvents force you into the Gui, which is more suited to non-coders. So basically for me, I see UnityEvents as generally an architectural anti-pattern, but recognize that for beginners, or non-programmers, they are might still be the best approach. As a developer myself though, I literally never use them, too hard to maintain, and you leave your compiler in the dark... ie I can't trace back to who turned something off, or called some method, cause the call binding is buried in some component somewhere. If you set up too many of these "game objects calling business logic" things in your scene, you project will turn into spaghetti really quick.

@uweeby69

3 жыл бұрын

Unityevents don't force you into the gui. I use them from code only often.

@ShawnBlais

3 жыл бұрын

@Jacob Ya that definitely is not so bad, as at least it's usually a local connection, like the child is directly connecting to parent. Doing that's in the Scene Gui is not going to bite you too often, though still pretty easy for that link to get broken, and you don't notice. If you wire up a listener via code (button.onClick.addListener), you'll usually get a runtime error if anything is wrong, which is preferable to the silent failure of some fxn call just not being made. So I prefer to just grab a reference to the btn in my view controller and add the listener: * Will throw RTE is btn is missing/unlinked * No hidden dependencies/connections that are not visible to compiler * Compiler can always trace back the caller of some important fxn (ending up in your view controller, and not some generic btn) * Less fiddling with massive dropdowns and finnicky gui * More consistent. When you have to use UnityEvents, they act like your other Events in the app. Don't need to wonder if something is mapped in Scene or Code, it's always Code.

@ShawnBlais

3 жыл бұрын

@@uweeby69 Ya that's a good pt, they don't force you into it, more like they have full GUI support which is better for those non-technical users, where Events can only be used through code.

@muratcanagic

3 жыл бұрын

@@ShawnBlais so you say i am a master coder and screw you. Unity Events offers both and Events are for only coding, so Events are better?

@Norivee

3 жыл бұрын

@@muratcanagic Unity Events are better in every way except for performance basically. So if you call an event pretty often, you'd probably want to use an Action event.

I use C# Events a lot for modular sorts of subscriber patterns. Very recently, I'm exploring adding UnityEvent fields (with very specific T0, T1, etc) to some scriptable objects to see if it's a viable way to expose ability scripting to a designer.

I'm the same. Most of my objects have some sort of C# event on them, and this is great for doing things like telling all objects in a raycast to execute their "Hit" function (although this doesn't need events, delegates or interfaces will do fine), or for subscribing to events that need to be watched closely (such as an inventory UI needing to update itself whenever the OnItemAdded event is triggered by a linked inventory). Overall, C# events are my go-to rather than UnityEvents, and are great for controlling functionality between 2 items where the link between them is known at creation time (like two objects that will ALWAYS interact with each other). Another thing you might want to do is wrap a C# event inside a ScriptableObject, as a "Event Object", and let your objects take them as parameters. This lets your artists do things like use the asset menu to create a "GameOver" event, then you can have your GameManager cann that GameOver event (referenced in the inspector), and then other objects that are completely unrelated can simply take an Event in the inspector to listen to it, which gives good-quality event control similar to C# events, but allows you to use the inspector.

Used a lot of UnitEvents with scriptable objects (like in the famous video describing the method), but transferred to mostly C# events. It became a mess with many scriptable objects, and what you pointed out, when changing or editing in the Editor, such connections can be forgotten. With the switch to C# events, you have it all in code, don't have to remember setting it up in the editor again. However, it seems like I'm moving towards some "C# event manager", like Game Manager, but for events, with public callable methods, so other classes can invoke the events. Don't know if this is a good way forward though.

I use them pretty much exactly as you describe. 95% of the time I use c# events and only use unity events for very specific one off things that happen in a particular scene so you dont have to clutter code for little edge cases. My only problem with unity events is its easy to lose the serialization on the call backs and that there is no compiler feedback, so I use custom attributes on anything invoked by a unityEvent and a little hacky editor script that lets me see all of those things, as well as logging out everytime a unity event is called and logging out the method name. Useful for when you come back to a scene after weeks and unexplainable things are being called lol

Both are great I can't decide on one .. I bet I'll use them both

I feel like the editing, sound quality, and overall quality of the videos have been steadily improving since I started watching. It's awesome to see. Good video as well. I don't know if you're allowed to talk about it, but does Pantheon use C# events or Unity Events at all? If so, what's the general mix?

Nicely exposed Jason. I make extensive use of the two kind of events and I think there are two thinks worth of mention: First, regarding the 'references flow', when using Unity events, the object triggering the event is the one with references to the object with the handler methods while when usind C# events the object with the handler method is the one which must be aware of the object triggering the event when subscribing (true, you can make c# style subcriptions with unity events but for me, if you are going to do that, then you should be using c# events from the beginning). This is interesting as allow you to approach the relations and 'object-to-object awareness' in two opposite ways. Second, in my experience c# events are far more easy to debug. Is easier to check who is subscribed to who and trace back what is happening. In the other hand, Unity Events are faster and more simple to set up (again, only considering Unity events set up from the editor as they don't make much sense when used as c# style). Usually my rule of thumb is 'if events are going to be static, meaning the suscription is performed in editor time and not going to change at runtime Unity events are usually the way to go; in the other hand, if I'm going to do/undo suscriptions at runtime then go for c# events'

Good stuff!

Hi Jason and/or Jason’s community. I’ve recently decided I’m going to get serious about learning game development and I’m going to start with trying Unity. Literally all I know about code is the small random bits I’ve picked up from watching random videos from this channel. I really appreciate your videos, man. My question is, are there some more specific videos here you would suggest a complete and total beginner to watch to get started? Especially interested in any videos that cover fundamentals and good practices to have from the start. Thank you so much!!

@12apidxHDxGamerx

3 жыл бұрын

Okay...well. My first step should have been checking the play list and seeing “beginner? Start here” LOL I swear I always forget KZread playlists are a thing for some reason. Still would appreciate any recommendations though, thanks all!!

Hi, Thanks for nice Contents :)

Greate Thanks Jason

Cool video. I was wondering if you have tested the performance between these two cases: 1. Have an event that will alert its listeners to turn on and off their Renderers for example. 2. Instead of triggering an event, simply activate/deactivate a GameObject and have the "listeners" monitor the state of the GO in LateUpdate so that they know when to change the state of the renderers. I dont know how events are structured, but listeners sure must check agains something in order to monitor for events, so at best it should be the same, but more likely a boolean check should be better than an event. (even when its not actually a boolean var but a state of a GO). What are your thoughts?

Another distinction is performances. I found a blog the other day that did a test case of both event types and UnityEvent have a much larger overhead! That said, you shouldn't have thousands of events running in loops, so you would probably only notice a difference if your game is already very tight!

Ohh funny. I just made german version of this same topic but not uploaded yet. I also talk about "Why to use unityevents, (static) events" + scriptableobjects to avoid singletons. Good video btw.

One blend of both events I hit upon not that long ago is wrapping a UnityEvent with a C# event like this: [SerializeField] private UnityEvent _someEvent; public event UnityAction OnSomeEvent { add => _someEvent.AddListener(value); remove => _someEvent.RemoveListener(value); } The specific implementation I used this for was a character prefab death event, so that stuff like Animator and ParticleSystem manipulation could be set up in the Inspector easily while also allowing the decoupling, strong typing, compile-time safety, and most of the other benefits of a C# event for anything external that might need to care about an event you could probably otherwise write as a stock C# event. I do want to emphasize that this was for a PREFAB, i.e. something that probably needs to be built with independence of any specific Scene, as opposed to a level-specific event like in this video. Honestly, though, I feel this particular setup, so long as it isn't overused and abused, is a pretty strong and durable architecture for marrying the benefits of both event types.

@ironbard4901

Жыл бұрын

Beautifully written and thought out reply : D

you can also hook up stuff in code for unityEvents too with AddListener/RemoveListener (and that's why I only use unityEvents) it's less pretty than having the custom opertaor but it allows to combine both wolrds

Thank you!

One thing I've run into, not so much a problem but an FYI. If I rename a UnityEvent in code, it clears my editor assignments to that event. Done that during a few refactors where I didn't remember what had exactly been assigned. Version Control makes it possible to double check, but I definitely find that to be a weakness of editor-assignment vs code, for what it's worth.

@Unity3dCollege

3 жыл бұрын

this is one of the biggest issues I run into as well :)

@kordeyrow

3 жыл бұрын

You can use the attribute "[FormerlySerializedAs]" to prevent that. blogs.unity3d.com/2015/02/03/renaming-serialized-fields/

@williamleebuckley

3 жыл бұрын

@@kordeyrow Good tip, didn't know that. Don't know that my OCD can abide that, but still really good to know.

@kordeyrow

3 жыл бұрын

@@williamleebuckley I dont know if I undertood right what you meant. After renaming the UnityEvent you can remove the "[FormerlySerializedAs]" atribute.

I mostly use UnityEvents for simple UI actions like buttons or OnPointerEnter trying to not subscribe more than one method and mostly those that come from the same object like closing a popup window or highlighting an object. For actions related to game mechanics i prefer regular C# events as they are much easier to debug and trace in code. You can easily find all the event references in your code.

Thank you a lot :)

To be honest, I keep forgetting how to use events so that's why I'm here xD

Hey jason great video like always. Do you think using unity events is bad idea for mobile game? Unity event performance hungry then regular c# events?

Not all heroes wear capes, but I really think you should consider wearing one Jason.

Jason my dream to get comment from you, you are the best!

tnx for youre video!

Hi Jason, I usually use UnityEvents instead of c# events, but to prevent things from breaking up easily in the scene, I only link in the UnityEvent the same object that is holding it, so even if I remove all the obejcts from the scene and add them again, the references wont break. And then, when I need to communicate between objects I use ScriptableObjects as Events. The SOEvent would be something like 'OnGemCollected' and may or may not pass any parameter. What do you think about it? Thanks for reading 👍

Most Important Questions for "When to use Unity Events vs UnityActions or delegates" Is there a possibility your designer or customer ever wants to trigger something when the event occurs, then use a UnityEvent. Do you want this event to be HIDDEN from the designer or customer? then use a C# event or UnityAction. I also keep reading comments saying "Unity Events force coupling in the GUI, or force you to use the gui". You can add listeners via code! I don't feel like Jason did a good job explaining this. I use UnityEvents almost entirely for the "Designer or Customer", but I never use them my self in GUI and instead subscribe to them just like you would a C# event via code.

that context menu thing is great! Before this I always did Editor scripts for the sake of 1 button for the inspector....

@halivudestevez2

2 жыл бұрын

( that is an event, too. an Editor event on the Component inspector ;) )

I prefer to use default c# events or custom observable pattern. I would like to use Unity Events, when I need to delegate job to junior developers, because they are much easier to understand and as far as I know they work in main thread when default events are asynchronous

I have been using a lot of ScriptableObject events for the past year, but all 3 types (unity, c# and SO) are useful in different situations.

Suggestion: Show the difference between dynamic input and static input to unity event. Hint: You can use dynamic input to prevent having multiple methods or relying on object references. Simplest example, wire a Toggle.OnValueChanged -> gameObject. setActive using dynamic bool

When it comes to C# events, according to the standard we should be using event EventHandler / event EventHandler, not event Action / event Action. I haven't heard about UnityEvents before, but I doubt I will use them. I dislike referencing stuff in the inspector. I have PTSD because pretty often my Unity loses those references at random which causes multiple random NullReferenceExceptions.

@Unity3dCollege

3 жыл бұрын

If ita for an external audience or library id go with the event handler, but for internal projects I really prefer the action syntax to avoid extra code. Undertand the view completely tho :)

One thing I found about UnityEvents is that private variables on the callee don't seem to change at all. So if object A exposes an event and object B's method is the method called when that event happens, if this method changes any of B's private variables, that doesn't work and variables seem to have their default values. I might try this again, but this happened to me a few months ago. Is this normal? I wonder whether I did something wrong, but maybe this is a case for C# events?

Thanks!

First ! Usually use normal events, but I've been programming for a very, very long time. Nice to see some more uses for unity events :)

@Unity3dCollege

3 жыл бұрын

Same here, i always have to remember the good times to use unityevents :)

I´m kind of new to unity, so I do not have a preference yet. I have been using simply what I find I could use or make :D

Reminder that it's good practice to unsubscribe from events when destroyed or disabled Also, in some cases you could have a public *static* event on those collectibles, so you only need to subscribe once

@Unity3dCollege

3 жыл бұрын

Unsubscribing is definitely something I shoulda covered :) Making them static may cause an issue though if we wanted to have multiple collectors collecting different things. But if that's not the scenario then there's no reason it couldn't be a single static subscription instead of all of them in a loop, great point :)

@frankzander5946

3 жыл бұрын

@@Unity3dCollege I always make sure that the subscibe stmt is adjacent to the unsubscribe to make it easy to track if I missed some anywhere. something like this: // delegate to collect everything we need to de - register on Destroy... private delegate void Dreg(); private Dreg dreg; private void Awake() { // register for the event and create an entry in the de-register list //for later execution AttackSubEvents.NewThustTarget += SetEngineThrust; dreg += () => { AttackSubEvents.NewThustTarget -= SetEngineThrust; }; } void OnDestroy() { dreg(); }

As someone who is comfortable with basic C#, enough so to make full games in Unity, could you recommend one book and/or reference to become more comfortable with intermediate/advanced C#?

"Work Hard and Be Nice to People" What a great slogan.

@Unity3dCollege

3 жыл бұрын

Ya when I saw it i had to grab that thing :) great daily reminder :)

@frankzander5946

3 жыл бұрын

@@Unity3dCollege Yeah I like that moantra too: shortened it for me to "work hard, be nice" ...easier to say to myself ;-)

@frankzander5946

3 жыл бұрын

mantra i.e.

What about sending information over events? Which one do you prefer? I could not manage to do it with UnityEvents.

Hello, will you do please some deep tutorial on multithreading in unity (c# jobs system) or multiplayer (photon unity networking)?

I developed a preference of handling any type of events without UnityEvents. Reason: persistent callbacks on UnityEvents are by definition not managed from code, thus they are the potential source of *weird behaviour* and they may straight up break the abstractions (when object A totally should not care about object B, but _some programmer_ linked them directly via UnityEvent). If anything is controlled by persistent callbacks on UnityEvents, then for the sake of clarity and integrity of your code it should have been controlled by regular callbacks.

@Unity3dCollege

3 жыл бұрын

I did the same for quite a while. But for some game types, UnityEvents seem to make a lot of sense (especially when working w/ designers who aren't programmers)

still no idea, seems like you could just hook up the referrences in code without using events at all? whats the strong case for using events?

8:38 - that syntax doesn't always work perfectly fine! It is not multithread safe, as some other thread might remove the last element after we checked for null. Always use the ? operator