Life saving suggestion for containers

  • Hi all,

    I saw around 2/3 years ago there was a suggestion for containers to have a checkbox that simply said "Maintain relative position" meaning that if that specific checkbox is checked that the objects inside/or connected to the container will maintain a relative position towards that container "host".

    This will allow creators to make menus, lists and any multiple moving parts less time consuming and not a tedious task.

    My game heavily relies on multiple categories and within these categories a unique generated list depending on the current game state. Having a feature like this can greatly reduce the time it takes to make setups like this by almost 50% because you would not have to reposition each element in the cell, and can change designs on the fly without touching the event sheet.

    I saw that there is already a suggestion over here: construct3.ideas.aha.io/ideas/C3-I-81 I'd thought I'd just mention it again :D

  • Instead set x to host.x, that's it, since being in a container will pick the rest of the objects inside. There is no need for such a feature

  • There's the Pin behavior that sets to the "relative" position which can go by not just the xy's for one tick, but the offset as well as the angle until it is unpinned.

    Also it does not have to rely on containers, just the initial picking.

    Would it be possible to create a behavior that works in a similar fashion rather than change the engine?

  • Over the years I've worked with a lot of IDE's. One of the best is Delphi. It's called a RAD (Rapid Application Development) platform. One of the ways it makes things really easy to work with is something called panels. You can drop these panels on a form (layout) and give them various alignments, like top, left, bottom, center or even custom alignments. When you drop components (objects) onto them, they have anchors and they anchor themselves to the panels. You can set the anchors to any combination of top, bottom, left or right. The beauty of this is, as the form gets resized, the panels automatically resize based on their alignment and the components anchored to them stay in a position relative to their anchor setting. A top alignment will adjust it's width but not it's height, to match the form size. Left aligns, adjust height, but not width. Panels and anchors are an almost fool-proof way of developing aps and having all of the components stay exactly where you want them, regardless of the size of the form.

    That... is something I desperately miss in C3. Call them containers or what you wish, C3's methods for layout placement always forces me to manually place things exactly where I want them in the onStart and browser resize events. And to me, that's pretty clunky.

  • I know exactly where you are coming from. My entire high school journey we used Delphi and the RAD ide.

    I know there is loads of other ways of achieving what I suggested, but the checkbox feature would make things much easier and convenient. I am currently using Pin with containers, but it still becomes a tedious task when you are dealing with alot of different elements.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Yes, I agree with that too !

    The containers are nil I find in C3, it's useless !

  • I don't think that containers in their current state are useless, it just depends what you are trying to achieve.

    In my case it makes it much easier to pick elements due to how the container system will automatically pick the relevant elements, of the picked "host" without you having to add any extra/special events. It's quite a unique mechanic and extremely underestimated, like I said it just depends on the purpose and if it's revelant to your game/mechanics.

  • If I hide or display the container, the attached objects are not hidden or displayed.

    If I move the container, the attached objects are not moved to the right position, do not keep their position relative to the container but are placed at 0.

    That's the weak point for me, so as it stands, it's totally useless!

  • If I hide or display the container, the attached objects are not hidden or displayed.

    If I move the container, the attached objects are not moved to the right position, do not keep their position relative to the container but are placed at 0.

    That's the weak point for me, so as it stands, it's totally useless!

    You're missing something somewhere.

  • What do you mean ?

  • Containers only apply to creation, destruction, and picking.

  • Then he's not missing anything. What he wants is exactly what I described in the Delphi panels. If you drop a button on a panel in Delphi and you anchor the button to the bottom right of that panel, regardless of how that panel changes in size, the button will always maintain the same x and y position relative to the bottom right of the panel. Once the alignment of the panel and the anchoring of the components is set, you never have to screw with it again.

    There is nothing in Construct whereby I can layout objects and have them maintain their relative position to... well anything. Even pin has it's issues. I can't pin a button to the layout and have it stay in that spot. Instead, I'm forced to create a function that I have to call every time a layout starts or the browser resizes and I have to go through every single visible object on the layout and tell it exactly where I want it positioned and if I want it resized, relative to the viewport dimensions.

    For example. In the project I'm working on I have a sprite in the top right corner of the layout. I ALWAYS want it 10px from the top and 10px from the right, regardless of how the browser is sized. With a Delphi panel, I set it's anchors to top and right and place it... done. In Construct I have to tell it... no, no, I want you HERE... now DON'T MOVE.

  • All these other requests should be handled by events or plugs. Containers do one thing, they make these other things easier, while not locking you into unwanted behavior.

    Yes we need more ways to deal with gui, no we don't need to complicate the basics.

    Edit:

    Also might want to take a look at the Anchor behavior.

  • I think OP is talking about having Child/Parent relationships between objects.

    It would be interesting to be able to drag an object on the Project Bar and put it hierarchically "under" another object (indented). So that it would inherit its move properties etc.. similar to the functionality of rigging a 3D model with bones with various relationships etc...

    EDIT: I think I saw it added here construct3.ideas.aha.io/ideas - not sure if that was you Blinky_RSA but if so maybe you should modify it to word it as 'Child/Parent' and frame it how many 3D programs utilize that functionality.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)