How about have a dummy invisible object that you move to that location and see if there's an overlap? The above code won't work properly (although the idea is valid) because X and Y will rarely be an exact integer number, plus what if there are other object types that you want to check for?

System: pick overlapping point might do it too.

— unless I am mistaking, this particular exemple is a free, non ads powered game.

ome6a1717

"It seems silly to try and build a whole new editor from the ground up that functions the same as the current editor they already have. Don't mess with perfection!"

it is not the case actually, for the most user, the difference may be not that huge (apart from working in more OSes, which I can understand perfectly as windows only is still a pretty weird decision for an engine that exports everywhere basically), but basically they will be able to correct most UI bugs they have, to implement the basic features they cannot currently (zooming in and out inside the tilemap window for exemple is the most basic thing I can think of), and plugin developpers would be abme to make their plugin works correctly and do much more than what they are currently doing, and perhaps be more emphasise with a "in program store" plugin, as currently 3rd party plugins are kind of a "use them but if they do not work, or if you need help, good luck with that as the author of it may be the only one to assist you".

they are tied up with the limitation of how they did C2 as far as we saw on the forums

It is a weird way to handle it I might admit, every other behavior seems to detect the collision then push back just outside of the solid, not to the previous position, also nothing in the manual seems to state that the behavior stop before reaching the solid, it just says it is blocked by them, which means that it would be expected that it just does not enter the solid itself. Not that it reacts accordingly beforehand to not go towards it before even reaching it.

it just feels wrong.

Sisyphus may I ask if the 8 max collision point issue is still present?

Aphrodite That is interesting. I did not try replacing the tiled backgrounds with sprites. I tried to keep it in the scope of what you made, assuming you had a reason for using tiled backgrounds instead of sprites. Perhaps it is indeed a bug. I noticed even when it stops short, you can press again and it will continue until it touches. Perhaps you should try replacing the "8 direction" behavior with another movement behavior, eliminating the "Move" variable, and see if the result is the same.

Well the only thing stopping it is the fact On collision triggers, and as we can see, it should not trigger in that case (since the bounding boxes themselves are not overllaping, so the collision is 100% impossible in that case), that is the bug, it seems that solid has to be setted on the walls, and that it happens with 8 directions behavior only (though I could be wrong).

I do not think I need to go deeper, as this is a bug in my mind and so there is no reason to take it as a "side feature" that we should explain, waiting the opinion of ashley to know if it has to be fixed or not.

http://www.construct3.com

Time to shift your focus, people

kind of quick, but I guess, since they posted it on twitter, that it is ok, and if people can be involved in alpha and beta, why not.

As far as I know, any kind of browser is able to play C2 games, while I think of it, pretty much the package.nw file exported with node webkit by C2 is what contain the game, so if a similar thing would have to be done, it would be to just have node webkit selecting the good file to play in the end.

However not sure how that would work with steam itself being in the party.

TheDom as expected, a tiledbackground collision polygon is equivalent to a rectangle, and I tested it, it still happens with a sprite with solid on it.

"I'm sure Ashley could elaborate better as to why the Tiled Backgrounds work differently as solids than sprites since you have no ability to draw collision polygons. "

They work indeed differently, as tiled background can only have a rectangle collision polygon, however they still react the same as sprite with a rectangle collision polygon (in this case too).

So definitively a bug I think.

This bug is also disturbing since I saw it originally as 8 direction fast moving objects tends to stop then move again when approaching a wall. But anyway, the fact it is solid or not should not change the way "On collision triggers" this much.

You know, if only someone from Scirra put these things into their blog posts/promotional e-mails or similar - perhaps these problems with an important element of their desktop deployment system would get sorted faster... Just a thought.

They did postede it on twitter 4 hours ago, but I get what you mean, a sort of listing of what to star to help and why would be nice to have sometimes, as it is kind of hard to keep up for the people that are not versed into browsers bugs reports systems.

Problem Description

As we all know from the manual, Jump-thru does not support slopes, yet it does and that means trouble for the normal use..

Attach a Capx

attached

Description of Capx

the capx shows some "Stairs" made out of jump thru, and a slpe with a jump thru, it is not supposed to be supported, however that is not the stair themselves the point, it is here to show how the bug actually works.

when you run off a platform, then come back quickly, you can sometimes climb back on it, I bet this phenomenon is due to the same effect that makes those stairs works, normally, you run up a jump thru, you should just fall inside it, here, you can climb those stairs (if that is not consistent enough, the slope should show you that this works).

This is a bug, as you should not be able to climb on a jump thru by running on its side (and slopes are not supported either, so you should just fall), this is troublesome when the player is falling off a jump thru but goes back quickly and climb on it back, sure there are workarounds, but using them is accepting the bug, which I cannot do.

Steps to Reproduce Bug

• run up the stairs
• run up the slopes
• if you like testing it, set the max fall speed to something like 3 or 10, go off the jump-thru, wait so you are just a little off, then come back on it, that is the actual bug!.

Observed Result

stairs works, and you can climb back on a jump-thru

Expected Result

slopes and stairs not working, passing right by the jump-thru

Affected Browsers

• Chrome: (YES)
• FireFox: (Untested)
• Opera: (YES)

Operating System and Service Pack

Win7 home edition

Construct 2 Version ID

r195

Problem Description

The capx have 2 objects: Blue which is a sprite with 8 directions, and Solid, which is a solid tiledbackground, when it enters in motion, it should stop when he collide, or that does not happen.

Attach a Capx

attached

Description of Capx

when you push up, down, left or right, Blue has a variable change, which simulate a control constantly until he collide with something, or so we though, the on collision triggers while the collision has not occured yet (you may see it being slightly off, like there is a space between blue and solid when it stops), if you increase the max speed and acceleraton by a factor of 10, sometimes the gap is huge.

Steps to Reproduce Bug

• Open capx and run it
• push and release right, left, up or down
• See the gap between blue and solid

Observed Result

Blue stops before colliding

Expected Result

Blue to stop when he was against Solid

Affected Browsers

• Chrome: (YES)
• FireFox: (Untested)
• Opera: (YES)

Operating System and Service Pack

Windows 7 home edition

Construct 2 Version ID

r195 (current stable)

I saw it a long time before but never reported it for some reason.

Perhaps it is expected, but I think not.