juani's Forum Posts

  • UPDATE

    I'm sorry, but I got ahead of myself in posting. I checked and is not the order of behaviours. The sprite that shows the "bug" has the right order of behaviours (1. 8-Direction 2. BoundToLayout).

    So I began to test one more time:

    Redid the example one more time. This time the "bug" does not happen. Order of behaviours doesn't matter.

    https://drive.google.com/open?id=1I_sHeTvYs-Ru0r_d8m9RCdYp-_pvJg2R

    Next, I cloned the second "car" sprite (since that was how I made the original capx), added the events for this new object and this time the bug appears in the new instance.

    Now I check what happens if I add a fourth car by not cloning. This car4 also does show the bug.

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

    All cars have 1. 8-direction 2. BoundToLayout. I've also tried changing the order of behaviours but it doesn't change anything.

    What do you think?

    PS:

    For Construct 3, were you running the C3 or C2 runtime in your version built from scratch ?

    It was the C2 runtime

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • Ajax requests are subject to the cross domain policy. Basically, you can only make an ajax request from the same domain. If you need something from another domain you have to have access to that server so as to explicitly tell it to allow requests from other domains. Read the Ajax object manual entry.

  • You don't have any instances of liquid nor ladders in level 2, so the events won't run. I'm not sure if that's a bug.

  • 2. You are not using the load url action correctly, i.e. you are supposed to wait for 'On image URL loaded' to trigger before trying to load an image (not essential, I think, but good practice).

    Actually, 'On image URL loaded' triggers once the image is successfully loaded.

    The correct way would be to put the 'Load from URL' action in the clicked button event.

    I agree though that is not a bug.