Listing all templates is also an interesting idea, but I think it's a slightly different use case. Should all those templates be in a separate section of the Project Bar? If so, there's still the problem of what happens when you drag in a new instance from the Object Types folder. Should templates appear as child items of object types in the Project Bar? If so presumably you can still drag from the object type itself, and the same problem comes up. So while I think that may well be worthwhile as well, it's probably best thought of as a separate addition.

Templates should probably have their own root folder as they could also contain hierarchies comprised of numerous objects that may already be organized in a variety of folders, or object permutations that are best organized in their own way. Also, personally, I don't want a hired level designer for example rummaging through standalone objects—they would almost exclusively use the much safer and curated templates folder for all available object permutations with brown highlights alerting me of any values they change. Of course this varies with dev teams but that's how I would do it.

I figured you'd want to leave the "non template default instance" alone in light of this solution. Yes it is a quirk, but the template folder is a way of solving it with templates as you wanted. The other template-involved method you suggested strikes me as a major case of crossing wires, especially with the likelihood of an upcoming templates folder. Perhaps I'm just not fully understanding it but it sounds confusing and doesn't actually address the issue because at the end of the day it's not actually changing the default instance, it's just creating a template called "default" and making it what is pulled from the project bar. This, again, will be extra confusing with actual templates in the project bar.

So then I would still argue that the the instance that is pulled from the property bar object type can simply be determined via a right-click menu option on the instance you want. Call it a "Root/Prime/First/Initial/Editor" instance or something instead, I don't know. Solves the issue right at the core though without bloat or new workflows or involving templates at all, and lets the user change it on the fly, to boot.

Ashley skymen

Thank you both for your insights. I'm glad we can have this discussion and I think we're on the right track.

After considerable thought, I think Skymen hit the nail on the head and everybody wins with his proposition.

None of this noise about default instances matters at all if we can just establish templates, default or otherwise, and have them all in neatly organized folders in the project bar.

-It is hands down the most intuitive, safest, and versatile option.

-It does not change or break anything for existing projects.

-It does not interfere with anyone's usual workflow, they can decide if they want to use templates from the project bar or not.

-There is no bloat or "hidden" functionality to it.

-Has the added benefit of pulling hierarchies from the project bar. Essentially prefabs as Skymen noted.

I'm fairly positive this is already a desired feature for many users, and it so happens to completely solve my longstanding "default instance" issue as well—in a very different way than I had expected—but one that is in fact actually better!

What do you think?

> B) Make it so new instances pulled from the project bar automatically become replicas of the "default" template if it exists.

This design makes it a bit of a hidden feature, and hard-codes an English string which isn't great for non-English users. What about a property to choose the default template name used for new instances? This seems like a good solution as templates are the feature intended to be used for determining initial properties.

I agree that "B" is not ideal, and would still much prefer "A". I think the feature you mention here is a welcome addition to the template/replica system, but it is not a good solution for this particular issue. Please let me explain:

My issue with your proposed solution is every single instance pulled from the project bar would then need to be manually set as a replica—an error-prone or easily forgotten step that my level designers should not be expected to do. I don't know that there is a suitable way to make that process automatic.

Furthermore, it forces object instances to become part of the template/replica system which, yes, gives a similar result, but is a completely unnecessary workaround!

Look, the "Default Instance" is already a real thing that Construct does automatically—It is not a new thing or new feature that I want. The problem is that it's ambiguous, most people aren't even aware of it, they have no control over it, and it's not explained in the manual. I am merely asking for a way to choose which instance it is.

As such, I find it hard to understand any reasonings against a very simple and intuitive "Make Default Instance" button in the editor category (or in the right-click menu), with a tooltip like "Makes this the default instance", and a manual entry describing—at long last—that the default instance is the one that all new instances get their initial properties from. I understand that there is a little bit of overlap with the template/replica system, but that is simply not what is being discussed here and it's fair to trust Construct users to discern the difference.

(For what it's worth, personally I think the template/replica system should be baked in to all objects, with the "default" template being the first instance, and the "default" replica being all instances that follow. This way we can easily determine and change the default instance, and automatically reap the benefits of the whole template/replica system. But that probably ain't happening!)

dop2000 Yes I agree the ability to copy JSON as plain text should remain. I propose this as an additional feature.

I didn't mean it was literally read-only! Just that its form in the debugger isn't exactly suitable for modification. I have edited the OP to prevent confusion.

