Ashley's Forum Posts

  • Again, the manual entry describes that:

    colorRgb ... An array with 3 elements specifying the red, green and blue color filter of the instance, with color values as floats in the 0-1 range.

    Using floats in the range 0-1 is how GPUs actually process the data. It makes many color calculations work more easily, and works regardless of the actual color data being processed. For example when using colors in the 0-1 range, the multiply effect is literally just "a x b". If you use colors in the 0-255 range, that is very much specific to 8-bit unsigned storage - e.g. 10-bit storage would use a 0-1024 range instead - and doing "a x b" will process an entirely different type of effect that isn't really useful - to get a multiply effect with the result also in the 0-255 you'd actually have to do "round(((a / 255) x (b / 255)) x 255)".

    So basically everything in computer graphics uses colors as floats in the 0-1 range as it works a lot better, and so does Construct.

  • Remember to think about the inherited classes. The ISpriteInstance manual entry states it derives from IWorldInstance, which in turn states it derives from IInstance. So all the properties and methods covered in all three manual entries are available for Sprite instances. (This is the standard way object-oriented programming works in a range of languages.)

  • Don't guess -look in the manual to see what methods and properties you can actually use. In this case you want the IWorldInstance property colorRgb, e.g. to set a red filter: 

    inst.colorRgb = [1, 0, 0];

    You might also want to take a look at using TypeScript which provides precise autocomplete and error checking to help catch mistakes like the one you made.

  • You can diff the JSON files for the event sheets. I realize it might not be too easy to read but it will show things like where additions, changes and removals have been made.

  • The latest beta release r401 may be able to open the project, as it has improved automatic handling of invalid names. It may also be able to show the first invalid name it encountered which could help speed up identifying the invalid names if there's only a small number of them. This guide has some more information.

  • Construct doesn't support asyncronous loop condition methods. You'll have to find another way to achieve this.

  • In r401 the Mobile Advert plugin has now been updated. Internally it has switched over to using community-admob-plus-cordovaygs@1.32.8 which now uses Google Mobile Ads SDK v23.2.0 for Android (and v11.3.0 for iOS). Hopefully this solves the immediate problem - let us know how it works out. We'll continue to review options for better long-term maintenance.

  • This is now supported in r401 with the new method createLoopingConditionContext(). You can use it like this (sample code for a 'TestLoop' condition that repeats a number of times): 

    TestLoop(count)
{
	const loopCtx = this.runtime.sdk.createLoopingConditionContext();

	for (let i = 0; i < count; ++i)
	{
		loopCtx.retrigger();

		if (loopCtx.isStopped)
			break;
	}

	loopCtx.release();
}

  • If that post doesn't help, send your project to supportdcb@construct.net and we'll take a look.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've already been through it all - the documentation doesn't cover it at all and from what it says it should work, but it doesn't. It's a bug in Steam and you need to get through to their technical team to get them to fix it. I'd happily talk to anyone on the Steam technical team, but I haven't been able to get through to them myself, even by filing bugs and doing everything I can think of. If anyone has any contacts at Steam, please try to get them on it!

  • This is a normal feature of browsers: they restrict media playback until there is an interaction. It's covered in the Video plugin manual entry under "Playback restrictions".

  • It's not supported and has been removed entirely. I don't believe it actually had any legitimate use and the main impact it has was to cause a bunch of bugs in other areas.

    I'm afraid we will not support a feature just because it works around a bug in a graphics driver. In that case the graphics driver needs to be fixed, not Construct.

  • If you think you've run in to a problem with Construct please file an issue following all the guidelines, otherwise generally it's impossible to help.

  • I thought the render scale did already take in to account the layout scale? I'm still not sure what you're doing that requires the render scale and layout scale to be handled separately.

    If you really do need both modes though, I'd just say switch to DOM mode and add a CSS variable from JavaScript.

  • I've added an extra parameter for the next release to "Pick Nth child" so you can choose whether the index is relative to all children (as it works now), or filtered to only the chosen object type (so it works like you want it to here). But I'd note this filtered mode actually works inconsistently to the other existing features - for example the 'Compare child count' condition and 'ChildCount' expression work with the list of all children. There is still no way to compare the child count of just one type of child, nor does there seem to be any good way to design an expression that returns the child count of just one given object type, as the current design of Construct does not allow an object type to be passed to an expression. So while the next beta allows you can pick from a filtered list of children of a given object type, there is no way to identify how many children there are of that type, nor is there any obvious way to design such a feature at the moment. I suppose if you have a fixed hierarchy setup, such as every hierarchy has both two arms and two legs, then picking Nth child with filter may be good enough, but usually I'm pretty reluctant to introduce feature inconsistencies like this - eventually someone else turns up and says "this mode is inconsistent/incomplete, it shouldn't be designed like that..." and we have a similar discussion like this again.