Nice and clean. I love it!

In the Ability UI panel, shouldn't the Bind() method also unsubscribe from the OnChanged method for the previously bound character?

@Un4GivNX

Ай бұрын

Went here to say this

Pheww, looking at the hierarchy, Im so glad I took the time to master UI Toolkit😅

@rarob0t

26 күн бұрын

Hey , where can I find more info about that? I really like thos icons for each GO in the hierarchy... I guess it is an asset or something he developed?

@Sim2322

25 күн бұрын

@@rarob0t Well, for one, be aware that UI Toolkit WILL NOT spawn a gameobject in the hierarchy for every element like the 'regular' UI framework (UGUI). It simply does not work that way. You have either 1 gameobject for all your UI, or, at most, 1 gameobject per panel. That said, it's much faster if you use it well (requires only 1 draw call to render the whole thing) and also much more flexible and portable. For me, the main resources I used to dive deep into it are: the official Unity eBook about UI Toolkit, the official Unity Demo Scene for UI Toolkit (Dragon Crashers), and I also got a coursera class about it. I would only recommend the coursera if you're really starting from scratch.

@rarob0t

25 күн бұрын

@@Sim2322 Oh looks like we were taling about different things. I was referring to the icons that are on each GO in the hierarchy. Thanks tho!

It looks like, perhaps, your UI scripts all have the Bind() method? If that's the case, would it make more sense to have a class that all the UI elements can inherit from which handles the binding methods, subscribing to the event etc, allowing the derived classes to override the methods they'd like to change? If not, why not?

@feildpaint

2 ай бұрын

Would an interface not be better?

@anonymous49125

2 ай бұрын

8:00 interfaces mentioned. Ideally you would just want a single interface per bound data (a great unity example would be UnityEngine.EventSystems's IPointerEnterHandler ), then register those interface-methods somehow with the event (which can be wonky, but there are a couple ways to go about it).. but that's just my preference on that. Problem with the class approach is it really locks you into extending from monobehavior or non-monobehavior (aka: object)... if you 100% are sure the class will always be a monobehavior, then class would work.... the second you want the to use it not in a monobehavior though, you're gonna have a bad time. Also, there is the old saying that "Nouns are classes, verbs are interfaces" - so if you're adding some methods to respond to an event (aka adding the ability to respond to an event), then they might be best served in an interface.

Rather than using a lamda for the "character.Abilities.OnChanged" delegate, couldn't you simply set the signature of "RefreshButtons(Character c)" to an take an optional parameter as such "RefreshButtons(Character c = null)"?

@Unity3dCollege

2 ай бұрын

Actually made that change yesterday. Afyer recording I looked at the again and realized the lambda was still hanging around from an early refactor and had to go :)

Couple of questions. Are Actions preferable to UnityEvents, as I've switched to UnityEvents so I can wire things up in the inspector. I notice abilityIndex is a byte, is that preferable over using an int, do bytes get padded out to ints when used and passed around? Thanks :)

@cq5857

2 ай бұрын

UnityEvents are actions, but get serialized in the inspector. For anything not serialized, use Actions

@Unity3dCollege

2 ай бұрын

Uea for inspector hookups use unityevents. Since these are all code only, I stick with actions. The byte is just because it's sent over the network eventually and I never have more than 6. Just reduces network bandwidth.

@connorjagielski6760

2 ай бұрын

In my experience it depends on the use case. For one off things like button clicks, unity events are nice because as mentioned you can just plug it in with the inspector. The downside is the limited use case, as it’s more difficult to pass parameters. Debugging is also much more difficult using unityevents. I’ve found that actions are a lot more flexible, and allow you to pass more parameters while being able to debug much easier. I’ve heard performance is better with actions too, especially when it comes to large numbers of listeners

@ezoray

2 ай бұрын

I do find UnityEvents a bit of a pain as in VS I'm blind to what's wired to where. I did wonder if the byte value was network related, makes sense. Thanks all.

@dreamcatforgotten8435

2 ай бұрын

Just going by what I've seen from different responses, but-- UnityEvent and UnityAction causes an instantiation when invoked. Both allow Serialization of events via Inspector. event Action and Action don't cause instantiations and don't have notable overhead until you have 100+ Listeners. 100-400 might be fine, but anything more and it might be better to use a Runtime set (a List that is either statically or SO-available at runtime) to iterate over and call some function. But that's really a personal recommendation and not a rule. When in doubt, do a benchmark test and profile for your usecase. tl;dr -- 95% of the time, you'll have more effective use of UnityEvents. You'd only really use regular Action if Serialization is not possible, or the event needs to be fired extremely often (every frame for example).

Where can i find more about the icons you have in each GameObject in the hierarchy? Thanks!

@Unity3dCollege

25 күн бұрын

Thats vHeriarchy from the asset store

Is your project resilient to unity fast domain reload? All those static events should be cleaned?

@Unity3dCollege

Ай бұрын

Yes but I don't use it because of the networking library and bugs it causes atm. I have fast reload times right now though and all the content can be added or modified at runtime so iteration is quick.

Why? What is the benifit of having that binding logic instead of using a simple UI components that reads the current selected character?

@SLaKMaNiTy

