Feature Request: Physics Joints for UI Elements
-
So they can be attached to characters and not be worried about any further. Fixed is best, but pivot also good and useful. For somethings the spring would also be of great value. I'm talking about UI elements that are passable, massless and friction free.
WHY?
Because using move-to in all its various guises lags, distorts and otherwise corrupts for anything moving fast or changing direction rapidly, where as massless, frictionless objects attached to anything respond as expected, staying with their "parent" perfectly.
This use of joints is much more than a mere substitute for parenting/nesting as it permits a degree of dynamic responsiveness in labels and other UI elements (particularly health bars) in their relationship with their characters that's often wonderfully organic, entertaining and engaging.
And it all overcomes the bugs in other approaches to solving this problem, which make this whole idea unusably unattractive due to lags and oddities.
Plus it's very low in cognitive requirements of users, and simply a case of making UI elements massless and frictionless and passable (by default) so this is possible without weirdness.
-
@Deeeds Physics attaches ONLY work for PHYSICS objects. I do believe it is possible to make a UI object a physics object, but it won’t be allowed on the UI layers. The 3 modes are Physics, Wall and Scenery. You’ve seen these yet?
-
Ok then, just tried it, only some UI elements can be made Physics, labels can, health bars can’t.
-
@Aidan-Oxley Ok. It's health bars I want.
-
@Deeeds you could make your own health bar.
-
@iTap-Development I could use Swift and SpriteKit, too...
-
@Deeeds for as much as you seem to dislike this app, that might be a good idea! LOL
-
@iTap-Development If I disliked the app I wouldn't bother commenting on its falters, fails, flails and foibles.
-
@Deeeds but you suggest using a different tool? 😂 LOL
-
@iTap-Development No. I'm mocking your suggestion.
I could also use Assembler to write an OS.
Or design a motherboard and BIOS.
How far down do you want to go?
When the name of the game is abstraction, the focus should be on finding the easiest and best possible ways to empower users.
Not turning on physics for all UI elements is a fundamental flaw in the cohesive experience of using hyperPad. It should be there. It's not because of an oversight or focus on other priorities. The OP is a request to remedy this situation.
As for your suggestion of building a health bar, I want to use the Clockwise health bar. This is not possible without masking, another feature missing from hyperPad that's about as traditional to 2D game (and art and animation) development as it gets.
-
You should be able to turn on physics on any object not on the UI layer through behaviours.
-
@Hamed Try it on a health bar that’s in a normal (not UI) layer. You can’t 🙁. EDIT: I’m a bad reader. You can do it through behaviours? Didn’t know that, but still, why can’t you just do it through the Scene Editor? Well, @Deeeds an easy way around this issue is in your health bar just have a Make Physics behaviour floating around with nothing connected to it lol. But yeah I think it should be in the Scene Editor.
-
@Hamed Thanks for this insight! I used a Pin connection, but it's kind of wonky. Spins when it shouldn't and locking rotation ranges doesn't work properly. The motor, also, is weird, simply acting like a weld rather than as a motor.
