Everade's Forum Posts

  • HTML5 games running in the browser are essentially websites, built using the same technologies like HTML, JavaScript, and CSS. So they follow the same security rules as any other website, including the use of iframe.

    If you're concerned about kids browsing online, there are plenty of great resources on internet safety you can find both online and at your local library.

  • Yes, a webGL 2D global illumination shader using radiance cascades was once shared by Xor in the construct community discord. One shader generated the cascades and another one was for GI, then multiple passes of blur. Although it didn't account for viewport scaling and wasn't very flexible. But you might still be able to find it there.

  • These events run on every tick. Meaning that as long as the event condition is true, the animation will start from the beginning and never get beyond the first frame.

  • Again same issue.

    In that specific scenario, on your Event Sheet "main", the event nr. 113 conditions stay true even after death. So it calls the "classicgamedeath" function on every tick. Means you reload the "deathscreen" layout indefinitely until you clicked that button for the first time, which is the last time the deathscreen is reloaded. Thus the second click will actually work as you escaped the endless loop.

    Note:

    All events with an arrow "On xyz" (including functions), are triggers. These only execute when that specific event is being triggered/called. Otherwise they are entirely ignored.

    Everything else, will run ON EVERY TICK. Even without specifically setting the event "On every tick". The "On every tick" event is actually redundant. That's just there for beginners, although i believe it causes more harm and confusion than anything else.

    So basically the game runs your entire event sheet, on every tick, all events from top to bottom, unless those triggers i mentioned before.

    "Trigger once", which you also seem to have been testing with, is also a beginners trap as it may behave differently than you would expect.

    One way to prevent something like this is utilizing Groups. You put these events into a "death" group, and deactivate the group when these conditions are no longer needed (after death) so on the next tick they are ignored. And reactivate the group when your player is back alive. Which is also performance friendly as all these event conditions are entirely ignored when deactivated.

    Or just refactor those nested events, so when your character dies it only calls the action once.

    Or you split the event sheets, so each layout has its own event sheet, only including event sheets that are required. For example the deathscreen should not need to run actual gameplay logic at all, it only needs to know certain variables which could be imported from a core/variables event sheet.

  • Set the 8Direction acceleration and deceleration by action.

    Then use the expression "Infinity" which returns a float set to positive infinity.

  • Because event nr.6 calls the classicgamedeath function on every tick.

    You can easily debug things like these yourself by adding an event at the very top of your event sheet. Then add a breakpoint to it and start a debug preview. It will hit the breakpoint right away, so you can continously click on the "step" button in the debugger, which will then visually show you where the code is currently at inside your event sheet.

    That way you can spot issues like these very easily.

    https://www.construct.net/en/make-games/manuals/construct-3/project-primitives/events/breakpoints

  • I made a workaround instead of using hierarchy i saved the UID in the "parent" object as an instance variable, then pick the "child" by evaluation. So not using hierarchy fixes the crash as well as further loading related issues, but also means you will need to handle hierarchy related conveniences manually.

    Or just leave it as it is and wait for a fix.

  • Sounds like it might be related to this https://github.com/Scirra/Construct-bugs/issues/8118

  • All events with an arrow "On xyz" (including functions), are triggers. These only execute when that specific event is being triggered

    Everything else, will run ON EVERY TICK. Even without specifically setting the event "On every tick". The "On every tick" event is actually redundant.

    So basically the game runs your entire event sheet, on every tick, all events from top to bottom, unless those triggers mentioned above.

  • Since you create them at a specific location they should just stack on top of each other. Have you checked in the debugger if there's truly just one instance?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Looks like it was indeed getting it from a cache. Glad i was able to help.

    Just keep in mind when calling with a parameter like you said:

    https://worddad.com/download/output.json?v=" & current_date

    Will still cache it locally, and also still get it from cache for a max of 24 hours.

    For example if a player starts playing at 01:00 in the morning, and you update the JSON file at 01:30, the player will not get this update (loading the file from local cache) until the next day comes around.

    Which might not be what you want. So a more accurate timestamp including hours/minutes would make sense here.

    However keep in mind that the json files are still cached locally for the duration set by your web server (possibly for a year), even if not needed. Entirely depending on your website's cache settings. Not a big deal, but something to be aware off.

    If you want to truly prevent caching locally, you would have to change the expire header on your webserver.

    This here would disable local cache for all JSON mime types on your website:

    In your .htaccess add: 

    <IfModule mod_expires.c>
ExpiresActive On
ExpiresByType application/json A0
</IfModule>

    But there might be additional layers of caching, for example if you run your website through a CDN (for example Cloudflare) which may cache files on their cloud systems as well.

  • Sounds like a caching issue to me.

    It might be possible that C3 (or any export option) loads the file from local cache. In that case, check your web server's Cache-Control / Expire Header settings. Or any other layer of caching.

    Might be worth checking out.

  • In the export options, set Minify mode to either "Simple" or "None".

    More details about minification can be found in the Manual.

  • Just press play, so it will stop on the next tick, more specifically on your next breakpoint.

    Or add another breakpoint like citron suggested.

  • Hard to help without seeing your code.

    It might be due to the host syncing the peer's position. In the official examples the host moves the peer. So the peer will always update its position according to the host's game state. If you try to move on the peer directly, the peer will be synced back to the position of the host's game state. Peers only send their inputs, then the host moves the peer.