Jump to content
  • Advertisement
Sign in to follow this  
Ovicior

Unity Increase Unity Movement When Holding Shift

This topic is 1118 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement

You just have to check if the "sprint" (or how you call it) key is down, and if so you you want to increate the "speed" varaible value a bit.

 

There are similar and a bit more complicated things in the code already(that's why i'm not posting the actual code)... 


PS:
I think that it's unit?ys and (community) fault that you don't know that you already know how to do it..

Share this post


Link to post
Share on other sites

You can also go further using an interpolation to not have directly a change of speed but smoothly change.

 

I think that it's unit?ys and (community) fault that you don't know that you already know how to do it..

Maybe he thought an automatic thing was already there in Unity about CharacterController, this is not a good link with the question to me.

Edited by Alundra

Share this post


Link to post
Share on other sites

You just have to check if the "sprint" (or how you call it) key is down, and if so you you want to increate the "speed" varaible value a bit.

 

There are similar and a bit more complicated things in the code already(that's why i'm not posting the actual code)... 

PS:
I think that it's unit?ys and (community) fault that you don't know that you already know how to do it..

I've tried

if (KeyDown.Shift) {speed == 8.0F;}

(Note: not exact code. Just example. This will not work in Unity.

Share this post


Link to post
Share on other sites

Your code doesn't look all that wrong outright, other than it's a little strange that you're setting the speed variable after you've already used it.  But that should be fine, since its' a member variable, and it just means you'll always have a one frame lag from when the key is pressed to when the movement happens.  And you also can sprint when in the air, which is a little weird.  I would move that 'if(shift) else' speed modifying code to inside the if(grounded) and before using the speed variable.  (Though like said, the code should still work)

 

I a couple of things to try:

Debug.Log() your code, check that the  if Sprint block is being reached.

Set some breakpoints to ensure the code is executing as you think.

Try it without a character controller.

 

EDIT: Also, don't forget to check for compiler errors elsewhere in your code, unity wont' update until everything compiles (I know, it's kind of a noob thing, but I still do it myself from time to time.)

Edited by ferrous

Share this post


Link to post
Share on other sites

It's a good idea to let us know what is not working exactly. What is the character now doing that it's not supposed to be doing and what is it not doing that it is supposed to be doing? That would help a great deal.

 

The above tips are still great, don't get me wrong on that, but we now (have to) assume that the error is somewhere in this piece of code, while it may very well be in another script or just the settings of the other components (rigidbody, collider, charactercontroller) that are causing an issue

Edited by AthosVG

Share this post


Link to post
Share on other sites

Okay, I've looked at the code.  I agree with those above that it is a mess.

 

Input controllers should ONLY give commands to components. They should not need to know anything at all about the character system's state or position, if the character has a skateboard (interesting mechanic) or other state of the character.

 

The input controller should map input into events that get forwarded to other components.

 

And you REALLY should not call this line every Update():  CharacterController controller = GetComponent<CharacterController>();

 

And this kind of manipulation belongs in FixedUpdate() which is called at a regular simulator time step, rather than Update() which is called irregularly and whenever the engine feels like it. 

 

And probably more things, but that's enough for right now.

 

 

 

So starting out, you should have the input controller have a public variable with the character that needs controlling.

 

In your FixedUpdate, your first test should be to see if that targeted character is not null. If it is null, log and return.

 

Then on your character's code object (not shown in your file) have a set of functions. Looks like you've got these functions that belong in your character's class, NOT in your input controller:

* Jump() -- Test to see if the character is on the ground unless you've got some kind of multi-jump system, makes sure the character's other state allows the action, then triggers the animation or the motion stuff that jumps.

* Skate() -- Tests to see if the character is able to start skating, triggers any animations or whatnot, then changes the character's state to skating. When that state is true, the character's own FixedUpdate() should handle moving forward at whatever speed needs to be applied.

* Walk() -- same as Skate, except the character has a different final speed.

* Stop() -- same as Skate, except the new speed is zero.

* Turn(yaw, roll) -- Not exactly sure how a skateboard character turns with its roll that way you've got it in your code, but you have it there so you'll need to figure it out. Instead, either save this in the character's own private variables for later FixedUpdate handling, or do something creative to make it happen immediately on call. Don't make the character code figure out the input device's axis data.

 

That change will simplify your logic considerably, an let you move on to solving other problems.

Edited by frob
Forgot some words.

Share this post


Link to post
Share on other sites


So starting out, you should have the input controller have a public variable with the character that needs controlling.

 

You can make it a member variable and set it in the Start() method.

Share this post


Link to post
Share on other sites

Whatever works for you.  My preference would be something public that shows up in the inspector, but if you want it parameter-based, whatever floats your boat.

Share this post


Link to post
Share on other sites
My preference would be something public that shows up in the inspector

Depends if the value is fixed for all the game I guess.

But to change it without open the script inspector values is of course better to use.

Edited by Alundra

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!