r88 _ Pb with platform has wall

C2 r88 64bits; Intel Core i5-2500K — GHz (x4), 8 Go DDR3, NVIDIA GeForce GTX 560 Ti (driver 296.10), Win 7 Pro SP1

Firefox 12.0; Chrome 18.0.1025.168 m

Capx

There seem to be a problem with the "platform has wall" condition in this specific setup.

I first used a "or" block has currently in the demo capx. (event 5)

The intended logic here is that if the char sprite is either out of screen or faces a wall on its right, it's considered dead and after a 1 second wait "resets"

Obviously, this doesn't work as intended with event 5. Death is instant and continuous.

The first one is "normal" I guess, I did not "bullet proofed" the state system (a spawning character shouldn't die either, even if not on screen).

But the following/continuous deaths are rather strange.

Disable event 5 and enable event 6 and 7.

This is closer to the expected behavior, but on chrome and FF, the sprite will randomly "block" in the right solid Sprite but not be considered dead. Like if the "has wall" condition did not trigger.

On FF, clicking out of the browser seem to "help" getting the event fired. On chrome, it doesn't seem to have much effect.

At first I thought it was a problem with "OR", but it sounds like the platform behavior might be responsible.

Or maybe I'm missing something. Anyway, report is done, let me know your opinion on the issue.

Woah, this was a complicated .capx. There are actually three issues combined:

1: like Physics, manually adjusting the Platform behavior's position confuses it. What happens is when by a wall, you set its X to a bit to the right - that wedges the object inside the wall slightly. Then you test 'is by wall' - the platform behavior thinks it's stuck inside a solid, so returns false. At the end of the tick the platform behavior pushes itself outside the solid as part of its ordinary collision detection, and the cycle repeats - the condition is always false.

Solution: use 'simulate control' to control platform behavior, instead of manually setting position.

2: 'is on screen' was always false for the first tick in a layout. So negated 'is on screen' was always true for the first tick. This is a bug and has been fixed for the next build.

3: OR blocks did not work correctly as subevents to 'for each' loops. This is a bug and should also be fixed for the next build.

Nice .capx, got two fixes out of it :)

1: like Physics, manually adjusting the Platform behavior's position confuses it. [...]

Solution: use 'simulate control' to control platform behavior, instead of manually setting position.

That's good to know, thanks.

2: 'is on screen' was always false for the first tick in a layout. So negated 'is on screen' was always true for the first tick. This is a bug and has been fixed for the next build.

3: OR blocks did not work correctly as subevents to 'for each' loops. This is a bug and should also be fixed for the next build.

Nice .capx, got two fixes out of it :)

Hehe glad I reported it then ^^

Good to know the "OR" block should be fixed too.