Yes, you can do draggable widgets like you'd do in other systems. But this is not included in the system out of the box currently

Sorry, I should've pointed that out. It's stat DrawCount

hi there and good question, The primary layout widget handles that, it is simply an overlay and the layers are ordered inside it. And you're correct, that's one way to hide other layers, we can either hide the top of the layer, or hide the layer itself. The system in the video is simple, and needs more utility functions like hiding other layers, handling fading in and out, etc., but it's a good starting point to build upon.

@@AmrMakesGames Got it, okay thanks

يا مرحب بابن بلدي يا مرحب

Welcome abroad, Sherif, and I'm glad you love my content!

طالما سلاسة الشرح جميلة يبقى انا اتعلمت من الفرجة على فيديوهاتك الجميلة يا زياد 🙏

@@AmrMakesGames يعم متقولش كدة دة احنا نتعلم منك يا استاذ عمرو

Sorry for the confusion, a viewmodel can be created in multiple instances and doesn’t need to be one only. The example we discussed at 06:00 is just for consistency and performance because they all read the same source of data. On the other hand, a singleton would be something like the MVVM subsystem, which is a single global instance.

@@AmrMakesGames Do all instance still refer to the same variable?

In that example, yes

One thing you could do since only one widget can be visible in a layer at a time, is to push the item pickup modal to the Modal layer, since it is a modal. Then, in your game screen where you have a vertical box of items or the inventory, your pick up modal will communicate with inventory widget to add an entry, and then you pop it from its Modal layer. please let me know if something is not clear

In general, I think there is a gap between the project and some understanding how this works. I might look up more viewmodel examples to help understand this.

Yes, mainly showing both ways, and looking into how MVVM works in general can help you understand it even better. But if you've any questions, please don't hesitate to ask.

Yes, it is complex to a high degree, but if we compose down to its components and explore the different llugins and features it uses individually, you'll find how flexible it is. For first person, if you haven't figured it out already, simply understanding how camera modes work in Lyra should make it a little simple for you

@@AmrMakesGames yer its a complex system i have first person working now with arms and hidden TP mesh but think i might have to make my own weapon system as lyra has hard refs to all the weapons instead of soft refs and also every time you change weapon it destroys it and respawns it which is a really bad way to do it , it might be alright for single player but for multiplayer its not very good

Exaclty. It is similar to using event dispatchers, but with an extra advantage that UI won't be coupled to the source of the data, and only to the view model.

ahhh, I just found out to make a key actionable during pause, I need to enable "Trigger When Paused" on the action. Mind blown

You're welcome Fahim. Possible yes, but may I know what you're trying to do so I can give you a more detailed answer? Currently each layer has a unique tag, this is the idea of using gameplay tags. And each layer can have one Widget active a time, since a layer is a stack of widgets. You can add more layers with more tags, and these layers are all shown simultaneously, but it's rare that you would need many of those. If you need two widgets to show in the same layer, then simply one widget should contain both of them and be pushed to the layer's stack.

@@AmrMakesGames thanks! Makes sense. Just like you merged the weapons and health UI.

Hi there, they're a very simple handling for UI Input focus. Focus Modal makes UI consume input and blocks it from passing to the Game. So, if you have a pause menu open for example, pressing WASD would move through the menu instead of moving the player. Focus Game does the opposite and allows input to pass to the game. This is a very simple implementation though; some work is required by widgets to specify what element should get focus. I recommend you take a look at How Slate handles input routing.

Will do!

⁠@@AmrMakesGamesI see that you use common user widget in the example project, would you switch to common activiatable objects instead to achieve what you said?

@@txu2011 definitely would do, along with other common ui features. This example was meant to be simple and avoid the overhead of common ui.

Will plan a more thorough video with a more sophisticated system that manage pop-up requests and UI input soon hopefully!

عفوا تسلملي 🙏

تسلم يا غالي بنتعلم منك

Hope it was useful, and take your time in grasping each point

It was slate console variables, I guess I used: SlateDebugger.Invalidate.Enabled 1 SlateDebugger.Invalidate.Start

@@AmrMakesGames perfect, thank a lot

حبيبي ❤️🙏

Here you go: discord.com/invite/bxNVFxhV

@@AmrMakesGames Thanks!!!

Definitely, the upcoming video will touch it briefly, and I'll plan a more detailed one regarding it and dependencies in general soon!

Thankful for your support as always bro!

Good question, yes they're very context sensitive as with anything related to performance. Inheritance can lead to larger object sizes since derived classes inherit all the properties and methods of their parent classes. Interfaces introduce a slight overhead due to the need for method lookup at runtime (similar to virtual function calls in inheritance). However, this overhead is generally minimal. Components add to the memory footprint since each component is typically an object attached to the main entity. However, this overhead can be minimized by designing lightweight components. But we can't say something is more performant than the other without the full context. For example, depending on how components are managed (e.g., using contiguous memory storage), they can be very cache-efficient, leading to better runtime performance, especially in entity-component-system (ECS) architectures.

Another thing I did to the system was add a always available widget array to the HUD and corresponding layer. This is for widgets like the settings menu and inventory screen we only want to collapse and show. Very well written and much respect for this man your a great programmer ! I would love to do a consulting session sometime about architecture etc. Have a great day man !

Hi, no, it is not functional, unfortunately, just for demonstration.

Definitely, DAs are a great option for styling and theming. This is kinda similar to common UI's style objects like UCommonButtonStyle.

Thank you for pointing it out, I wasn't aware of that, and I believe you can send an issue to Epic. Meanwhile, the only way I know of is to dig into how this context menu button is implemented in the engine code and modify it that it shows on the rig graph.

@@AmrMakesGames I'l look into reporting it to Epic (I'm not knowledgable enough with C++ and the Unreal source code to do any real investigating^^).

Hopefully, will make more UI guides soon

Will consider this one, but in the meantime, and since I'm not experienced with such a system, I believe you'll find many answers if you post on Unreal's dev community or discord servers.

@@AmrMakesGames Thanks