On the creation of each sprite.. in the same event, create the text object and also set this variable:

Sprite.TextID to Text.UID

and then to keep each text updated:

for each Sprite

pick Text by UID = Sprite.TextID

that'll single out the corresponding text object for the actions such as:

-> set text to Sprite.Health

-> set text position to sprite.x, sprite.y

etc

Another idea would be to use the "adjust HSL" shader on each sprite and let the player pick exactly what colours.

Easier than individual sprites but it'll makes your games framerate drop if there's too many shaders.

just thought i'd chime in with something relevant here..

Ashley it can be a problem in other cases.. although the work around is simple.

I had an event which created text and the clickable area behind it.

In the same event I set the areas width to be the text.textwidth.. and obviously this didn't work because of what you just said.

Anyway, the work around was just to add a "wait 0.00001" seconds just to make it set the width on the tick after the text was displayed.

It's the bullet you have placed outside of the layout. It's hiding behind another object.

after 1.5 seconds, there is an event that makes it angle towards the player.

I'd recommend creating a separate layout and just placing one of each object onto that, instead of placing them off the screen in your actual game layout.

It's cos you spawn a 'bullet' but then refer to 'fam_bullets' to set the angle..

objects and families are like separate things regarding the way C2 picks instances.. so it isn't sure on what to set the angle of.

just change

'fam_bullets' set bullet angle of motion..

to

'bullet' set bullet angle of motion

ramones, nice..wish I thought of that.

Just realised, if you use:

'For each chain order by distance(chain.x,chain.y,red.x,red.y) ascending'

then it will order the chains going from red, regardless of direction.. so you can have it going up right down etc.

sorry, I don't have an answer but i am compelled to ask why you'd want to set the timescale so high?

One way to do it would be to add an instance variable to the object (Can't think of a good name so I just used 'B') and an event with the system condition:

"for each object by order of Object.RandomValue ascending"

             --> set object.B to loopindex

This will number each object.B by the order in which it was picked. going from 0,1,2,3 .. etc

Then in a separate event, to pick the highest, you can do

Object.loopID = object.count-1

      -->set scale to... etc

the -1 is necessary because the 'loopindex' expression is 0 based (0,1,2,3..), but the 'count' expression isn't (1,2,3,4..)

you're right, it seems to detect overlap when it's simply against. Maybe it's supposed to work that way? I'm not sure.

Anyway here's a cap with a few changes:

capx

The main thing is I just made the collision polygon a slighly smaller square.

I thought i saw some picking problems so i just instinctively added the 'for each' condition, it might not be necessary though.

The detect variable is so it doesn't have to check for overlaps every single tick.. collision detection is relatively more cpu heavy than most actions..apparently

and the set x to (int(self.x/16))*16 is just to add snapping.

If you are using the physics behaviour, then i'd see if enabling 'bullet' mode in the properties would help. I don't know the details of it, but it basically gives the object more precise collision detection.

Firstly, it may not be id'ing them correctly from left to right..

if you leave "order by: " blank, then I assume it will pick them based on the order they were created within the layout editor.

so either make a system that creates the chain objects on startup inbetween 'Red' and 'wall', or for now you can simply do "order by chain.x ascending", this will pick them from left to right.. (so bare in mind that this wont work if you want the chain to go in other directions)

next there are some picking problems with chain and link..

Im not sure if you just followed example, or you figured out for yourself, but the reason it's good to use a family here is to help make it clear what instances your action is referring to.

For example having "chain: create joint to chain" will make it confused as to what chains to pick

but having "chain: create joint to link" means that, in the conditions, you can specify what chain, and specify what link. Even though a link is just a chain, it allows you to pick two seperate chains. It's awkward, yes :)

so anyway..

link: id ? 3

should be

chain: id ? 3

and for the last two events you just need to be consistent with whether your choosing link or chain.

the "link:id=0" event i think is fine, but the "link:id=3" event then goes on to refer to a chain instead.

for simplicity and ease of reading the sheet i'd replace all occurences of 'link' in those last two events with 'chain' instead