#Vector stuff

1 messages · Page 1 of 1 (latest)

balmy dock
#

Let’s make a thread

#

@dawn steppe

dawn steppe
#

ok

#

so my idea was that you simply add input to velocity but that has a problem too

vivid crag
#

you want physics-based character controller

#

you need to use rigidbody.AddForce

#

everything else is figured out for you

dawn steppe
#

if you just keep adding it results in something like this where you never actually get to straight movement on x axis because it also involves braking on the y axis but idk how to do that part

#

no I do not want to mess with physics simulations

#

its always janky

vivid crag
#

it's janky because people don't understand how to use it

#

if you have enough willpower to reinvent it then why not just learn it

dawn steppe
#

I dont want full physics on my character I want basic FPS movement with momentum

vivid crag
#

what are you imagining as full physics?

dawn steppe
#

ridgidbodies

static scarab
#

This approach is like source engine's approach to speed

var currentSpeed = Vector3.Dot(currentVelocity, desiredDirection);

var speedToAdd = Mathf.Clamp(maxSpeed - currentSpeed, 0f, maxAcceleration * deltaTime);

var velocityToAdd = desiredDirection * speedToAdd;
vivid crag
#

and what do you think rigidbodies are

balmy dock
dawn steppe
#

ridgidbodies roll, have fricion, bounce, collision detection, etc.

balmy dock
#

But like keep forward momentum

vivid crag
#

@balmy dock he's trying to make inertia

balmy dock
#

Yeah I’m thinking that

static scarab
dawn steppe
#

is desired direction normalized to a magnitude of 1?

static scarab
#

yes

dawn steppe
#

or is it multiplied by the max velocity

#

ok

vivid crag
static scarab
#

You could also get the speed via velocity.magnitude, but using Dot is what quake / counter strike does to allow some amount of air strafe

dawn steppe
#

like where is the result here?

#

I see A and B but not the actual resulting vector

static scarab
#

dot does not give you a vector

vivid crag
#

that's because dot's a float @_@

static scarab
#

it gives you a float value

dawn steppe
#

oh is dot the one that's like

#

if two vectors are identical it's 1

#

and if they are opposite it's -1

static scarab
#

Yes, for normalized vectors

dawn steppe
#

and if it's perpendictular it's 0

static scarab
#

yes

dawn steppe
#

var currentSpeed = Vector3.Dot(currentVelocity, desiredDirection);
so what this is doing is, it's getting a -1 to 1 value based on how much your current velocity aligns with your desired normalized direction?

vivid crag
#

no

vivid crag
#

you're not normalizing it here

dawn steppe
#

or it's getting a -velocity to +velocity value

vivid crag
#

in any case, the question's stupid, your solution is just using physics

dawn steppe
#

so if I'm going +X 30 but input is -X 1, currentSpeed will be -30?

dawn steppe
#

but what if I'm going +X 30 but I input +Z 1, then it will be 0 right? that doesn't seem right since I'm moving

static scarab
#

it's a bit weird because it's not based on the magnitude. To be honest, it just happens to allow air strafing because of weird math results. So, it's not directly based on the magnitude in the way you are probably thinking

#

I think a more understandable approach would be to just use velocity.magnitude instead of the dot product..

dawn steppe
#

idk why that's related to airstrafing. can't I just like... not turn off your controls when you are in the air? lol

static scarab
#

no I am talking about the Quake bunnyhop air strafing

dawn steppe
#

oh the weird "vector projection gets really big" stuff

static scarab
#

yes

dawn steppe
#

yea I still barely understand that

#

so for simplicity I will use velocity.magnitude where velocity is the current actual player velocity?

static scarab
#

I just basically sent the exact quake code in C#, but using the velocity.magnitude (as far as I know) gives a more "normal" result with the same general concept

dawn steppe
#

alright, I do want movement tech but I think it wont be exaclty like quake and I want to understand the fundamentals of my system first

static scarab
#

you will need to apply your own friction as well, as this calculation alone can never lose speed

