Tokinsom's Forum Posts

  • Ashley No worries, thanks for the thorough response. I appreciate the consideration being put into this and am seeing myself why it's a bigger feature than it sounds.

    I am definitely a proponent of methods 2 or 3. I'm not exactly sure how there isn't a way to tell a rename apart from a delete-and-add - I would assume finishing either operation could or would send a particular signal to differentiate, but evidently not.

    Overall method 3 sounds just like 2 (my favorite option) but with a dedicated rename operation to solve this so... Unless I'm missing something I say that's the winner!

    Even my current project has 18 "area" layouts with far more layers than I care to deal with, so this feature will help immensely. For level-based games in the future it is an absolute must! Thanks again for considering it and I look forward to seeing how it plays out.

  • Ashley I've been curious if any planning has been done for a feature / feature set to accomplish the things discussed in this thread. I know 3D is the big focus right now but this is clearly a big refactoring / productivity related one that's been wanted for a very long time, regardless of implementation. Thanks.

  • Some of the issues raised in this thread still exist, at least in the latest LTS. I have not checked the standard releases but since there was no response by Ashley or Diego I question if they were ever addressed.

    As noted, there doesn't seem to be a way to reproduce said issues directly, but they are quite common doing typical sprite import / origin & image point placement type stuff so a small time doing that is bound to bring them about.

  • Ok so batch editing then.

    If layers get a new "Batch Edit" or whatever checkbox, then all changes made to them will affect all other layers in the project with the same name? Somehow including layer order/structure with an error if it can't be done?

    Honestly I'm fine with that. Functionally it's the same thing. 👍

    Template Layer was only suggested because it "is literally copy/paste of global layers but with less features," and it is far less error-prone, but clearly we're at an impasse about that and there's more to it.

  • They are just normal layers, though. The only difference is they inherit their properties and order from a master layer elsewhere.

    These "complex scenarios" don't exist, the request is not beyond anything Construct already does.

    I almost feel like we're talking about different things here?

  • > If project-wide changes based solely on the layer name with no ability to select specific layouts was acceptable, that would be a quicker and easier update and therefore more likely and possible to come sooner

    That sounds pretty good? Would that work for you Tokinsom?

    Maybe? Hard to say without knowing the specifics. I don't see how this could address layer organization, for example. It seems like it would just apply changes to all layers of the same name, potentially all properties? That's close but not everything we need. I'm not concerned about layout exclusions though, fwiw.

    I'm still of the opinion that "template" layers as my earlier thread talked about is the best approach, and even fedca just proposed the same thing. I don't get the claims of it being overcomplicated—it's just an "extension" of global layers with slightly altered functionality (remove instances carrying over from the master layer, and allow unique instances on non-master layers). So much of it is already there, you know?

  • Right, we're not talking about shared layer contents like for UI which is what the current global layer system solves.

    Ashley Please refer to my thread The Case For a Proper Layer Template System where I elaborate on this and provide real world examples.

  • Yeah this is one of those grand architectural quandaries when it comes to Construct. Either you put up with it, jump through lots of hoops to use an external editor (thereby radically changing your entire workflow in Construct) or find a different game engine.

    I've been requesting some solution to this for years and have been met with little more than "Eh, that sounds like a lot of work." without even exploring solutions or acknowledging the critical need for such a thing.

    You can maybe tell I'm a little bitter over it by now.

  • I've been meaning to report this for ages but it hasn't been a real issue for us (yet).

    I noticed it when exporting a tilemap as a .tmx so we can utilize Tiled's auto-tiling features. As you said, no matter the current size, the internal "tile canvas" will persist as its maximum from any point in time. Occasionally we will find a single stray tile waaaaay off in the distance.

    Either scaling down a tilemap should scale the internal size respectively and delete tiles, or a new button should be added that does this.

  • There is definitely something screwy with the image editor. It often reverts certain things like image point placements when I switch frames or animations, and I want to say collision polys and image scale too, but it happens very sporadically and there is no way to reliably reproduce it that I've found, so I don't know... Was hoping someone else would find and report it.

    Not sure if this is the same deal but sounds like it may be related.

  • For what it's worth, is editor extensibility not part of what was advertised in the Construct 3 promo page before its release almost a decade ago now?

    I'm well aware things change and not all promises can be kept, but it looks to me like this is knocking at the door, and hard.

    Personally I'd rather see this sort of thing than, say, 3D features with an incredibly low ceiling. But funnily enough, many folks are wanting editor extensibility for 3D features.

    Me? I just want proper 2D lighting...

  • Yeah, Git. In the off chance your project does get corrupted, you can just revert the commit and will have a list of the exact changes to help narrow down the source of the corruption. Also, developer console (f12).

  • Sounds like the ideal solution is to treat anything that would affect the corresponding .uistate file as a project change to be saved then. As it stands there is a bit of a discrepancy between project files and .uistate files, despite both utilizing the save function to update.

    Alternatively all "editor changes" flag the corresponding .uistate files to be updated when the project closes, decoupling it from the save function entirely.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The confusion likely comes from the fact that .uistate files are only updated when the project is saved, and possibly only for layouts & event sheets that have been modified since the last save (but I'm not certain on that.)

    I made a feature request to resolve this ages ago but it didn't gain much traction.

    Ashley It maybe sounds inefficient but ensuring all .uistate files are updated upon saving and also when closing a project or Construct itself would resolve this potential issue and is in line with expected behavior I think - having to make actual changes to the relevant layouts & event sheets when doing "clean up" should not be required.

  • You can load a specific release from the releases page. If you browse to editor.construct.com it will always serve the latest stable release.

    Right but if you "Install C3 as a desktop app" as detailed in the manual, this becomes a problem because it forces the latest version. It asks me once, then ignores my answer and automatically updates upon reloading.

    Sure we could install a dedicated version URL but updating that might be a pain? I'd have to play around with it. I swore uninstalling wiped the UI, installed plugins, etc. but this latest time there was a prompt asking if I want to delete that or not.