Ashley

When you pull a new instance out of the project bar, its initial properties are determined by the first instance ever created—I will refer to this as the "default instance."

As such, most Construct users create an "Object Repository" and put the very first instance of an object in there, thus establishing the default instance for that object. Modifying this particular instance is the only way we can control the initial properties of new instances pulled from the project bar.

The problem is if this default instance gets deleted, or was never established in the first place, then the initial properties of all future instances pulled from the project bar are determined by, essentially, a random instance elsewhere in the project. This is a very undesirable outcome and Construct provides us with no way of fixing it.

Here is a great example of why this is problematic: Let's say I'm working on a level and go to pull a tilemap from the project bar, expecting a clean and blank "default" tilemap. Instead, it actually created a copy of a previous tilemap from another level! Now every time I want to use this tilemap, I have to erase all of the tiles and change its size first. Now extend this problem to literally every instanced object in the project! The only reason this happened is because a default instance was not established in the object repository...but now it's too late, the only way of fixing this is to delete every single tilemap instance and establish the default instance in the object repository, or somehow locate the first-ever instance and transfer that to the object repository.

Technically yes I could create a template called "default" but I should not have to then go through the steps of making every single new instance a replica of it. This does not fix the core issue (and there's a bug where it doesn't work on tiles anyway).

So I propose one of two solutions:

A) Give the property bar a new "Make Default Instance" button in the "Editor" category. Clicking this ensures that all new instances pulled from the project bar start with the properties of this particular instance.

B) Make it so new instances pulled from the project bar automatically become replicas of the "default" template if it exists.

I have made a suggestion for this here but this is such a frustrating and longstanding editor quirk that I am hoping to bring it directly to your attention here first.

https://github.com/Scirra/Construct-feature-requests/issues/405

Ashley

In the debugger, arrays & dictionaries get a nice little interface to view and modify values. This is incredibly useful for a variety of reasons—I need not state the obvious!

So then why does JSON—the generally superior alternative that can do both arrays and dictionaries of its own—not get any similar functionality? It is treated as a big, ugly, condensed, plain text string that is practically impossible to navigate or modify in any meaningful way.

I'm well aware that JSON is often used as static data, but it is equally useful as dynamic runtime data (and can be substantially cleaner and more organized than a mountain of separate array & dictionary objects) yet this side of it has gone completely ignored.

As such, I implore you to consider a sort of "JSON Tree View" inside the debugger with modifiable values. I have made a feature suggestion with additional reasonings and details here: https://github.com/Scirra/Construct-feature-requests/issues/356

Ashley

It seems that C3 is still mostly unusable with source control on account of the .c3proj file and UID shuffling.

The .c3proj

If more than 1 collaborator adds a new behavior, effect, object type, family, layout, event sheet, script, or timeline, it modifies the .c3proj and creates a conflict. This might be the case with removing and renaming as well. This can be resolved by hand, but is obviously very error prone and can easily corrupt the project.

As it stands, all users except one must basically only touch existing contents.

I'm not the expert here but one potential solution that comes to mind is replacing the .c3proj entries with individual files and populating the project bar etc. from those instead (basic project properties can remain as one file). Each object already has its own .json file anyway so why not just extend this format to the aforementioned assets instead of making lists inside the .c3proj?

UID Shuffling

Furthermore, UID shuffling can be detrimental and risks breaking many things in your game or outright corrupting it. UIDs are the only auto-assigned reference that instances get which are identical in both the editor and runtime. They are often used extensively to manage objects in save data or managing connections between objects in and across layouts. The only alternative is manually-assigned instance variables but...imagine a Mario level with hundreds of coins per level or a Metroidvania with hundreds of items scattered throughout the world, each one given a manually assigned variable to prevent from respawning or what have you. That is just insane, but there are C3 users who are doing just that to prevent their objects' only real IDs from being scrambled.

Again, not the expert here, but sequential UIDs might not be the safest approach. I believe skymen had proposed some sort of UUID but he would need to elaborate on that.

Taking a quote from your GitHub tutorial: "Source control is widely regarded as mandatory for any kind of professional development." I strongly agree with this sentiment but as it stands even small teams cannot use C3 together with confidence. I see that improvements have been made over C2, we aren't quite there yet. If Construct 3 is to be viewed as professional software, especially with paid tiers and increasing prices, then its compatibility with source control needs to be locked in. Thank you for reading and I hope you give these issues your consideration.