OR-block ignores instances picked in parent event

dop2000

Nice bug detection! A+

I had some issues in the past with this but never gone to deep into it... simply assumed im doing it wrong.

I've found problems with the OR block too, but I think the previously picking event wasn't a "pick by comparison" but something else. I might have that block commented out in my events somewhere. Will report back if I find it.

Initially I thought I didn't understand the picking process correctly, but then figured the OR block was not reliable, so have been avoiding using it in a sub-event.

I think the bigger issue is what's supposed to happen with system picking.

If it's not going to work like regular picking then users need to know that.

newt

I still don't understand what you mean.. There is nothing in the official manual about system picking being any different from "regular" picking. I'm using system picking a lot and apart from this bug with or-block I never had any issues with it.

Do you have any links or maybe a demo capx that explains your point?

Nevermind, its not acting like I thought.

Time to stop looking at the bugs.

I hit this bug again today and it took me almost 2 hours to figure it out!

This time it was a bit different. I have two sprites in a container, and an event like this:

Sprite1 DragDrop is dragging

   Sprite2 var=foo    -> Sprite2 set x to 100
   or
   Sprite2 var=bar

   Else        -> Sprite2 set x to 200
[/code:3lirp5ur]

The Or-block and its Else part are supposed to test only one instance of Sprite2 (the one in the container with Sprite1 which is being dragged).
But instead, these subevents sometimes pick some other instances on the layout...
Changing the Or-block to "System compare two values: Sprite2.var=x | Sprite2.var=y"  resolved the problem.

@Ashley , will this ever be fixed?

dop2000

Just saw this and found interesting because I have similar events in my game

but I have never assumed that only the associated container sprites are picked (so I filter with a uid check as well, or similar)

Is it normally expected that associated container sprites are automatically selected?

NetOne

Yes, this is one of the main features of containers - when you pick one object, other objects from the container are picked automatically.

dop2000

Oh.. Damn, so I totally missed this!

(And Ive just seen it is right there in the manual , really should read that from time to time)

Cheers.

This would make life a lot easier..... it means I could kill of a ton of events that are probably eating a lot of CPU.

But it looks like it is not dependable unless the OR block is taken out of the equation

Still I have something to look into tonight.... Thanks....

I gonna crazy down. Please somebody help me resolve this small *peaceOS

https://www.dropbox.com/s/oj96gj0vng3zf6g/Screenshot_BUG.png

I asking my self - HOW IT WORK?

p.s. OMG ...and how insert image to post?

Pic update

https://www.dropbox.com/s/q66nzqmpd4yhd12/Screenshot_BUGupdatePic.png

Ashley

dop2000

Woooow... I spent hours trying to understand what I was doing wrong there. I made a small .CAPX too and was about to post the bug when I saw your post with the flaming icon, and I was shocked to read a title I was about to write.

So yes, it's a very annoying bug and I have made a small example too: https://www88.zippyshare.com/v/5KTgQmw3/file.html

Basically, you have two identical characters, two zones and a blue square.

If selected character is moving over Zone 1 or 2, hide Blue square

If selected character is NOT moving over Zone 1 or 2, then show Blue square.

(Move them with basic keyboard arrows)

And here the bug is that, even if the selected character moves, while the second character is over a zone, the blue square is still displayed while it should be hidden.

I know it's not something you can understand right away in 5 seconds, but after playing with it for a few minutes you understand that it's not reacting the way it's supposed to.

I know you guys are working on C3 and the progress you've made so far is amazing, but I didn't think such a core mechanism wouldn't act as intended.

[EDIT] : Indeed, the "simplest" workaround right now is to avoid using "OR" blocks combined with "Pick ...". The annoying thing is that it makes you multiply events unnecessarily...

(...)

Sprite1 DragDrop is dragging

   Sprite2 var=foo    -> Sprite2 set x to 100
   or
   Sprite2 var=bar

   Else        -> Sprite2 set x to 200
[/code:96xj18pe]
(...)

The way the code is put, i think the problem lies on Construct messing with the OR and Else, last being used against "Sprite2 var=bar" only.

Telyko by looking quickly couldn't it be a logic problem?

I'm at work so can't see your example.

Cassianno

I really tried to make an example as simple as possible to understand but I'm not sure I succeeded:

Here's how it breaks down

If click on Character then Pick only this Character

Character (UID = 1) and Character (UID = 2) (Same object)

One Character is on top of Zone A, and second Character is on top of Zone B

EVENT:

Pick selected Character only (After click on Character)              < C2 IGNORES THIS
	
	If Character is over Zone A
	OR
	if Character is over Zone B
	
		If Character is 8-Directions Moving
		OR
		If Character is Pathfinding Moving on Path
			
			Hide Blue Square

		If Character is NOT 8-Directions Moving
		OR
		If Character is NOT Pathfinding Moving on Path

			Show Blue Square[/code:2u8kurzm]
			
So the fact that there are OR blocks in the middle of the event in sub-events, C2 ignores the "Pick only this instance of the object" instead it picks all objects so the behavior doesn't work as intended. The blue square should react only to the selected Character where here it's also affected by the 2nd one who's not selected. You pick a character, you move it over a zone, this should hide the blue square and show it only when character stops moving over the zone. But blue square is still displayed because the 2nd character which SHOULDN'T be picked is over a zone and not moving.

Maybe this thread refers to the same error.

I'm not sure.