Movement behavior

NerdinaNutshellNerdinaNutshell Member Posts: 20
edited June 2018 in Working with GS (Mac)

So I recently put together a movement behavior and it works perfectly except if you let go of the right or left key (respectively) you lose all momentum (which isn’t something I exactly want) here’s a picture of the script.
https://drive.google.com/open?id=1oAccbjUvy60t9XlSEEIXV-Wptv2wUi8K (Not sure how to embed)

Comments

  • jamie_cjamie_c ImagineLabs.rocks Member, PRO Posts: 5,772
  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949

    @NerdinaNutshell Upload the project file to a file-sharing site and then post the download link. If you use Google Drive, you have to provide a link that anyone can use with permissions to view the file.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • NerdinaNutshellNerdinaNutshell Member Posts: 20

    @tatiang said:
    @NerdinaNutshell Upload the project file to a file-sharing site and then post the download link. If you use Google Drive, you have to provide a link that anyone can use with permissions to view the file.

    Okey dokey

  • JapsterJapster Member Posts: 672

    @NerdinaNutshell - Hmm....

    Doesn't make sense why it's doing that without some other rule - Have you got a rule somewhere saying if the keys are up, to stop / set to 0? - if it was adding or subtracting 200, I'd guess that was it, but I'm assuming that the code you linked should indeed work, as it's just setting to 200 or -200 - Are we missing seeing another rule for either key being back UP/unpressed?...

  • NerdinaNutshellNerdinaNutshell Member Posts: 20

    @Japster said:
    @NerdinaNutshell - Hmm....

    Doesn't make sense why it's doing that without some other rule - Have you got a rule somewhere saying if the keys are up, to stop / set to 0? - if it was adding or subtracting 200, I'd guess that was it, but I'm assuming that the code you linked should indeed work, as it's just setting to 200 or -200 - Are we missing seeing another rule for either key being back UP/unpressed?...

    I’ll share the file today so you can all of the behavior

  • JapsterJapster Member Posts: 672

    Hi @NerdinaNutshell - took a look at the file - it's as I suspected... :wink:

    You have an 'unlocked' copy of the actor in your scene, and the unlocked one contains a rule to stop him moving the instant that both LEFT/RIGHT keys are up.

    I've modified the project (you can always re-enable that 'stop' condition if you actually intend to have it included), and also added a 'tag' (Platforms), then dragged both of your platforms into this tag (you can create tags from the main 'actors' home screen) - not sure if you use these yet, but they can make a LOT of difference when cutting down logic and organising behaviours... (I have about 30 different actor types in my latest game, tagged for a single check!:-

    eg:- I use about 20-30 tags in my game, which cover every scenario - "Any Hazard Except Parcel", "Birds" (I can check if I've hit a fence bird, tree bird, owl, etc, with one check on that one TAG, instead of 3 TYPEs, and it's faster too!).. Same with bushes - I can have several different actors for bushes, plants, etc, all with custom colliders, and just use one condition to check if the parcel has bit a 'bush')... :smile:

    PS - You have walls, platforms, etc, and 2 (so far) types of platforms - I couldn't get your man to jump over the first smaller platform, so I just changed your behaviour to include those 2 newly-tagged platforms - it's maybe not what you want completely, as you still need to add logic based on what you want him to do (ie. at present, it looks like he can 'jump' up the side of platforms, but I can see that you've already set a placeholder attribute to store his vertical position).. :wink: ...but I'm assuming you want him to be able to jump while on ANY platform, so moving forwards, you can drag any new platform types you may add, that behave the same way, into this tagged group, and not have to touch a line of 'code'... ;)

    So in summary, I'll upload the modified project for you (or email it to you if you PM me your email address), and I'd suggest maybe putting the logic / fixes from the unlocked actor, into your prototype, THEN, reverting to the prototype one (as your unlocked one (so far) doesn't seem to reference anything that would make it NEED to be an unlocked one (yet). The simplest way is just to make a carrier/holder 'GROUP' behaviour, putting ALL behaviours from your unlocked actor in to this, and dragging it to the existing "Behaviours" panel, to make a portable copy to then drag into the prototype actor (assuming no SELF attributes are referenced, you can do this with pretty much any behaviour block) - If you're not sure how, I can do this tomorrow for you, but I'm now off to bed mate!

    All the best,

    Den.

Sign In or Register to comment.