It lets you specify a zero-based index ID. So, for example, if you have two Sprite objects, Sprite(0).X returns the X position of the first Sprite and Sprite(1).X returns the X position of the second.

See IndexIDs in the manual, then look at Object Expressions on the Expressions page.

i can't seem to make TrailGlow to follow the Character when i'm moving with the 8Direction behavior not with the mouse.

That's because most behaviors -- 8 Direction included -- update before events are processed. Set OldX and OldY after all of the trail events -- at the end of the event sheet, for example -- and things will work. As it stands now, the flow of actions is:

Update 8-Direction behavior -> Set OldX, OldY -> Update trail, Result: OldX and OldY equal the actual position when the trail is updated, thus, no trail.

Whereas updating afterwards yields:

Update 8-DIrection behavior -> Update trail -> Set OldX, OldY, Result: OldX and OldY are different from the actual position when the trail is updated since they were updated at the end of the previous frame.

Here's one way of doing it, with every step commented.

[attachment=0:c6gco203][/attachment:c6gco203]

This is the simplest way to get an unbroken trail. Unbroken, of course, meaning that if a fast moving object has a trail, there will be no breaks due to speed, as trail segments are created depending on how far the object has moved since the last frame.

You'll want to be careful with performance on this, most especially if you're targeting mobile. It would be better to limit this to objects that aren't moving excessively fast, or to have a quick fade-out time on trail segments to keep the amount of segments created to a minimum.

Let me know if you have any questions.

You'll need to be more specific about what you're wanting. An "auto wave enemy" could be a lot of things.

Scrolling - both horizontal and vertical - are used when your layout is bigger than your window and you want to view different parts of the layout. This is great for games where you have purposefully designed levels of a finite size.

Finite is the key word here. In the case of the space example you provided, the idea is to have an infinitely scrolling level or background. Since you can't make an infinitely sized level, the idea here is to reuse "scrolling" objects by having them wrap from the bottom to the top by modifying their Y position. This provides the illusion of scrolling through an infinitely tall level while using a finite amount of objects and resources.

It should be mentioned that these techniques aren't restricted to the Y axis. You could just easily do infinite scrolling on the X axis using the same tricks.

Just for recap: for purposefully designed levels of finite size, change the layout size and set the scrolling; for infinite levels/backgrounds, change the position of onscreen elements to give the appearance of scrolling.

Try using nested For loops. So for example:

For "x" from 0 to 100:

---For "y" from 0 to 100:

------Create object YourSprite at (LoopIndex("x") * YourSprite.Width, LoopIndex("y") * YourSprite.Height)

This example will create a 100 x 100 grid of sprites of an arbitrary size. You can, of course, change the loop bounds if you want more or less tiles. The expression LoopIndex(LoopName) returns where you are currently in a loop.

Let me know if that helps at all. I'll clarify points if you have any questions.

Set Cursor is aware of picked objects, object creation is not. If Construct made assumptions about what kind of object you want to create from a family, it could lead to confusion, thus it simply creates a random object. Honestly, I feel it would make more sense if you couldn't create an instance of a family object.

This is by design. The function object is a global object, with one instance that spans the entire project, similar to keyboard, mouse, etc. There's no reason you would ever need more than one, thus they only allow you to add it once.

You have your wheels on the non-scrolling UI layer - move them to the same layer as the truck body.

You just need to subtract the angle of the sprite from the angle you're already calculating. Since Angle() returns a value between -180 and 180 while the angle of a sprite is between 0 and 360, you'll need to adjust for this by adding 360 degrees to your calculated angle if it is less than -180 so that your final value is also between -180 and 180. Here's a one line solution(using the conditional operator):

Set ang to (angle(Sprite.X,Sprite.Y,hit.X,hit.Y) - Sprite.Angle) < -180 ? (angle(Sprite.X, Sprite.Y, hit.X, hit.Y) - Sprite.Angle + 360) : (angle(Sprite.X,Sprite.Y,hit.X,hit.Y) - Sprite.Angle)

GIve the enemy the Bullet behavior and set their angle of motion -- under the Bullet behavior actions -- to 180 degrees at the start of the layout/whenever created.

sqiddster Part of it is the time required by the GPU to swap your low resolution rendered image to a location where it can draw from that image. Another is the fillrate hit you're going to take drawing your upscaled low resolution image to the full resolution of the screen. If you have a lot of layers, you end up drawing a lot of massive images on top of each other to composite them into the final image. In comparison, when drawing everything at the full resolution from the start, you don't have to worry about rendering layers to their own intermediary targets and then compositing them -- you simply draw all of your sprites sequentially starting from the bottom layer.

Perhaps if you had relatively few layers and were rendering a lot of smaller images to each of them, you might get some benefit from intermediary low resolution rendering. But if your layers consist of, say, one or two large background images each, you're absolutely going to take a hit on performance.

EDIT: I figured I should mention, I absolutely agree that something could be done about the performance of fading to a solid color. Setting the background behind the canvas to your color of choice and then adjusting the transparency of the canvas itself would do the trick, if possible. This precludes the ability to draw, say, text on top of the fade, but it at least helps in some situations.