dawn steppe
#

var speedToAdd = Mathf.Clamp(maxSpeed - currentSpeed, 0f, maxAcceleration * deltaTime);

var velocityToAdd = desiredDirection * speedToAdd;```

so speed to add... looks like it's just determining how much you can increase by clamping how much remaining speed to the max you have to max acceleration
static scarab
#

yup

dawn steppe
#

and if you are faster than max it just doesn't add, makes sense

#

is velocityToAdd a vector?

static scarab
#

yes

dawn steppe
#

wait this just seems like exactly what I was doing before

#

which results in this

static scarab
#

I wasn't really following the convo so I am not sure

dawn steppe
#

if I'm moving up, and I just hold right, I will never get to the point where I am only moving right

#

because adding the right vector never removes the positive "up" component of the black vector

static scarab
#

well that is what friction would remove

#

which is just velocity -= velocity * (friction * deltaTime);

dawn steppe
#

huh so is that how source does it? just friction for that control?

static scarab
#

yes

#

they have a slight air friction and a strong ground friction

dawn steppe
#

weird, that doesn't intuitively feel right, because it feels like you should get "more" friction if you are trying to actively change directions than if you just stop

static scarab
#

and they use the dot product for that weird air strafe that lets you redirect your momentum when looking / moving at certain angles

dawn steppe
#

like if you are running, turning yourself around seems like friction would be much greater than if you just started sliding or something

urban quail
#

I haven't followed this discussion but to answer your original question:
Let G be the green vector, R be the red vector, B be the black vector, G2 be the shorter green vector, and a be the angle between G and R

you then have three equations from the identities of trig & linear algebra
[1] G = R + B
[2]: dot(G, R) = |G|*|R|*cos(a)
[3]: cos(a) = |R|/|G2|

you can substitute [3] into [2] and rearrange for the length of G2, in the direction of G

dawn steppe
dawn steppe
#

hm

#

does my confusion about the friction make sense though?

#

like, friction decays the black vector at a flat rate

#

but then if you hold sideways, it doesn't increase that rate despite trying to change direction?

#

that feels intuitively wrong to me

static scarab
#

the friction is just high, and it's applied before you add velocity (so that you can actually reach your max speed)

#

I see what you are saying though

#

but friction is not a flat rate

#

friction is essentially a percentage of your current velocity

#

so if you had 500 Z velocity and only 1 X velocity, it would decay the 500 Z much faster than the 1 X

dawn steppe
#

hm ok

#

so to be clear like

#

if I have 500Z and I am not inputting anything

#

vs I have 500Z and I am inputting X positive

#

the Z axis of my vector is being decayed by the same curve either way?

#

and it doesn't feel off in the game?

static scarab
#

yes

#

yeah I think it's just something you would have to try and see

#

my experience is that it seems to work just fine

dawn steppe
#

well I mean I guess if source does that and people like source movement I guess it's ok

#

and you said that goes before I add velocity?

static scarab
#

yes, that way the speedToAdd equation can actually cause you to reach the max speed

dawn steppe
#

yea

#

but wait

#

if I have 500Z right

#

my current speed will be higher than my max speed

#

so speedToAdd will be 0 and I wont be able to move

#

until it decays from friction to below my max speed

#

I think im kinda figuring out what I was really trying to ask now, which is something like how do I find my max speed vector when the player has momentum greater than their max running speed

static scarab
#

yeah well... this is what the Dot helps to alleviate (and the reason it existed in the first place) because it changes the calculation to add speed based on your intended direction, the air strafe was just an unintentional side effect

#

The problem with the dot is I don't even fully understand it (and I don't think it works perfectly, hence the air strafe)

#

lol

#

so I can't really explain it if I don't understand exactly how it works

#

But essentially it will consider your current speed to be "low" if you aren't going your intended direction

dawn steppe
#

var speedToAdd = Mathf.Clamp(maxSpeed - currentSpeed, 0f, maxAcceleration * deltaTime);

var velocityToAdd = desiredDirection * speedToAdd;```

