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

Bugs will be moved here once resolved.

Post » Thu Mar 05, 2015 12:15 pm

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
You do not have the required permissions to view the files attached to this post.
B
18
S
5
G
6
Posts: 17
Reputation: 4,413

Post » Thu Mar 05, 2015 3:38 pm

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.
B
31
S
7
G
8
Posts: 232
Reputation: 6,254

Post » Thu Mar 05, 2015 4:14 pm

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)
B
18
S
5
G
6
Posts: 17
Reputation: 4,413

Post » Thu Mar 05, 2015 5:27 pm

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:

CopyFamily.png

Overlap with two SOL Lists Example.capx


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.
You do not have the required permissions to view the files attached to this post.
B
31
S
7
G
8
Posts: 232
Reputation: 6,254

Post » Mon Mar 09, 2015 1:32 pm

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.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

Post » Mon Mar 09, 2015 4:06 pm

@Ashley
As I said in the earlier post:
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.
B
31
S
7
G
8
Posts: 232
Reputation: 6,254

Post » Mon Mar 09, 2015 5:25 pm

@Ashley, could it be included in the manual as a tips ?
B
18
S
5
G
6
Posts: 17
Reputation: 4,413

Post » Mon Mar 09, 2015 7:04 pm

@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.
B
31
S
7
G
8
Posts: 232
Reputation: 6,254

Post » Mon Mar 09, 2015 7:10 pm

@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.
B
18
S
5
G
6
Posts: 17
Reputation: 4,413

Post » Mon Mar 09, 2015 8:04 pm

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.
B
31
S
7
G
8
Posts: 232
Reputation: 6,254


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 1 guest