I want to fill the layout with non-overlapping sprites. Unfortunately, I couldn't find a built-in way to do this, so I built a function. The function calculates a random position, then checks to see if there are any sprites nearby. It repeatedly recalculates a position and checks the sprites until no overlapping sprites are found. Here's a screenshot of my event sheet:

<img src="http://dl.dropbox.com/u/18659416/fill%20events.jpg">

Unfortunately, it looks like picking isn't working in my favor, as my logging is showing that no sprites are being looked at in my while loop. Since the function is called from inside another loop that is creating the sprites, I'm guessing that the sprites are never getting added to the selection list.

Here's my cap file: http://dl.dropbox.com/u/18659416/fill.cap. It includes extra expressions for logging that I removed from the event sheet screenshot for simplicity.

Here's a screenshot of the current output:

<img src="http://dl.dropbox.com/u/18659416/overlapping%20sprites.jpg">

Here's the logging output that the CAP file will add to the clipboard:

FindEmptyPosition called
Starting loop, setting position to 209, 432
Exiting function
FindEmptyPosition called
Starting loop, setting position to 51, 441
Exiting function
FindEmptyPosition called
Starting loop, setting position to 386, 471
Exiting function
FindEmptyPosition called
Starting loop, setting position to 331, 271
Exiting function
FindEmptyPosition called
Starting loop, setting position to 417, 203
Exiting function
FindEmptyPosition called
Starting loop, setting position to 47, 236
Exiting function
FindEmptyPosition called
Starting loop, setting position to 623, 230
Exiting function
FindEmptyPosition called
Starting loop, setting position to 82, 43
Exiting function
FindEmptyPosition called
Starting loop, setting position to 380, 209
Exiting function
FindEmptyPosition called
Starting loop, setting position to 541, 223
Exiting function
FindEmptyPosition called
Starting loop, setting position to 239, 388
Exiting function
[/code:1v6kg4hs]

Any thoughts on how to fix this?  Or, better yet, a completely different approach that is less complicated?

When you create an object it becomes the only picked object for the remainder of that event.

In this context, does event mean the top-level event, or does it also include sub-events?

After that the object cannot be picked until the next tick (or frame).

It sounds like this makes what I want to do fundamentally impossible. You simply can't create a bunch of objects in subevents, and pick them all in another subevent later on.

A way around it is to do the actions on the next tick, or in our case tick 1.

That sounds like a reasonable solution. I'll try it out.

I'm having a problem with picking. I have an event in which I'm randomly generating a level. There are multiple sub-events and loops. As a final sub-event, I want to change some properties of all objects that were created in the event. Unfortunately, the Construct selection list appears to have filtered out all objects, so the last actions have no effect.

In the referenced CAP file, you can see how I'm creating some sprites and then trying to change them all at the end. The only sprite affected by the changes is the one created in the top-level event. Changing the last sub-event to a foreach loop doesn't work, either.

What can I do to fix this, aside from duplicating the last event in all the individual places where I'm creating a sprite?

http://dl.dropbox.com/u/18659416/picking%20problem.cap

Okay, that makes sense. Thanks.

Here you go. After simplifying my larger cap file down to the bare bones, it looks like the problem is caused by dynamically adding a new instance of the ShouldBeOnBottom object.

http://dl.dropbox.com/u/18659416/SpriteOrderProblem.cap

FYI, this is the first time I've used Dropbox, so shout at me if it doesn't work.

Thanks, Newt. I implemented your proposed solution and it works great. It's a bit slow because I'm creating a new "vision checker" sprite each frame for each object, so I may need to optimize that a bit later.

I have two sprites, both on the same layer. On the first one, I sent it "To Back". I sent the second one "To Front". However, the first sprite is still being rendered on top of the second sprite.

Any thoughts on what I can do to fix this?

However if you were using the attribute to group your obstacles you can add those objects to a family, and use the family instead.

I'm using the "solid" attribute to block movement, not for any kind of grouping.

Keep in mind los does not add objects it detects to the selected objects list.

What are the "objects it detects" and the "selected objects list"? Are you saying that solid/obstacle objects are not in the list of objects to check for LOS?

On number two:

The behavior works off of points, basically its the same as distance(x1,y1,x2,y2), only it can detect if something is in between those two points.

I checked out the code and confirmed this. Thinking about it more, LOS logic that accounts for the size of the object is non-trivial. Nevertheless, it would still be really nice to have.

There is a work around that does not use the behavior. That being a detector sprite that you have scaled to the to the range of sight.

That would give me an easy arc and distance check, but it doesn't account for obstacles. I'd need to manually check if LOS to an object is blocked by another object.

I'm using the LineOfSight behavior with a little top-down space adventure game. I want to use it along with a player-centered light and shadow-casting obstacle sprites to hide areas and objects that the player doesn't have a line-of-sight to.

It basically works, but I have two problems which I'd like to discuss:

1) Objects marked "Solid" never satisfy the "Has LOS to object" condition.

2) The "Has LOS to object" condition is only true when the player has direct line-of-sight to the center of the object.

Issue #1 can be worked around by using a secondary non-solid object at the same position as the solid object, which is then used to query visibility. Is there a better option, short of changing the behavior code?

Issue #2 seems to require a change to the behavior code to consider object width/height/radius. Or is there another option?

Thoughts?

What's the best way to modify a private variable (i.e. health) by a variable amount on a collision, depending on the force of the collision? Here's a cap with sprites that crash into each other: http://sites.google.com/a/mike-wyatt.com/mike-wyatt-s-blog/PhysicsDemo1.cap?attredirects=0. I don't see any physics-related conditions that are fired on collision. I also don't see a way to hook into the process and calculate any kind of change in velocity.

Thoughts?

What is the latest version? Both the website and my client say version 0.99.62 is the latest. I'd like to check out this sweet cap file, but I'm also getting an error when I load it:

Microsoft Visual C++ Runtime Library

------------------------------------

Runtime Error!

Program: C:\Program Files\Scirra\Construct\Construct.exe

abnormal program termination

Your example is exactly what I want. The ObjectPairer makes more sense now. Thanks!