if I understand dot, currentSpeed would be 0 under the condition that your input is perpendicular to your velocity?
static scarab
#

Yes

dawn steppe
#

ok I think I kinda know what you mean by low friction in air now based on tf2 because if you jump you can't really change direction in air, I thought they disabled your horizontal inputs if not touching ground but maybe it's just becuase that momentum doesn't decay so it's harder to change the actual "direction" of that vector

static scarab
#

yeah exactly

dawn steppe
#

what exactly do you mean by airstrafing? like just being able to have air control?

static scarab
#

Here

#

Good video

dawn steppe
#

alright, ill try to understand whats going on here lol

#

im not sure if I exactly want quake bhopping so my idea is something like being able to change direction in air but clamping your actual velocity to the velocity before your input changed it or somethin

static scarab
#

Well yeah so in CS:GO they have the same code, but they created a feature like that called "Z-block" which lowers your speed if it passes some hand-crafted threshold

#

because being able to fly around the map lightning fast is a little bit game breaking

#

and they wanted a more tactical experience

dawn steppe
#

yea lol

#

that might be something like what I want

#

I do eventually want super fast movement I think I just want it in a new way

#

so we will see

#

right now im just trying to get the basics of movement with intertia where you can move yourself out of the interia but not use it to gain more speed than the intertia itself gave you

static scarab
#

watching this video reminded me, you can very easily implement the "anti-airstrafe" mechanic by just having air friction

#

Quake has no air friction which means you can essentially get unlimited speed eventually

dawn steppe
#

hm

static scarab
#

but having air friction makes it so that you can still gain a bit of speed but you will lose more and more speed from friction as you try to gain more and more speed through air strafing

#

so it balances out

dawn steppe
#

real quick dot product doesnt matter the order of the parameters right?

#

I dont think it does

static scarab
#

I don't think so? but I am used to using it with normalized vectors

dawn steppe
#

HMM ok I think I understand this line now

#

so when it's 0 you can add speed because 0 is less than max speed

static scarab
#

yeah

dawn steppe
#

when it's positive you can't if you are at max speed because you are already at max speed and its * 1 or greater

#

when it's negative I dont think you can either

static scarab
#

when it's negative it will actually let you stop even faster than usual

dawn steppe
#

ok I see because it adds to maxspeed

#

but it will still be clamped to max acceleration

static scarab
#

yes

#

a lot of great movement games use these calculations pretty much as-is

#

they just add air accel

#

like Apex Legends, Titanfall 2, etc

dawn steppe
#

air acceleration? is that a new thing?

#

or just a lack of friction

static scarab
#

well, it's not new, it's just an innovation on Quake

#

Quake had no air friction, but all the more modern source games use air friction

dawn steppe
#

what is air acceleration though in this context

static scarab
#

oops, meant air friction

dawn steppe
#

you said "add" as if its new code

#

ah I see

static scarab
#

something else to note is you will likely want different "max speeds" for air and grounded movement, with air speed being lower

dawn steppe
#

so if you simply just run the third line as is, it appears that you can actually increase your speed by strafing while travelling forward?

#

I mean I feel like im saying obvious stuff but still

static scarab
#

yeah, with no air friction it can just keep increasing if you abuse it properly. However, there is still at least 1 frame you touch the ground and get ground friction applied, so it's not actually infinite, but if you were somehow airborne the whole time it would be infinite

dawn steppe
#

yea I see why the dot product can allow for increasing speed now

#

because if input is perpendicular it counts your current speed as 0

#

however it wont "steer" you like I was mentioning because it's simply adding

#

the friction steers by removing that forward component over time

#

if you really want to steer hard right you actually need to press back and right instead of just right?

#

I think quake does not apply friction on the first frame of touching ground iirc

static scarab
#

ah well then

#

infinite power!

static scarab
dawn steppe
#

so you can get infinite speed with frame perfect jumps I think

