WackyToaster's Forum Posts

  • Looks quite like it's a similar (the same?) problem that it was back then. Maybe. There's lots of removeChild and appendChild listed, which seem to somehow rise in numbers when Construct is actively used.

    Compared to the same interaction (drag & drop) in a freshly opened editor.

    I saved the profiler traces if it helps but Ashley mentioned in the other thread that they are not really helpful due to obfuscation, but I can post them if needed. The delay always happens on pointer interaction, like when selecting an instance on the layout. So something is ballooning there the longer Construct is in use.

  • If you encounter this again you could start the chrome dev tools profiler, that may give a hint at some memory leak or something.

    Yeah I will do that. It's bound to happen again. I kinda forgot that this profiler exists, but I did take a video for comparison yesterday with two editors open side by side. Left one being freshly opened, right one being the sluggish one. I wouldn't say there were outright freezes, but I could imagine it getting so sluggish that it would be considered "frozen". The only freezing I had was when zooming the layouts, there it would sometimes not do the zooming despite the scrollbars indicating I was indeed zooming. Eventually it would then snap out of it and display the correct zoom again.

    Subscribe to Construct videos now

    I don't believe it has much to do with the eventsheet because I was barely doing anything in the eventsheet at that point. I also have everything well grouped though, but if there would be an inherent problem with the eventsheets or objects or layouts, restarting shouldn't fix it I think.

    I just have 288 events with 259 conditions and 607 actions. 58 Object types and 9 Families, 19 layouts and 5 eventsheets. That's like a baby-project.

  • But I don't really know why. I mainly wonder if anyone else noticed that. Here's what I do know:

    • It does take a while to be noticable, but it seems to get more sluggish the longer I'm working
    • Simply restarting the editor solves it
    • I wasn't doing much work in eventsheets, mainly saving, previewing, duplicating/adjusting a bunch of replicas across a handful of layouts
    • The project isn't exactly huge overall
    • I have a beefy pc so that shouldn't exactly be a problem
    • The lag is very noticable when: Switching tabs, selecting instances, moving instances

    Considering that simply taking 10 seconds to restart Construct fixes it I'm not even sure if it's super worth to investigate. However, I'm not 100% certain if that was a problem before todays update r421. I feel like I didn't have that issue in r420 but I cannot tell for sure.

    There also used to be a bigger thread about this 3ish years ago, possibly related?

    construct.net/en/forum/construct-3/general-discussion-7/anyone-seeing-slower-167843

  • Hard to say... You could try increasing the version gradually. Open it in r350 and save -> r380 and save -> r400...... perhaps that kind of works out.

  • Hmm good question. The bullet setting adds more steps in the physics engine, so it's probably simply that more steps = more chances that when the collision triggers in Construct there also happens to be a collision in the physics engine. Without trying I'd suspect though that it's still not 100% reliant because the physics engine treats the shape as a perfect circle whereas Construct just uses the collision poly.

  • Oh that's probably just because I'm on the latest beta version. It will come to the stable version eventually, you don't really have to worry about it. It just means that the wait action takes the timescale of the project into account when waiting. Timescale of 2 would mean everything in the game runs twice as fast, so a wait of 1 second would instead be 0.5 seconds long. It's simply an option to say you don't want timescale to change the duration of the wait.

  • Custom actions have some advanced uses (overrides), other than that the difference isn't really that big. I mainly like how custom actions help with organisation. The action to roll the dice is now available on the dice object itself, rather than shoved into the function object.

    construct.net/en/make-games/manuals/construct-3/project-primitives/events/custom-actions

  • You have to replace your mouse conditions with the corresponding touch conditions. Mouse only covers mouse inputs. Touch covers touch AND mouse inputs (if you check that checkbox). So instead of "left button is down + is over button5" you can just use "is touching object" and it will also work with mouse.

  • Yes, using wait can be tricky and you have to be a little bit careful, but it's fine depending on the case. You're using the timer wrong, the timer doesn't behave like a wait. You're just starting a timer on the dice, that's why this is happening in an instant. I personally wouldn't bother with a timer in this case actually.

    wackytoaster.at/parachute/10dicerolls.c3p

  • Your example is just working here and there for me too.

    Ball1.Physics.ContactCount>0

    That works consistently for me, this is 100% the way to go. I suggest you can call a raycast here towards ContactX/Y (+ some extra distance otherwise the raycast may be too short) if you need to know what exactly was hit since you can get the UID of the hit object like that.

  • You're in luck, that's a feature of bbcode!

    [icon=0] or [icon=tag] - insert an icon to the text. The icons are taken from the animation frames of a Sprite object set in the Icon set property. The icon can be referred to by its zero-based frame index, or by the Tag property of the animation frame.

    construct.net/en/make-games/manuals/construct-3/plugin-reference/text

  • Wow, really cool project!

  • Call me silly but I don't fully trust "Wait for previous actions to complete" I almost always use the trigger conditions. Feels more robust to me, can't explain it. There were some bugs with "wait for previous" when it was introduced iirc, maybe that's why. It does come in handy in some cases though.

  • I had this exact issue except not on Steam Deck. In my case the setting for "Steam input" was incorrect. I set it to use "Steam input" and for some reason this made the xbox controller not work/be detected properly.

    You can also quickly test and disable this in the steam library: right-clicking the game in the library -> properties -> controller

    If it's enabled there you can try disabling it. If that fixes it as it did for me, you have to change the settings for steam input in the backend.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you wanna be a little bit silly, javascript + eval()