MasterPose's Forum Posts

  • I think it's reasonable to say you should have the consent of the original addon developer before publishing an update to their addon, especially if it was not originally published under an open-source license, in which case obtaining their consent is likely a legal requirement.

    Also if you really want to talk about legal stuff and are really concerned about that, you should probably update the addon exchange upload form. As presumably you can only upload MIT licensed works, in which case, there's not even a speck of the legal requirement you're talking about.

  • I don't think this is a straightforward thing to do. It violates a fundamental security property that only the addon author has permission to update their own addon.

    Ashley Yeah, I thought of that too. That's why I mentioned maybe only explicitly marked as deprecated addons by the author. I'm of course talking about the cases where the original addon developer has given authorization.

    and users only have implied trust in the original addon developer and should not be assumed to trust some other developer updating their existing addon

    I'm not talking about making an auto-update. The addon should still be treated as a different addon. But the same ID allows users to replace the unsupported addon.

    Currently the only way to do it is by modifying the .c3proj. Something I've done many times and don't have problems in modifying any of the JSONs generated by Construct directly. However, suggesting that to normal users is a whole different thing, and it's what my suggestion aims to solution.

    If you think deprecated addons should still be protected, could you at least look the suggestion of github.com/Scirra/Construct.net-website-bugs/issues/205 that has been ignored for over a year?

    Maybe being able to replace deprecated addons and SDK-v1 addons is too much of a security risk. But don't just turn away from the problem. At least let's discuss another alternatives, such as the one suggested over a year ago.

  • With the end of SDKv1 support, the great majority of the Construct 3 addon landscape was beheaded and now users don't know how to update their unsupported projects.

    Many addon devs are trying to carry this crisis by porting some of the addons from SDKv1 to SDKv2, even though they aren't the original authors of them. However, there's no current way to upload these ported addons to the exchange.

    Allow that either explicitly marked "deprecated" addons IDs can be resubmitted or from all the SDKv1-only addons.

    Suggestion ticket which hopefully won't be ignored like this one from a year ago.

  • If you have time, could you please port the EasyStarJS behavior?

    https://www.construct.net/en/make-games/addons/1140/easystar

    Thank you for doing this!

    Hey wrote you at the Discord community :)

    I'll also try to help others porting old addons to SDKv2. So let me know which ones would you like to port.

    For those addons that are impossible to port to SDKv2 following the rules, I will do so using my Jail Break plugin.

  • There's always someone out there determined to find their way around it - I'm baffled from the other topic that there's hacky shenanigans with recent SDK, whether it's safe or not (which... would be ironic if it was less safe compared to SDKV1, but I digress).

    Hey, if you talking about Jail Break it's totally safe. SDK v2 basically wrapped SDK v1, but SDK v1 is still there under the hood. Actually Scirra's first-party plugins still use SDK v1.

    The only thing Jail Break does is give you access to the same old SDK v1, so you have the same freedoms as Scirra.

    Anyways, I don't want to hijack the thread topic. I think a close collaboration from Add-ons developers with Ashley is the best to progress forward the engine, so it doesn't stagnate and grows as a more powerful tool set for serious game development.

    Many of us Add-on developers are very technical and have our own internal tools that I think the majority of the userbase could benefit from if they were included in Construct or at least if Scirra improved the APIs of the SDK to allow us share them as third-party plugins.

  • then you should expect to see an SDKv3 which does editor script sandboxing. So my advice is: do not do this or anything like this at all

    So if this is how things will be, then OK.

    I just posted a tutorial on how to use my plugin JailBreak which let's you break SDKv2's encapsulation and use SDKv1 directly in Scripting, and thus can be used to port add-ons which are impossible to port to SDKv2.

    Check the tutorial here: construct.net/en/tutorials/break-sdkv2-encapsulation-3256

    If Ashley will create wrappers of wrappers of wrappers of wrappers, the only realistic way to keep using Construct is by breaking those. And I here and now pledge to do it and share it with the community so everyone else can do it also.

    • Post link icon

    I posted a tutorial of how to port/use SDK v1 in newer versions of Construct using Jail Break.

    Check the tutorial here: construct.net/en/tutorials/break-sdkv2-encapsulation-3256

    There are some Add-ons that are impossible to port using SDKv2, and thus the only alternative is Jail Break it. I will accept requests for porting such Add-ons here and on Discord.

  • Three.JS is excellent from what I've seen/read, but at the end of the day, Scirra have figured out extremely effective and optimal design choices for 2D game design, from cheap collisions to optimised rendering, all without the user barely needing to configure anything. Maybe it's bad for me to say this as it makes third-party addon devs, or those familiar with Three.JS, have less use for their skillset or become restricted in some ways, but I stand by my point as of now.

    I think we can all agree that a Scirra developed 3D engine would be the best. However, Three.JS is being discussed as an alternative. Alternative to what? To Scirra not being capable of making a 3D Engine.

    In an ideal world, all the points you mention would be developed, but Construct 3 has been out for ~8 years. 3D features have been available for ~4 years. Those 3D features are just a cube with not even rotation.

    So Three.JS is mentioned as an alternative. If Scirra is not capable of doing a whole 3D engine (which is completely understandable!), just use an already existing 3D engine and give the Addon Developers the ability to create all the ecosystem for them.

    Three.JS is an excellent alternative, if Scirra were to abandon any 3D intentions, something that just not long ago many of us thought. However, it's refreshing to see Ashley still have intentions to continue his 3D work and being open-minded about it.

    But on the other side, if Scirra will continue its 3D work, how much more time it will take? It's definitely not their priority and even if it were, with the time it has taken to get other features you could say they're "basic" on the engine, there's no telling how many years we have in front of us to have something most users will be happy with.

  • I found this real-time 3D editor that was in the works below on the 'open collective' link here ---> https://opencollective.com/construct-community/projects/3d-editor

    You can also vote for it to get funding from the collective, by joining the Construct Community Discord and then logging in to construct-community-voting.dedragames.com

  • RPGs are a very data-centric type of game. Depending on your experience, you may find it way better to move any abstract systems to scripting. But it's 100% possible (but managing data with EventSheets alone may become a pain).

  • With this plugin you can load scripts directly to the DOM Side and communicate with the Web Worker using a simple API of events and procedure calls (IPC).

    Addon Page: construct.net/en/make-games/addons/1531/dom-side

    Itch: masterpose.itch.io/primitives-c3

    The first thing you should do is to create a new JavaScript file inside your files folder (no scripts). Then load it with a simple action.

    Inside your loaded script, you have full DOM APIs.

    The script doesn’t have context of your game though, so if you want to communicate between the Web Worker (where the runtime of your game is running) and the DOM Side (where you have full DOM APIs and can modify the HTML), you must use the global object DomSideHandler.

    DomSideHandler is a global object that exists on both sides. With it you can listen for events or send events to the other side. You can register procedures so the other side can call them or call procedures of the other side.

    You can listen to events like:

    And on the other side, you can dispatch them like:

    You can also do everything in EventSheets of course:

    Events can be listened with on or onOnce, then dispatched with send. But what if we want to execute an action that returns us a value? For that we must register procedures.

    You can register a procedure like:

    Or you can do it via EventSheets:

    Then you can call those procedures from the other side like:

    So we can register procedures with handle and call them with invoke. Just be sure that your procedures have distinct names, you can only have one procedure per name, meaning that if you register two On Handle triggers in the EventSheets with the same name, only one will run. If you need to execute multiple stuff use events.

    That’s pretty much it, the plugin is simple but powerful. With it you have a way to load scripts to a limitless context and you have a simple API to communicate with your game.

    Enjoy!

  • Hey guys, yesterday I updated my theme: Himmlisch. What is Himmlisch you ask? Himmlisch Theme is a dark, compact theme for professionals that makes working with Construct faster.

    All screens are optimized for space and you have better readability with the accented colors. And Himmlisch does it all at the same time it looks elegant as any professional software should look.

    And Himmlisch does it all at the same time it gives you multiple different color variants! Choose your favorite!

    Try it completely free via Itch:

    masterpose.itch.io/himmlisch-theme-c3

    Or purchase it at the Construct Store:

    construct.net/en/game-assets/themes/himmlisch-theme-elegant-slick-4790

    Tagged:

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Oh ok,

    But do they get more expensive?

    Or is this the same price from like a couple of years ago?

    Radkampfwagen

    Over the years Construct 3 plans prices have been adjusted, but the price you pay is locked to the one you original subscribed unless you stop paying and your subscription expires

  • Hey guys! I noticed I don't share any cool news here on the forums. Let's change that!

    I just published a free and open-source plugin for SAM: the original Text-To-Speech from the Commodore C64, published in 1982!

    Check it out on Itch:

    👉 masterpose.itch.io/sam-c3

    The style of the TTS fits very well for retro or horror games.

    Subscribe to Construct videos now

    Easy to use ACEs

    • Post link icon

    I've also seen cases where people claim they need to hack the internal engine to do something, but there was a straightforward and perfectly good alternative.

    And there's also cases where people claim they need to hack the internal engine to do something, because they need it. Dismissing that the public API is limited is dishonest, as well as claiming that there's "straightforward" perfectly "good alternatives" for everything. For what I've seen, most of your alternatives are "don't do it".

    I don't have time to make a proper long response as you like to debate, but the problem really is: you.

    There wouldn't be a problem of the API being limited if the process of suggesting and actually adding features wouldn't be so long and stressing due to your constant arguing with the suggestions, specially when it sometimes feels you aren't arguing against the actual idea but against the dev who proposed it. Even here in your recent responses, you blame the add-on devs for everything, you always seem to have a bad attitude against them and a contrarian attitude when dealing with suggestions from them. Even with perfectly explained suggestions, that took a lot to elaborate to their authors such as the ones of Overboy, you dismiss so easily and in a very blockheaded way.

    I really hope you're working on that, because the addon devs, me being one of them, don't really want bad blood with Scirra. We only look to extend the power of Construct, I can only hope you have the same goal.