PixelMonkey's Forum Posts

  • No new release yet, but I felt it was worth giving a quick update since I mentioned the 11th as a potential release date. Progress has been pretty good so far, I got the bulk of the work on the angle stuff done, so I'm well on the way to getting something released, though as usual, I'd probably best not give a date I can't guarantee.

    As it turns out, SAGE has been delayed, which doesn't really have a bearing on this, but I guess it means that if I get a template going by the new deadline (whenever that is) I could get something submitted, so at least I don't have to write that off till next SAGE.

    Anyway, this weekend will probably be taken up by the Ludum Dare, so I may not be able to get further work done for a bit yet. Thanks again for your patience, guys!

    Also, Rilem, that looks pretty cool, I've never actually put any sprites to the behaviour yet, so it's good to see it looks ok! I assume you're just setting the sprite to SurfaceAngle there, or are you interpolating things somewhere?

  • As usual I'm at least going to attempt the LD. I've been making a bit of a bad habit of not finishing them lately, but I ought to at least keep going!

  • This time round there has been a bit of progress. I'm not quite able to throw myself right into it, but my last exam for the semester is tomorrow, and after that I should have a lot more time to dedicate to things.

    I'm currently tackling the tilemaps, or more specifically tackling the way I retrieve angle so that it works with tilemaps. I'm also, by coincidence, making it work better with running off ramps. If you put a 45-degree-rotated square sprite down somewhere and try to run off it at speed, you'll notice there are issues.

    I don't quite want to put out a specific date, because as is evident, sometimes stuff happens and I can't stick to them, but I'd sort of like to have a new release and a template to go with it ready by SAGE, which'll be around the 11th of December.

    The behaviour itself will be updated here as soon as it's ready, though, of course.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Effectively no progress since the last update, unfortunately, I have been busy with other things. I have a small break in a week or so, when I can hopefully sit down and work on this for a bit. I'll be sure to post any updates here when I have them.

  • Tokinsom

    Ah, sorry, fixed. Really need to start double-checking things before I upload them.

  • Ah cool, looks like a pretty solid implementation there. There are a few things I've done differently (mostly to mimic the Platform behaviour where it doesn't remove accuracy) but it could be good for reference. Thanks!

  • KZR

    To clarify, the new Falling Angle Threshold property should be set to 46 to make this work (in the last version, this was hardcoded as 45, which was 1 degree off). With it at 0 I can see the issue, but setting it to 46 fixes it.

  • Alright, small update to the behaviour. Again, so sorry about the wait. Had I known I'd be this busy I'd have waited until I could provide more regular updates.

    Changes:

    Air drag now works

    Simulate Jump now works again

    Can now specify an angle threshold for when the downhill slope factor will have an effect.

    Issue with 45 degree slopes locking controls fixed

    KZR:

    Found that slope issue you were talking about! When the object stops moving on a slope (assumed to be because it's too steep) the engine locks horizontal controls for a fraction of a second while the slope factor kicks in and pushes the player downhill a bit. Generally this is a good thing, since you don't want the player on a slope they can't walk up just pushing against it, but with slope factor disabled (which I'm assuming is what you did?) and when on a 45 degree slope (also assuming you did that) it triggers the lock, doesn't push the player down, and just sits there counting down the horizontal control lock and repeatedly triggering it again when it hits 0.

    The threshold for the angle is 45 (non-inclusive), but with swapping between radians and degrees being a little unexact it's counting 45.0000012522 as being above 45. Which it is. I've changed it so it's a parameter defaulting to 46: FallingAngleThreshold. If the slope is shallower than that, falling off should not trigger. Should fix the issue as it currently is, as well as allowing some fine-tuning if it still presents a problem.

    There are a couple obvious issues still present that I really need to work on (including tilemaps, which I will get to, I promise!), but if I'm honest I'd still expect things to be a little slow on my end for a bit longer yet. Please keep letting me know if there are any issues, and I'll try to solve them as soon as I can!

    Also, regarding rotation and the Set Angle property, I've had a quick go at it and ran into issues reliably moving things around so as not to clip a non-square bounding box into terrain or off a slope it should be sticking to. It isn't ideal, but as a workaround I'd recommend keeping the collision poly for the main object square, and overlapping another object with a non-square poly if you need one for other collisions.

    I'm getting to the point where my inexperience with some of this is showing, so if it comes to it, please bear with me as I try to refactor things to make future changes more feasible.

  • KZR:

    Yes, sorry, I've fixed the jump issue and added an air drag effect already, I just want to do a couple more things before I release an update. Sorry for the wait!

    R0J0hound:

    Ah, cool, that should be helpful, thank you!

  • KZR:

    Ah, sorry, I misunderstood you. The sim jump issue is definitely something I can reproduce, and I can have it fixed by the next release. For the slopes, have you changed the downhill slope factor then?

    Azu:

    Eventually the Set Angle of Gravity action should be able to manage things like that, though I need to go back and change a couple of angles to be relative to that.

  • Momio: To be fair, the Sonic Physics Guide is the main thing that make the physics accurate.

    KZR: Still can't replicate the issue. Is it happening in the example capx? If not, could you give me one where it is happening?

    My weekdays have been fairly busy (and probably will be for a few months more unfortunately), so my general plan is to work on things on the weekends, releasing an update on Sunday evenings if I can get anything substantial done.

    That said, I might not manage to release anything by tomorrow. I'd like to address the tilemap issue in the next release, but I haven't made as much headway as I would have liked today. I guess I'll see how tomorrow goes.

  • Ah yeah I saw the Sonic Portal thing on Retro, didn't have an account at the time though. From those videos it certainly looks like you had much more success with the event-based approach than I did. Looking forward to seeing what comes from that!

    KZR: Is it something you can reproduce reliably? I can have a look at it, but I haven't had any noticeable issues on slopes myself.

  • Yeah I'd certainly say so. As far as I can tell I've done things in much the same way as the Platform behaviour, so there shouldn't be much impact.

  • Candescence: Thanks! I've had 2 or 3 attempts at making an event-based system myself, but the whole thing failed to hold up with even the basics, and doing it via a behaviour seemed far more sensible and user-friendly.

  • Thanks! Yeah, no events yet, though I'd like to add some as some examples of extending the behaviour via events like you would the Platform behaviour, but for the essentials it's as simple as assigning the behaviour to a Sprite!