Overboy's Recent Forum Activity

  • This would be amazing but i think it would be better if we could turn a Regular Folder into a Spritesheet Folder (so a setting per folder) instead of a global project setting turning all Regular Folders into Spritesheet Folders.

    This way we would still be able to use folder for organisation purpose as it works right now and create just a few special "Spritesheet folder" dedicated to memory optimisation whithin the same project.

    It could be an option on the right click context menu of Object Folders :

    Right Click > Turn into Spritesheet Folder (that folder would have a slightly different icon so we immediatly know this folder will force spritesheet packing for all its children)

    Right Click > Turn into Regular Folder (turn back the spritesheet folder into a regular folder)

    Regarding nested Spritesheet Folders, it should probably pack the Spritesheet subfolder into a single spritesheet and the content under the Spritesheet parent folder that isn't itself under a Spritesheet subfolder into an other spritesheet.

    Which means each Spritesheet Folder would be guaranteed to generate a different spritesheet no matter the size of its texture and their parent/child relationship.

  • EDIT : I released an addon pack including a Custom Expressions behavior and everything else i've been advocating for in this thread !

    ✅ overboy.itch.io/construct-3-object-signals-custom-expressions

    I posted a suggestion for Custom Expressions

    Vote here: construct23.ideas.aha.io/ideas/C23-I-336

    How it works :

    • It would work the same as returned Function.
    • You can use them using an ObjectType.MyExpression(MyParams) expression.
    • The special event block would be named "MyObject expression MyExpression1 -> Number" like in the mockup.

    Benefits :

    • It would support polymorphism
    • we would be able to create getter function very easily.
    • Would help to keep complex projects clean and readable.
    • No need to use Functions and passing UID parameter anymore
    • Just "MyObject.myexpression1" instead of "Functions.MyObject_myexpression1(MyObject.UID)"
    • Just "MyObject.myexpression2(Params)" instead of "Functions.MyObject_myexpression2(MyObject.UID, Params)" (look how long and unreadable it can get currently)

  • Yes I understand but at the same time, stuff like conditions and actions are SOL-based in Eventsheet while their equivalent in JS interfaces are instance-based.

    It would be better if Custom Actions scripting interface followed the same logic. SOL-based in eventsheet but instance-based in JS.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

Overboy's avatar

Overboy

Member since 21 Oct, 2013

Twitter
Overboy has 9 followers

Connect with Overboy

overboy.itch.io

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