Ashley's Forum Posts

  • Glad the debugger is proving useful! We do have lots of improvements planned, such as breakpoints and a 'watch' (so you can make an area with just a few of your own chosen values showing).

    Darklinki - AJAX can work in preview mode if you set up CORS right. Check the manual.

    Global variables aren't shown because I forgot about them! Oops, will try to add in the next beta :)

    The Steam update was late because I was away for the past two days - it should be live now.

  • You do not have permission to view this post

  • Did you notice we now ship a built-in sprite font plugin in the latest Construct 2 release?

  • I think there's a mistake in your translation of the original formula where it says:

    293 / 1000 x

    which I think means

    Seed / (1000 * x)

    Your expression says:

    (Seed / 1000) * X

    which is equivalent to

    (X * Seed) / 1000

  • Excal - 0.1 seconds! There's no point using dt when the units are already seconds. "Every 0.1 seconds" happens at the same time interval regardless of the framerate, which is the whole point of framerate independence. I'd suggest re-reading delta-time and framerate independence.

  • It should be, have you tried it?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The solution you mentioned should be fine. By default games run at 60 FPS, so will be doing collision checks 60 times a second. If you do a collision check every 0.5 seconds it will be 30 times faster. Even if you do a collision check every 0.1 seconds, it will be 6 times faster, and fairly unlikely to miss any collisions providing the objects are relatively slow moving.

    If possible, you should also use additional conditions to filter down the list of objects being checked. E.g.:

    + Sprite: is overlapping Block

    + Sprite: is moving

    In this case it collision checks every Sprite, since it's the first condition, then of those that are overlapping it filters down to just the moving instances. The instances that are not moving had an unnecessary collision check. The other way round:

    + Sprite: is moving

    + Sprite: is overlapping Block

    This first picks only the moving Sprites, then of those, runs a collision check. This can save a huge amount of collision checks if most of the Sprite objects are not moving.

  • The desktop app exporter is based on node-webkit, which is a standalone version of Google Chrome. The game should work nearly identically.

  • You do not have permission to view this post

  • Thanks, should be fixed in the next build. Note however the problem was not with OR blocks in general, but the specific "is overlapping point" condition when used in an OR block. Please post new reports for any other conditions which have the same issue.

  • Actually scratch that, I found it reproduced with one of our old demos and posted a bug for it here: https://bugzilla.mozilla.org/show_bug.cgi?id=901574

    Definitely a Firefox bug by the looks of things.

  • You do not have permission to view this post

  • The old method of exporting appended binary data to the end of EXE files, which was suspicious to some AV software. Now it always exports the same single EXE file (the plain, unmodified version of node-webkit) and uses a separate data file. That has resolved some false positives, but if some AV software thinks the plain old EXE file with nothing extra added is suspicious, there's really not much we can do about it. We can't digitally sign the file, because we don't want our digital signature to be used for other people's games. You could try signing it yourself, or disable AV, or find a way to whitelist the file, and I'd also report the problem to your AV vendor since node-webkit is not malicious software.

    It's possible future node-webkit updates will resolve the issue, basically by chance (the binary data in the EXE is more or less random, and must be by chance matching the signature of a virus). However it doesn't mean it won't come back in future updates.

  • Doesn't reproduce if the jumpthru is a lot taller and you fall down further. The snapping has to happen to at least a small extent so the platform movement is tolerant of small errors in the movement. However it does look like the tolerance is too large for jumpthrus; I've reduced it for the next build, so it only happens if you really are very close to the top of the jumpthru.

  • Works OK for me. Note if you resize the window really narrow, there are minimum widths for the columns in the event sheet. You have to do it deliberately to make it change the sizes though. If the restored window is still a reasonable size, it doesn't change the sizes. So just make sure the restored window size is not really small.