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.

This is a perfectly valid request undeserving of the sarcasm and useless snarky responses.

"Simulate Jump" only works if the object is on the floor, and the built-in double jump feature is silly and shouldn't be used for coyote time anyway.

Instead "Simulate Jump" should just execute when it's called, allowing any amount of proper mid-air jumps and/or coyote time jumps determined by instance variables. If the player only wants "Simulate Jump" to work on the floor then they can pair it with the "Is On Floor" condition instead of it checking for them. It's not rocket science.

Also, not only does setting the y vector to a negative value not give you jump sustain, but it doesn't trigger "On Jump" either. Seems the only ways to trigger "On Jump" are by using "Simulate Jump" when on the ground, or by executing a built-in double jump...so, y'know, there's that.

As I've mentioned in the earlier posts, "Set Canvas Size" does not affect internal resolution as you are suggesting it does - it merely changes the external resolution but without changing the window size.

Please take a look at this .gif: media.giphy.com/media/A2OHsceP7gBTRADQvm/giphy.gif

Or the .c3p itself here: dropbox.com/s/mbe5ma4s677pt0c/Internal%20Resolution%20Test.c3p

This is what happens when setting the canvas size to 200%, 300%, etc.

I get the exact same results regardless of fullscreen quality mode or any other project properties / display modes.

If it is supposed to work how you are suggesting then maybe this is a bug?