piranha305's Forum Posts

  • Here is a suggestion I opened for this github.com/Scirra/Construct-feature-requests/issues/293

    I think right now the only work around is wrapping it in a function and using runtime.callFunction like you mentioned

  • ISpriteInstance.animationFrame = frame;

    you set the property after you set the animation.

  • Will do thanks

  • I'm currently working on a project where I am subclassing a bunch of object types and have control over when some code runs pre/post event sheet would be very nice

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ashley

    Currently in the scripting api you can listen to the tick event in IRuntime.

    Is this the same tick event that happens in the sdk when you call Tick() which happens before event sheet tick?

    Is there a plan to expose the sdk tick(pre event sheet) and tick2 (post event sheet) from the scripting api?

    Believing that community feedback could be heard by Scirra, as Unity did after the runtime fees disaster (by changing their mind), seems to have been a mistake. I’ll just try not to waste more energy on this.

    This is a real shame.

    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?

    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?

    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?