Thank you for an idea! I’d rather add another macro containing the cast part itself to make your CastSomeClass more abstract, otherwise you’ll have to copy-paste too much similar logic again and again. So your CastSomeClass macro would have (among outs) Cast pin for external CastAttempt macro call (like Loop body in foreach) and Success/Fail/Object ref ins to send control back and either loop further or return the result. A bit ugly but correct and understandable :)
This is handy! I am trying to replicate player stats across the network (matches that have about 20 people connected at once) that change once every 15-20 seconds. Ideally the user interface would update each player's stats in real time. I imagine this would be way too much casting and bottleneck things?
Considering the "Tell, Don't Ask" programming principle, it appears to be more beneficial to inform the UI of the presence of the `PlayerState` object and the need to create corresponding widgets upon the triggering of the `PlayerState.BeginPlay()` event, instead of awaiting the existence of a valid `PlayerState` reference in the UI as you propose. Would you mind explaining why you opt for the latter method?
That setup makes 1 class (PlayerState) responsible for communicating to all dependant widgets. So 1 (playerstate) takes care of 15 others (widgets) for example. In the other scenario, the ‘ask’ scenario. Each individual widget takes care of itself rather. Instead of the playerstate now being responsible for all widgets. Each widget takes care of their own. Easier when plugging widgets in and out of differing gameplay within the game in my opinion. Your game setup becomes more modular when each widget handles itself and simply ‘asks’ for data it needs.
A scenario for the tell method which might get complicated: When UI get’s created at a different stage then the BeginPlay event perhaps. But all methods can work. Simply a matter of proper planning. Tell method can definitly be beneficial too if you are able to keep proper track of the spiderweb you create if that makes sense.
Hey guys,
👨🏫 My Patreon link:
www.patreon.com/kekdot
Download Project Files | Premium Tutorials | Courses
💦 Get our Game on Steam | Kekdot Center:
store.steampowered.com/app/1487180/Kekdot_Center/
Thank you for an idea! I’d rather add another macro containing the cast part itself to make your CastSomeClass more abstract, otherwise you’ll have to copy-paste too much similar logic again and again.
So your CastSomeClass macro would have (among outs) Cast pin for external CastAttempt macro call (like Loop body in foreach) and Success/Fail/Object ref ins to send control back and either loop further or return the result. A bit ugly but correct and understandable :)
This is handy! I am trying to replicate player stats across the network (matches that have about 20 people connected at once) that change once every 15-20 seconds. Ideally the user interface would update each player's stats in real time. I imagine this would be way too much casting and bottleneck things?
Considering the "Tell, Don't Ask" programming principle, it appears to be more beneficial to inform the UI of the presence of the `PlayerState` object and the need to create corresponding widgets upon the triggering of the `PlayerState.BeginPlay()` event, instead of awaiting the existence of a valid `PlayerState` reference in the UI as you propose. Would you mind explaining why you opt for the latter method?
That setup makes 1 class (PlayerState) responsible for communicating to all dependant widgets.
So 1 (playerstate) takes care of 15 others (widgets) for example.
In the other scenario, the ‘ask’ scenario. Each individual widget takes care of itself rather.
Instead of the playerstate now being responsible for all widgets. Each widget takes care of their own.
Easier when plugging widgets in and out of differing gameplay within the game in my opinion.
Your game setup becomes more modular when each widget handles itself and simply ‘asks’ for data it needs.
A scenario for the tell method which might get complicated:
When UI get’s created at a different stage then the BeginPlay event perhaps.
But all methods can work. Simply a matter of proper planning. Tell method can definitly be beneficial too if you are able to keep proper track of the spiderweb you create if that makes sense.
2:39 Does anyone know what that 'bloop' sound is?
I've been getting that when using UE and it's very very annoying. ;^/