@ My hero :-P - That line is actually this now:
But besides the z parameter change, I think you're thinking that 'c\tzPivot' is at the player, which it is not. 'c\tzPivot' is actually a child pivot that is always at a local 0,0,-20 position relative to the main camera pivot (which is at the head of the player). Thus, my line of code there will move the camera back until it reaches that pivot (0,0,-20). The reason for it is so when there's nothing between the camera and player (ie linepick = 0) that the camera doesn't just fly off into space. 'tzPivot' is the limit. (hehe it rhymes)
@ Verty - Sure you'd have a faster fps but of course in compromize it would be taking alot more frames to check where the camera should be, plus if I read correctly you'd need two 'updateworld()'s'. But something I tried was along those lines:
and even having a cube scaled to the length of the distance between the camera and player and tested for collision
+ moving the camera to the collision xyz globaly...
And that didn't work well, however I probably just implemented it wrong because it sure makes sense in theory.
On a lighter note -- I now have an extremely fast an optimized 3rd person camera that works perfectly for a ninja fight!
Many thanks to all!
Mat -- tizzle
PS - I think an addition to the code archives is in order... ;-)
If EntityZ(c\Cam) > EntityZ(c\tzPivot) Then MoveEntity c\Cam, 0,0,(EntityZ(c\tzPivot)-EntityZ(c\Cam))*0.1
But besides the z parameter change, I think you're thinking that 'c\tzPivot' is at the player, which it is not. 'c\tzPivot' is actually a child pivot that is always at a local 0,0,-20 position relative to the main camera pivot (which is at the head of the player). Thus, my line of code there will move the camera back until it reaches that pivot (0,0,-20). The reason for it is so when there's nothing between the camera and player (ie linepick = 0) that the camera doesn't just fly off into space. 'tzPivot' is the limit. (hehe it rhymes)
@ Verty - Sure you'd have a faster fps but of course in compromize it would be taking alot more frames to check where the camera should be, plus if I read correctly you'd need two 'updateworld()'s'. But something I tried was along those lines:
and even having a cube scaled to the length of the distance between the camera and player and tested for collision
+ moving the camera to the collision xyz globaly...
And that didn't work well, however I probably just implemented it wrong because it sure makes sense in theory.
On a lighter note -- I now have an extremely fast an optimized 3rd person camera that works perfectly for a ninja fight!
Many thanks to all!
Mat -- tizzle
PS - I think an addition to the code archives is in order... ;-)