BUG??? Touch release fires when its not supposed to (or not at all)
synthesis
Member Posts: 1,693
I have found that when building buttons - only one way seems to work consistently.
HERE IS HOW:
Rule: when Touch is INSIDE
..... Rule: when Touch is RELEASED
..... ..... { CUSTOM FUNCTION }
I have found 2 things sometimes occur if you don't place a TOUCH RELEASE rule inside a TOUCH INSIDE rule (or even if you do).
1) Sometimes the button fires even though its not touched but when something else is touched or if another actor (possibly using the same parent) is touched and released.
2) It doesn't fire at all (which usually requires me to change it to a TOUCH PRESSED (even though I don't want the rule to fire until a release occurs). Having used Flash for years...their UI controllers (mouseOver, mouseDown, onRelease, onReleaseOutside, etc.) work flawlessly. The GS UI controllers seem somewhat flaky (or incredibly sensitive to 100% accurate micro-sequencing)
I have found TOUCH>PRESSED works very consistently (when inside a TOUCH INSIDE RULE)...but TOUCH RELEASE seems buggy as it sometimes doesn't fire or mis-fires (in another actor).
The reason I use embedded rules is because if I place a TOUCH INSIDE and TOUCH RELEASE valuations on the same rule - sometimes bad things happen or nothing happens (at times). In short...it sometimes doesn't fire or it misfires. Embedding them seems to provide more accuracy. But intuitively...it seems they should be able to be in the same rule values.
Again...in Flash...you would code:
on(Release){
do something;
}
In GS - a similar logic sequence seems to be:
RULE: when Touch is Inside and when Touch is Released
do something
but this doesn't always fire correctly and the TOUCH INSIDE control should be assumed in the touch release.
HERE IS HOW:
Rule: when Touch is INSIDE
..... Rule: when Touch is RELEASED
..... ..... { CUSTOM FUNCTION }
I have found 2 things sometimes occur if you don't place a TOUCH RELEASE rule inside a TOUCH INSIDE rule (or even if you do).
1) Sometimes the button fires even though its not touched but when something else is touched or if another actor (possibly using the same parent) is touched and released.
2) It doesn't fire at all (which usually requires me to change it to a TOUCH PRESSED (even though I don't want the rule to fire until a release occurs). Having used Flash for years...their UI controllers (mouseOver, mouseDown, onRelease, onReleaseOutside, etc.) work flawlessly. The GS UI controllers seem somewhat flaky (or incredibly sensitive to 100% accurate micro-sequencing)
I have found TOUCH>PRESSED works very consistently (when inside a TOUCH INSIDE RULE)...but TOUCH RELEASE seems buggy as it sometimes doesn't fire or mis-fires (in another actor).
The reason I use embedded rules is because if I place a TOUCH INSIDE and TOUCH RELEASE valuations on the same rule - sometimes bad things happen or nothing happens (at times). In short...it sometimes doesn't fire or it misfires. Embedding them seems to provide more accuracy. But intuitively...it seems they should be able to be in the same rule values.
Again...in Flash...you would code:
on(Release){
do something;
}
In GS - a similar logic sequence seems to be:
RULE: when Touch is Inside and when Touch is Released
do something
but this doesn't always fire correctly and the TOUCH INSIDE control should be assumed in the touch release.
Comments
It appears that if you build a button actor with a touch control in it...and then if you CLONE that actor into a new actor (with new behaviors...but still a button)...when the first actor is released...it fires on both the original actor as well as the cloned actor...even though they are separate actors.
It appear that maybe some of your XML isn't getting 100% separated when you duplicate an actor in the builder...my guess anyway.
The only way to prevent this "ghost" firing of the cloned release behavior seems to require that you put the TOUCH >> RELEASE within another TOUCH >> INSIDE rule.
I created an Index that is referenced for each instance.
Then in event behaviors the index = 0 is the first to be changed, then if index = # and if touch is pressed-> if touch inside/release -> block of actions; then 0.001 timer to reset index to 0.
Seem to work as all other action on screen is ignored by the individual instance action.
I am getting to love indexing as it is the closest thing to array/database I have to work with.
Though if you have lots of instances ...better put the list in a Note and put that in My Behavior and drag to each actor...I have 25 actors and 25 instances of a square to correctly place them in.
in large areas, I used a clear dot.png(5x5) for a display area and it is 0 in the index...and I just call for change of image in runtime. then change back to 0 when player is done...saved a lot of time, and clutter on work-up screen.
the clear dot placeholder makes 1 piece of programming work in many areas...EX:
my logo actor...serves as the the Congratulations actor... by changing image and position when a playIndex changes.
Nice thing about GS ... image behavior is good; it auto-resizes actors to the image size. and Index variables are very responsive, keeping the fps rate high.
MH
-Experiment-
Create several instances around the screen of an actor with:
on touch inside
change game.inside to 1 (true)
otherwise (or on touch outside)
change game.inside to 0 (false)
Create another actor that displays text: game.inside
Quickly mouse between the instances with inside detection and notice that for most cases, the display text accurately reports true, however, there is a possibility you will be inside of one of those instances, but the text displays false. I assume this is an issue with order of operations and events not getting processed before moving on.
Does anyone know a way around this? Thanks!