piranha305's Forum Posts

    • Post link icon

    I know this is the exact thing you want to avoid. Because if you ever changed something about how groups work in the engine, the addon could also have broken.

    So essentially they are breaking all the addons now so just in case in the future if engine changes break the addon, they are technically not at fault?

    That's not sound logic, because engine change always have a chance to break your project regardless?

    Which is why if u have a game that's going to be released you stick with one version to mitigate those risk factors?

    • Post link icon

    On other thing is the way to access runtime? will that be changing? becuase there are alot of things documented in the current sdk runtime

    construct.net/en/make-games/manuals/addon-sdk/runtime-reference/runtime

    that are not exposed in the scripting runtime

    construct.net/en/make-games/manuals/construct-3/scripting/scripting-reference/iruntime

    things like manipulating SOL, and EventStacks? + many other functions? will these need to be added to scripting api before tehy can be used?

    • Post link icon

    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.

    • Post link icon

    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.

    • Post link icon

    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.

    • Post link icon

    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

    • Post link icon

    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.

    • Post link icon

    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

  • For example, how'd you do a check for: "if (player.health < 10 && player.poisoned) showOption()". Currently a flowchart has two fields where we could convey this information we want to test for with the eventsheet. The name, and the value. The name doesn't really appear to be the right place for this. The value... maybe? But it would mean we have to write a JSON string into the value, then parse the JSON, then extract the intent what we want to check for with which values, call a function and if true, stitch in some flowchart. When with the other approach, we'd just have a field that says "condition" and we throw in a function that returns true or false, and if false the node is not shown.

    I 100% agree with this...

    being able to attach a condition to the flow chart weather that is thur some type of expression or a custom node or function? that handle conditions and branching based on that, it improves the eventsheet / flowchart workflow so much.

    having all the logic in event sheet adds a bit of context switching, and if your nodes for some reason dont share a common interface you could end up with a spaghetti of event.

    if there is a vote for much needed feature in flow charts... I vote for that one!