Re: [hlcoders] Can't seem to modify Player Angles
gamemovement:
::CheckParameters
--snip--
if ( !IsDead() )
{
v_angle = mv->m_vecAngles;
v_angle = v_angle + player->m_Local.m_vecPunchAngle;
// Now adjust roll angle
if ( player->GetMoveType() != MOVETYPE_ISOMETRIC &&
player->GetMoveType() != MOVETYPE_NOCLIP )
{
mv->m_vecAngles[ROLL] = CalcRoll( v_angle, mv->m_vecVelocity,
sv_rollangle.GetFloat(), sv_rollspeed.GetFloat() );
}
else
{
mv->m_vecAngles[ROLL] = 0.0; // v_angle[ ROLL ];
}
mv->m_vecAngles[PITCH] = v_angle[PITCH];
mv->m_vecAngles[YAW] = v_angle[YAW];
}
--snip--
On Mon, Aug 20, 2012 at 11:23 AM, Michael Kramer wrote:
> Modifying it in the animstate does properly do what I'm wanting, I just
> didn't know if it was proper, it seems like modifying the roll values in
> gamemovement would carry over, but no where in the animstate does it
> overwrite the angles passed in by gamemovement, but doesn't seem to carry
> over ROLL.
>
> I think I'll just modify animstate to properly read the angles from
> gamemovement.
>
> Thanks everyone,
>
>
> On Sun, Aug 19, 2012 at 10:29 AM, Garry Newman wrote:
>
>> I might be missing something obvious, but can't you just override
>>
>> *Player::GetRenderAngles()
>>
>> or
>>
>> *PlayerAnimState::GetRenderAngles()
>>
>> or find out where it's fudging m_angRender in the playeranimstate
>>
>> // Rotate entire body into position
>> m_angRender[YAW] = m_flCurrentFeetYaw;
>> m_angRender[PITCH] = m_angRender[ROLL] = 0;
>>
>> and make it do what you want there?
>>
>> garry
>>
>>
>>
>> On Sun, Aug 19, 2012 at 5:20 PM, Michael Kramer wrote:
>>
>>> If I attempt to modify the player angles in gamemovement, nothing
>>> changes, even though it is the last step pretty much, it should be able to
>>> overwrite everything else.
>>>
>>> Adjusting the angles in playermove, does work, even though it is called
>>> way before gamemovement.
>>>
>>> I can adjust the viewangles (engine->SetViewAngles()) in gamemovement,
>>> but can't adjust the player angles at all.
>>>
>>> Your hierarchy is very helpful though, so thank you for that, but it
>>> seems like finishmove does not use the angles from gamemovement, the code
>>> is in there (player->SetLocalAngles( move->m_vecAngles );) but no matter
>>> what m_vecAngles is set at, nothing changes even the slightest.
>>>
>>> I was hoping that animstate would update relative to the model/entities
>>> position, but it does seem like it is overwriting anything sent back from
>>> gamemovement in regards to angles. If I adjust the angles in animstate it
>>> properly updates.
>>>
>>> I can do this without updating angles at all, simply with a barrel roll
>>> animation, but was hoping I could do it all code wise easily.
>>>
>>> On Sun, Aug 19, 2012 at 1:54 AM, Tony "omega" Sergi >> > wrote:
>>>
It's not that it's "all over the place" but rather they are different
components of the entire process.
The majority of the actual movement is handled inside gamemovement.
the in_* (CInput) handles the raw input itself for the local client
(and by default the view angles as manipulated by the mouse) which puts it
into CUserCmd. CUserCmd is then transmitted every frame down to the server
which is used by playermove and finally into CGameMovement for the final
step, and CPrediction also uses it to predict locally.
Once all of that is done, animstate is called from postthink every
frame to take the final result of everything and then decides what
animations to play as well as the final rendering angles of the player.
So to summarize the whole process (from memory here, I might be missing
something):
Input - Create CUserCmd
CUserCmd is sent for each frame to the server, and processed locally
with prediction
CPlayerMove then does:
some prelimilary copy like eyeangles and buttons
prethink (calls prethink on the player)
think (calls think on the player if set)
setupmove (copy usercmd -> CMoveData)
gamemovement
finishmove (update the player origin, angles, etc from gamemovement
(CMoveData)
postthink (run animstate)
the client-side is slightly different for networked players, but the
local player runs the same process (more or less, through CPrediction
instead of PlayerRunCommand.
and note, that it doesn't happen precisely in that order for every
command, as the client will run and transmit input/CUserCmd as fast as it
can.
Gamemovement is where you should be handling your "barrel roll"; why
that it's not working for you, I cannot say as I cannot see your
implementation.
-Tony
On Sun, Aug 19, 2012 at 2:07 PM, Michael Kramer
wrote:
> Alright, I was able to modify the angles by adding some code into the
> multiplayer animstat
Re: [hlcoders] Can't seem to modify Player Angles
Modifying it in the animstate does properly do what I'm wanting, I just didn't know if it was proper, it seems like modifying the roll values in gamemovement would carry over, but no where in the animstate does it overwrite the angles passed in by gamemovement, but doesn't seem to carry over ROLL. I think I'll just modify animstate to properly read the angles from gamemovement. Thanks everyone, On Sun, Aug 19, 2012 at 10:29 AM, Garry Newman wrote: > I might be missing something obvious, but can't you just override > > *Player::GetRenderAngles() > > or > > *PlayerAnimState::GetRenderAngles() > > or find out where it's fudging m_angRender in the playeranimstate > > // Rotate entire body into position > m_angRender[YAW] = m_flCurrentFeetYaw; > m_angRender[PITCH] = m_angRender[ROLL] = 0; > > and make it do what you want there? > > garry > > > > On Sun, Aug 19, 2012 at 5:20 PM, Michael Kramer wrote: > >> If I attempt to modify the player angles in gamemovement, nothing >> changes, even though it is the last step pretty much, it should be able to >> overwrite everything else. >> >> Adjusting the angles in playermove, does work, even though it is called >> way before gamemovement. >> >> I can adjust the viewangles (engine->SetViewAngles()) in gamemovement, >> but can't adjust the player angles at all. >> >> Your hierarchy is very helpful though, so thank you for that, but it >> seems like finishmove does not use the angles from gamemovement, the code >> is in there (player->SetLocalAngles( move->m_vecAngles );) but no matter >> what m_vecAngles is set at, nothing changes even the slightest. >> >> I was hoping that animstate would update relative to the model/entities >> position, but it does seem like it is overwriting anything sent back from >> gamemovement in regards to angles. If I adjust the angles in animstate it >> properly updates. >> >> I can do this without updating angles at all, simply with a barrel roll >> animation, but was hoping I could do it all code wise easily. >> >> On Sun, Aug 19, 2012 at 1:54 AM, Tony "omega" Sergi >> wrote: >> >>> It's not that it's "all over the place" but rather they are different >>> components of the entire process. >>> The majority of the actual movement is handled inside gamemovement. >>> the in_* (CInput) handles the raw input itself for the local client (and >>> by default the view angles as manipulated by the mouse) which puts it into >>> CUserCmd. CUserCmd is then transmitted every frame down to the server which >>> is used by playermove and finally into CGameMovement for the final step, >>> and CPrediction also uses it to predict locally. >>> Once all of that is done, animstate is called from postthink every frame >>> to take the final result of everything and then decides what animations to >>> play as well as the final rendering angles of the player. >>> >>> So to summarize the whole process (from memory here, I might be missing >>> something): >>> >>> Input - Create CUserCmd >>> CUserCmd is sent for each frame to the server, and processed locally >>> with prediction >>> CPlayerMove then does: >>> some prelimilary copy like eyeangles and buttons >>>prethink (calls prethink on the player) >>>think (calls think on the player if set) >>>setupmove (copy usercmd -> CMoveData) >>> gamemovement >>>finishmove (update the player origin, angles, etc from gamemovement >>> (CMoveData) >>> postthink (run animstate) >>> >>> the client-side is slightly different for networked players, but the >>> local player runs the same process (more or less, through CPrediction >>> instead of PlayerRunCommand. >>> >>> and note, that it doesn't happen precisely in that order for every >>> command, as the client will run and transmit input/CUserCmd as fast as it >>> can. >>> >>> Gamemovement is where you should be handling your "barrel roll"; why >>> that it's not working for you, I cannot say as I cannot see your >>> implementation. >>> >>> -Tony >>> >>> >>> >>> >>> On Sun, Aug 19, 2012 at 2:07 PM, Michael Kramer wrote: >>> Alright, I was able to modify the angles by adding some code into the multiplayer animstate, but I have a question for you. It seems that gamemovement adjusts only the origin, and not the viewangles/player angles at all, so I'm assuming adding anything in there would be wrong to do. It also seems like the movement code is all over the place, in player, gamemovement, in_mouse, playermove, etc is there a reason it is spread all over the place? It seems like ideally all player movement should be controlled in 1 place, and not 5 or 6 different areas... >>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>> >>> >>> >> >> >> -- >> *Michael Kramer, Software Engineer & SEO Expert* >> http://www.siosphere.com | kra...@
Re: [hlcoders] Can't seem to modify Player Angles
I might be missing something obvious, but can't you just override *Player::GetRenderAngles() or *PlayerAnimState::GetRenderAngles() or find out where it's fudging m_angRender in the playeranimstate // Rotate entire body into position m_angRender[YAW] = m_flCurrentFeetYaw; m_angRender[PITCH] = m_angRender[ROLL] = 0; and make it do what you want there? garry On Sun, Aug 19, 2012 at 5:20 PM, Michael Kramer wrote: > If I attempt to modify the player angles in gamemovement, nothing changes, > even though it is the last step pretty much, it should be able to overwrite > everything else. > > Adjusting the angles in playermove, does work, even though it is called > way before gamemovement. > > I can adjust the viewangles (engine->SetViewAngles()) in gamemovement, but > can't adjust the player angles at all. > > Your hierarchy is very helpful though, so thank you for that, but it seems > like finishmove does not use the angles from gamemovement, the code is in > there (player->SetLocalAngles( move->m_vecAngles );) but no matter what > m_vecAngles is set at, nothing changes even the slightest. > > I was hoping that animstate would update relative to the model/entities > position, but it does seem like it is overwriting anything sent back from > gamemovement in regards to angles. If I adjust the angles in animstate it > properly updates. > > I can do this without updating angles at all, simply with a barrel roll > animation, but was hoping I could do it all code wise easily. > > On Sun, Aug 19, 2012 at 1:54 AM, Tony "omega" Sergi > wrote: > >> It's not that it's "all over the place" but rather they are different >> components of the entire process. >> The majority of the actual movement is handled inside gamemovement. >> the in_* (CInput) handles the raw input itself for the local client (and >> by default the view angles as manipulated by the mouse) which puts it into >> CUserCmd. CUserCmd is then transmitted every frame down to the server which >> is used by playermove and finally into CGameMovement for the final step, >> and CPrediction also uses it to predict locally. >> Once all of that is done, animstate is called from postthink every frame >> to take the final result of everything and then decides what animations to >> play as well as the final rendering angles of the player. >> >> So to summarize the whole process (from memory here, I might be missing >> something): >> >> Input - Create CUserCmd >> CUserCmd is sent for each frame to the server, and processed locally with >> prediction >> CPlayerMove then does: >> some prelimilary copy like eyeangles and buttons >>prethink (calls prethink on the player) >>think (calls think on the player if set) >>setupmove (copy usercmd -> CMoveData) >> gamemovement >>finishmove (update the player origin, angles, etc from gamemovement >> (CMoveData) >> postthink (run animstate) >> >> the client-side is slightly different for networked players, but the >> local player runs the same process (more or less, through CPrediction >> instead of PlayerRunCommand. >> >> and note, that it doesn't happen precisely in that order for every >> command, as the client will run and transmit input/CUserCmd as fast as it >> can. >> >> Gamemovement is where you should be handling your "barrel roll"; why that >> it's not working for you, I cannot say as I cannot see your implementation. >> >> -Tony >> >> >> >> >> On Sun, Aug 19, 2012 at 2:07 PM, Michael Kramer wrote: >> >>> Alright, I was able to modify the angles by adding some code into the >>> multiplayer animstate, but I have a question for you. >>> >>> It seems that gamemovement adjusts only the origin, and not the >>> viewangles/player angles at all, so I'm assuming adding anything in there >>> would be wrong to do. >>> It also seems like the movement code is all over the place, in player, >>> gamemovement, in_mouse, playermove, etc is there a reason it is spread all >>> over the place? >>> >>> It seems like ideally all player movement should be controlled in 1 >>> place, and not 5 or 6 different areas... >>> >> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> >> > > > -- > *Michael Kramer, Software Engineer & SEO Expert* > http://www.siosphere.com | kra...@siosphere.com > *[c] 801-530-9454* > * > * > * > * > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please
Re: [hlcoders] Can't seem to modify Player Angles
If I attempt to modify the player angles in gamemovement, nothing changes, even though it is the last step pretty much, it should be able to overwrite everything else. Adjusting the angles in playermove, does work, even though it is called way before gamemovement. I can adjust the viewangles (engine->SetViewAngles()) in gamemovement, but can't adjust the player angles at all. Your hierarchy is very helpful though, so thank you for that, but it seems like finishmove does not use the angles from gamemovement, the code is in there (player->SetLocalAngles( move->m_vecAngles );) but no matter what m_vecAngles is set at, nothing changes even the slightest. I was hoping that animstate would update relative to the model/entities position, but it does seem like it is overwriting anything sent back from gamemovement in regards to angles. If I adjust the angles in animstate it properly updates. I can do this without updating angles at all, simply with a barrel roll animation, but was hoping I could do it all code wise easily. On Sun, Aug 19, 2012 at 1:54 AM, Tony "omega" Sergi wrote: > It's not that it's "all over the place" but rather they are different > components of the entire process. > The majority of the actual movement is handled inside gamemovement. > the in_* (CInput) handles the raw input itself for the local client (and > by default the view angles as manipulated by the mouse) which puts it into > CUserCmd. CUserCmd is then transmitted every frame down to the server which > is used by playermove and finally into CGameMovement for the final step, > and CPrediction also uses it to predict locally. > Once all of that is done, animstate is called from postthink every frame > to take the final result of everything and then decides what animations to > play as well as the final rendering angles of the player. > > So to summarize the whole process (from memory here, I might be missing > something): > > Input - Create CUserCmd > CUserCmd is sent for each frame to the server, and processed locally with > prediction > CPlayerMove then does: > some prelimilary copy like eyeangles and buttons >prethink (calls prethink on the player) >think (calls think on the player if set) >setupmove (copy usercmd -> CMoveData) > gamemovement >finishmove (update the player origin, angles, etc from gamemovement > (CMoveData) > postthink (run animstate) > > the client-side is slightly different for networked players, but the local > player runs the same process (more or less, through CPrediction instead of > PlayerRunCommand. > > and note, that it doesn't happen precisely in that order for every > command, as the client will run and transmit input/CUserCmd as fast as it > can. > > Gamemovement is where you should be handling your "barrel roll"; why that > it's not working for you, I cannot say as I cannot see your implementation. > > -Tony > > > > > On Sun, Aug 19, 2012 at 2:07 PM, Michael Kramer wrote: > >> Alright, I was able to modify the angles by adding some code into the >> multiplayer animstate, but I have a question for you. >> >> It seems that gamemovement adjusts only the origin, and not the >> viewangles/player angles at all, so I'm assuming adding anything in there >> would be wrong to do. >> It also seems like the movement code is all over the place, in player, >> gamemovement, in_mouse, playermove, etc is there a reason it is spread all >> over the place? >> >> It seems like ideally all player movement should be controlled in 1 >> place, and not 5 or 6 different areas... >> > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > > > -- *Michael Kramer, Software Engineer & SEO Expert* http://www.siosphere.com | kra...@siosphere.com *[c] 801-530-9454* * * * * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Can't seem to modify Player Angles
It's not that it's "all over the place" but rather they are different components of the entire process. The majority of the actual movement is handled inside gamemovement. the in_* (CInput) handles the raw input itself for the local client (and by default the view angles as manipulated by the mouse) which puts it into CUserCmd. CUserCmd is then transmitted every frame down to the server which is used by playermove and finally into CGameMovement for the final step, and CPrediction also uses it to predict locally. Once all of that is done, animstate is called from postthink every frame to take the final result of everything and then decides what animations to play as well as the final rendering angles of the player. So to summarize the whole process (from memory here, I might be missing something): Input - Create CUserCmd CUserCmd is sent for each frame to the server, and processed locally with prediction CPlayerMove then does: some prelimilary copy like eyeangles and buttons prethink (calls prethink on the player) think (calls think on the player if set) setupmove (copy usercmd -> CMoveData) gamemovement finishmove (update the player origin, angles, etc from gamemovement (CMoveData) postthink (run animstate) the client-side is slightly different for networked players, but the local player runs the same process (more or less, through CPrediction instead of PlayerRunCommand. and note, that it doesn't happen precisely in that order for every command, as the client will run and transmit input/CUserCmd as fast as it can. Gamemovement is where you should be handling your "barrel roll"; why that it's not working for you, I cannot say as I cannot see your implementation. -Tony On Sun, Aug 19, 2012 at 2:07 PM, Michael Kramer wrote: > Alright, I was able to modify the angles by adding some code into the > multiplayer animstate, but I have a question for you. > > It seems that gamemovement adjusts only the origin, and not the > viewangles/player angles at all, so I'm assuming adding anything in there > would be wrong to do. > It also seems like the movement code is all over the place, in player, > gamemovement, in_mouse, playermove, etc is there a reason it is spread all > over the place? > > It seems like ideally all player movement should be controlled in 1 place, > and not 5 or 6 different areas... > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Can't seem to modify Player Angles
Well, I don't really know why its all spread out like that, I guess they tried to make their design modular. But at the same time its pretty complicated and hard to understand. And about where to add code, its pretty much up to you, you can try to follow valve's layout, or go with your own thing. Just keep in mind upgradability, readability, and etc.. Of course, I'm probably not the best person to give this kind of advice, seeing how often I disregard those things ... On Sun, Aug 19, 2012 at 1:07 AM, Michael Kramer wrote: > Alright, I was able to modify the angles by adding some code into the > multiplayer animstate, but I have a question for you. > > It seems that gamemovement adjusts only the origin, and not the > viewangles/player angles at all, so I'm assuming adding anything in there > would be wrong to do. > It also seems like the movement code is all over the place, in player, > gamemovement, in_mouse, playermove, etc is there a reason it is spread all > over the place? > > It seems like ideally all player movement should be controlled in 1 place, > and not 5 or 6 different areas... > > > On Fri, Aug 17, 2012 at 12:27 PM, Psy_Commando wrote: > >> The animstates override player angles, if I remember correctly. You may >> want to check it out. >> >> On Fri, Aug 17, 2012 at 1:05 PM, Michael Kramer < >> gameexpertmas...@gmail.com> wrote: >> >>> I've been trying for the past few days to implement a "barrel roll" >>> function, by applying a transform on the player angles, but no matter what >>> I do, the angles never seem to update. >>> >>> I've tried implementing it in several places, including >>> gamemovement.cpp, and even setting the player angles to all 0, doesn't >>> affect a thing. >>> >>> I've tried tracing through my code, and it seems that the value gets >>> saved, but nothing ever updates on the player in-game. >>> >>> I'm wondering if there is something in the code that is overriding my >>> set angles, I've traced through and cannot seem to find anything involving >>> playermovement or the player itself that is modifying the angles. >>> >>> Thanks, >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>> >>> >>> >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> >> > > > -- > *Michael Kramer, Software Engineer & SEO Expert* > http://www.siosphere.com | kra...@siosphere.com > *[c] 801-530-9454* > * > * > * > * > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Can't seem to modify Player Angles
Alright, I was able to modify the angles by adding some code into the multiplayer animstate, but I have a question for you. It seems that gamemovement adjusts only the origin, and not the viewangles/player angles at all, so I'm assuming adding anything in there would be wrong to do. It also seems like the movement code is all over the place, in player, gamemovement, in_mouse, playermove, etc is there a reason it is spread all over the place? It seems like ideally all player movement should be controlled in 1 place, and not 5 or 6 different areas... On Fri, Aug 17, 2012 at 12:27 PM, Psy_Commando wrote: > The animstates override player angles, if I remember correctly. You may > want to check it out. > > On Fri, Aug 17, 2012 at 1:05 PM, Michael Kramer < > gameexpertmas...@gmail.com> wrote: > >> I've been trying for the past few days to implement a "barrel roll" >> function, by applying a transform on the player angles, but no matter what >> I do, the angles never seem to update. >> >> I've tried implementing it in several places, including gamemovement.cpp, >> and even setting the player angles to all 0, doesn't affect a thing. >> >> I've tried tracing through my code, and it seems that the value gets >> saved, but nothing ever updates on the player in-game. >> >> I'm wondering if there is something in the code that is overriding my set >> angles, I've traced through and cannot seem to find anything involving >> playermovement or the player itself that is modifying the angles. >> >> Thanks, >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > > > -- *Michael Kramer, Software Engineer & SEO Expert* http://www.siosphere.com | kra...@siosphere.com *[c] 801-530-9454* * * * * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Can't seem to modify Player Angles
The animstates override player angles, if I remember correctly. You may want to check it out. On Fri, Aug 17, 2012 at 1:05 PM, Michael Kramer wrote: > I've been trying for the past few days to implement a "barrel roll" > function, by applying a transform on the player angles, but no matter what > I do, the angles never seem to update. > > I've tried implementing it in several places, including gamemovement.cpp, > and even setting the player angles to all 0, doesn't affect a thing. > > I've tried tracing through my code, and it seems that the value gets > saved, but nothing ever updates on the player in-game. > > I'm wondering if there is something in the code that is overriding my set > angles, I've traced through and cannot seem to find anything involving > playermovement or the player itself that is modifying the angles. > > Thanks, > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
[hlcoders] Can't seem to modify Player Angles
I've been trying for the past few days to implement a "barrel roll" function, by applying a transform on the player angles, but no matter what I do, the angles never seem to update. I've tried implementing it in several places, including gamemovement.cpp, and even setting the player angles to all 0, doesn't affect a thing. I've tried tracing through my code, and it seems that the value gets saved, but nothing ever updates on the player in-game. I'm wondering if there is something in the code that is overriding my set angles, I've traced through and cannot seem to find anything involving playermovement or the player itself that is modifying the angles. Thanks, ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