dawn steppe
#

that's what feels weird to me

static scarab
#

a lot of it sounds weird in theory, but if you actually implemented it you might not think it's so weird

#

basically, I just think those side effects are almost completely unnoticeable

dawn steppe
#

something like this where if you also backpedal while holding right, the angle of orange tilts more rightward than the angle of green

#

maybe thats just an opporunity for movement tech lol

static scarab
#

yeah you would have like a frame or two to do it, but I think that's the case yes

dawn steppe
#

taking corners faster at high speed by braking

static scarab
#

generally the friction is high enough for you not to notice things like that while playing

dawn steppe
#

maybe yea

#

im trying to think if there is a theoretical way to stop that even if it's not noticible

#

like ill probably keep it but I feel like it will help me understand better

static scarab
#

I guess just clamping the dot product result to above 0?

#

like Mathf.Max(currentSpeed, 0f);

#

haven't really thought that through though

dawn steppe
#

hm because the back-right would be a partially negative dot product right

static scarab
#

yeah

dawn steppe
#

which in code would mean...

#

no I dont think that would actually do anything, I think negative is equivlent to 0 in terms of max speed

#

negative just gets clamped to max acceleration like 0 does

static scarab
#

but it removes the bias that backward movement has over forward movement

#

because by default, you will cancel your forward velocity more quickly by holding backward

#

than if you were trying to cancel it by holding right

#

or I say "cancel" by holding right but I really mean wait for friction to cancel it for you

#

whereas backwards movement actually cancels it

dawn steppe
#

maybe that makes sense, I guess this is a result of the fact that cancelling forward allows the side component of the input to have more effect over the angle or something?

#

maybe it's actually related to the acceleration being clamped

static scarab
#

I don't even know anymore lol

dawn steppe
#

lel

#

no I do think it might be that though tbh

#

or maybe it not being clamped

#

idk this is confusing

#

but you can theoretically adjust the magnitude of your input or acceleration or whatever to compensate

#

I think ill just implement it how it is though lol

static scarab
#

yeah just give it a shot and see

#

easier to mess with values when you actually have it working

dawn steppe
#

what im basically saying though is you use the purple line instead of the red when backstrafing, the only question is how do you get the amount to shorten it by

#

but yea Imma just move forward with it

#

I dont think I really understand how to prevent the speed gain but I should keep watching the video

static scarab
#

in general?

#

friction is how you do that

#

if that's what you are talking about

#

air friction would remove the speed gain (up to a certain point)

#

I guess "limit" is the better word

#

just a slight amount would work

dawn steppe
#

ill try to draw it out

#

but I basically want no movement tech until I can understand the basic foundation

#

and then I can choose if I want quake stuff later depending on that understanding

#

but im basically just talking about this scenario

#

say you got blasted along black vector greater than max speed

#

inputting red vector

#

current speed is 0 cuz it is perpendicular

#

so it adds max acceleration

#

and since you just add the vectors it results in green

#

and the part im interested in, green magnitude is greater than black magnitude

#

im not sure how friction plays into this exactly

static scarab
#

could you do something simple like, after getting the green vector, just clamp the green vector's magnitude to the magnitude of the black vector?

dawn steppe
#

I was just thinking that yea, that might work

#

so the section that adds the player input vector basically gets current magnitude, adds it, reclamps to current magnitude

static scarab
#

yeah

dawn steppe
#

though probably only if the magnitude is above the player's max

#

so you can still accelerate lol

static scarab
#

yeah it would be like

velocity = Vector3.ClampMagnitude(velocity + velocityToAdd, Mathf.Max(velocity.magnitude, maxSpeed));
dawn steppe
#

alright im gonna see if I can actually code this now lol

static scarab
#

good luck

dawn steppe
#

tnx

#

I imagine I should apply friction before I calculate current velocity

#

interesting thing I realized, I think the maxAcceleration value kinda controls if you can backpedal faster or not

#

