HermitUK's Forum Posts

  • 5 posts

  • Apologies; Google drive link: docs.google.com/open

    Should add that I checked this in Chrome, FF and IE, and it occurred in all of them.

  • There seems to be an issue with sprites being drawn one pixel too high at certain times with platform movement:

    <img src="http://i47.tinypic.com/2a4o67r.png" border="0" />

    In the enclosed CapX you'll note in the layout the player object is clearly touching the ground, but will be one pixel higher when the cap is run. If you jump, the collision starts working correctly again. The bug also occasionally re-triggers when transitioning from the slopes back to the floor (Try moving back and forth a few times and it'll happen)

    Thus far I've tried fiddling with Pixel Rounding on and off, but it occurs either way. Only workaround I can find at the moment is to make the collision box smaller, but this causes the sprite to appear to sink into the ground slightly when the bug is not present.

    CapX:

    docs.google.com/open

  • > Actually I prefer Control+v to a painting type of action, as painting will often add multiple objects all in one place.

    >

    But of course the painting action would not add more then one at the same place... It wouldn't even have to be painting. Just clicking the sprites out would be better then it is now.

    for that matter, you could have a toggle box that prevents you putting another sprite into a grid square if there's already one there on the same layer - A similar function to "Preserve transparency" in a lot of image editors.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • there actually is a sustain jump check box somewhere in the properties bar.

    > The lack of a sustain meant it was impossible to get up after grabbing a ledge with my ledge grabbing code.

    >

    I've made plenty of working ledge grabbing examples, the simplest way of getting up is to trigger another jump when your player is on the edge.

    Yep, that's exactly how I'd set it up. However, originally I had a small jump strength with a fairly large amount of sustain time. Since sustain jumps do not trigger from a "Jump" action, the jump strength alone wasn't enough to get up. Essentially I dropped the sustain entirely and increased the jump strength.

    Cannot find the checkbox you mention - There's a Jump Sustain Time and a Jump Sustain Gravity values in the Behaviour, but no way of making the plugin trigger the sustain off of a custom jump (As in, one handled by the "Jump" action instead of by the Behaviour itself). To be clear - Jump Sustain functions fine when jumping from a solid object, but not if you're in midair and force a jump through actions.

    [quote:3i4p6824]I believe the additional x/y velocity action is being implemented by Davo (the plugin's creator) in the near future.

    That is good to know, thanks :D

  • I've been working on a new platform game project recently (loving Construct, by the way), and there's a little list of extra features that it'd be great to see added. Some of these have been suggested before, I think, but I didn't want to bump two or three seperate topics.

    1. Any plans to add a "sustain jump" action, or at least allow mid-air jumps to be sustained?

    The lack of a sustain meant it was impossible to get up after grabbing a ledge with my ledge grabbing code. I did try sticking an invisible solid object under the Player to trick the behaviour into thinking he was stood on the ground, but it wasn't really ideal. In the end I've just disabled the sustain jump, which is a shame. Back in MMF, triggering a "User is holding jump in the air" action was a quick and easy way of programming in a jetpack, too :p

    2. Is there likely to be an "additional x/y force" option added in? Again, this was a nice feature in MMF. As it is, it shouldn't be too difficult to program this in manually using timedelta and some calculations, but it'd be cool to see the option there.

    3. When you change the direction of gravity, the player controls don't change.

    In other words, while on the ceiling pressing Move Left moves you right (Which is left from the point of view of being upside down), and vice versa.

    Would it be possible to have some sort of setting to allow context-sensitive directions? For instance, when gravity is on the left or right, the Move Up and Move Down controls will move your character up and down the wall (Which, from his perspective, is left and right). At the moment this movement is controlled by Move Left and Move Right.

    Again, this isn't too hard to fake, at least for the ceilings (I just set the gravity to a negative number). And it may be this is in there somewhere and I missed a tickbox or something.

    4. Finally, can't really tell if this is a feature or a bug, but if my decceleration is higher than my acceleration, the acceleration is ignored entirely. In other words, you'll accelerate at your decceleration speed.

    Edit: Should probably mention that I'm using 99.5 at the moment.

  • 5 posts