Big Fixes From Lore

Hey Guys.

Lately, I've been running into TGE bugs with some of the newer Lore features. With a little editing, these are the fixes for em. They've all been emailed to Ben Garney for inclusion into TGE Head, but I dont believe you'll see em till 1.4. So if anyone wants them sooner and is running into these problems...

Bug in Player's Look Animations
The Players updateLookAnimation function uses the wrong datablock value for its horizontal look position. It uses maxLookAngle by default, which in stock TGE is only ever used for the vertical look max. maxFreeLookAngle is used for the head.z movement, and so the values do not match up and you'll get wierd left/right look animations where its out of sync with where your pointing.

void Player::updateLookAnimation()
{
...
if (mHeadVThread)
{
F32 tp = (mHead.x - mHeadVRange.min) / mHeadVRange.delta;
mShapeInstance->setPos(mHeadVThread,mClampF(tp,0,1));
}
if (mHeadHThread)
{
F32 dt = 2 * mDataBlock->maxlookAngle;
F32 tp = (mHead.z + mDataBlock->maxlookAngle) / dt;
mShapeInstance->setPos(mHeadHThread,mClampF(tp,0,1));
}
}

Changes to
if (mHeadHThread)
{
F32 dt = 2 * mDataBlock->maxFreelookAngle;
F32 tp = (mHead.z + mDataBlock->maxFreelookAngle) / dt;
mShapeInstance->setPos(mHeadHThread,mClampF(tp,0,1));
}

It could have been changed to act more like the Vertical thread, where the animation expects a full 180 degrees left and right, and basically reuse the mHeadVThread block. In my case, the art was already setup to use the angle defined. So path of least resistance here. Consistency would state, a full 180 degree setup be more consistent with the way up down handles. Or change up/down.



Bug in the Win32 net connection code.
I was having a problem with a postEvent having the wrong socket tag, using the previous tag actually, which in my case was for a different object altogether.

In the following code, you'll see that the notifyEvent.tag doesn't get set to the socket id that actually activated the event. It just sets the state
I added 'notifyEvent.tag = temp->socket;' after the notifyEvent.state is set and it works as intended. I did also take a look and verified that mac and unix have the tag also, so its a Win32 bug only.

in static LRESULT PASCAL WinsockProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
line 128
if (error)
{
notifyEvent.state = ConnectedNotifyEvent::DNSFailed;
::closesocket(temp->socket);
}
else
{
...
}
Game->postEvent(notifyEvent);

final code looked like
line 128:
if(error)
{
notifyEvent.state = ConnectedNotifyEvent::DNSFailed;
notifyEvent.tag = temp->socket;
::closesocket(temp->socket);
}
else
{
...
}

[Profiler Stack Overflow
I found 3 starts that could exit out without an end.

Line 157 in gameProcess.cc:
if (!res)
return;
Line 636 and 800 in precipitation.cc
the Start is before the
638: GameConnection* conn = GameConnection::getServerConnection();
639: if (!conn)
640: return; //need connection to server
641: 642: ShapeBase* camObj = conn->getCameraObject();
643: if (!camObj)
644: return;
645: in 2 functions. I just moved it to afterwards. easier that way.

I did notice something odd about it. In debug build, it would assert, but it keeps going in the background without crashing. So I imagine release builds just have it fucking up the profiler