Parent/Child events causing random crash (sometimes), 2.5+ : build 295.10

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
  • As the title says, in some cases, trying to reorganise some events in an existing project into this structure, occasionally causes a very nasty crash.

    The point at which this occurs is when I try to run the application or frame, and the crash doesn't simply ANR the runtime, the runtime never even starts, and the Clickteam Fusion editor itself completely shuts down without so much as a warning, and is unable to restore the project when relaunched. In fact it launches as if nothing happened.

    My project is so large, that it would be very tedious to try and isolate where exactly this happens to see if it's related to any events I have. In any case I don't think it matters, because on some blocks of code, it seems to work, but on others blocks of events, ones which seem to me to be completely unrelated to each other in the event list, it nonetheless causes this crash.

    My only real question is, is any dev or anyone at all, aware of any known specific ways of eventing parent/child events, that could cause a total crash of the entire software, at the point when you try to run the application?

    If its a case of a particular set of circumstances or event/group arrangements that could cause the crash (and I suspect it is), as my project is quite far along, I'd have make a decision of whether it's just better to avoid using them altogether.


    Thanks in advance :thumbup:

  • A lot of things can make game to crash. Infinite loops, for example.

    But, you said your project is big and Clickteam also crashes. So I suppose you are out memory. Probably you are using very big sprites with tons of animations.

    FNaF game? Try to deactivate parts of code and find that crasher condition. Or maybe uncheck "Create on start" for every object you don't need on start. Create objects only when you need them and destroy objects when you don't need them.

  • A lot of things can make game to crash. Infinite loops, for example.

    But, you said your project is big and Clickteam also crashes. So I suppose you are out memory. Probably you are using very big sprites with tons of animations.

    FNaF game? Try to deactivate parts of code and find that crasher condition. Or maybe uncheck "Create on start" for every object you don't need on start. Create objects only when you need them and destroy objects when you don't need them.

    Hello, and thanks for replying.

    The crash only happens when I try to run the application, after turning certain events that already exist in the project, into parent/child events from what they were previously. It's very specific that the crash follows doing this particular thing, and doesn't happen at all otherwise.

    Maybe a screenshot of what I'm trying to say will help...

    Please login to see this attachment.

    This is an example of what I'm trying to do. This block of code has been arranged in a parent/child structure, and crashes Fusion in the way I described when I try to run the application.

    Please login to see this attachment.

    This is the same block of code in it's original form. This does not cause a crash at all.

    In addition, there are similar structures in my project that I've tried to retroactively turn into parent/child events, in the same way that i have in the first screenshot, which does not cause a crash, and works as expected. There seems to be no obvious reasons why some parent/child events crash, and not others.

    I thought it might possibly be a memory issue, indeed, the way it crashes made me think this at first, but even though the available memory on my dev laptop is very low, there's still about 20 GBs free, which should be more than enough, & the applications RAM usage when running is relatively low (97mb, 191 objects). If anything, by using sub-events I'd be reducing the memory usage, because the whole reason for using them was to try and reduce the condition count on very computationally heavy areas of code which are frequently run. In order to turn the original events into sub-events means I have to delete conditions, like the "on loop" ones.

    Ths project doesn't use any large objects or objects with many animation frames. In fact the entire thing runs in a single frame and most active objects are either invisible value containers, or small UI buttons. It's otherwise very stable and rarely ever crashes.

    It's definitely not a FNAF game :D it's essentially a fantasy console/Chip 8 emulator, although I've added features to the chip 8 side of things that weren't in the original spec, such as programmable horizontal and vertical blanking periods, a scanline interrupt, a 16 colour mode, a tilemap with an attribute table, & up to 16 8x8 "hardware" sprites on screen at once. The code block in the screenshot actually shows a segment of how the colours are being fetched from memory ("memory" is just a big 2D array), via alterable values, for each 8 pixel row of a sprite. It uses a loop which, for a minimum of 8 sprites, runs 512 times per frame (64 times per sprite), so i had identified this area as one that could potentially benefit from being optimised with sub-events.

  • Please show event that launches loop

    This calls the outer loop...

    Please login to see this attachment.

    And the outer loop calls the inner...

    Please login to see this attachment.

    Now I think about it, the fact that it's a nested loop, being called from inside a Surface Object callback, possibly might have something to do with why Fusion isn't liking it being turned into sub-events :P

    And the entire project is littered with very precise fast loop interactions like this, which is why it would be tedious to try and isolate.

    I'm perfectly fine with not using sub-events at all, as the program works ok enough without them, but if there is a potential crash lurking inside certain specific use cases of sub-events, then it's probably a good idea to let the devs know, just in case it is a rare bug.

  • Were you able to locate the problem? If possible could you send me the MFA and explain how to reproduce the problem? Thanks!

  • Were you able to locate the problem? If possible could you send me the MFA and explain how to reproduce the problem? Thanks!

    Hello Yves

    Yes I can reproduce the problem very consistently in my MFA, I just have no idea why it happens 😕

    What happens, is I try to turn some existing events in my project, which are just normal events like the ones in the second screenshot i posted, into parent/child events (1st screenshot). Then after I've done so, I click "run application" or "run frame", and the application seems to hang momentarily, then does a hard crash of the whole app, including the editor, straight to the desktop. Usually I would get a warning about fonts used etc before the runtime launches, but this doesn't display with this crash.

    One scenario that causes a crash is when I specifically turn the exact events in the screenshots I posted earlier, into sub-events. The only reason I can think of why it crashes is maybe because it's a loop that gets called from inside another loop, which itself is called when the Surface Object callback event reaches specific points in its iteration.

    The callback itself is looping through an array holding pixel data, and rendering this to the Surface Object window every 2nd tick. When the callback hits specific rows in the window, it calls the nested fast loop, which is used to draw 8x8 pixel tiles (again using array-stored pixel data) to an Overlay Redux object, so it's pretty complex and not very easy to isolate.

    Funnily enough, if I turn the "on callback" events which draw pixels to the surface into sub-events, it seems to work fine with no crash (although I didn't notice any significant gain in performance)

    I'd be happy to send the MFA once I've tidied up the code a bit more, I don't know when I'll get around to doing it though. There are over 3000+ events & I've been quite busy with my day job recently.

    And like I said to ikko, it's not a show-stopper if I just avoid using them. My app runs absolutely fine without them otherwise.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!