"Is overlapping ... at offset" is ignoring non picked object

Problem Description

"Is overlapping ... at offset" is ignoring non picked objects.

Description of Capx

The file show two rows of squares.

The first one (grey and blue) permits to see which "Sprites" have been selected in the row bellow.

The next one (red and green) is the actual test and its separation should be at the same place than the first one.

The square at the bottom show where each separation is expected to be.

Why ? Because the "is overlapping ... at offset" should take all objects into account and not only the picked ones.

Steps to Reproduce Bug

Simply execute the file !

Observed Result

Non picked objects are ignored in the "is overlapping ... at offset".

Expected Result

"is overlapping ... at offset" should be agnostic to the picked list.

Affected Browsers

• Chrome: YES
• FireFox: YES
• Internet Explorer:YES

Operating System and Service Pack

WIN7 SP1

Construct 2 Version ID

Build 198

All conditionals are by definition subject to the currently picked list. If you need to reset the selected object list, you need to include a "Pick All Object".

Since you restricted the list of red sprites to those on the right half of the screen, it makes sense that the center red sprite does not detect the sprite on its left (not part of the SOL).

Changing "is overlapping ... at offset" to ignore the SOL would break hundreds of projects, including one of my own.

Hi cacotigon,

the problem is that if you include "Pick All object" then you cancel the purpose of your first filter.

There's a solution but she is suboptimal and convoluted.

One have to use either a local variable or an instance variable.

In that case, maybe this condition should have an option to ignore the SOL which defaults to "false".

That way, It wouldn't break old projects and has an added bonus, it will make it clear that it will ignore the SOL.

(Unless you decide to do so)

Yes that is true. You can't have two different SOL for the same object type. A workaround I've used in the past is creating a family called GenericFamily which contains every sprite object in the project. Using GenericFamily in pick statements resolves this problem. Note that following the comparison event (overlap, etc), you'll have to repick the GenericFamily using the normal object type in order to access any custom instance variables, for example:

[attachment=1:3bxs5ssq][/attachment:3bxs5ssq]

[attachment=0:3bxs5ssq][/attachment:3bxs5ssq]

For anyone else who looks at this, this logic tests all right-hand screen Red Squares to see if they overlap at -64 X with *ANY* Red Square (including left-hand screen ones). CopyFamily is designed to be used generically with any sprite object type. The above logic could be drastically simplified if one simply created a RedSquareFamily specifically containing only the red square object type.

The local variables don't serve any practical purpose. They're just to demonstrate how one would compare identical object type's instance variables in subsequent sub-events.

This is indeed how the event system is intended to work - you can never pick instances outside of those previously picked in the same object type, unless you use "Pick all".

You can however pick instances from a different object type, which includes families. So all you need to do is make a new family with just the red square in it and test the overlap with the family, which includes all red instances. This is much simpler than cacotigon's workaround. Here's a .capx: https://dl.dropboxusercontent.com/u/15217362/fixed%20overlap.capx

Closing as not a bug.

Ashley

As I said in the earlier post:

[quote:3qboelsf]

CopyFamily is designed to be used generically with any sprite object type. The above logic could be drastically simplified if one simply created a RedSquareFamily specifically containing only the red square object type.

The example you posted only works specifically with the Red Square object type. If I wanted to run this same type of logic test for Gray Box against Gray Box, I'd need to have a family just for Gray box as well. One family for each test. I was demonstrating how one could create a generic test for future reference.

Ashley, could it be included in the manual as a tips ?

programaths

Look at rexrainbow's rex_uid2prop plugin as well. It lets you get instance property values via UID indexer.

http://c2rexplugins.weebly.com/rex_uid2prop.html

Did you understand my example, or do you need me to explain it further? Families keep distinct SOL, which is why it works.

cacotigon, I do understand your example.

You simply use the generic familly to hold the "current instance" and reset the SOL with pick all.

I guess that the Ashley method could be detected and optimized by the engine while yours would be harder to recognise.

If families are cheap, I think it is the way to go.

Thank you both for your insights.

No problem. I tend to agree with you programaths regarding the simpler solution. I usually go for the abstract way of solving a problem because it's what I'm used to in my work. But I think from a case scenario perspective, simply creating one extra family does the job just fine.

Good luck on your project.