piranha305's Recent Forum Activity

    I'm repeating myself here, and there are only so many times I will repeat myself before I deem it no longer helpful to respond. Here we are talking about the long-term maintainability of installable addons, not whether you can download a copy of the engine source code. Any open-source project with installable addons will also have to consider long-term maintenance of the addons that are created, and the professional, industry-standard way to do that is encapsulation, which is what the Addon SDK v2 does.

    I don't think the issue is really with open source, and while I agree encapsulation is generally a good thing in a large code base. I think the frustration comes from the fact that with the changes, the API surface is being heavily reduced. compared to other similar game engines which also use encapsulation, the main difference is they all have vast API's to modify the engines internals. and while these are generally not supported indefinitely, they are supported for a subset of time usually gated by major releases. this probably does not play well with construct release cycles since they are very frequent. but access to all the older version of the editor still help.

    one thing that worries me as an addon developer, is major overhauls like this will probably occur in the future again. and a large portion of the community hard-work will need to be rewritten or become obsolete.

    In his reply on that thread he mentions

    The solution to this is: define and document a public API with specific methods that you promise to support indefinitely. Then we know the feature set we have to support when making changes. This is the standard and widely accepted approach in the software industry.

    But that is not how software works in 99% of major companies. Breaking changes have all the time that's why things like symantic versioning exist. Eventually there will always be breaking changes weather it's add-ons or optimizations or new features. IMO the fix is to have better versioning. What's happening now is a lose/lose situation for everyone involved. It adds more friction and does not really solve the underlying problem.

    I have marked my none effect addons as deprecated now as I am not sure I'll port them. They are open source though and it should be straight forward for anyone to port them if your project relies on any of the addons.

    It is so disheartening, I think I will do the same.

    what if addons were versioned with a specific editor version. this would guarantee that addons don't break project's on a particular version of the engine. and just prohibit addons from being installed on new version?

    enforce addon devs to signoff on the version to keep parity with the engine? packages in other software follow this principle. where libraries and packages only support a set of versions of the tool.

    If I am creating software and decided to use x library. and then mid-project I need to upgrade my tool. and the library is not compatible with the tool (yet, or maybe never). there is a tradeoff of I need to find a new solution or not upgrade until the next project? i don't to go to like Microsoft and say hey this library on github does not work with dotnet 8, fix it? thats not how stuff works

    Simplest example: The platformer behavior. You can code this entirely in events if you want. But it's also surprisingly complicated and it's really convenient to just use the behavior

    To this point, code reuse in construct is not friendly towards add on devs, let's say you build a system around ledge grabbing in events. Let's say you want to use this system in multiple projects. Oh just turn it into an add on, oh wait there is no way to extend the current platform behavior with out completely rewriting the whole behavior. (which imo becomes an even bigger compatability nightmare)

    This is not the case in other software? Not just game dev? And the philosophy of this new sdk I think is very detrimental to construct.

    Other game engines also don't make you reinvent the wheel every time, they have standard libraries, and a set of extensible classes for you to build upon and use. This has not appeared to be the case. To make the simplest of add-ons your forced to implement all the logic when the engine already has that built it? This makes no sense. Construct has built in vectors, and a built in color class that handles all the math and conversion, yet if an addon needs these, your force to rewrite all that code? Engine are literally suppose to make making stuff easier. This deviates so much from that idea. I seriously keep asking my self why I keep using construct?

  • Is there was to pass an image to html? That is not part of an icon set?

    That I can use in an img tag or as a background in css?

    Tagged:

  • piranha305

    I don't understand what you're meaning with this screenshot ??

    Why are you setting the "variables" as node outputs, how would you branch this Dialog node to other Dialog nodes. Outputs is supposed to store other nodes, no the values of the current node.

    The Dialog Node should be linked to other Dialogue Nodes.

    so the way i understand this feature? is the Output is optional, its all just data that could be linked? and you can traverse the structure? since its just data you can store all the values relevant to the current node... including transitions? its flexible enough that your not tied to rigid implementation? let me see if i can come up with a better example

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Fib Yeah but this means we have to recreate every single ACE that already exist in Construct 3 to create our own awful node-based Unreal-like Blueprints ?

    why are you trying to recreate blueprints though?

    imo this should not be a replacement for eventsheet? but a tool to supplement them? having every single ace exposed as a node does not really make sense?

  • Also it still doesn't solve the Node Data issue i keep mentionning. What about the avatar sprite, the avatar animation, the text animation and so on ?

    aren't those just different properties on the node? that you can read while traversing the graph? I see those kind of the same as doing a JSON.get(path) just your path is the property name on the node... then perform whatever logic you need on those? like create the sprite set the animation?

  • 2. or you create a new trigger for each node via the "OnSpecificNodeEnter"

    So I see where this is coming from, but could the system be designed where you add a string based tag to "identity your node type"

    and instead of having 5000 on node enter condition foreach case? you just need to implement logic for each type (which could have whatever properties you want?)

    and on any node enter look at that first NodeType value and branch accordingly?

    With this in mind some improvements would be the ability to duplicate nodes, and having text auto complete in the flowchart controller plugin.

  • I Have been using Construct for while, and I feel like this year has been amazing in terms of updates to the engine. There have been some truly game changing features added. By far the most impactful to my workflow (in no particular order)

    • Auto Reload Addon on Preview
    • Hierarchies
    • Templates
    • Custom Actions
    • 3D Objects

    And that's just to name a few, there really are so many it's mind boggling. I really want to express my appreciation for the Scirra Team for continuing to improve construct, and engage with the community and take feedback.

    THANK YOU!

    Ashley DiegoM Tom Laura_D

piranha305's avatar

piranha305

Early Adopter

Member since 26 Apr, 2016

Twitter
piranha305 has 34 followers

Connect with piranha305

Trophy Case

  • 8-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • x5
    Coach One of your tutorials has over 1,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x4
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x2
    Lightning Draw First person to up-vote a new Construct 3 release
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

18/44
How to earn trophies