alastair's Forum Posts

  • Also layers can enable "render cells", that might be useful for large layouts too.

  • corlenbelspar, I get this error when I experience the bug where objects are created on the next layout: (though Ashley still claims it isn't a bug.)

    I can't seem to replicate it in my fresh .capx, but I'm guessing it's trying to create an object on a layer that doesn't exist or something?

  • Problem Description

    If you use the "search" ability in the event sheet and you forget to "clear search" before closing the program, the next time you open your .capx the sheet that you last did your search in will have every event expanded/open. Because there is no "collapse all events" button like there is a "collapse all groups" button, this creates massive issues for large projects because you do not always want to have all your thousands of events open as it makes your work harder to navigate.

    Attach a Capx

    https://copy.com/ctEWp4cFtVkRp84Z/searc ... download=1

    Steps to Reproduce Bug

    • Open the provided .capx
    • Open the event sheet
    • Notice that every event and subevent is closed. There should only be 2 events visible in the sheet
    • Do a search in the event sheet for "text"
    • For event 67, which has the condition for "text", give it any action (such as "set visible")
    • Save the current project
    • Close the Construct 2 program
    • Open the .capx you just saved
    • Open the event sheet, and notice that all 124 events are open and visible on screen
    • Optional step to experience the pain of the bug: Close every subevent and parent event individually until all of them are closed and only 2 events are visible

    Observed Result

    Every single event is open and visible.

    Expected Result

    Every event should be closed.

    Feature request if unresovable

    Allow us to "collapse all events" in the event sheet right click menu (just as there is a "collapse all groups"), this would be highly helpful as it's more beneficial for our time and workflow to have every event collapsed and to only open events where we desire. More details are here: request-collapse-all-events_t111954

    Of course in a perfect world users would always "clear search" before saving, but sometimes there is the odd occasion where we forget!

  • New build!

    Node Webkit v0.11.5 (based on Chromium 38)

    https://www.scirra.com/node-webkit

  • Thanks for the reply!

    Ashley I still don't understand why the engine still allows those triggers to be run when they should be stopped though?

    I didn't even know what was happening when I experienced this bug, since it's been in every game I've made so far I'd always just expected that you should never change layout if possible because weird stuff happens, thankfully I realized the exact details and I hope other users will be able to stumble upon one of these posts in the future so they don't have to suffer too.

  • Just some interface things that I can think of:

    • New elegant interface. Cleaner, simpler, less noise. Which is basically the direction website/UI/OS design is going anyway. (Shouldn't need to have random little buttons tucked in every corner of the screen.)
    • Entire dark interface option, not just parts of the event sheets. See applications like Photoshop for how it can look good dark.
    • Better event reorganization (see here: )
    • Better event insertion. Adding new events in C2 doesn't feel natural at all: you usually end up right clicking on an event then choosing to insert above or below it, why not right click and insert an event directly where my mouse is?
    • More people involved on the project would be nice if it makes development more efficient!

    Ya like Silverforce said, I've done everything as instructed, it just happens to the occasional user for some reason.

    Yes it works for most people, I dont know why that user is having an issue.

    I have a user tell me this issue, does anyone know what's wrong?

    [quote:32v7fjns]Uncaught node.js

    Error: Access is denied.

    C: \ Users \ LG-PC \ AppData \ Local \ Temp \ nw8468_6777 \ greenworks-win32.node

    at Error (native)

    at Module.load (module.js: 354: 32)

    at Function.Module._load (module.js: 310: 12)

    at Module.require (module.js: 362: 17)

    at require (module.js: 378: 17)

    . at Object <anonymous> (C: \ Users \ LG-PC \ AppData \ Local \ Temp \ nw8468_6777 \ greenworks.js: 13: 18)

    at Module._compile (module.js: 454: 26)

    at Object.Module._extensions..js (module.js: 472: 10)

    at Module.load (module.js: 354: 32)

    at Function.Module._load (module.js: 310: 12)

  • Thanks for showing that closed report, I still desire an understanding of the logic though. To me it doesn't seem right to still create objects on the next layout, as I never told it to do that.

    To me the best way would be to finish running the event sheet (which includes finishing the trigger events, so basically stopping the sheet) THEN destroy all objects and change layout.

  • IIRC it has already been reported but was closed as wontfix

    That's a bit odd?

    Currently for me a it's a game breaking bug, on none of my event sheets have I told it to create objects on a different layout, but it's doing it anyway.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks for confirming that it's not just me!

    I think I'll just wait for the fix, bug workarounds end up making things messy in a large project.

  • I came across this issue I was having again, after noticing it over a year ago: request-destroy-all-sprites-action_t80832

    I think sprites are created (every browser/node) when changing layout. This means sprites are created on the next layout you go to. What's the logic you're using when you use the "go to layout" action? Because the way it seems to be working for me is this: When it gets the event "go to layout" all instances are destroyed, then it continues to run the rest of the sheet (or just the triggers?), if you had any "on destroyed" events or "create object" actions that were going to run that that tick then they'll be created — but on the next layout.

    This causes issues for me, you can see here that after "go to blank layout" it has some newly created sprites? The layout should be completely black, but it's not, it has objects that were created from the previous layout:

    This also seems to cause issues when I return to the layout:

    Nodewebkit:

    Chrome:

    Firefox:

    I originally thought that objects were simply lingering from layout to layout, but since realizing that they were most likely newly created I then tried disabling a group that was creating most of these objects before I used the go to layout action:

    Disabling that group, which I use to mostly create things, seems to have solved the issue of objects from one layout moving to another layout and I now get a nice black screen when going to my blank layout. It also removed the above errors from occurring.

    ____________________________________________

    Summary:

    Objects are probably destroyed by the "go to layout" action is performed but then events that use "on destroyed" are still run afterwards. This should not be the case as it means objects will be created on the next layout you go to.

    Here is a CAPX: https://copy.com/gRmijhp1JWJb7Qkz/bug_c ... download=1

    You'll notice that after 2 seconds, it will change to a black blank layout, and an object from the previous layout will be on the next layout (when it shouldn't be there).

    I'm guessing this is something like what you're currently doing for the tick?:

    • Change layout action is noticed
    • Automatically destroy every object
    • Layout is changed
    • Continue running the event sheet for that tick (which may include creating objects, that are then placed on the new layout)

  • Yeah, actually auto-saving is a good idea

  • That's an interesting question, but I don't think it would be possible.