piranha305's Forum Posts

  • Check out the game I created for the GMTK Game JAM 2024

    https://piranha305.itch.io/the-bacterium

    It's an RTS game where you play as the immune system, and you have to fight bacteria.

    If you created a game for the game jam, give it a rate as well https://itch.io/jam/gmtk-2024/rate/2912680

    Subscribe to Construct videos now

    if you participated in the jam, post your games and i'll play them and also rate!

    Tagged:

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

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

  • Try Construct 3

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

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