DiegoM's Forum Posts

  • The next releases will not be showing layers with a -1 index. Even though it is more accurate at showing what is happening, it runs into the possibility of showing the same layer multiple times in different places of the tree when combined with global layers, something which the Layers Bar was never meant to do and is actively design against.

    So we will be rolling back on that.

  • I thought about looking into this, and it looks like loading a website from a zip file into an iframe is way more complex than I thought XD

    I mean, it's possible but it's a bit ridiculous. The main issue is that since the files are not served from anywhere, you need to create in memory URLs to all of them and then update all the places that use URLs in your index.html with your in memory ones, so the iframe can find them.

    It seems like it might work for simple use cases, but a C3 export is not a simple use case and I wouldn't be surprised if the approach runs into problems.

  • Have you checked "auto keyframes" are turned on? It's the "A" icon in the toolbar.

  • This should work in theory, but it will clash with a basic restriction of the Files folder, no duplicate file names.

    Importing the files of the first export will be fine, after that if you try to import a new file that has the same name as an existing one, the old file will be updated.

    Even if a new unique name was assigned to each file so everything was imported as expected, the name changes would probably break the exports.

    A possible solution I am thinking about would be compressing each export in it's own zip file, then importing each zip file with a unique name. Doing that you should be able to keep each export intact because C3 doesn't actually get to see the compressed files.

    Then you would need some scripting to decompress a zip at runtime and show the contents in the iframe. Assuming you also import zip.js to handle decompressing the zip files at runtime, it shouldn't be too difficult... depending of course on how comfortable you feel about scripting. What I just described will be pretty difficult if you are not comfortable scripting.

  • Global layers wouldn't work for this because in the editor they are effectively the same as the source, making any changes to them is actually changing the source, which propagates the change to all other global layers with the same name. That would be the same for the sub layers, assuming you could edit them directly, I decided not to allow that because of a potential plethora of problems. If you open the layout where the source global layer exists you can edit the sub layers and the changes are propagated to all other relevant layouts.

    What you are describing is different though, we would need some kind of new system to define a template of layers, which when used in a layout, all the layers in the template would be created, essentially acting as a shortcut to creating all those layers manually. Then editing the template would somehow update all the "real" corresponding layers in each layout, that would include adding, removing, renaming and sorting layers.

    Sounds like a massive feature :)

    Edit: Maybe not massive, but larger than it seems for sure.

  • It's to avoid unexpected problems.

    The layers bar was originally made to work with the layers of the current layout. Showing layers from other layouts and also being able to edit them normally will most certainly run into all kinds of subtle problems. Showing them and not allowing to edit them is a middle ground, so you can at least see if there are layers from another layout being shown in the current one.

    Global layer items have a context menu option to open the layout of the original global layer, so if you want to edit those layers, you can quickly find the layout they belong to.

    As for deleting the layers with a -1 index, I think that should be ok as in most cases once you make a layer global, you don't care too much about what it was showing previously.

  • The editor now shows you the sub layers of the original global layer. Those sub layers are grayed out because they don't belong to the current layout, so allowing them to be interacted with would likely have a lot of unexpected behaviors.

    The editor now also shows you any sub layers a layer might have, but are not being shown because the parent is a global layer and instead it is showing the global sub layers of the parent. Those are shown with the crossed out eye icon to indicate they are not visible. They are also given the -1 index to reflect how they would react at runtime if their index was to be queried using the LayerIndex expression.

    All of that was added because of this github.com/Scirra/Construct-bugs/issues/8532

    The main problem in that report was the editor was showing different layer indexes to the runtime when working with global sub layers.

    I guess this can be confusing if the layers that take the -1 index also have the same name as the original global layer's sub layers.

  • To answer the main question, no, the feature is not abandoned.

    We are always working on something to improve Construct, and we can't work on multiple things at the same time. Usually what happens is that periodically some part of Construct will be worked on and a few things will be fixed and/or added all in one go.

  • Are you using the latest stable release?

    Something like you are describing was fixed in a recent beta release. The problem was related to making image point changes immediately after loading a new image, that's why it seemed like it happened at random.

    You can give the beta release a spin and see if you still encounter the same problem doing what you do normally.

    If you don't usually use beta releases make sure to have backups of your project, just to be sure!

  • There is no built in way to do this, there isn't any browser API either, so anything you do will likely be imperfect.

    If I were to cobble something together I would probably look into a combo between the on movement trigger and a timer.

    Whenever the trigger takes place start a timer, if the trigger happens again before the timer completes, reset the timer and assume the mouse is moving. If the timer manages to complete before on movement is triggered again, the you can assume the mouse is not moving.

    You would need to try out different lengths of time to see what works for you.

  • Rnamon

    I am not 100% sure on this, but I don't think C3 functions support the kind of meta programming your are describing.

    My suggestion would be to have functions that ADD and SUBSTRACT (possibly more operations) that receive two parameters, the attribute of your character they are modifying and the value.

    You would then make as many function calls as you have hats. Each hat would also need to have an instance variable indicating what attribute they modify and another saying by how much.

    The body of each function can then modify the corresponding attribute of your character and use the value accordingly.

    This would make it easy to later add more functions and different hats with different properties.

  • supergameweb.com

    If you take the event you showed before, and replace rgba with rgba255 it should work. Just tried it out myself.

  • Oh right! I also went to the docs to check, but I misread :P

    But I still don't understand the purpose of rgba() and rgbEx() with the values from 0-100. Not a single program I've ever used in my entire life did use 0-100 for setting RGB-colors. Except Construct. I guess it's easier to set something to 30% red, but that's such a specific thing I don't think I've ever needed that. Anyway, I'm glad there's still the variants that just take 0-255 values.

    I wasn't going to go into detail, because it seemed a bit off topic, but since you are mentioning it...

    The 0-255 range is a relic of the past which just refuses to die and it looks like it won't be dyeing any time soon.

    The 0% to 100% range makes a lot more sense conceptually, 0% is no color and 100% is all the color, every position in the middle is valid. This allows the notation to represent essentially an infinite amount of colors, where with 0 to 255 you have a workable, but in comparison very limited amount of values, because there are no fractional values.

    Using a single byte to represent a color channel was introduced at a time where using a 64 bit floating point value to do the same was impossible.

    I guess the main reason it is still used, is for backwards compatibility. There are some really old file formats floating around and they are still supported, so that means that new programs still need to understand that color information can be stored in individual bytes.

    You can also never underestimate the power of familiarity, there are a lot of people that will just not question that 255 is the maximum value a color channel can have. And so the range continues to be used. I am pretty sure that all popular image editing software uses the 0% - 100% range under the hood, but presents the legacy format in the UI.

    In Construct there really is no reason to support the 0 - 255 range, other than backwards compatibility and user familiarity with the format. It literally offers no benefits.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I see, I misunderstood what you were trying to do.

    To use the RGB values as they appear in the animations editor you should use the rgbEx255 expression or the rgba255 expression, these accept values in the 0-255 range.

    rgba and rgbEx accept values in the 0-1 range.

    If you are not interested in the alpha channel use the Ex variants, those only accept red, green and blue values.

  • Have you checked the luminosity slider at the bottom of the main color picker?

    If it's all the way to the left no matter what color you pick it will be black.