Ashley's Forum Posts

  • Behaviors are ticked in a certain order, and making a chain of pins creates a dependency on the order of ticking.

    It's best to avoid chains of pins, or position with events in that case.

  • Take a look at the 'Ghost shooter code' example. That stores various instances in global variables, which can also be used in scripts in event sheets.

  • If you need to compare if a value matches any of a large number of other values, put them all in an Array, and use the Contains value condition.

  • This is a common mistake: "A"|"B" evaluates to 1 (meaning true, because one of the values counted as "true"), so you are actually comparing TEST = 1.

    You probably want an OR block instead. See How events work.

  • Refer to the Scripting reference in the manual for available scripting APIs. For example if you look up the Sprite object's script interface you'll see animationName is read-only, and there is a separate method to set it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Each script block in an event sheet has its own scope, so local variables aren't shared. If you want to share something between them, you could use global scope instead.

  • Answer your own performance questions with measurements

    I would guess in this case you will struggle to measure any difference at all, because it's not important to performance.

  • You do not have permission to view this post

  • I checked our code logs and there have been no substantive changes to the Physics behavior this year. This means it's pretty unlikely there really was any breaking change in the Physics behavior, so I would suspect that's not actually the cause and you've mis-attributed something else. Additionally if you roll back to a previous release and it still doesn't work, that is a strong sign that there was not actually a change in Construct itself; it could well be a change you made to the project and mis-attributed to Construct.

    This is very common - the bug report guidelines are there to help you get to the bottom of the real issue and provide all the information we need to actually help, so I can only advise that you follow those.

  • It seems to show the HTML correctly here. Images and other sub-resources won't show though because you've not really uploaded your project. For example the HTML file referencing img.png in preview mode will request preview.construct.net/local/img.png, but you haven't uploaded a file there (and can't since it's our domain). So it won't work until you publish your project.

  • Yes, you can use the full set of web APIs. Your JavaScript code runs just like it's in a <script> tag.

    Also you don't need to include extra scripts to use browser APIs - you can just use them directly (e.g. document.title = "Hello world";). Although importing JS libraries can be useful as well.

  • Why not just use "Move to object" every tick? If you have an action that starts automatically following an object, you'd also need an action to stop it again, and all that seems redundant compared to just using "move to object" with a condition that controls if it's true or not.

  • Obviously I'm totally unbiased, but it looks like they use a flowchart system instead of anything approaching the event sheet. It looks like it doesn't do much of what Construct's event system can. Also one of the big disadvantages of flowchart systems is they are 2D and quickly land you in a spaghetti-like mess as soon as you do anything more than the basics. Event sheets stay well-organised even with thousands of blocks, since they are just listed in the event sheet.

  • Construct 3 already supports publishing to Xbox One.

    For other consoles we'd need the console maker to add support for HTML5 games, and the more people ask them for that, the more likely it is to happen. Until then there are a couple of porting companies that have sprang up that can take a Construct game and port it to major consoles for you.

  • Construct 3 uses a different spritesheeting algorithm that is better at combining multiple objects on to the same spritesheet. However if you do things like create lots of objects dynamically at runtime without them being placed on the layout, this can cause higher memory usage as Construct doesn't know ahead of time how to group objects on spritesheets according to when they're used together. See memory usage in the manual for more information on best practices.

    If that doesn't help solve it, you can try reducing the spritesheet size in project properties. It can help increase the granularity of image loading, which can bring down the overall memory use.