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.

Guys at one point we just have to give Scirra the benefit of the doubt.

I agree with this, I think the only beneficial thing for the time being.

However, many are skeptics since:

- SDKv1 was featureless even after years.

- Even the Script Interface has the same problems.

- Scirra always excuses themselves with being small, so they can't add many features.

But let's leave the trust issues aside just for this once. Let's see how this plays out. The next beta releases should give us a good vision of what Scirra really will do.

Hey Ashley, just a reminder that the problem is not that you will break ALL existing projects with third-party addons. The problem is that nothing shows that you will give the community the tools to fix them back. The past says you won't do it, but I'll try to be optimistic and cope that you'll finally make an industry standard API.

And with "Industry standard" I don't mean encapsulation btw, I mean F-E-A-T-U-R-E-S.

But nonetheless, if you insist of leaving addons to die without reason, I'm sure the community will just find a way to break through your encapsulation, I'm sure I will.

Ashley

However, please, please don't try to bypass the encapsulation, or start copy-pasting chunks of the engine. Please, please, please please please please don't do that.

So you're well aware the encapsulation does nothing? It doesn't achieve what Scirra wants, and the process of creating plugins hasn't changed, so it doesn't achieve what developers want. So why bother continuing with this lose-lose scenario?

"Because unless we remove it, people will just carry on using it, and the disasters will still happen."

Little Timmy shouldn't be using third-party plugins in the first place. If Little Timmy breaks a project because of a third-party plugin, it is not Scirra responsibility to fix it; that's the meaning of third-party. Something that I can't get my head around is that you're more-or-less known for being easily dismissive, but why can't you be dismissive for Little Timmy? Why do dismissals only occur with power users?

I've been using Construct since I was a child, 10 years ago, and I've almost never used third-party plugins. Once I discovered them, I never had any problems, and even if I did, I would have never desired for those addons to stop existing. No addon-dev wants that; no normal user wants that; it seems Scirra is the only one with those intentions.

"Addon developers largely ignored that warning, and hence the difficult situation we're in."

The situation would have never happened if Scirra had listened and created a proper API. Now after years of not doing a good job on the SDK, you are throwing it away, starting with an even more limited API and telling us that *now* you'll do a good job? What is the guarantee that you'll take into consideration developer wishes?? Because you're clearly not doing it in this and previous threads.

Great developers here have given you alternatives, please, please, please consider them:

- Make the warning message appear for SDK v1 plugins, but don't drop support.

- Prevent SDK v1 from being used in educational license.

- Make plugins be constrained to specific Construct versions.

- And one of my own, disable SDK v1 compatibility by default but have a way to enable it similarly to developer mode, so little Timmy can't easily access to those addons and break their project.

Ashley you're always talking about how Scirra is such a small team with limited resources to invest in new features, this is a reason for addons to exist: to EXTEND the functionality you can't get with the first party plugins and event sheets. What's the point of addons that literally do the same as event sheets?

It's hypocritical to say you have limited resources and then invest them to LIMIT further the possible features the engine can have instead of ADDING new features.

Also, if you're trying to compare Construct to other engines you're in a losing battle from the start. Other Engines not only are source-available but you EXTEND the literal classes, you have access to the physics engine, you have access to the drawing engine, you have a proper editor API to extend it. Construct lacks all of this.

If you're 100% certain about going further with this move, that is awful in many ways, at least make it somewhat worth it:

- Give access to the Phsyics engine.

- Make the process of developing Addons less of a hassle, because contrary to what you've said NOTHING HAS CHANGED, you only removed features but the process is the same, take a look of what the community has achieved with C3IDE2.

- Give access to a proper Editor API.

If you don't want/can't do all of this, let the community do it with Addons.

We will not drink the Kool-Aid. You're removing features by saying you added some, you're not Apple,you need to remember yourself that, yeah, you're just a small company... and we're the clients.

Version 2, on sale!

You can get this plugin on discount over Itch.io

A more robust camera rig

Now you're able to enjoy a more featured plugin, with more control using tags, free camera mode and a "zone"/"focus" mode.

New Features

Tags

Now you can assign tags to coordinates to later reference.

Free Camera Mode

Although the main use of the plugin is to *Snap*, now you can choose to opt-out whenever you want.

Move Along Objects

Now you can set an object from where the camera will start moving with in its area.

This is my solution to be able to make more Metroid/Castlevania types games, with different room sizes.

Fullscreen Modes Support

If you're working with a game with different screen size support, you're probably using Screen Inner or Screen Outer on your game.

Previously, you would encounter the screen transitions just moving the original viewport instead of the whole screen.

Now, you can set with Grid Scale Mode to either keep the original grid size, or scale it with the screen.

However, this will inevitably make the coordinate triggers unpredictable.

Thanks for reading, don't forget to get the behavior on discount!

- Master Pose

How to make a Zelda-like game camera?

Have you ever struggled on making a smooth camera system for your retro game? Focus on what really matters and leave the boring stuff to this out of the box solution!

Simple in design with powerful utilities that will allow you to create your own metroidvania/zelda-like game with no difficulty!

Example:

https://www.construct.net/en/free-online-games/zelda-like-game-camera-37117/play

Purchase it over:

Itch.io

https://masterpose.itch.io/snap-to-c3

Hello I made a simple example for you, just click on something to water it

drive.google.com/open