Adding new positions..." questions

#1 OK with the not firing issue here is some more info. The exact same technique works fine for mounitng/dismounting vehicles. Additionally, if you change weapons they will start working again. So I guess its something getting messed up when swimming.

#2 Ignore question number 2, apparently my eyesight is horrid.

#3 OK I almost have the player eye sight per animation problem figured out but my fix introduces another problem. I read a bit on Jacob Dankovchik's "More Realistic First Person" resource and decided use one of his methods.

In Player::setActionThread change

mActionAnimation.firstPerson = fsp;

to

mActionAnimation.firstPerson = true;

and change

mActionAnimation.animateOnServer = fsp;

to

mActionAnimation.animateOnServer = true;

Now this does solve the eye transform issue but now I see a weapon rendering issue. The weapon disappears at certain angles in first person view.

If anyone has some ideas or better methods I would really appreciate it.

#4 Well it seems it mostly happens when I am in the crouch position. No idea why.

#5 That has something to do with the bounds boxes. I think your bounds box isnt big enough to house the mounted image, so thats why it will dissapear at different angles.

#6 Sorry for the double post, but I am interested in your question number 2. What exactly did you do to make the player conform to the terrain for the prone position? I have been looking into doing that as well but just havent gotten around to it.

#7 Thanks Adam for that answer. I fixed number 2 by adding in the conform to terrains resource witha couple of minor changes.

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3148

Basically I completely got rid of the variable, conformToGround. So when it was needed in setPosition and setRenderPosition in the if statements

if (mDataBlock && mDataBlock->conformToGround)

I used this instead:

if(getPlayerPosition() == 3 && mWaterCoverage == 0.0f)

The just follow whatever was added in the later comments and it works great.

I figured out how to adjut my problem with the bounding box, I would just like to know if there is a good way to fix the muzzlevector when using that code?

#8 What happens to the muzzlevector when your in crouch or prone? Also, for some reason using this resource I cant get the prone/crouch forward anims working. Not sure what it is, but I havent been able to fix this issue.

Also, how are you animating your players crouch and prone animations? Are you just moving their feet up and adjusting the bounds box or what? My players are always floating above the bounds box when they go to prone/crouch.

#9 Well I gotta be honest I ripped mine off from the MG starter kit. Going to replace those later with TorqueMotion.

As for the muzzle vector, it still shoots at the old standing level.

#10 There is a parameter in the WeaponImage datablock called correctMuzzleVector. If you set correctMuzzleVector = true; it should work.

#11 Already done, no help.

#12 What I am seeing is that even though the animations and camera are updating properly now, the muzzleVector is not adjusting according to the new positions. This is likely due to the eye transform being incorrectly updated.

#13 Well the problem with number one was a combination of a bug with the resource and a bug on my side with the script. I use weapon cycling and wasn't setting the lastWeapon flag when changing the weapons.

Now the problem with the code side is completely different and well is kind of confusing. It is screwwing up the ghosting when you swim. I know this because at the bottom of Player::updateMove it has a !isGhost check. This helped determine if you are inLiquid. Well once you start to swim it no longer passes that check. So with that being said ShapeBase::setImage will also fail because it also checks !isGhost.

I have no idea why this is happening yet, but now at least I know what it is and now my weapon does not mount again after swimming which proves what I discovered.

Has anyone that used that resource resolved this yet?

#14 I se that on the resource site that others have also had issues resolving the multipler for this. If someone has fixed that could they please post the code?

#15 Yeah I just tried an actual multiplayer game and it doesn't work at all. You know it would help if someone could just give me somewhere reasonable to dig. I have been lookng all through the code and cannot find a reason for it to fail.

#16 Well I have everything fixed EXCEPT the multplayer ghosting issue. I used Josh Albrecht's Melee tutorial code that affected the player (well most of it) and it fixes the weapon muzzle vector, camera positions, and it even makes the accuracy dead on if you have mauzzle correction set to true in your image script.

This is the code that I used.

Player::Player()
{
...
mActionAnimation.animateOnServer = true;

}

...

void Player::setActionThread(U32 action,bool forward,bool hold,bool wait,bool fsp, bool forceSet)
{
...
      mActionAnimation.firstPerson = true;
      mActionAnimation.holdAtEnd = hold;
      mActionAnimation.waitForEnd = hold? true: wait;
      mActionAnimation.animateOnServer = true;
      mActionAnimation.atEnd = false;
      mActionAnimation.delayTicks = (S32)sNewAnimationTickTime;
      mActionAnimation.atEnd = false;

      if (sUseAnimationTransitions && (isGhost() || mActionAnimation.animateOnServer)) {
         // The transition code needs the timeScale to be set in the
         // right direction to know which way to go.
...


void Player::updateAnimation(F32 dt)
{
  ...
   // If we are the client's player on this machine, then we need
   // to make sure the transforms are up to date as they are used
   // to setup the camera.
   if (isGhost() || mActionAnimation.animateOnServer) {
      if (getControllingClient()) {
         updateAnimationTree(isFirstPerson());
         ...

Now if you make those changes it should work great for a single player game. No since I have figured all of this crap out and how to fix it, could someone please help me with the multiplayer???

#17 By the way the not firing after swimming in my first part of this thread is due to the multiplayer problem if you missed it.

#18 OK I fixed everything but I need to ask one more question because I suspect this is the source of one more issue.

What yould ActionAnimBits be set at? Should it be increased by 1 for every new position added? I ask because now when mounted to a vehicle my game is laggy as hell in multiplayer.

#19 I believe that value sets how many bits are used to store and transmit the Action Number of the animation. For example, if ActionAnimBits is 8 then you can have 256 different animations, since 8 bits can store numbers 0-255.

#20 OK that sounds reasonable. So the 9 that was already there in TGEA should be more than adequate.