Ай бұрын

How would the UI component know when the character changed? You'd have to check the current character in update or something and check if the character is different to the previous character. This is inefficient and may cause things to happen when you're not ready for them to happen. E.g. the character selector might set the current character, wait a few frames, then broadcast that the character has changed, but your UI would update too early. Basically the selector can say "Hey listeners, I've changed the character! You can update your stuff now" rather than the other components constantly interrogating the selector to see if something has changed.

Okey, so u pass data through static fields & event. But if u cant? What should u do then. In my experience you should avoid static events and use them in very specific scenarious. Because unity dont reset static context when u trying to reload your game. Therefore, it is easier to rely on destroying objects and completely removing subscriptions along with the object, than always control static events. Have you ever had problems with static subscriptions when reloading a scene? How do you fight them?

@aldigangster123

2 ай бұрын

I don't think that static events are a problem in this sense. Static variables in general don't belong to a gameObject which has this component on it. Instead it "belongs" to the class itself. So yes, if you use a static float, it's value will survive a scene reload (= gameObject destroy - as it is not actually belonging to that gameObject). But in this case, a static Event Action is just like a broadcast-channel. Other classes are not looking at the static Action and ask "what's your current state?". Instead they LISTEN to a change, which is only triggered by a "living" gameObject. It broadcasts "I made a change, here is the new value" and the UI is reacting to it once. Hope that makes sense.

@w0lfend0

2 ай бұрын

​@@aldigangster123 I have encountered situations where you have to trigger static event but you still have subscriptions from unloaded scene with destroyed objects. So when this objects trying to handle event trigger an exception appears, because this == null. (subcription exists but object isnt). So to avoid this exceptions you should always check is "this != null" before doing something with your object. Its confusing to read this in code

@kantagara

2 ай бұрын

That actually sounds like you haven't unsubscribed from the event, and it's still trying to call the method that subscirbed to the static event.

@aldigangster123

2 ай бұрын

@@w0lfend0 Yeah like Kantagara said, this is not an issue with the static part of the Event Action per se. if you destroy a GameObject which has subscribed to any event (static or not), you always need to unsubscribe it in that same Destroy process. Not doing so will cause the event-raiser to still send a notification to that event-reader, even though it does not exist anymore = error. I persistently use OnEnable() for subscribing and OnDisable() for unsubscribing to events.

@lancemclachlan6603

Ай бұрын

@@kantagara Yeah I think that's the point he was making, you have to make sure to unsubscribe all your static events when changing scenes which is another overhead. I prefer to have a singleton that broadcasts the events.

I always prefer to create my own delegated events. Is there any advantage for using Action?

@Unity3dCollege

2 ай бұрын

Just less code, but either works.

@johncarlogamboa7331

2 ай бұрын

Delegates allow you to nice name your input parameters. So if you have an event that is ambiguous and may not easily reflect your intent then use delegates. Actions i use when my event sounds obvious like Action CountdownStarted; for example.

@anonymous49125

2 ай бұрын

action() is tantamount the same as a void() delegate... no great reason to write a delegate to void(), whereas you could, it functions much the same as an action with no huge benefits (both in functionality and readability). This is especially important if it is your intent to communicate that it is valid and welcome to quickly slap a ()=>{} into something and get that invoked easy enough. action() communicates 'KISS' to other devs and not to go crazy with the invokable (especially with communicating to not add new params nor returns willy nilly). Have parameters and returns and want it to be readable/intelligible? Then you want to use delegate; and if you want to protect the delegate from being cleared by mistake and invoked by mistake, you can use events as well. It's more effort, but the biggest benefit is that you're specifically communicating to other devs what it is that you want them to do and what they should expect... a lessor benefit is that it's easier to refactor and change the signature of the invokable (add a return - easy... change/add/remove a param, - easy... and so on). tl;dr - If you're just void(), action is perfectly fine and communicates that it's just something simple that's going to get invoked. Anything past that (void(int) is pushing it for me, and a void(int,int) or an int() is right out of the question) I would be itching to switch that over to a delegate+event asap, as the verbosity sets and expectation for other developers on how the event should be treated (and also makes changing that delegate signature slightly easier, also gaining the benefits of eventsTM)

Are you using unity dots, ecs and job system in this new course ?

@kantagara

2 ай бұрын

Doesn't look like it

Is the MM course complete?

@Unity3dCollege

2 ай бұрын

About 90%, still waiting for students to catch up on the content before adding the last bits to the extraction course, but the racing part is done and extraction is just getting a few more features for new libraries, etc. We still have our live calls mondays & thursdays and in the next few we'll be talking about steam integration (working on putting the moba up on there now w/ friends / etc integration so it'll be a key topic :)

@KyryloVesna

2 ай бұрын

What is MM? The More Mountains plugins?

@MalikenGD

2 ай бұрын

@@KyryloVesna Multiplayer Mastery, his multiplayer course

You know all these mechanics and Code and modular Design is nice and all But could you please showcase more advanced enemies or Boss fights So far from the little Trailers the enemies AI I saw is Kindergarten at best if the fighting is this dull then no amount of vfx is gonna save it. I really want to get this course but please tell me there will be more advanced and immersive combat coming into this course