basically maxAcceleration being equal to maxSpeed means backpedelling is just as fast as forward

#

float speedToAdd = Mathf.Clamp(maxRunSpeed - currentSpeed, 0f, maxAcceleration * Time.deltaTime);

#

trying to figure out how to explain this hmm

#

ok basically

#

you accelerate by maxRunSpeed each tick

#

because thats what is clamped in speedToAdd

#

and at 0, side strafe, you accelerate exactly by maxRunSpeed * delta, assuming maxAcceleration is at least maxRunSpeed

#

you can only get the boost from going opposite your direction by going above maxRunSpeed which would of course require a negative number etc. etc.

#

but it's always clamped by maxAcceleration

#

basically if maxAcceleration is equal to maxRunSpeed you will only ever clamp reverse-movement

#

you have to set maxAcceleration HIGHER than maxRunSpeed to get backpedalling boost

#

2x higher specifically

#

if you set it 1.5x higher, like run speed of 40 max acceleration of 60, then inputing the opposite of your velocity is 1.5x faster than inputting sideways

#

this might also affect how quickly you can side strafe interestingly

#

I think you might actually strafe faster if you are currently above max speed and you hold right AND forward

#

vs just holding right

#

but only at high enough speeds

#

interesting

#

wait no

#

I think if you go too fast, holding right and forward wont do anything at all

#

something doesnt seem right :/

#

imagine you are going 1000X

#

that means dot product of right and forward held would be 500 right?

#

maxRunSpeed (50) - 500 is like -450 or something which gets clamped to 0

#

so you dont even more right at all

#

unless my dot product is wrong which is totally possible

#

yea no idk if I just coded it wrong but if I'm above max speed I can't move sideways

#

no I might have broke something

#

nope I was right, fixed the thing I did and it still happens

#

I bound a key to give me really high speed on x axis

#

and I can still strafe out of it

#

but NOT if im also holding forward

#

maybe that's why I have so much trouble airstrafing in tf2 lol, maybe I need to stop pressing the forward key

#

nah that doeesnt seem to be it

#

still though I dont want that behavior

dawn steppe
#

ok I think I may have figured out a solution

dawn steppe
#

nope this is complicated

dawn steppe
#

ive been overthinking this but I think I might have figured out what I need?

#

basically when the speed gets high enough any small bit of the input vector that points in the same direction as your velocity scales way above maxSpeed or whatever

#

so it consdiers you moving

#

basically the issue is the green part

#

that makes the dot product positive

#

and at high enough velocities, any positive is greater than that important value

#

my goal is to "flatten" the red arrow into the purple arrow, though under what conditions I havent figured out

static scarab
#

Would that not just be the clamping within the black vector magnitude that we discussed?

dawn steppe
#

var speedToAdd = Mathf.Clamp(maxSpeed - currentSpeed, 0f, maxAcceleration * deltaTime);

#

this line?

#

I dont think so

#

what I'm trying to do now is do each component seperately, the forward and the strafe

#

im bad at vector math tho

#

yea idk what im doing

#

this feels like it should be simple

#

add the input vector to the velocity unless it would increase the velocity vector in that direction above the max

dawn steppe
#

but the fact that in this above image, the black vector can project onto the red one entirely means that the code thinks its pointing in its direction

#

I think that's unrelated to what im doing

#

I will show you what the conceptual problem is though

#

how I feel it should be able to work is simple, just add input to velocity until the velocity in the direction of the input reaches the max speed

#

however

static scarab
#

The line of code I sent would do this

#

it's a bit confusing though in this graphic

#

because you wouldn't actually go backwards

#

but your velocity + added velocity would be clamped within the magnitude of the black vector

dawn steppe
#

if you input left up, the dot product thinks you are already going above your max in the inputted direction

#

which feels wrong because you can't steer any more

#

but if you ONLY input left, the dot product is 0 so it thinks you ARENT moving in that direction

#

that is the thing that's causing issues I think

#

I don't think dot product is actually the correct measurement for how much faster you can go in the inputted direction

