Ashley's Forum Posts

  • It's not currently supported. Further, as the concept of custom actions relates closely to picking in the event system, and since picking is not a concept that is built-in to JavaScript, it's not necessarily obvious how to design a script interface for calling a custom action. They operate in different paradigms.

  • I'm afraid it's impossible to comment on just a video. If you think there is still a problem please file an issue following all the guidelines, as we need all that information to be able to investigate and help.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The Touch object just reports what the browser provides via the deviceorientation event, so you may as well just read the same value directly from the browser when using scripting.

  • The current plugin uses the billing library v4 - we'll update it to v5 soon (hopefully well before the November deadline).

  • Here I am to once again explain that we get far, far more suggestions than we could possibly do. We have got probably 5+ year's worth of work posted in a few months to the latest suggestions platform. It is such a vast amount of suggestions that it is an enormous amount of work merely to review and respond to them all. Further, suggestions that look simple or obvious frequently turn out to be far more complicated than anticipated.

    I'm mostly just repeating what is described in more detail in this thread about the suggestions platform. That also explains why we do not guarantee a response to suggestions, and has a section saying "please do not try to claim your idea is simple or easy to do".

    I did have some email contact with someone else about this. The email thread originally started about a bug in the SDK, which was fixed, but then went on to a suggestion. It's not actually clear to me the topic discussed in that email thread is exactly the same as the thing described here. Anyway I ended up saying pretty much what I said here. I did some brief exploration of the feasibility - even though as I said there is no way we could possibly do even that for the volume of suggestions we get - and as far as I could tell from that, it would in fact be extremely complicated to do anything more at all in this area. Construct is first and foremost a 2D engine and adding more features that you'd typically see in a 3D engine quickly becomes very difficult, not least because the entire existing engine is geared for 2D. I would definitely prefer not to discuss such topics by email mainly because we don't have the resources to do that for everyone, and also because we have the suggestions platform to try to deal with that in a more consistent and transparent way.

    I realise that hearing a negative response to suggestions can be disappointing. I would emphasise once again this is usually due to the volume of suggestions and our limited resources, and nothing to do with the quality of the ideas. I'd do all the suggestions we got if possible, but it's just totally inconceivable. It's unreasonable to take an excessively negative interpretation of this, and so I must point out the Forum & Community guidelines, in particular this part, which if it continues may result in the thread being locked.

    Having a persistently antagonistic, cynical, combative, sceptical or complaining attitude. For example, no software is perfect, but if you continuously claim that our products are absolutely terrible in every way, you may quickly wear out your welcome.

  • r327.3 came out a couple of months ago and so far it seems to have been working fine for everyone else.

    Usually the quickest way to help is to share your project file.

  • The export file structure affects how URLs like those used in the AJAX object are used. It's documented in the manual.

    You should use 'Request project file' instead of 'Request URL' as you don't need to type in a URL, which saves you from problems like this.

    You should also always add error events and at least display something if they trigger, because it is so helpful during development. I'd guess the problem was not that it was clearing the arrays, but that it was failing to load anything at all, but you didn't know that because you didn't have anything checking for errors.

  • I discovered another potential backwards-compatibility issue this caused. Previously if you set the position of an object with the Platform behavior exactly adjacent to a Jumpthru object (e.g. setting its position to Jumpthru.X, Jumpthru.BboxTop) then the player would land on it. After this change the player now falls through the Jumpthru. This affected the Kiwi Story demo game which does this when the player walks through a door.

    Previously this essentially relied on the bug in the Platform behavior processing things in the wrong order. In Construct an object exactly adjacent to another one counts as overlapping it, and so moving a Platform object exactly adjacent to a Jumpthru is in theory the same as moving the Platform object halfway inside the Jumpthru. So in both cases the correct thing to do is to allow the Platform behavior to fall through the jumpthru, as it didn't land on top from a position not overlapping it. So with the latest fix the Platform behavior now does the correct thing of falling through, but due to the fact the previous bug meant things were processed in the wrong order it allowed it to handle it as landing on the Jumpthru instead.

    Unfortunately this means adjusting the Platform behavior to keep compatibility with the way it used to work is extremely complicated, as it means trying to retro-fit a subtle bug on to what is now the correct code. This also makes it a risky change as making such a change could easily break something else, and maintaining complicated quirks like this long-term is also challenging.

    Meanwhile the workaround is straightforward: it works fine if you position the player slightly above the Jumpthru instead of adjacent to it (e.g. setting its position to Jumpthru.X, Jumpthru.BboxTop - 1). So while once again we are always extremely reluctant to make breaking changes, I think we will have to go with adjusting projects instead of changing the Platform behavior. Hopefully this is easy as it is a straightforward change to make. I made this change in a single place in the Kiwi Story project and it fixed the problem. So this is another thing to watch out for with the latest change to the Platform behavior.

  • It definitely can't reset the picking every condition though - consider:

    + Sprite X < 500

    + OR: Sprite Y < 500

    You'd expect this to run actions with all Sprite instances picked that are left of X=500 or above Y=500. If it resets picking for every condition, it becomes essentially just "Y < 500" by itself, which will look broken again.

    The current design of OR blocks gets this right though.

    You could file a suggestion, but based on the problems I've shown, I don't see a better way it could work unfortunately! Then there's also backwards compatibility: we can't just change how thousands of existing projects work...

  • The latest releases also have ViewportMidX/Y system expressions which mean you don't need to calculate the mid-point yourself.

  • There is nothing special you need to do. Family variables also appear under instVars.

  • It's a difficult feature to design. The problem is it can't work like a simple logical OR as it needs to involve picking, which is a unique aspect to event sheets.

    You can illustrate the difficulty with a counterexample. Suppose it did just work like a boolean test, and then you set up this event:

    + A overlaps B

    + OR: spacebar is down

    -> destroy A

    Now if you press spacebar, even A which are not overlapping B get destroyed. But this violates a key principle of events that actions only run on the instances which met the event's conditions.

    This would mean running the OR block like this:

    1. Test "A overlaps B". None are true and so none of either A or B are picked. Usually this means it doesn't run the event, but it's an OR block, so other conditions might be true, so keep checking them.

    2. Test "spacebar is down". If this is true then the actions can be run. However "A overlaps B" just unpicked everything. Should it then go and pick them all?

    If it worked like this I think you'd get equally-confused threads where people say "why does this OR block affect things that did not meet the condition?" I can't remember exactly as this was originally designed years ago, but I think this was originally the case, it confused people, and so the design was changed early on, but the new design still trips people up.

    Because of picking, I'm not sure there's any obvious or intuitive way to design OR blocks. Perhaps the naming is misleading and they should be called something else like "ANY" blocks, so people don't approach it with the mindset of a logical OR. That does also better match how they work, as an OR block really means "run all the conditions, and then run the actions if any condition was true".

  • Well, currently the intent is that you'd use Construct Animate for that.

  • I'm afraid this comes down to an unresolved issue with the HTML specification. Construct tells the browser to draw the text in the same place, but different browsers end up drawing the text in different places. Unfortunately I don't think there's much that can be done about it other than try to manually correct it.