dop2000's Forum Posts

  • Check collision polygons and origin image points of your sprite. Ideally the collision polygon and origin image point should be the same for all frames/animations.

    Incorrectly positioned image point on a single frame could trigger unexpected falling/jumping/collision events.

  • The only way to do this is to add an instance variable "type" to the family. Set type="A" for sprites A, type="B" for sprites B etc.

    Then you will be able to pick family members by type and loop through them.

  • What do you mean "no longer working"?

    Tokencount works and you can use it to validate email address format, but you need to create several conditions:

    tokencount(emailText, "@")=1

    tokencount(emailText, ".")>0

    tokencount(emailText, ",")=0

    tokencount(emailText, " ")=0

    etc.

    Those are some basic checks, if you need a more strict validation, you can create a string of all characters that are not allowed in email and do something like this:

    charList="`:;'<>,/?\"   <-- this is just an example, not the actual list of restricted characters
    For x=0 to len(charList)-1
       tokencount(emailText, mid(charList,loopindex,1))=0
    [/code:1sinvf5u]
  • First line determines zoom level - from 1.4 for stationary (zoomed in), down to 1 when player's speed is equal to layoutWidth (zoom 100%).

    If the player is moving even faster, zoom can become <1. I didn't want that, so I added zoom=max(zoom,1)

    I don't like this zoom effect either, you should definitely play with the values or camera speed etc.

  • Yeah, you need to be careful with the void

    Frankly, this is the first time I'm playing with smooth zooming/scrolling. I should add something like this to my game.

  • There was a similar post recently:

  • You mean something like this?

    Screen zooms in (up to 1.4) when the player is stationary and zoom out when moving (down to 1).

  • I live on another side of the globe, it's not very late here yet

    I changed too many things, but I think it works much better now. It doesn't allow to stay on the wall for too long and the height of wall jumps decreases with every consecutive jump.

    You'll see in 4 hours

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I don't see any ghosting either.

    Maybe you have motion blur enabled somewhere in your video card settings?

  • [quote:2us7wkbf]I wanted to implement a limit to how long people can walljump in a way that feels natural but you can stay on the wall infinitely just holding against it and tapping away

    Sorry, your wording is a bit unclear - do you want to allow players to stay on the wall infinitely? Or is it a bug and you want to get rid of it?

    I made a few changes, have a look:

    https://www.dropbox.com/s/c7wfnichstid7 ... .capx?dl=0

    It still may need some tweaking, also you can move repeating code to functions.

  • Ok, for starters:

    1) You have two PlaceInInventory functions. Delete the duplicate one in Logic group.

    2) You need to add InvCell sprites to your layout. Don't forget to set correct value for Order instance variable for each cell.

    3) In lines 42 and 44 change Item.animationFrame to Collectibles.animationFrame

  • [quote:2cbt7wck]this isn't stopping the problem of being able to hold against the wall and just slide up it without leaving the wall

    Do you mean when it's sliding up the wall for about 100px before it starts falling down?

    I think this is not because you continue to hold any button, but because the jump is too high - you decrease the gravity by more than a half, so the character keeps accelerating up.

    The way you are disabling buttons by adding another condition like "wallToLeft=0" is perfectly fine.

  • You can change the "Pick player by UID" event in my demo with "For each player".

    Not sure what are you trying to achieve, could you give more details?

  • I'm sure it's possible, but I can only speculate what you are doing wrong.

    Your current two animations (attack and shield) probably "overwrite" each other, because they include movements of all body parts. If you make attack animation to only move one hand with a weapon, and shield animation to only move another hand with the shield, then you may be able to play both simultaneously. You'll probably need a third animation for the remaining body parts.

    But again, this is only a guess, I may be completely wrong