PixelMonkey's Forum Posts

  • —

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

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

    >