piranha305's Recent Forum Activity

    • Post link icon

    TBH I don't think construct has to change how its handled internally, I think this can be solved with a good example project of a volume slider, demonstrating how to do the conversion?

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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

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

    • Post link icon

    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.

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

piranha305's avatar

piranha305

Early Adopter

Member since 26 Apr, 2016

Twitter
piranha305 has 34 followers

Connect with piranha305

Trophy Case

  • 9-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • x8
    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
  • x7
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x3
    Lightning Draw First person to up-vote a new Construct 3 release
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

19/44
How to earn trophies