Ashley's Forum Posts

  • It sounds like an issue that was fixed (well, worked around), yes - best try it in r227 and check.

    There's no point reporting Chrome on iOS bugs to Chrome btw - it's just a Chrome skin for the Safari browser engine because iOS bans other browser engines. Same for all other iOS browsers.

  • It's not actually quite as simple as it might seem: the layout renderer view is actually a 3D view (no, we won't be doing a 3D editor), with a camera pointing down to the layout surface and zoom is done by moving the camera Z co-ordinate. Then there is the traditional view frustum and projection maths that go with that. There's a bunch of stuff that needs tweaking to update this. However I can say it's already fixed in C3 - you can zoom out to 1% there.

  • I can't reproduce this in Firefox or Edge, only Chrome, so it's really a quirk of Chrome than a problem with the C2 engine. I think what is happening is the browser lazy-loads the positioned audio playback engine the first time you play a positioned sound, which takes a moment. I think you can work around this just by playing a positioned sound on startup, maybe on the menu/splash screen.

  • Another day, another iOS viewport bug. Thanks for the report, found a workaround for the next build.

  • Closing as won't fix: because the objects are solid, it's the job of the 8 direction behavior to prevent itself from ever overlapping with the solid objects, hence the collision event should never fire. I don't know why it does destroy on two of them, it shouldn't on any, but this is definitely not something you should rely on.

    The workaround is obvious: there's no point making an object solid if it is destroyed as soon as you touch it, so just remove the solid behavior...

  • "Text (Drop Shadow) Object" appears to be a third party plugin. As per the bug report guidelines, we cannot accept reports for bugs in third party plugins, please report it to the plugin developer.

  • Closing, please see the bug report guidelines. There is nothing we can do about reports like this, they are useless.

  • There are two problems here:

    1) there is a lot of complicated logic in the platform behavior to handle slopes, gravity angles, moving platforms etc. As part of handling this it remembers the object it is currently standing on. This means changing the solidness doesn't immediately take effect until you next jump.

    2) your example seems to teleport a large solid object over the player. I'm not sure what you expect the platform behavior to do in response, since it's physically unrealistic. So I don't think any weird behavior doing this should be treated as a bug.

    Anyway given both these facts I don't think we'll fix this - it's super complicated code to cover an unrealistic case, and there are workarounds (usually "nudging" the player makes it update the standing-on object again).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Closing as driver bug.

  • The .capx link returns 404 not found, so I cannot investigate this. Besides, this type of problem is very difficult for us to do anything about. I did not know about Windows' "10,000 objects is enough for anybody" limitation when designing C2, and even if I had I don't think I'd have imagined anybody would ever create a project with such a colossal number of images. So at this stage we'd have to rearchitect C2 to work around this, which is not going to happen. We are however designing C3 with this limitation in mind.

    Construct 2 has to create a couple of graphics objects per animation frame - one for the frame itself, and two (but sometimes three) different icon sizes for the frame. It doesn't seem to matter if these are small, they still count towards the 10k limit. I assume the .capx is just a project with several thousand images. I have a hard time understanding how this is necessary. I cannot think of any reasonable way to design a game where this really cannot be avoided. For example I've seen projects in the past which have the same character with 100 animation frames, copied and pasted 30 times, with tiny alterations. There are much better ways of doing that. The advice in remember not to waste your memory will help you avoid coming close to the limit too.

  • Closing as your pathfinding behavior has diagonals enabled, so it is set to do what you are seeing. If you think there are any other issues please file separate reports.

  • Closing, please see the bug report guidelines

  • Closing, please see the bug report guidelines.

  • Sorry, there's nothing particularly useful in that crash report, so there's nothing much we can do about this.

    Often issues can be caused by the VM, particularly around graphics drivers, so I'm afraid all I can recommend is trying to update the VM or maybe the version of Windows inside the VM.

  • Closing, please see the bug report guidelines. NW.js (formerly Node-webkit, changed quite a while ago!) has gone through major updates as of the latest r221 release, so updating will likely solve your problem too.