static scarab
#

no it's not

#

that's why you get the air strafing

dawn steppe
#

what I actually need is the green line

#

if brown is input * max run speed

#

so maybe some kind of dot product of max strafe and input, and a dot product of max forward and input?

#

I was making a "forward" vector that is normalized velocity, or normalized facing direction if velocity is 0

#

imma finish doing that

#

actually no I did that part already

#
        if (playerVelocity.magnitude <= 0) forwardDir = transform.forward.normalized;
        Debug.DrawRay(transform.position, forwardDir * 100, Color.blue);```
#

so then I could take the dot product of forwardDir and input I imagine

static scarab
#

transform.forward is already normalized btw

dawn steppe
#

alright

#

I thought it might be but wanted to make sure

#

I might have to actually seperate input vector into just the forward and strafe axes actually

#

maybe? egh

#

hm here's an idea

#

nvm idk what im talking about

#

one idea I had was just to have two separate velocities and I apply both to the player

#

one that is controlled entirely by input and one that gets set from any forced movement

#

idk though

#

feels like the player input SHOULD be able to just directly affect the actual velocity but there's all these weird quirks of vector math that make it behave in ways that feel wrong

#

ok maybe something like this. orange is max speed on the axes of "forward/velocity" and "perpendicular to velocity" or strafe

#

and then something like, hmm

#

idk a projection of current velocity onto the forward and strafe angles right but an inverse of that

#

so that you would get left with the horizontal orange arrow

#

and then a projection of input onto that resulting vector

#

which would give you the pink line for input

#

its like I need a vector that represents the max vector that you CAN add

#

like this pink vector

#

then I project input onto the pink vector to see what you actually do add

#

or something like that

#

you add the input vector as constrained by some function by the pink vector

vivid crag
#

@dawn steppe is movement controller the first thing you're doing with this project?

dawn steppe
#

idk? I have other stuff in the project already but im trying to rewrite the movement to be better

vivid crag
#

alright, i know the feel but you're really OCDing over there

#

just increase mass, crank up the drag and focus on something that players will actually notice

#

A detailed look at how we built our physics-based character controller in Unity for our game Very Very Valet - available for Nintendo Switch, PS5, and Steam
BUY NOW!! https://toyful.games/vvv-buy

~ More from Toyful Games ~

â–¶ Play video
dawn steppe
#

OCDing is what I want to do

#

I want every part of it to be directly controlled by intentional choices I understand

vivid crag
#

there's also an asset unity bought out recently for dots, but the author also has the mono kinematic controller which he made free

#

basically what i'm saying is go study what others did, steal what you like

#

catlikecoding has a free movement system guide as well that's worth looking at

#

also

#

celeste code is also open source even though it's in XNA(?), the first levels have the accelerating platform so you can see what they did there

dawn steppe
#

the reason I've gotten here is cuz I've had problems with the simple movement code that most tutorials give you

#

plus I want to actually understand what's going on

vivid crag
#

you're focusing on the wrong points though

dawn steppe
#

I don't think I am

vivid crag
#

sigh

#

what state is your movement code in right now

#

i want to see how bad it is for you to think that

dawn steppe
#

I mean I keep reworking it but I will see what it is currently

#

oh right

#

basically all I have right now was trying to get a vector that represents the forward direction, which is the players current velocity or their facing direction if velocity is 0

#
        if (playerVelocity.magnitude <= 0) forwardDir = transform.forward;
        Debug.DrawRay(transform.position, forwardDir * 100, Color.blue);

        forwardAmount = Vector3.Dot(playerVelocity, inputVector);```
vivid crag
#

ok, where's the rest?

#

the actual movement

dawn steppe
#

that's it rn I removed all the other stuff because it wasnt working

#

however I can get the code we were working off originally

#

var speedToAdd = Mathf.Clamp(maxSpeed - currentSpeed, 0f, maxAcceleration * deltaTime);

