Nepeo's Forum Posts

  • — this thread is talking about the new feature added in todays beta release which allows you to disable the collisions on a per tile basis in a tilemap. Which means you don't have to have a separate invisible tilemap for collisions anymore. Although that approach does allow for additional flexibility in how your collisions behave at runtime.

    newt you could always have 2 copies of each tile, one with collisions disabled. I would have thought normally you'd want to change the visual aspect of a tile if it went from solid to passable. Even if you didn't this would give you the flexibility to do it later if you wanted.

  • I don't believe so. It don't remember it being discussed prior to the implementation of the feature.

    I believe the data is baked in at export time, and shared for all instances of the tilemap. So making it tweakable at runtime would be somewhat complex at this point. Possible, but some good arguments would need to be made.

  • Ensure you have the tilemap bar open, the select the tilemap you want to edit. Double click the tile you wish to edit. On the right hand side a properties bar should be visible with a single check box "Use collision" untick it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Neither minification or the "write_external_storage" permission should have either effect on this. But I'm glad it's working either way.

  • Apple's support for making apps on older macs is rather unfortunate. The official line from Apple at the moment is "Starting April, 2020, all iPhone and iPad apps submitted to the App Store will need to be built with the iOS 13 SDK or later." So as of April the minimum version will basically be Xcode 11.

    As for simulator support the restriction is Webassembly (WASM) support. There's several components in the C3 runtime that require WASM to work, such as the audio decoder and the physics behaviour. All physical iOS devices do support WASM, but for some unexplained reason it is disabled in the iOS simulator.

    If you are not using features that require WASM, the project can be modified to remove the check... but things are likely to break if they do need it ( for instance if you have audio the project will not load ). In general we advise that you should test on a physical device anyway, so most of the time it's not worth the effort.

    The C2 runtime does not have the WASM requirement so works in the Simulator, but you are obviously missing out on a fair amount of features which are only available in the C3 runtime.

  • Tiny Martian yes the max speed is tied to the magnitude and the max_stick_movement at the moment. You can however fix this by normalising the value ( divide by it's maximum to get a value in the range 0...1 ) then multiplying it by the new maximum. Like so (min(magnitude, MAX_STICK_MOVEMENT) / MAX_STICK_MOVEMENT) * TRUE_MAX_SPEED. This will give you a speed between 0 and TRUE_MAX_SPEED which can be any positive value you want.

    EDIT: I've updated the example with this behaviour.

  • Taximan did you try out the example project I posted at the end of the thread? Seemed pretty similar to the original example you showed, but with support for Tile Movement and 8 Direction as well.

  • Ah well if you haven't uploaded an APK yet they won't be able to check if it has the billing permission, it's just not a very good warning.

    If you go to look at your app on the G Play console, then go to "Release Management > App release" you can create a internal test or closed alpha release. This will allow you to "publish" an APK to the play store without real users being able to see it on the store. It doesn't have to go through QA either.

  • The plugin should already include the billing permission, could you give a little more context?

  • The cost of executing the actions is the same in both, but in the second example you pay the cost of the loop twice. As well as the setup and teardown, the loop will also do the following for each iteration:

    1. check if loop finished
    2. start of block work
    3. actual actions
    4. end of block work

    The work your actions are doing is the same, so you can ignore that, but the steps in bold are now being done twice per item.

    Now realistically this overhead is fairly minimal, unless you are frequently doing this in your game and the loop is long you are unlikely to notice any difference. I would opt to use whichever is clearer to you, or keeps your game logic simpler. It's worth considering the performance implications of your events, but you should also consider the flexibility and maintainability of your logic. You can always make it less flexible later to improve performance if this particular part proves to be too slow.

  • We've seen something similar to this before with local storage, Android phones backup application data to your account which is restored when the app is reinstalled.

  • There's a workaround on Android that comes to mind. The "Share" plugin can be used to show the share tray on Android, allowing a user to choose an app to use a image with. A quick test showed that you can use this to save to photos, upload to twitter etc.

    The downside being that Safari only supports sharing text and URL at the moment, not files. You could encode the image as a data URI and share that instead but the user would only be able to post this to social media and the like, not download the image.

  • I've looked at it and it was a simple typo in a recent QOL feature. Fixed for the next beta release.

  • Looks like the error markers in the text editor aren't being cleared, it isn't normally possible to see more than 1 syntax error because the JS parser we use stops once it hits an error. Opening and closing the text editor should clear any invalid markers. I'll take a look at it.