The runtime has to run behaviors in some order. There's no fundamental way around this. The order you are getting is either:

1) move 8direction

2) bound to layout

This means it bounds it to the layout after moving 8direction, which works as you want it to. Otherwise it's

1) bound to layout (before it's moved)

2) move 8direction (which could then move it outside the layout)

This means the object can temporarily be left outside the layout, because 8direction moved it after it checked the bounds.

The workaround is to change the order the behaviors run in, which you can do by rearranging the list.

Ahhhh!!! Many many thanks. I was losing my mind. I knew that I was missing something. Didn´t occurred to me to check the order of behaviours.

Thanks you very much Kyatric and Ashley

Hi Kyatric. Thanks for the response.

What I experience from the capx I shared is:

• All is ok when moving without reaching the edge of the layout.
• when reaching the edge, and without lifting the key, the wheels of the bottom sprite move relative to the sprite they are pinned to (which shouldn't happen since they are position pinned to this bottom sprite).
• when releasing the key, the wheels of the bottom sprite return to the original position relative to the sprite that are pinned to.

I've also tried to replicate this behavior in C3 building it from scratch, but it didn't show. Now, when I imported the C2 example to C3 it behaves again as I described above (???).

I'm using the last build of C2, r262.

Hello!

Just wanted to make sure before posting a bug that I'm just being a fool and it's not actually a bug.

The example is very simple. Two sprites with pinned "wheels", both with bound to layout and 8 direction. If I move the sprites to the edge of the window one set of wheels doesn't behave properly when the sprite reaches the edge.

https://drive.google.com/open?id=1gBzXmUDmay7q5vp3eHqrXrpc1Q6IEZh_

Thanks

Not a bug.

From the manual:

[quote:2ivd3n3b]The Cell border property can adjust how cells are marked as obstacle. If the border is larger than 0, then cells close to obstacles but not actually touching may also be marked as obstacles, effectively giving an extra "obstacle border". If the border is negative, cells only just touching an obstacle may not be marked as an obstacle, effectively shrinking the obstacle area inwards.

You have the cell border property set to -1 in your example.

The same in Windows 7, C2 r221, Chrome 49.0.2623.87.

As a workaround you can set a "wait 0" action before changing the position.

It's not a bug. If the platform is solid it won't jump through. Remove the solid behaviour and just leave the jumpthru one.

scirra.com/blog/112/remember-not-to-waste-your-memory

Problem Description

Filename of files loses (letter) case on export. I believe that filenames shouldn't be altered.

Attach a Capx

dl.dropboxusercontent.com/u/16940759/filesCaseBug.capx

Description of Capx

Blank capx with imported files to test export.

Steps to Reproduce Bug

• Check imported files names.
• Export
• Check filenames in the exported directory.

Observed Result

All imported files are exported as lower case.

Expected Result

Filenames should be left as is.

Affected Browsers

Editor bug.

Operating System and Service Pack

Win7 Home 64bit SP1

Construct 2 Version ID

Release 221 64bit

The issue started occurring with either r210 or r211, if that helps at all.

I disagree. I've seen this occur long before that. Perhaps since r152, I can't say for sure.

Anyway, until someone finds a way to reproduce, it is not going to get solved.

I've experienced this issue a few times on large projects but never been able to reproduce...

In my case I'm pretty sure it happened randomly at save time with or without versioning.

blackant please read these:

enable-cors.org/ (here you will find instructions on how to serve CORS enabled content)

developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

I can't explain it better than I already have.