Overboy's Recent Forum Activity

  • You do not have permission to view this post

  • You do not have permission to view this post

  • I created a suggestion for Custom Actions scripting support a month ago :

    Vote here> construct23.ideas.aha.io/ideas/C23-I-272

    The best way to handle it in scripting would be per instance :

    instance.callAction("MyAction", parameter0)

    As it works for all the other stuff in scripting interfaces.

  • Functions map are tedious to use.

    We need 2 things to solve all issues :

    1. Ability to turn any Function/Custom Action into a Better signal (= Multiple "Listener Block" support) : construct23.ideas.aha.io/ideas/C23-I-165

    It would be the same as calling Multiple Function at once with the same parameters but with an amazing UX, an optional execution order feature and a single thing to "Find All References" for (single name).

    2. Ability to call a Function/Custom Action by its name

    (3. For 2 to be easier to use in some situations, it could be cool to have Function/Custom Actions Names autocomplete and autoupdate everywhere thanks to new System Expressions such as EnumFunctions.MyFunctionName and EnumCustomActions.MyObjectType.MyCustomeAction as in this suggestion : construct23.ideas.aha.io/ideas/C23-I-69 )

    I detailed those 3 points extensively in this thread : construct.net/en/forum/construct-3/general-discussion-7/custom-actionsfunctions-175063

  • You do not have permission to view this post

  • IMO Buttons/Sliders/Radio Groups and that kind of UI component are already achievable relatively easily with existing Eventsheet features (Families/Hierarchy/Custom Actions)

    While it would be great to have those "Components" built-in in C3, IMO this isn't the real pain we're facing with UI right now. It could bloat the engine with a bunch of additional Plugins/Behaviors and each person might want their Sliders/Buttons to act very differently. So Component would probably need too many features and parameters to cover everyone's need and might even be disappointing in the end, and dismissed in favor of "custom Components" created with existing features.

    If those potential "Built-in Components" were Plugin, it would be the same pain as today as there is not Multi-Plugin support for Families in C3 for example

    The biggest pain is manipulating the position (transform) of all UI Objects with auto-layouting which is almost impossible to achieve even with Families as Text and Sprite for example are different Plugin and can't share common logic. (it would be the same issue with Button/Sliders)

    This is why Hierarchy based autolayouting would solve this as it works with any world object (+ easy picking benefit and intuitive display in a potential Hierarchy view)

    Hierarchy based autolayouting + a "Selectable" behavior would help us to make those Slider/Button/Grid/Scrolllist "Components" ourselves

  • As i said several times in the past, we don't need to replicate everything HTML and CSS can achieve to be able to create UI in C3.

    We just need :

    1. Hierarchy-based autolayouting features (similar to Godot Containers docs.godotengine.org/en/stable/tutorials/ui/gui_containers.html as they're the best autolayouting ever created for a game engine)

    2. maybe a new "Selectable" behavior

    (The suggestion explain those 2 points further,https://construct23.ideas.aha.io/ideas/C23-I-78)

    The existing C3 features and all existing synergies that exist between them will do the rest and allow us to do anything we could imagine for our UIs using eventsheet features.

    On the other hand, turning HTML/CSS into a decent UI solution is a rabbit hole and might even be impossible for a bunch a reasons I pointed out in the Twitter thread. (live preview of UI at editime, reliable and consistent display across platform and browser, event sheet ways to manipulate the UI, Layer support just to name a few)

    Anyway sorry this wasn't the subject of this topic, just wanted to pointed out that 3rd party console porting would be 100% impossible to achieve for games relying on HTML/CSS UI as opposed to any game currently developed in C3

  • browser things the HTML Element object with custom HTML and CSS may never be portable.

    I think this is quite an (additional) important point against requiring us to use HTML/CSS for UI systems. Most popular C3 commercial games are ported to console thanks to those 3rd party companies but soon it might be impossible to ever port a C3 game to console if the whole UI of the game was done using HTML/CSS.

    And this is only one of the less annoying drawbacks with going with a HTML/CSS-based UI solution for C3 as we talked about recently

    twitter.com/OverboyYT/status/1638952637315047424

    (which is also why i think we need built-in UI features and they could be Hierarchy-based construct23.ideas.aha.io/ideas/C23-I-78 )

  • You do not have permission to view this post

  • You do not have permission to view this post

  • I forgot to mention it but this is happening to me since at least r332 (not just since last stable r336 release)

  • It happened to me several times too. The editor was completely frozen and I had to close c3 without saving.

    I'm using project folder.

Overboy's avatar

Overboy

Member since 21 Oct, 2013

Twitter
Overboy has 7 followers

Connect with Overboy

Trophy Case

  • 11-Year Club
  • Entrepreneur Sold something in the asset store
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • RTFM Read the fabulous manual
  • x18
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x15
    Lightning Draw First person to up-vote a new Construct 3 release
  • x25
    Great Comment One of your comments gets 3 upvotes
  • Delicious Comment One of your comments gets 10 upvotes
  • Email Verified

Progress

23/44
How to earn trophies