—

Sorry for the delayed response, I don't frequent the construct forums much these days. I'm not particularly sure how you're implementing rolling animations and such, so I don't have any feedback specific to your issue, but I wouldn't be surprised if there's issues with the various roll conditions/actions/etc. My best suggestion at this point is to track this kind of thing manually via events, for example checking when the player uses whatever key you have rolling assigned to, and using that to trigger rolling animations, the proceeding to check things like player speed to go back to non-rolling animations.

Slug101

I won't be porting the plugin to Construct 3 as a subscription isn't currently an option for me. The plugin is in something of a poor state, where it really needs to be overhauled. Since I don't have the time to do so, the plugin is no longer being worked on.

XtremeBlueTronic

Right, I see what you mean. Definitely a bug, but I'm not really sure how specifically I broke it, and with the mess that the code is in I don't really have the time to dive in and try to fix it, sorry.

XtremeBlueTronic

You can do this by using the "Simulate Control" action.

Something along the lines of these events should get the effect you're after:

The second condition makes it so that you'll only get the effect of the spring if you hit it from above, but you can remove it if you want to be able to walk into a spring from the side.

So, a double-post, but I think it's about time I gave a clear verdict one way or another regarding this behaviour:

In its current state (and considering my current circumstances) it's safe to say that I'm unable to continue developing this.

I haven't wanted to outright say "no I'm not working on this anymore" because the longer I went without updating this the worse it would look and I'd hoped to make at least SOME progress, but it's been so long that I think the lack of progress has given enough of an indication of disinterest, so I might as well make sure it's clear rather than just implied.

To lay out a few of the issues and give a general indication of why:

In terms of code, the plugin is a mess. This was my first time touching javascript (and before starting this I hadn't done anything more complicated than event-based programming, hence why I was using C2 in the first place) and it clearly shows. It was a learning experience, sure, and I've learned enough that I know WHY it's messy and WHAT I did wrong, but taking that knowledge and fixing what are very fundamental issues isn't something I have time for anymore.

Between the messy code and my inability to commit time to this, it became difficult to make any proper headway at all, since most development was in very isolated chunks. As time has passed it's only made it harder to look at the code and not simply see a demotivating brick wall.

I've made a couple attempts here and there to sit down and finish a couple of the bigger bits on the todo list (tilemaps, basically) and between either a lack of skill/understanding on my part or me simply trying to twist bits of C2 that weren't quite intended to be used for this particular thing (or at least not in the way I'm trying to do it) it just keeps falling apart. So I'm afraid I don't have a nice final clean "no-longer-blatantly-unfinished" update.

So yeah, it was still a fun little project, and I've been pleasantly surprised to see how much use people have squeezed out of it. Maybe I'll have a go at a more reasonably-scoped project in the future, see if I can make something a little more complete.

Thanks again for the feedback/interaction.

lavareef

Basically no progress lately. I have the time to keep mostly up-to-date on the thread and answer questions, but the first half of 2017 has been the busiest semester at university I've had yet, so I more or less decided to put the behaviour aside entirely for the last few months. Might pick it up again soon, have a bit of a poke at putting another update together, but we'll see.

lavareef

If I recall, it was just to try and simplify the behaviour a little, as well as to possibly simplify the min/max jumping that I replaced jump sustain with. The idea was to eventually replace it (either via events or the behaviour itself) with all the various air actions (flying/gliding, S3K elemental shields, maybe the drop dash). As is, the various actions can be replicated via events fairly easily, I think.

lavareef

Good question, though not one I have an answer to yet. I don't know if anything much has been said about Construct 3's addon support yet, so I don't actually know what the process will be like. I don't assume it'll be unreasonable, though, so I don't see that as an obstacle. That said, time always has been and probably will always be an issue on my end, and on top of that I'm still undecided whether or not I'll be upgrading to C3 myself. The subscription model doesn't particularly appeal to me, and while I'm interested in seeing new features to come, none yet seem to justify the cost, personally.

So short version: May or may not upgrade to C3, may or may not then have time to convert.

If it did happen, though, I'd probably try to keep both 2 and 3 supported, unless 2's userbase drastically lowers (which I don't expect would happen overnight).

lavareef

Hm, yeah, jumpthrus have a few issues. I'd noticed similar issues before, and it seems to boil down to the behaviour not being able to pick which jumpthru to stay on when sticking to a slope. Another related issue is when moving in the other direction and the behaviour decides to not notice the upwards slope and treat it as a background object. From playing around with the standard Platform behaviour, it seems like this is an inherited issue that mostly occurs at low speeds (such as in your example when letting the behaviour move down the slope on its own).

In all honesty I don't see myself having time to fix this particular issue quite yet. I've still been chipping away at things in my spare time, but this is a fairly fundamental issue based around how jumpthrus are handled. When some of the more essential features are done (like tilemaps, which I'll still get to soon, I hope) I might well see if I can find a solution that works better for this behaviour, but for the time being, I'd recommend making jumpthru slopes all based on one object (like the chunky purple slope blocks), or simply cutting down on jumpthru slopes (which isn't ideal, I'm aware).

patchester:

The latest version that's in a releasable state is in the opening post. I notice that the example html isn't working now that Dropbox has changed the way they do things, so I'll need to get that sorted out at some point, probably switch to itch.io. I have been working on an update, but there's still some more changes that need to be made before it's actually usable.

Problem Description

When a Platform behaviour object walks off an object while overlapping a Jumpthru (or walks down a slope while overlapping a Jumpthru) it will be moved downwards further than it should, resulting in a noticeable jolt downwards.

On a similar note, while walking down a slope, while also overlapping a Jumpthru, the Platform object will be embedded in the ground until it is no longer overlapping the Jumpthru.

The issue appears to be at lines 791-2 of the Platform behaviour's runtime.js. When the behaviour checks whether it is overlapping a Jumpthru, it does not check whether it was overlapping previously. If, in this case, it walks off an edge while overlapping a jumpthru, it moves the player downwards, attempts to push upwards (including jumpthrus), and when it fails to push upwards it doesn't move the player back.

I've been developing a behaviour of my own that also has this issue, so I've already attempted to fix the issue for my own use, if it helps simplify things: here's the runtime.js.

In the checks at around line 690, if you hold on to the overlapping Jumpthru instance, you can then check further down, just before the push that fails (line 794 onwards in example), to see if it's still overlapping after moving downwards pre-push. The vertical push can then be changed to only push out of Jumpthrus if there's still a valid one.

Attach a Capx

Capx

Description of Capx

This capx contains an object with the Platform behaviour, a few Solid objects, and a few Jumpthru objects that overlap areas where the player can walk.

Steps to Reproduce Bug

• Step 1: Run capx
• Step 2: Walk off Solid
• Step 3: Walk off lowest Jumpthru
• Step 4: Walk downhill along Solid slope, through lowest Jumpthru

Observed Result

When walking off the ledges, for a single frame the Platform object moves noticeably more than it should. When walking along the slope, the Platform object clips into the ground for as long as the player continues to move and overlap.

Expected Result

In both cases, normal vertical movement is expected, without the player object being pushed lower than usual.

Affected Browsers

• Chrome: YES
• FireFox: YES
• Internet Explorer: YES

Operating System and Service Pack

Windows 7 Service Pack 1

Construct 2 Version ID

r236