You can create loading screens for sure, but unfortunately when you load a new map within UE4 the screen freezes. There is not UMG-only solution to this, so we cannot solve that in MMS. Google for “unreal animated loading screen” or similar for more information on this issue.
The buttons you see in the MMS video and screenshots are samples, screens that you can create easily with MMS. However, we do not ship the game-specific logic behind the buttons. So for a “play online” button you would need to write your own logic. MMS provides the tools to create the menu and its layout though.
Yes, youi can change the template looks. Depending on what you want to change, you can either modify our UMG templates, or you can make your own textures etc.
Starting from today, the Modular Menu System is on sale with 35% off for one week!
So if you every played with the thought to test MMS, this is your chance now
As far as making it “work” with VR, all you need to do is create an actor class, add a widget component, and then make the widget component the root. After that, it’s just positioning that actor into the world. This part is easy. I think what people really want is for the UMG widget to be attached to the player, in 3d space. This part… I wouldn’t include in this project to be honest, since this is highly dependent on the person’s game. However, it’s done by adding a BP actor (the one created above) to the component list.
The other “VR features” are, in order of importance:
Controller support (UMG should support this out of the box, why it only supports mouse and keyboard out of the box is… something Epic needs to look into. However, there are a number of “BP hacks” you can do to implement controller support)
Look-at support (Look-at support just involves a line trace from the camera to the UMG button / area. When the line trace is successful, then that button becomes active, allowing the player to click on it)
Here is how “VR menus” should work, in my mind… and this is what I am most comfortable with, using a screenshot that was provided in the examples:
User activates the menu (“Special Right”, aka: Start button)
Menu is divided into the 3 vertical areas (I forget what they’re actually called atm), and the 1 horizontal area at the bottom. We’ll call the verticals as VB1, VB2, VB3, and the horizontal as HB1 (Left to right, top to bottom)
When the user looks at (Camera trace) to VB1, then that section becomes “active”.
At this point, the user can use the up/down to cycle through the items.
If the camera trace hits on the “SDsdflj sd s Hsdf”'s (2nd item in VB1) drop down menu, then that drop down itself becomes active.
However, if the user does not activate the drop down (instead of activating it using the… “face button bottom” (aka: the A button), the player can still select other objects. An example of this behavior would be in HB1. If the player looks at Save Settings, then it will become active. However, if the player (still looking at save settings) presses the right button or right axis, then the Cancel and Return button becomes active.
It takes a bit of logic for this type of behavior, but in the end, it is much more of a natural interface to work with than using just one or the other. Of course, there are exceptions, and this behavior should be selectable (Look-At, Controller, Hybrid).
Something else I would suggest, not specifically VR related, but the ability to populate a menu with items from a data set. Specifically, when the user “unlocks” a level, then that level becomes selectable in the game for the user to transport to. This could be a horizontal/vertical layout box filled with buttons (button text and level names coming from the data set) or drop down menu items coming from the data set.
@haimat I would like to use your menu system, but my game uses gamepads. As far as I am aware, Modular Menu System doesn’t support navigation using a gamepad. If that ever changes, please let me know.
Cant wait for gamepad support! Just bought it and it’s very easy and straight forward to use. Just a note though, it doesn’t look like you set the Dialog Menu in the Event handler at least in MMS_SimpleMenu. Also you never got rid of the event caller, I modified these to set the event handler in construct and delete event handler on destruct. Overall great system though!
Good news everyone, we have updated the Modular Menu System to version 1.4.
This update contains the following changes:
Every Add… BP node will now return a reference to the newly created menu element (e.g. a button)
Auto-save dialog/menu object into event handler at menu construction
Now every time you add a new menu element via one of the AddXXX Blueprint nodes, the newly created element is returned back to you. Usually you won’t need to interact directly with those objects. You might, however, want to hook custom event handler functions to the event dispatchers within the menu elements. That way you can omit the generic MMS Event Handler and react to user interaction events, such as button clicks for example, directly in your BP graph.
To make use of that feature you will need to bind a custom event to the new element’s event dispatcher. You can easily do so by dragging a line out of the return value of the AddXXX BP node, search for “dispatcher” in the context menu, and click on the “Assign … Dispatcher” option. This will automatically generate an event function for you to use in your BP graph.
For example, to print out the ID of a button when it has been clicked you can create something like this:
We hope you like this new update.
As usual, if you need any help with the MMS, please don’t hesitate to post into the MMS support thread.
Cheers
PS: We have updated the MMS manual as well, which you can download from here.
I want to buy this, but I am using UE 4.13.0 …on the marketplace it says supported engines 4.10 - 4.12 …will it still work? …if not …will you keep updating it for the different engine versions as they get higher?
