We still need a way to set an object's default instance (not template & replica)

0 favourites
  • 15 posts
From the Asset Store
Hand-painted tiles, objects, animated objects, and background to build a colorful Mayan civilization environment.
  • 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

  • As someone who works with tilesets a lot, this would be a godsend.

    I never understood why each new tilesets object copied the first one I designed. I'm making a new tileset object because I want the tiles in the set, not the way I laid them out the first time.

    +100!

  • The Instances bar largely solves this.

    You can copy and paste an instance from it, or drag it into the layout to create a copy of it.

    Create sub folders to group the ones you know will be used frequently, that way you don't need to actually look for them in the layout.

  • Oh ok, thanks for the tip DiegoM - I haven't adopted the new instance bar yet.

    So to get a blank tileset each time, you'd make a tileset object, put it on an 'object storage layout' with no tiles drawn, then pull that object from the instance bar instead of the project bar?

    (which feels like a lot of unnecesary work if so, compared to just pulling it from the project bar!)

  • The Instances bar largely solves this.

    You can copy and paste an instance from it, or drag it into the layout to create a copy of it.

    Create sub folders to group the ones you know will be used frequently, that way you don't need to actually look for them in the layout.

    Respectfully, that is not an adequate solution. That's basically just copy/pasting a particular instance from one layout to another which is hardly a reasonable workflow, and completely ignores my already-well-organized object folder structure in the project bar.

    The project bar has an objects folder for a reason. I expect to be able to pull object instances from it with consistent results, and determine the default properties of said instances at will. This is the case with basically every game engine except Construct.

    The way Construct handles this is bizarre, unintuitive, and problematic especially when collaborating with a team over GitHub. I should not have to explain all of these oddities to them—they should be able to simply locate an object in the project bar, and pull an instance from it with initial properties that I chose by way of a default instance - NOT from the first instance ever created (or the second if it got deleted and so on.)

    I really hope I am getting my point across here. This editor design quirk has plagued me and my team for ages, and others too but we have "just put up with it" for so long. It can be very easily fixed with a simple button as described in the original post. Please give it your consideration.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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.

    Oh wow, coincidentally I had written something like this on a bug report earlier today! Definitely seems like a good way to solve it without affecting existing projects and finally putting an end to this whole "default properties" thing.

    github.com/Scirra/Construct-bugs/issues/8352

  • 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.

    This seems like a great feature for templates regardless and definitely gets my vote!

    But I imagine this isn't the solution for getting blank tilesets from the project bar? Is it possible to make them empty by default?

  • > 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!)

  • > 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.

    To be honest, I think that if you were to do something like this, you might as well make it so you can save any template in a "template" folder in the project bar so it would almost work like prefabs and you can drag and drop them in any layout.

    I don't see why this feature should be limited to just one "default" template per instance or even why there should be a way to decide what the default template name is.

    Also, I feel like it really wouldn't solve the issue being discussed here; the main problem is when dragging an instance from the project bar in a large project. Having to retrofit "default" templates for every instance sounds like a lot of work for very little benefit, especially when this could be solved with a simple right click menu option. Right Click > Make Default Instance.

  • I think it's important to use the templates feature for this. It's what it's for: by defining a template, you are defining a named instance which you can make copies of. It's also what's used at runtime for creating instances based on copying another instance. If we define some other system for the editor, then the editor and runtime have different systems to define default instances. This then causes other inconsistencies, and people will ask things like "how do I create an instance at runtime that matches the editor's default instance?" to which the answer will still be "use templates"; others would rightly complain that the design of Construct is inconsistent. So I think this feature has to be based on templates.

    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.

    What if there's another checkbox to control whether new instances are replicas or not? It looks like the default at the moment is to make replicas. If you disable that then you just get a non-replica copy of the template set to be used for new instances in the editor.

    We could still then add a 'Make default instance' context menu option, which would just be a shortcut to:

    • Set the instance as a template with a default name (e.g. "default", but that string can be made translatable as the specific string doesn't matter)
    • Set the object type to use that template name for new instances

    ...but it's not clear what that should do if the template named "default" already exists, nor whether you want the 'new instances are replicas' setting to be enabled or disabled. I'm also a bit concerned about long-term cluttering the Layout View context menu too much, as it's already pretty long. Perhaps it's not too bad to leave that as something that you manually set up?

  • 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?

  • 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.

  • 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.

  • I am not sure that listing ALL of the templates is a good idea. I would rather have it be opt in so it doesn't clutter the project bar.

    Also, wether to just copy a template or make it a replica I would assume would be off by default if pulling the default instance, and on by default if pulling from template list.

    I think having the templates be children of the object type in the bar instead of having it in its own list could be an interesting idea, but I'm not sure it's a good idea for all use cases. Having a separate folder is probably a better idea, especially if it's opt in.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)