PixelMonkey's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • You'll want basically just:

    Sonic: On collision with Bumper:

    -Set Vector X to 420 * cos(angle(Bumper.X, Bumper.Y, Sonic.X, Sonic.Y))

    -Set Vector Y to 420 * sin(angle(Bumper.X, Bumper.Y, Sonic.X, Sonic.Y))

    The Sonic Physics Guide, particularly the Springs and Things page, gives some more numbers and info, but you'll want to update most values from pixels per frame to pixels per second.

    ^ That said, though, I tried it out myself, and I've recreated TheAmazingApple's bug in the process. Unless you're holding down the jump button, it caps your speed to Min Jump Strength. So the above example events currently won't work unless the jump button is being held down.

    If you wanted a really hacky workaround, you could simulate jump button under certain conditions to stop the behaviour from limiting the jump, but I realize that's pretty terrible.

  • The way it works is to offset the position by 1 so the object is overlapping the ground, and then figure out which segment to check the angle for.

    You could probably achieve something along those lines by shifting the object down until it hits the ground, checking the angle, and then pushing it back up again, although looking at the plugin as it is now it seems there isn't a way to specifically trigger the surface angle check. I might make a note to add an action to recalculate the surface angle.

    Another alternative could be to have a sensor object sitting on the ground and following the object above, though keeping it on the floor nicely could present issues, depending on the terrain.

  • Ah, thanks for the feedback!

    For the first issue, it turns out that's a very quick fix, just a typo. It'll be working whenever the next build releases.

    For the springs, how have they been implemented, and what specifically do you mean by "wouldn't go as high"? The initial thing that comes to mind is that the variable jumping could be messing with it, which could be fixed in a couple of ways, but I'll probably need a couple more details.

    As for the third issue, I don't understand entirely. Would I be able to get a screenshot of what kind of terrain the issue is being caused by? And what do you mean by trying to walk onto the gap?

  • Alright, so another status update, probably the last for the short-term. As mentioned previously, most time spent on this recently has been for replacing the way retrieving surface angles work. As of recently I managed to finally fix all the issues I was having, getting things to effectively the same point as the previous release, just easier to expand from, in theory.

    The current issue, though, is that now that I've started trying to actually add things (namely rotation and tilemap support) I've started uncovering more bugs and edge-case scenarios.

    Now, I'll still eventually get to the point where I can fix these, but A: running up against MORE BUGS after spending all this time on just getting back to square 1 is demotivating, and, more relevantly, B: university has started again.

    It's not really fair for me to keep saying "soon, I promise" since it's already been like 6 months, so this is effectively notice of a hiatus in development for the behaviour, at least for a few months.

    I still intend to continue work on this eventually, I'll continue adding any bug reports or feature requests to the todo list if anyone has anything, and if anyone needs suggestions for workarounds in the meantime I'm happy to give suggestions, but I thought it'd be only reasonable to let you guys know that development isn't speeding up quite yet.

  • Thanks! As long as it can end up as at least a viable alternative I'd be pretty happy.

  • Well this is a first, I think! Two tied themes: Two Button Controls, and Growing!