var velocityToAdd = desiredDirection * speedToAdd;```
#

this is basically the code I had for a while however it has an issue

#

if you are moving in a direction faster than max speed, you can steer by holding left, but holding left AND forward will NOT move you left at all

#

which feels wrong

#

but I can't find a way to fix it

vivid crag
#

remove your code and just add force, increase mass and drag to limit speed

dawn steppe
#

I am not using the physics system

vivid crag
#

you don't have rigidbody at all, and calculating all collisions manually?

dawn steppe
#

the wall collision works fine for what I want, but the phyics based movemnt does not

#

I mean if I really really need to im sure I can just cast a ray to the collider of the level geometry and stop the player if it's within a range controlled by the radius of the player

vivid crag
#

man, i can't even put into words what this sounds like

dawn steppe
#

here is how it actually controls the player

vivid crag
#

alright let's skip that,

dawn steppe
#

controller.Move(playerVelocity * Time.deltaTime);

vivid crag
#

tell me

#

what part of physics based movement does not

dawn steppe
#

mass, drag, friction, force, I want to calculate the players velocity not have the physics system do it

vivid crag
#

did you read physx documentation?

dawn steppe
#

no, I do not want to use a system that calculates velocity for me

vivid crag
dawn steppe
#

if I see how complex the theoretical calculations for basic velocity are maybe I will change my mind, but not until I understand the actual basis for what it is

#

my problem right now is very simple

vivid crag
#

they're not actually complex, the formula was out there somewhere

dawn steppe
#

I want to use an input vector to increase the velocity vector up to a limit

#

however I have a problem

#

when the current velocity has already exceeded that limit, my method for calculating your current speed in the direction you are inputting thinks you are already travelling above the limit in that direction

#

as in the yellow line projection

#

if you project velocity (black) onto input (red) it results in a vector that's greater than the limit, and so it ignores your input

#

that's my issue, you can't actually steer if you are going too fast

#

and I dont know the proper way to measure that distance

#

what I'm trying to simulate is basically how a human can run, up to a point

#

but at a certain point they can't run any faster

#

I want to limit the amount of velocity you can gain by running

#

however, I also want other forces like say explosions to be able to push you further than you can run

#

without cancelling out your run

#

it should only "cancel" your running to the degree that your running is travelling in the same direction as the vector you are already above your running max on

#

but because of dot product, the black arrow is fully cancelling the red despite it actually being in a different direction

#

does that make sense

vivid crag
#

not being able to move sideways is actually realistic in that case

dawn steppe
#

only because of the way legs actually work and it's a video game and I don't care to add that level of realism

#

basically if you can run at 20 mph and the wind is blowing you forward at 21 mph I still want you to be able to move sideways at 20 mph while the wind blows you

#

instead of it just going "you are already faster than 20 mph no changing direction"

#

and it seems that the problem is an issue in how your current speed in inputted direction is calculated

#

it thinks you are travelling in that direction at 20 mph already even though that's only one component of the input vector

#

I dont think you understand im trying to solve that problem, not just trying to get the bare minimum movement code and copy paste it

#

I found this quake III code that says its the "proper" way but im having trouble reading it

#
    vec3_t        wishVelocity;
    vec3_t        pushDir;
    float        pushLen;
    float        canPush;
    VectorScale( wishdir, wishspeed, wishVelocity );
    VectorSubtract( wishVelocity, pm->ps->velocity, pushDir );
    pushLen = VectorNormalize( pushDir );
    canPush = accel*pml.frametime*wishspeed;
    if (canPush > pushLen) {
        canPush = pushLen;
    }
    VectorMA( pm->ps->velocity, canPush, pushDir, pm->ps->velocity );```
#

the thing I was attempting though was to separate the forward and strafe axes

vivid crag
#

then if you're flying sideways you won't be able to move forward

dawn steppe
#

that is the issue im trying to solve

vivid crag
#

you want to "apply remainder of vector3 that's not past the desired magnitude"
you have your velocity direction, velocity magnitude, and the input vector to work with...
i can see why you have OCD, it sounds like it should be simple but nothing's coming to mind

