Ashley's Forum Posts

  • Do you mean using autocomplete? That's a feature of the editor, so it depends entirely on the features of whichever editor you're using.

    Note Construct's built-in editor has Construct-specific autocomplete based on its own APIs, such as listing runtime methods after typing runtime.. Other editors won't be able to do that, because they aren't specially designed for Construct's APIs.

  • LOS has always worked that way. It's a quick and simple design and it seems to be fine for the majority of uses, since it's worked like that for years and most people seem fine with that.

    Also, testing line of sight to any point on the collision mask isn't necessarily desirable. In many cases you don't want to count line of sight if only a tiny fraction of the collision mask is exposed. For example if only a tiny hair-width of the player is showing past a wall, should enemies count that as visible? If it works by any point on the collision polygon, the answer is yes, and then you get enemies that leap in to action chasing you down when the player is still basically hidden (and based on past experience people will probably file this as bugs thinking Construct is calculating this wrong). This then also breaks the symmetry of line-of-sight, meaning the enemies have line of sight to the player, but the player doesn't have line of sight to the enemies. You could also try to fix that by allowing any part of the player collision polygon to have line-of-sight to any part of the enemy collision polygon, but then you get even more absurd results, like a hairline edge of the player's shoulder being able to "see" a hairline edge of an enemy's shoulder counting as both objects having line-of-sight to each other. So then you could try to fix that by having some kind of way to configure the proportion of the area of the collision mask that counts as visible... and now you have a complicated feature that's hard to visualise, difficult for beginners to understand, and tricky to program.

    As with most features if you run all the way down the rabbit hole of the various details and edge cases, you end up with lots of complications, which in turn makes Construct more complex and difficult to understand. The main point of the product is to be simple and intuitive for beginners, so we avoid doing this wherever possible. As it stands, you can test line-of-sight to any position, so you could set up a few key image points around the edges of the object, and count it as visible if you have line of sight to any of those points. That's pretty straightforward, doesn't require any new features, and still more or less solves the problem.

  • Those screenshots don't show the full configuration since you also have to set up AdMob correctly too. See the documentation.

  • I tested ads recently and they worked correctly. Most reports of ads not working turn out to be users who have misconfigured them. So check they are correctly configured. If you still think the problem is with Construct, please file a bug following all the guidelines, since we need all that information to be able to help.

  • You can't request permission in 'On start of layout'. See the manual entry for it, you must use a user input trigger.

  • Thanks for the feedback, it's interesting to see people's thoughts on C3 especially in regards to the wider market.

    For what it's worth, from my perspective points 1 to 3 are basically feature requests, and I think at least 2 and 3 are already filed on our feature suggestion platform. These all sound great and only reason things like this are not already done is we're a very small team with limited resources, and we're also being asked for literally hundreds of other feature requests. I estimate there's about 10 years work logged on our feature suggestions platform, so we have to prioritise pretty ruthlessly. FYI suggestion 2 is probably best achieved through a layer tree rather than a flat list of layers, but as with many suggestions it's pretty complicated and we have to balance it with everything else.

    Suggestion 4 should already be possible. If you disable all behaviors, stop animations, and don't run any events involving an object, then the engine does virtually nothing with it. The only thing left that it does is a tiny check every frame to see if it's visible and on-screen for drawing. This is usually negligible, but if you have the unusual case of thousands of such objects scattered across the layout so that this check is using a measurable amount of CPU, then the render cells feature should fix that. It organises objects in to cells to organise their rendering and only check instances already near the screen. This brings the engine overhead of a far-away instance to exactly zero: the engine will do absolutely nothing with it, unless your own events do something.

  • Construct's event system is itself implemented in JavaScript. So JavaScript code can do everything the event system can and more. It's a strict superset. So there are lots of things you can do in JavaScript that aren't possible in events, such as using browser APIs that are not exposed in the event system.

    The main advantage of event blocks is they are very quick and easy to set up. There are things event blocks can do in a few clicks that could take you weeks and weeks of very difficult programming to achieve in JavaScript. So naturally it's a trade-off.

  • The manual isn't updated until the next stable release, and the Physics APIs are currently only available in beta releases. In the mean time you can use debugging in dev tools to explore the available APIs.

  • You need to request permission before using motion/orientation.

  • As ever, without a project to look at, all I can say is it should work, and if it doesn't, the error message it tells you is presumably correct in its diagnosis and you should do what it says.

    I also noticed that functions are global now, you can call them from any eventsheet even if they are not attached, is this by design or a bug?

    This is by design.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
    • Post link icon

    This looks like a duplicate of this thread so closing. Posting the same thread is against the forum rules, please see the Forum & Community guidelines.

  • As I said, if you can reproduce a case where Construct seems to get it wrong, please file a bug following all the guidelines. It's the usual way that we deal with problems and the process is designed to maximize the chance we can fix the problem.

  • I manually removed a few files from our releases that aren't needed for the purposes of Construct, including:

    • pnacl (Portable Native Client), a browser plugin that Construct doesn't use (and Chrome will remove themselves in future anyway), including the .nexe file
    • All locales other than en-US
    • The tools chromedriver, nwjs, payload (these are separate to dev tools and aren't generally needed in Construct)

    I did ask the NW.js developers for info about which files are essential, but they said to just use trial and error, and I've noticed the set of files changes sometimes between releases too. So basically you can find out which files are essential by deleting them and seeing if the app still starts! I'd watch out though since some files may be optional and could break features. For example the app may still start if you delete notification_helper, but then it seems likely notifications won't work any more. So it's worth doing a little research to try and figure out what the purpose of the file actually is, and if it doesn't sound important and the app starts without it then it can be removed.

  • Actually, I can't find anything that's wrong, it all seems to be working correctly. If Construct is doing something like inconsistently copying some properties but not others, please file a bug following all the guidelines.

  • The instance properties are stored in the instance. So if you delete it, those properties are gone.

    When you create a new instance, Construct will copy the properties of an arbitrary existing instance. If none exist, it will try to use the properties of any previously deleted instance. If there are still none, you get the defaults.

    So the properties you get depend on whether there are other instances in the project, or whether you previously deleted instances.

    I think there might be a small inconsistency in how behavior properties are handled though, they don't seem to refer back to deleted instances. I'll look in to that a bit further.