Ashley's Forum Posts

  • Nobody can help you get your project working from watching videos - try posting a small .capx with a clear goal and asking for help with that.

  • I'm not sure it is possible. How do you think the case I described should be handled? I don't think there is a clear answer.

  • Closing as won't fix: the problem is the "Bound to layout" behavior does its clamping after the events run, so it works in this order:

    1. drag-and-drop moves object outside layout

    2. event fires and spawns object

    3. bound-to-layout moves object back inside layout

    Changing this order will doubtless break other projects that depend on things working this way, so we can't really change it. It should be straightforwards to work around if you just do the layout bounding in events instead of with the behavior.

  • I copied over the r221 encoders for the next build (again), r229 will ship with the same encoders as r221 used in the 32-bit build. (There are no issues reported with the 64-bit version so I haven't changed them.) I thought I did this for r228 but I guess I made some mistake, so hopefully r229 will fix this.

  • Can't reproduce on an iPad Air 2, plays the sounds just fine. We routinely test devices like iPad and would surely notice ourselves if audio playback didn't work.

  • Closing as won't fix: jump-thru slopes are not supported. It makes it more or less unresolvable in situations like this - the fact you can pass through a jump-thru upwards but not downwards makes it pretty much unresolvable when dealing with moving up/down a slope. Imagine making a large jump-thru that covers the entire slope - what should the engine do? Let you fall through a jump-thru (not usually allowed), or only allow you to move up, or allow you to move horizontally through the big one...? Actually I'm surprised it works with slopes at all, I thought that was something we deliberately never supported...

  • You should test on weak mobile devices from the start. Building a game then going backwards to figure out which part is slow is a lot harder than regularly testing throughout, and noticing any significant drops after particular changes.

    Your CPU measurements don't seem to add up - your screenshot shows 95% CPU on an iPhone 5 but 47% in your original post... are those correct? The 95% CPU indicates a CPU-capped game so you probably have too many events, collision checks, or something like that.

  • I think a lot of it is actually done by paid humans who can circumvent any restrictions we put in place. So unfortunately we have to just clean it up sometimes.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can already pass different banner IDs to the pubCenter actions can't you?

  • They're both probably about the same, since they basically do the same thing but one has a built-in "trigger once". This is the kind of thing you can measure yourself.

  • Refer to the layer by its name instead of its index and the order doesn't matter.

  • I just tried it and gamepad input seems to be working fine for me in NW.js 0.14.5, at least on Windows.

  • That's the right folder. There wasn't any code changes in C2 itself - just changing the encoder EXEs.

  • Your bug report about the "Open Windows Store" action not working turned up a wider issue that the Windows Store plugin incorrectly checked specifically for Windows 8. So a bunch of stuff including roaming values and the opening the Windows Store action only worked on Windows 8 and not Windows 10! I've fixed the check for the next beta which should fix those problems, and maybe one or two others.

  • It seems like when the elements have long text and extending in to the next "cell" that when you get strange behaviour.

    Hmm - I think you're right. I made a fix which increases the column widths for the next build. This prevents there being so much overlap and seems to help. We'll see how it works out when r229 is released.