dawn steppe
#

yea

vivid crag
#

and that means that when you're just using normal gravity, you're currently getting movement stopped when falling down too

dawn steppe
#

possibly, havent thought about gravity yet

vivid crag
#

it's just downwards velocity and if it's higher than movement then you're getting override again

#

wait

#

we need to calculate remainder

#

doesn't that mean we just need to take normalized velocity and subtract that from input?

dawn steppe
#

what would that look like visually

vivid crag
#

i'll leave that up to you

dawn steppe
#

something like green arrow?

vivid crag
#

i have no clue how you're thinking visually, i'm doing it in a different way

dawn steppe
#

oh normalized velocity

vivid crag
#

something similar to that, i'm just assuming it's always the overkill

#

if magnitude is less then just use that

dawn steppe
#

yea idk I dont understnad this, im gonna keep doing what I was doing

vivid crag
#
x = playerVelocity.magnitude;
if (x > 1) { x = playerVelocity.normalized; } 
input -= x;  //?
velocity += x;
#

to make it simple, just assume you're using only 1 axis for movement
ok nvm that doesn't work, but it's probably something close to this

dawn steppe
#

what? why would it subtract the input

#

maybe I do need to separate the x and z components of the input vector though

vivid crag
#

thinking in 1 dimension:
if x is 0.3, and player is adding 1, input must add 0.7.. final velocity 1
if x is 11, it must normalize to 1, and if input is same dir it must add 0, going in opposite direction it must add -1.. final velocity 11 in case 1, 10 in case 2

dawn steppe
#

im tryin to code something but my brain is fried lol

#

basically just calculating each axis seperately

vivid crag
#

oh

dawn steppe
#

we will see what it does

#

I think I might need a break tho im super distracted

vivid crag
#

input - x?

same direction but low velocity
1 - 0.3 = 0.7
result + velocity = 1

same direction
1 - 1 = 0
0 + 11 = 11

opposite direction
-1 - 1 = -2
-2 + 11 = 9 (double speed...)

idk, i still think looking at somebody else's kinematic movement controller code would be a better idea than trying to figure it out yourself

dawn steppe
#

ok I took a break and I thought of some stuff

#

gonna try the simplest first

#

im simply going to add input, then clamp to prevoius magnitude if it was above max speed

#

I anticipate a lack of steering at high speeds but I have another theory for that

#

actually this... kinda just works I think

#

the reduction in steering control from clamping the magnitude doesn't seem to be strong enough to notice

#

maybe at like ridiculous speeds, but I will get there when I get there, if I ever do

#

im gonna just make sure it's acutally clamping it properly

#

yep I can set myself to an above max speed and strafe perfectly fine, and it only ever decreases the speed im ad

#

no way it's actually this easy lol

#

this is basically what I have:

#
        // Friction
        playerVelocity -= playerVelocity * (friction * Time.deltaTime);

        float prevVel = playerVelocity.magnitude;
        playerVelocity += inputVector * maxAcceleration * Time.deltaTime;
        if (playerVelocity.magnitude >= maxRunSpeed) {
            playerVelocity = Vector3.ClampMagnitude(playerVelocity, Mathf.Max(prevVel, maxRunSpeed));
        }```
#

I was worried that the loss in strafe component represented in orange would feel bad, but at the speeds I tested it wasn't really noticible. hm

#

im going to try and do walls cancelling momentum now, which I imagine works like this

#

you raycast to the wall you are touching (maybe character controller has a method to get a wall you are being blocked by?) and project your momentum perpendicular to the normal

#

idk if "negative" projections like this work though

#

like if im going left but im calculating it based on a right pointing vector

#

(if you slide into a wall, im gonna make it so it redirects you but will keep the magnitude of the resulting vector, so you can use it to redirect yourself when travelling at higher than max speed without braking)

vivid crag
#

you're just digging the hole even deeper