6. Allow to drag and drop an Instance from the Instance Bar to the Layout to copy this instance

Right now we can drag and drop ObjectTypes from Project View to the Layout to create an instance of this ObjectType but we can't do the same with the Instance Bar

It would be amazing if we could just Drag and Drop instance from this new bar to the Layout to create a copy of this instance. (currently, drag and dropping instances from the Instance Bar to the Layout does nothing)

Ideally, the created instance should be exactly the same as the original instance (same common props like size, same variables values etc...). If the original instance was a Template Source or Replica, then it creates a Replica of this Template.

Exactly as it works when copy pasting an instance in the Layout.

It would allow cool workflows such as easily set-up "Templates Palette" in a top folder of the Instance Bar to then easily build levels of Replicas by just drag and dropping stuff (especially with the "Show Template infos" option enabled)

(the user could put "Template Palette" instances on a "Template Palette" Global Layer)

5. Allow unfolding searched Hierarchies and Folders

This would be amazing both for Project Bar and Instance Bar, it's something i always wished we could do in Project View.

This way by default, only explicitely searched Folders/Instances are displayed (folded), but then we can just unfold those Folders and Hierarchies to find their children (even if those are not explicitely searched)

See example below, where i want to find a "Player" instance by typing "Chara" as its part of a "Chara" folder.

First of all, I'd like to say a big thank you for this amazing feature, it's the feature I've been waiting for the most for several years, and the implementation is perfect, it already comes with a lot of very handy things and the changes that have been made to my "Hierarchy Bar" suggestion are even better. It's very cleverly designed.

Also special thanks for all the right click context menu options on the instances in this new Bar (flash selection, scroll, hierarchy/template/layer etc..) this is just awesome.

Here are the first feedbacks i'd like to provide after trying the Instance Bar:

1. Show/Hide UID Option

Add an option to show/hide the UID number of the instances, as we can name instances using tags anyway but also because it could help to lessen the number of infos so it's less overwhelming in some situations(this option could be available in right click context menus)

2. Put extra info on a seperate, right-aligned column

So it's more readable, we should be able to drag the separator horizontally because the space required for the extra info could vary a lot between "Template/Replica infos" and "Layout/Layer" info for example, and we should be able to make sure the whole Template/Replica infos fits in 1 line (in case the name of the instance itself is very long for example)

Also maybe the separator column would allow to remove the parenthesis ?

3. Selecting an instance Folder should select all its instances in the Layout View

(or at least, there should be a right click context Menu > "select all child instances" option for the instance folders)

4. Option to automatically select the layer of the selected instance (while displaying Layers/Layout)

This is an adaptation of a suggestion i made for the Layer Bar but for the Instance Bar instead, as it might be better.

If the Instance Bar is currently showing more info for Layers/Layouts, add a check option just above to automatically select the layer of the instance. It would be very handy as way to select layer in workflows were a lot of instances are placed in the Layout. (avoid placing new instances on wrong "HUD", "FX", "Background" layers)

Also now we have a lot of handy bar but not many places in the editor to dock them, it would allow to stack the Instance Bar and the Layer Bar together, and switch between the 2 only when needed. (as Instance Bar would allow to select Layer too)

