trueicecold

Right, ok. I'm assuming what you're referring to is also visible in Rilem's example, where Sonic goes from being slightly embedded in the ground to being slightly above the ground at the corners of the inverted loop?

That's something that's part of the whole rotation thing on the todo list, so eventually the behaviour should provide a simple expression to retrieve X/Y values to offset the display sprite by, but for the time being, try using something along the lines of this:

Also of note is that when doing the above, if your main Sprite is a square you shouldn't need to rotate it at all, as in the example capx.

Still a bit messier than just an expression (and could be refined further) but it addresses the main problem, I believe?

EDIT:

Oh, and the base offset value there assumes you're using a 32x32 sprite. If you're not, the value should just be the difference between the width (or height) and the diagonal of your sprite.

trueicecold

The behaviour is meant to automatically jump off the end of the ramp, assuming the angle is sufficiently different (since you don't want the behaviour losing its grip on an ordinary downhill slope). The bug that's causing it to not do that, however, is that when the sprite is sitting on a solid's corner it still thinks it has the uphill angle, rather than either swapping to the downhill one or 0. It's an unintended consequence of the fact that Construct 2 uses collision polygons for collisions, while the original games had a single sensor in the middle used to retrieve angles.

After I fix the issue I'm planning on adding a property that allows the stickiness threshold to be specified, but for the short-term I'm afraid I don't have any suggested workarounds. You could potentially try and force the VectorX/VectorY, but that would probably get very messy very quickly.

trueicecold

Thanks, appreciate the feedback!

Rotation is indeed on the todo list in some form. After trying a couple of things it seems like the most straightforward way is to keep automatic rotation to 90-degree intervals (which, as I understand it, is how the classic Sonic games handled it anyway). This will still probably require the user to define the left and right corner points that they wish to rotate around (though it'll probably default to the bottom left/right corners of the bounding box for simplicity's sake).

Regarding your second question, I'm not entirely sure I understand. Collision polygons are limited by Construct 2 itself to be made up of segments, rather than being truly circular. That said, I don't think the limitation is too much of an issue. The example capx has curved surfaces made up of only a few segments, but even that is enough to give the illusion of a curve.

If, however, you're rotating the sprite with the behaviour itself, then I can see where you'd be having issues. In the current version of the behaviour, the base sprite should be kept unrotated (or rotated manually only at 90 degree intervals). I'd recommend making the base sprite invisible, and overlaying another sprite used purely for display purposes. Rilem had a brief example that seems to work reasonably well:

>

> > Good luck, can't wait to see this finished.

> >

> >

> How'd you get the surface rotation to work here exactly?

>

lavareef

No worries, the support is appreciated.

As far as the exe wrappers go, I'm not really in the loop. My understanding is that there were some issues on Chromium's end for a while that have since been resolved (though that may have been another matter entirely?), so things should currently be in working order, I believe.

lavareef

As long as the work is your own IP (basically what Freedom Planet did) then I don't think there would be any issues. Regarding selling the behaviour, the way I see it is that I've built this behaviour off of the Platform behaviour and the freely available Sonic Physics Guide, so I wouldn't feel comfortable selling it. Besides which, the Sonic fangame community has a pretty long history of engines and templates provided for free, and I don't really think they'd care to purchase it with so many free alternatives out there. Having the behaviour (and the template that I eventually plan to make to go with it) free means it's more accessible for people to just pick it up and play around with it, which is the end goal here.

As far as other plugins go, nothing to specifically go with this, I don't think. I'd like to have a go at a grapple hook/swinging behaviour to go with the Platform behaviour (and by extension, this too) at some point, but that's a fair way off I think.

Poxnixles:

Thanks for pointing that out, I'll get it right the first time one day. Fixed, I think.

Poxnixles

Looks like it has been reported before, way back in March, actually, and I've just been slow about getting to a bugfix release. Has been fixed, thank you.

MatheusCastellar

Thanks, though it's worth noting that I've been using the SPG since the beginning of this. Awesome resource, essentially fundamental for this kind of thing. Now that I think of it, though, I ought to have that linked in the main post.

And so now that I'm sitting down and responding, I can see that it's been more than a year since I first released this, and getting close to a year since any kind of actual update. I apologise, I've been more caught up than I realised with work and uni. I genuinely appreciate the patience, especially as I seem to be still getting bug reports every now and then despite my lack of progress here.

While I still haven't had time to fix some of the more fundamental issues that have been bogging things down, I've made a long-overdue bugfix build, and updated the opening post.

Changelog:

-Set Soft Max Speed now works

-Vector Y is no longer capped to Min Jump Strength if jump button isn't held (will allow springs and bumpers to work)

-Rolling Jump Control Lock now functions if enabled

-Removed Is Double Jump Enabled condition

Feedback is still appreciated. If there's anything clearly broken I'll try to get to it ASAP, though I unfortunately still can't give an ETA on much-needed core improvements (such as tilemaps).

patchester

What kind of slopes cause this issue? Does it happen anywhere in particular in the example?

patchester:

Yep, tilemaps are still not working. It's one of the higher priorities at the moment, though. Would you be able to give me more details on that second issue?

patchester

As far as I know, the behaviour shouldn't really change the way either of those things work in comparison to the Platform behaviour. The standard events for collisions and overlaps should still trigger under the same circumstances, and if you have a "is key down" condition followed by the "simulate control: jump" action, that should mimic the default controls.

TheAmazingApple

I believe that's on the todo list, but noted, thank you. Worth clarifying, though, that I've deliberately removed the double jump functionality for the sake of not filling the properties section with more than is necessary, since double jump functionality is fairly straightforward to implement. I see that I missed the actions/conditions related to that, though, and I assume that's what you're referring to?

TheAmazingApple:

I think I'm following a bit more clearly. Sounds like an existing issue that I've been trying to redo the angle system for regardless, so hopefully when I fix the issue I know of it'll fix yours by extension. The behaviour doesn't cope well yet with more complex surfaces and intersections between multiple angled sprites, since it currently all boils down to choosing a single segment to stick to, which doesn't always act as you'd expect it to. Working on this has given me a fair bit of insight as to how complicated this can get, even if not yet how to actually make it work, haha.

Zebbi

Actually, I'm pretty sure the standard Platform behaviour could get you a close match to Mario physics via events. I'm not as familiar with the Mario games as I am with Sonic, so there could be some subtleties that'd need to be mimicked, but sounds to me like it'd be more waiting on someone to make a capx than a behaviour. I do recall briefly looking for a Mario equivalent to the Sonic Physics Guide a while back, though, but I didn't have any luck. Anyone know if something along those lines exists?