[Solved] Preventing a character from changing direction while still moving.

enginenumber9

  • Posts: 11
Hello all,

I'd like to prevent the character from changing direction while still in motion.  I created a global variable called 'playerMoving' that is initially set to false.  As long as it is 'false' then if the player presses a button, they will move.  Once they start moving, the value is set to 'true' so that - I was hoping - further button presses would have no result until something sets the value to false again. 
This is not the case.  I can change direction any time I want.

There is no interference from other behaviors at this point.  The only other behavior I have right now just keeps the player in bounds of the screen and sets 'playerMoving' to false when they reach the border.

« Last Edit: March 25, 2013, 08:01:13 pm by enginenumber9 »

SpookyBurger

  • Posts: 82
Have you closed/re-opened stencyl?  Also a screen of the other behavior that turns "playerMoving" to true would be nice.
Please try out my latest build of Patient 9 here.   http://www.stencyl.com/game/play/23179

The8BitMan

  • Posts: 424
This code looks alright. I think it must be the other behavior that has a problem. Can you give us a screenshot of that please?
Need music, graphics, scripts? Just ask!

Red Frostraven

  • Posts: 23
1: Revisit the code that turns True to false and post that

2: Check if the global variable is set to boolean (true/false) or number (0/1)

enginenumber9

  • Posts: 11
Attached is an image of the behavior that keeps the player on screen and sets the value to false.  Thank you all.

enginenumber9

  • Posts: 11
and here is an image displaying the attribute type as boolean.

enginenumber9

  • Posts: 11
More specifically, when the scene begins, the value of playerMoving is set to 'false'.
On the player's initial move, they can not alter their direction once one is chosen.  However, once they come to a stop (by contacting the edge of the screen) and then they try to move again, they are able to re-direct once before their direction locks. (undesirable)

Example:

1. Scene starts
2. player presses right arrow
3. character moves toward the right side of the screen - player can not change direction with additional button presses (good)
4. character stops at the right edge of the screen
5. player presses left arrow
6. character moves to the left side of the screen - player CAN change direction once with an additional button press before the direction is locked (undesirable)
7. every move from here on out is executed in this manner.

Red Frostraven

  • Posts: 23
This is officially a matter for the console.

Add a "print" block to each and every step that can set the boolean to False, and have it print:

"Something that tells you what trigger is triggered"

And you should probably set it to print every step that can set the boolean to true, too -- and have it print the value of the boolean in the same go, using the "text + text" block -- where one text field contains the block GetActorValue[PlayerMoving]

yngar

  • Posts: 22
I see what your problem is. On the left and top sides of the screen your code is setting the player to 1 and thereby making the player moving variable true again.
The code only makes moving false while the player is at 0, but it moves him away from the 0 coordinate while it does so, so the player is only at 0 for one frame, then he is at 1 and its true again.

enginenumber9

  • Posts: 11
Thank you Red.  The printing to console was very useful.  I had never used it before.  Well, the project now functions as intended.  The difference came down to the directional controls being set to respond when the button "is down" rather than "was pressed"

And thank you yngar.  While that issue did not effect the functionality I had posted about, I did notice after correcting said functionality that when the character was stopped at the edge of the screen, the console kept printing out 'false' values.  I thought: 'that doesn't look very efficient' and realized that my 'keep onscreen' behavior, while keeping the character in bounds, never actually sets the respective x or y speed to 0. 

With these corrections in place I am ready to move forward with the project.  Thank you both again.