Tokinsom's Forum Posts

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

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

  • 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

  • Note that in general if you have a feature request you can submit it here.

    I suggested this like 4 years ago and it got tons of upvotes 🥴

    Ain't happening.

  • That sounds about right. There are still far too many things tied to the .c3proj to safely have more than 1 contributor add content to a project at a given time.

    The other killer is modifying objects that exist throughout the project. For example, if Contributor A adds a variable to an object which exists in all layouts, then all of those layout files get updated. This means no other contributor can edit any one of those layouts without resulting in a conflict.

    At least, that's how I remember it happening. Only solution there is Contributor A has to inform others about it so they can push & pull the new object variable before resuming work.

  • Yeah this is an extremely long-standing issue with new pages in chrome defaulting to white. I've actually developed muscle memory to close my eyes when opening chrome/C3 for the first time lol. Apparently it's much more difficult to fix than one would think. I thought it only happened when entering a new domain, however...

    Searching something along the lines of "white flash when opening chrome" will give you a lot of results, but no permanent fixes it seems.

  • The new random UID option is a life saver. Thanks Ashley.

    It should only be a conflict if two people both try to commit changes at the same time that both affect the same line (e.g. both adding an object to the same folder).

    Ah you know what in all my testing I was just adding objects to the root objects folder, so that would explain that. Wouldn't introducing new effects/behaviors to the project go on the same line though? I will do some more testing...

  • 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 controller is only meant to be used in wired or 2.4ghz mode for PC, and bluetooth mode for Nintendo Switch. It *can* work on PC over bluetooth with the right drivers/software (Steam is providing them while it's running) but it isn't exactly meant to. In other words, it's an issue with the controller and some weird decisions on 8bitdo's part.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    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.

  • Color values in Construct are a bit odd. You might have to store just the values as a string and then use rgbEx255(dictionary.get("values")) instead.