same family + drag + overlapp

Hey guys,

if you could help me with my problem, I would appreciate it very much.

Short description: Ten squares, all in one family with one family behavior: drag'n'drop. When you drag one square over another, call the action (in this case: restart layout).

Problem: Version 1 is not working. Version 2 (same as version 1, but the order of event and sub-event has been inverted) is working, but I think it is way more performance-heavy and I also cannot use in my project since I need to call an 'else' later.

Could you advise me on how to make version 1 work? Creating another family with another name, but with the same objects as in the first family is not an option.

Thank you.

Here is the .capx: https://www.dropbox.com/s/khlz8r2ewyv8v ... .capx?dl=0

Wel, you read those events wrong. Forget for once that "IF THIS THEN THAT" dinosaur.

In event 2. You pick the square that is dragging. Not one square more. Not one square less. So at this moment the List Of Picked Objects contain that ONE object. The dragged object.

For each following condition, this is the PREVIOUS PICKED OBJECTS LIST. Until you forget that list by making a new top level condition.

So, If you gooing to look for that overlap as you do. You have ONLY ONE object picked. That condition is only true when that object overlaps itself. Wich is kinda impossible.

In event 5 you Pick All the Squares that overlap another Square. For each following condition, this is the PREVIOUS PICKED OBJECTS LIST. So the next event looks in that list (the list of all squares that overlap another square) and filter out of THOSE ... the square that is dragging. If it finds on, the conditions is TRUE.

Your calculation is also wrong. For the last one its (10 * 10) - 10. Look in the debugger.

For the first one it is obvious (10 * 0) + 1. Again look at the colission checks in the debugger.

Thank you for your fast reply, 99instances.

1.) Sorry about the debugger thing. I used the debugger in the bigger project (from where I extracted this problem from) and the number of checks per tick kept changing without me doing anything so I got confused. Should have looked at the debugger for this example project too.

2.) Ok, so you are saying that after line 2 the Previous Picked Object List consists of only the one square that is dragging. But now let's say in line 3, I would change it to the following:

This seems to work, so even though the circle is not on the Previous Picked Object List, it is still considered for this condition. Then why in this version

all the instances and objects of the square family are not considered for this condition? Yes, they are not on the Previous Picked Object List, but neither is the circle. Is it because - in constrast to the circle - they have been excluded in line 2 from being considered for subevents after line 2? Why is that? I mean what is the reason for Scirra to have made it like that?

3.) Hmmm. This doesn't bring us closer to the solution I think. I have to go work in the garden now, I will check back in later when I have come up with a solution or to see if someone else has found one.

Yes, the circle is unreferenced. It is not previous picked. So it just adds the circle to the previous picked list.

An other way to understand this is .. to state that for the circle it is the first 'top event'. So its previous picked list was forgotten.

Read this:

https://www.scirra.com/manual/75/how-events-work

It is way more clear then i can ever explain it. You are not the only one. A lot of beginners are using Contruct the wrong way. And i, me myself, still fall in that trap. Why i dont consider myself as a avid user.

But serious, once you got the hang on picking objects, the system is absolutly beatyfull.

Now you would ask, how do i forget a picked list ? Just make a new top level pick event. A function is very handy, it is a top level event.

On more thing on optimizing. You captured that there are loops behind the scenes. If you make a condition like 'pick by comparisation' it loops behind the scenes trough all the specified objects and compares them to what you want em them to compare to. Those loops are just inevitable. And to be honest, dont worry about them to much.

Unless they look for overlaps and collisions. Those are performance eaters.

I have Two examples for you. This one should explain what happens. How it picks. It is importand to understand this.

https://www.dropbox.com/s/4kofww888ajdw ... .capx?dl=0

This one showes a way to minimize collission dedections. It comes down to make 'behind the scenes loops' that dont check for overlaps/collissions. So, forget all the other optimizing you have read about. (that statement gonna make me public enemy nr1, hehe)

https://www.dropbox.com/s/awhfbsw9n04do ... .capx?dl=0

Check the debugger and enjoy a collission dedection of only ONE every tick.

Do i recoment this ? I dont know. Construct is supposed to be easy. This aint easy coding for most.

You seem to understand those things.

Hehe okay I see. Like I said in the first post, I'd rather not have two families with the same content just for workaround purposes because then everytime I create or delete a new object I have to remember to do it in two families. But I guess this is the best solution at the moment. You can even put the whole code segment in a group that becomes active on Drag Start and becomes deactivated on Drop so that it only uses resources when in fact a dragging is in process. Thank you!

You can even put the whole code segment in a group that becomes active on Drag Start and becomes deactivated on Drop so that it only uses resources when in fact a dragging is in process. Thank you!

I suppose you can prove that? Getting the collsions check/dt under the 90 while dragging this way ? And having a working logic ?

https://www.dropbox.com/s/qde1ask8hzh6p ... .capx?dl=0

LOL, you just set my own dragging solution active/non active. Its k, dude.