Forums » Suggestions
RmlUi - Draggable HUD design
I think it would be beneficial if the new RmlUi-based HUD were designed from the beginning to allow major display components to be draggable.
RmlUi's <handle> tag already works out-of-the-box to allow simple movement or resizing of display elements.
One major consideration that comes to my mind when planning for this is the structure of the HUD. The IUP HUD currently uses a multi-layered, single-document (dialog) approach. I'm assuming this was due to how IUP dialogs interacted together and possibly styling limitations. With RmlUi being much more free-form, I think a multi-document approach would be a good direction to take things. Each major HUD component would be a separate document that is only sized to its contents and has a <handle> that could be used to freely reposition it.
Clearly, certain elements, like the center crosshairs, would need to be static. For these, a fullscreen-sized document would probably be best. Of course, this introduces the possibility of clicking this document and pulling it to the front and on top of everything else. This should be easily remedied by having a Click event for it that merely uses `Document:PushToBack()`.
In my own experimentation, I've been looking at trying to use RmlUi Templates as a means to create the building blocks for these component documents, but these efforts are hampered by our current inability to use inline scripting in Rml files. My plan here was to use a combination of inline scripts for "onload" and the "onhandledrag" to retrieve or store positioning and then update custom RCSS properties. While this can be worked around using `Element:AddEventListener()` in the back-end Lua, or C++ equivalent, it could be streamlined by having it all defined in a single template.
RmlUi's <handle> tag already works out-of-the-box to allow simple movement or resizing of display elements.
One major consideration that comes to my mind when planning for this is the structure of the HUD. The IUP HUD currently uses a multi-layered, single-document (dialog) approach. I'm assuming this was due to how IUP dialogs interacted together and possibly styling limitations. With RmlUi being much more free-form, I think a multi-document approach would be a good direction to take things. Each major HUD component would be a separate document that is only sized to its contents and has a <handle> that could be used to freely reposition it.
Clearly, certain elements, like the center crosshairs, would need to be static. For these, a fullscreen-sized document would probably be best. Of course, this introduces the possibility of clicking this document and pulling it to the front and on top of everything else. This should be easily remedied by having a Click event for it that merely uses `Document:PushToBack()`.
In my own experimentation, I've been looking at trying to use RmlUi Templates as a means to create the building blocks for these component documents, but these efforts are hampered by our current inability to use inline scripting in Rml files. My plan here was to use a combination of inline scripts for "onload" and the "onhandledrag" to retrieve or store positioning and then update custom RCSS properties. While this can be worked around using `Element:AddEventListener()` in the back-end Lua, or C++ equivalent, it could be streamlined by having it all defined in a single template.
Okay. I certainly have no opposition to the idea of a customizable interface (I've always been positive about the idea, the resources were just difficult to justify in the face of more pressing problems).
But, we are not currently working on the HUD. The point of RmlUi is to allow rapid prototyping and improvement of the weakest structure in the game, which is the station/ship/PDA menu interface, and also to allow us mock up complex new interfaces relatively quickly.
We will come around to redoing the HUD in time, and when we do, it is likely we'll make it customizable.
That said, I think what you're asking here is that we enable things to allow you to move forward in your desired direction. I'd like to support that, if possible, but I can't speak to that right now; we'd have to dig into it further.
We'll try to take a look at this, before long, but we are a little over-loaded right now.
But, we are not currently working on the HUD. The point of RmlUi is to allow rapid prototyping and improvement of the weakest structure in the game, which is the station/ship/PDA menu interface, and also to allow us mock up complex new interfaces relatively quickly.
We will come around to redoing the HUD in time, and when we do, it is likely we'll make it customizable.
That said, I think what you're asking here is that we enable things to allow you to move forward in your desired direction. I'd like to support that, if possible, but I can't speak to that right now; we'd have to dig into it further.
We'll try to take a look at this, before long, but we are a little over-loaded right now.
I fully understand. I mostly wanted to get out in front of the horse and start floating ideas before too much work had potentially been done to easily change directions.