Ashley's Forum Posts

  • By putting a 0.1 second wait before the local storage gets the key , it worked .

    You shouldn't do that, because it will still break if 'Set item' takes longer than 0.1 seconds. You need to use the 'On item set' trigger instead.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Oh, you're actually using Construct 2. You posted in the C3 forum. Moving post to C2 forum.

  • 'Set item' doesn't finish until 'On item set' triggers. If you 'Set item' then 'Get item' without waiting for the set to finish, it will likely get the existing value of the item before 'Set item' is done.

    The new 'Wait for previous actions to complete' system action makes this a lot easier in the latest release - all you need is 'Set item', 'Wait', 'Get item', 'Wait'.

  • If you already have duplicated 'On key pressed' events in layout-specific event sheets, you may as well just call the right function directly, instead of calling a common function that then has to work out which function to call.

  • Can you post the full phone model name? "Huawei" is a manufacturer, not a device.

  • What device model is it and what version of Android is it running? This should have been fixed in Chrome 74. I'd guess you're somehow still on an older version of Chrome. Android 5-6 use a separate app for the webview, the Android System Webview, and that must be updated separately to Chrome, so having Chrome 74 doesn't mean it's definitely up-to-date.

  • From the Text object's manual entry:

    Text rendering

    Different browsers render text in different ways, and Construct 2's layout view also renders text differently to other browsers. This means you should expect the appearance of the Text object to vary slightly across browsers.

    You should test your game in a range of browsers to ensure text objects display how you intend for all users. For more information see Best practices.

  • In this situation if you want to do something completely different depending on the layout, you really ought to have two different functions. The old Function plugin only allowed this usage by accident, and I really think it's a poor way to structure your events - for example if you look at a "Call function" action, you can no longer tell what that does, and "Go to function" can't work - it depends on which layout you're on, which also involves reviewing the tree of event sheet includes across your project, which is hard work. If you just call a different function it's much more obvious what it does.

    How to better structure the events depends a lot on the details of your project. If you have a "common" event that really needs to call two completely different functions, I'd argue that is not actually a common event and ought to be implemented as layout-specific logic. This will involve rearranging the whole way those events are used, but I think it will be much clearer afterwards. Alternatively a quicker (but not particularly elegant) approach is just to have a global variable with the game mode that you set on each layout, and dispatch to different functions depending on the mode. I'd avoid relying on the layout name, because people normally expect to be able to rename things without breaking anything, and you end up in the situation where you can accidentally break your events just by renaming a layout.

  • This can't work in preview mode because there's no public URL to your project file. (It's not on a server, it's only on your device.) This can be worked around though, file a bug for it and we can look in to it. It should already work after exporting your project.

  • I don't think you need to specifically address this, since if you already have error triggers, if the user wants to check if the operation was successful after 'Wait for previous actions to complete' they can set a flag in the error event and then check for that flag after the action. Alternatively you can just add some success checking conditions, e.g. WebSocket's 'Is connected' condition which can be checked after the async connect action to see if there is a connection now (i.e. the connection was successful). Maybe we could adjust the design to handle this better though, but I'm not sure how that would look...

  • This is a different question to the one you originally asked, which is kind of confusing. It sounds like the obvious thing to do would be to make the script run in a function, and call the JS function from events when you go to that layout.

  • The runtime automatically stops all audio so long as "Play in background" is "No", so maybe check that setting.

  • As the message says, it only affects insecure origins (i.e. HTTP, not HTTPS). For years we have been recommending to publish to secure websites (HTTPS) to avoid exactly this kind of problem.

  • Mobile Advert only works in Android and iOS apps. It won't work anywhere else (preview, remote preview, HTML5 export, etc).