(it would only do something if the last selected instance was selected individually or if all instances selected together are on the same layer, if several instances were selected exactly at the same time on different layer, it wouldn't switch the Layer)

That being said, having that option directly on the Layer View too could be great, maybe the best would be to have that option accessible both from Layer View and for Instance Bar in "show infos for Layers/Layouts" mode (disabling it in one place would disable it in the other place)

What about the 'Reload all from folder' option for folder projects? You can have an external tool that changes files in the project folder, and then use that option to update the files in Construct.

A "Reload all from folder" button would be great, would it work for everything ? (Layout/Eventsheets/Families/ObjectTypes etc.)

It would be nice if there was a shortcut for this.

Now maybe I'm missing something and I'm talking nonsense, but doesn't construct have almost 2 million paying users?

We don't know how many gamedev subs they have exactly but based on several infos we can estimate : in 2022, Scirra revenues were 100k/month (probably bigger now), approx 50% of their revenue are indiedevs/hobbyists and 50% is from education/school, the sub price varies a lot between regions. US/EU is 100-200 dollars per year but some other countries pay much lower price

I would very roughly estimate the number of individual/gamedevs subscribers to be approx 10k (not counting Education licence : there are probably even more children/students using C3 than hobbyist/indie but the licence is very different - it's one big entity paying for many students)

if we consider 1.2M revenu per year, 50% rev from gamedevs subscribers and approx 70$ paid per year for each gamedev subscriber, it gives 8571 gamedevs subs. But it's hard to estimate how much is paying a sub on average, if most users are from EU/US then there is less subsribers like 5K, if more users are from other countries then it's more subscribers like 20K.

I would say none of this above is our business but they definitely COULD hire 3 additional devs, but Scirra probably think it wouldn't be worthwhile for them. It would lower the profit of the founders or make their position more risky because they could not afford losing a big Education client or losing 30% of their userbase for Godot etc.

Hiring at least 1 additional dev is long overdue though, based on subscription price increases or Construct Animate which was supposed to help Scirra to hire additional workforce so it benefits gamedev users in the end even if it's targeting a different audience etc.

(Edit : to answer UltraLion below ↓, I don't think the numbers of the frontpage are meaningful, any account created automatically follows Ashley, so it looks like there is approx 1.2M accounts ever created for Construct, but most of them never paid a sub, also 60K exported games per month doesn't mean 60K different games are released but just the button "Export" is pressed 60K times per month, an export can just be a test to check if it works, a student exporting their homework, an alpha, a bugfix release etc. Those are mostly marketing tricks)

They do have limited resources (only 2 devs working on the engine) which is why I don't think it's a good idea if we depend on them for every single thing and if they limit the expandability of the engine and what 3rd party devs can achieve. Because we know a lot of popular feature request are sleeping for 5+ years, while some of them are created pretty easily by addondev thanks to SDK1. Even if Scirra had 20 fulltime devs, it wouldn't be a great idea to limit the expandability, the industry standard is to give users the power to do what they want, not to lock/hide/break everything on purpose

"industry standard", "encapsulation", "desperate customers with ruined projects come and beg us for help"

Each of those points were already heavily nuanced by everyone and for multiple reasons. So anyone can just read this thread and the previous one from 2 month ago to understand why it doesn't justify what is happening here

But i just want to insist on this "desperate customers with ruined projects come and beg us for help", "happening often, happening right now"

We all know how you're handling users facing bugs/black screens : copy pasting this same message :

If you run in to a problem please file an issue following all the guidelines.

If at least one of those extensive guidelines isn't respected, you just immediately close the issue without even invastigating. Which is fine, we understand you can't afford spending several hours each time someone think the bug is due to C3 codebase when it's just the user who did the mistake themself in their eventsheet (Even if sometimes actual bugs following all guidelines are closed for arbitrary reasons)

But here is what has always been written in those guidelines :

You never provided any support to anyone facing an issue with an addon : even if that addon use only documented feature. You always put the responsability on the addon dev (and you're probably right to do that) and that's all.

So it doesn't seem worth it to destroy all the collective work and all projects relying on it, and make it impossible to expand the engine in relevant ways, for an issue you never ever took responsibility for to begin with. And your policy regarding this would be exactly the same after SDK2.

Besides that, a lot of the most active addon devs like Skymen, piranha305, Mikal, Federico, MasterPose, Wackytoaster, Chadori, ppstudiomty or me replied in those 2 threads about SDK2. And it looks like none of us is aware of those users "with ruined projects" you keep mentionning again and again. (Also many of those addondev provide extremely qualitive support for their tools, they even fix broken addons made by dev that left the community, or provide their work under open source licence to let anyone fix it). The only reason some addons started breaking during the past few weeks is because you started your work to lock everything with SDK2. So all the arguments provided are looking very sus.

Over the past 2-3 years they already :

- spent 1+ year working on working on a new seperate product targeting a different audience : Construct Animate (back then Scirra said it would allow to expand their team so it would benefit us, which has yet to be seen...)

- increased the subscription price for gamedev users even if less time was allocated to gamedev features as lot of time was allocated to Construct Animate instead

- spent several months to work on a RTS game instead of improving the engine (EDIT: to answer Dop2000, you're right it was a personal project but it wasn't presented that way and it was Scirra allocating their "limited resources" on this instead of other stuff)

- Then spent many months developing a opinionated Flowchart feature

Sure those projects maybe allowed to add a few handy features useful for specific gamedev needs but who asked for it ? i'm pretty sure it would have been 100x better for anyone if they focused on community requests, you know the actual subscribers needs.

Now we're here funding a massive regression in the expandability of the engine and the destruction of 6 years of collective work (actually 13+ years as there is also a bunch of working addons that were ported from C2 and that will also be impossible to port in SDK2). We know we'll have to stick to a frozen version forever to expand the engine meaningfully and still need to pay a yearly subscription just to open old projects on obsolete versions until they no longer work at all in a few years. Feels great paying a subscription. 👌

I mean if you don't have time or don't care about community requests and feedbacks, then at least just let 3rd party devs do their stuff 🤷‍♀️

official UI plugins

This is a perfect example of the whole issue with Construct and community feedback. Everybody has been asking for in-editor UI features (like Unity or Godot) for years, and instead, they chose to spend about a year implementing a solution that requires CSS/HTML. This solution involves tedious workarounds and shenanigans, doesn’t allow any preview of what it would look like at edit-time, and has very limited synergies with other C3 features. HTML/CSS support is a cool feature, but who asked for it? Is C3 really a beginner-friendly engine if it requires using Eventsheets, JS, HTML, and CSS with an unintuitive workflow to make a simple game?

Addon devs have been asking for years to expose existing hidden methods, that would allow to easily create 3rd party UI Solutions, in the Editor SDK (which is fully locked/obfuscated, making it totally impossible to create relevant stuff with it : exactly as the Runtime SDK is about to become with SDK2), and the answer is just "we prefer users to use HTML/CSS to create UI". So not only they don't want to create UI system themself, which could be understandable, but they also don't want to spend a few days providing the capabilities for anyone to do it themselves and share it with the community. Great example of collaborative effort with Addon devs !

It's just a massive regression in what's achievable with Construct. It looks like C3, as it exists today, is at its peak. The upcoming versions might bring some fancy vanilla features, but they won't counterbalance the huge loss of expandability, customization and power that is happening. Meanwhile, all the alternative engines will continue to get more powerful, fix their actual user issues, grow their 3rd party ecosystems and achieve more indie game hits.

Several less drastic and more efficient alternative solutions to the issue you're describing were suggested. Everyone mentioned the biggest drawbacks of this decision, which feel far more important to actual gamedev subscribers than the issue it was supposed to solve, an issue we haven't experienced over the past six years.

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.