[hlcoders] "Unable to load authentication library", then crash
This started about 2 weeks ago. When you try to run the debug version of a build, the game launches fine to the opening menu. But when the level starts to load, it gets about half way and then an error box pops up announcing "Unable to load authentication library, exiting...", followed by a game crash. Building the release version allows the game to run normally. What happened to the debug builds? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Sprites not animating on linux server.
This problem has appeared here before, but I don't think there was a
solution ever posted, and from what I think I've found, it looks like
the problem is in the engine itself.
The problem is that env_sprite's do not animate when a client connects
to a linux-based server. I've traced the problem to this line of code:
** inside ::Spawn(), sprite.cpp about line 162:
m_flMaxFrame = (float)modelinfo->GetModelFrameCount( GetModel() ) - 1;
The problem seems to be that m_flMaxFrame gets sets to 0 under linux
which causes the AnimateThink() function not to run, which in turn
freezes the animation. GetModelFrameCount() appears to be an engine
function call and therefore can't be fixed via the SDK. Any thoughts on
this?
**
One other problem I've noticed (well not a problem, but it will bite
you). Do the following somewhere inside Sprite.cpp and run it:
(Assume m_flSpriteFramerate has been previously set to 10.0)
{
...
float x = m_flSpriteFramerate;
Msg("X: %f m_flSpriteFramerate: %f\n", x, m_flSpriteFramerate);
...
}
The results will be:
X: 10.0 m_flSpriteFramerate: 0.0
How did that happen? It turns out if you define a variable as a Netvar,
you can't use it in print functions. This modified version does work:
Msg("X: %f m_flSpriteFramerate: %f\n", x, m_flSpriteFramerate.Get() );
Beware of printing Netvars because of this. It will drive you nuts if
you overlook it. (Is there a way to do an overload to prevent this?)
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] jerky platforms
--
[ Picked text/plain from multipart/alternative ]
The client shouldn't even know the entity's name anyways... it should only
know the nearest defined network class relative to the networked entity's
class. What function do you use to retrieve the entity's name on the
client?
--
ts2do
--
Msg("cl: %s\n", pEnt->GetClassname() );
Actually, that's kinda unexpected about the client not knowing the
entities classname. Doesn't it have a copy of the BSP and spawn it's own
copy of the entities? I would have thought that when the client spawns
its own version of an entity that the correct classname would get set.
In fact, I have code on the client that looks for specific entity types.
It's a bit scary now that it's been revealed that the client is loose
with the entity names.
On the other hand, the network class might explain what's happening with
the classname since func_platrot doesn't have any network vars defined,
but the baseclass (func_plat) does.
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] jerky platforms
When making maps, with a func_door as my platform, and setting the move value higher then 120 units/s the player would be left under the platform, and travel at around 100 units/s - the jerky movemnt was not noticable, but it was very sad to see the platform way above you and you moving up on an 'invisable' platform. So this might be prediction code? Adam My Website http://www.ammahls.com Lead Programer NightFall http://www.nightfallmod.net Developer of CST and ZHLT 3.0 http://www.zhlt.info Team Lead - Prime - http://www.nigredostudios.com It's kinda looking like it's a prediction issue combined with the fact that the plats don't simulate their physics nearly as often as the player, so they're a bit jerky even with good prediction. I would think that the client would smooth the updates from the server, but that doesn't seem to be happening. Unfortunately, the interpolation code is rather complex and heavily burdened with nested STL macros making it very hard to read (at least for me). Plus the interpolation stuff isn't really documented making things that much more difficult to debug. It all seems to come down to m_vecOrigin and m_iv_vecOrigin which are defined on the client. As I mentioned, this stuff isn't documented very well, but I believe that when the server sends the updated m_vecOrigin to the client, it gets intercepted by the interpolation code and this raw value is stored in m_iv_vecOrigin (actually m_iv_vecOrigin seems to be an array which stores a history of the changes). Then any references to m_vecOrigin on the client are overloaded by the interpolation code which substitutes the interpolated value of m_vecOrigin instead of the raw value sent by the server. The problem seems to be that there is no actual interpolation taking place, plus the client is falling well behind the server which respect to the plat's actual position. This is happening on a listen server which has essentially 0 ping. The problem is much worse on a dedicated server with a 50 or higher ping. The fun part is that both the client and server know when the plat starts and how fast it moves. This should be a trivial entity to predict. But somehow, it's not. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] jerky platforms
Here is a somewhat long log I made of a player standing on a platform. I made a special map which is just a single room with a platform in the center. The origin of the platform at the bottom is (0,0,4). The platform moves up at 75units/sec. I printed the platform state everytime the ProcessMovement() function is called for both the client and server. I also printed the classname of the entity that CategorizePosition() thinks the player is standing on. The client values are marked with a "cl" and the server "svr". Two things become apparent from studying the log. The first is that the client is not interpolating very well. It's stair stepping the plat's position. (The server is also stair stepping badly too.) Secondly, the further the plat travels, the wider the gap between where the server thinks the plat is located and where the client thinks it is. When I stopped the log, the plat was half way up its 256 unit travel (at 130 units). You'll notice that at that point the client was a full 10 units behind the server. You'll also notice a discrepency in the classname of the plat between server and client too. (This is being run as a listen server.) I understand that a plat can't be given the same level of simulation that a player gets. But there must be someway to improve this behavour. svr CategorizePosition: func_platrot vz: 0.00 ProcessMovement cl plat: z: 4.00 vz: 0.00 cl CategorizePosition: class C_World vz: 0.00 Player steps on platform here. cl CategorizePosition: func_plat vz: 0.00 ...PerformPush... ProcessMovement cl plat: z: 4.00 vz: 75.00 cl CategorizePosition: func_plat z: 75.00 <--- notice class name of plat on client. it's wrong! cl CategorizePosition: func_plat vz: 75.00 ProcessMovement svr plat: z: 5.125000 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 <--- notice class name on server. It's right. svr CategorizePosition: func_platrot vz: 75.00 ProcessMovement svr plat: z: 5.125000 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 4.00 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePoition: func_plat vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 4.00 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 4.00 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ProcessMovement svr plat: z: 8.50 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platro vz: 75.00 ProcessMovement svr plat: z: 8.50 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 ProcessMovement svr plat: z: 8.50 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 8.423737 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ProcessMovemnt cl plat: z: 8.423737 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ProcessMovement cl plat: z: 8.423737 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 8.434322 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ProcessMovement svr plat: z: 10.75 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 ProcessMovement svr plat: z: 10.75 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 8.445797 vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 8.456138 vz: 75.00 cl CategoizePosition: func_plat vz: 75.00 cl CategorizePosition: func_plat vz: 75.00 ProcessMovement svr plat: z: 13.00 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 ProcessMovement svr plat: z: 13.00 vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 svr CategorizePosition: func_platrot vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 8.467813 vz: 75.00 cl CategorizePosition: func_plat v: 75.00 cl CategorizePosition: func_plat vz: 75.00 ...PerformPush... ProcessMovement cl plat: z: 8.477271 vz: 75.00 cl CategorizePosition: func_plat
[hlcoders] jerky platforms
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
>
>
>>/ First, for some reason the client shows the platform as class
>/>/ "func_platrot" which is correct. But the the server lists the
>/>/ same entity as "func_plat" (the base class). I discovered
>/>/ this by accident by printing the classname of the ground
>/>/ entity indentified in the
>/>/ ClassifyPosition() routine. (I remade the map to force all
>/>/ the plats to func_plat and this problem went away, but the
>/>/ other problems remained.)
>/
>That sounds like a bug. How are you printing the class name? Anyway,
>probably not the root problem.
>
>
>
I did the following to find the weirdness with the classname: (inside
the CGameMovement::CategorizePosition( void ), about line 3280)
if (pm.m_pEnt)
{
#ifdef GAME_DLL
Msg("svr base: %s\n", pm.m_pEnt->GetClassname());
#else
Msg("cl base: %s\n", pm.m_pEnt->GetClassname());
#endif
}
SetGroundEntity( pm.m_pEnt ); // Otherwise, point to index of ent under us.
>>/ Third, the jerkiness seems to be from the player being kicked
>/>/ up into the air (sorta like going up a stair step) and then
>/>/ falling back to the plat. The result is that the FL_ONGROUND
>/>/ flag is oscillating randomly (along with the ground entity
>/>/ switching from NULL, to the platform, and back to NULL) while
>/>/ the platform is in motion. The weird thing is that the code
>/>/ used to navigate stairs doesn't seem to be the thing that's
>/>/ doing this.
>/
>It sounds like the player isn't finding the ground entity. There was
>another bug we fixed in episode 1 that could have fixed this:
>
>/src/game_shared/collisionproperty.cpp:
>
>void CCollisionProperty::CollisionAABBToWorldAABB( const Vector
>&entityMins,
> const Vector &entityMaxs, Vector *pWorldMins, Vector *pWorldMaxs
>) const
>{
>
>// delete this section
> if ( IsSolidFlagSet(FSOLID_ROOT_PARENT_ALIGNED) )
> {
> matrix3x4_t mat;
> // Get Root Parent's axes - align box to those
> MatrixCopy( *GetRootParentToWorldTransform(), mat );
> MatrixSetColumn( GetCollisionOrigin(), 3, mat );
> TransformAABB( mat, entityMins, entityMaxs, *pWorldMins,
>*pWorldMaxs );
> return;
> }
>// end delete
>
>
>this code was made obsolete hadn't been removed. It can cause problems
>with players riding on rotating entities set to SOLID_BSP.
>
>You might give it a try. I haven't tried to debug or repro this problem
>- I'm just reading the messages here, so again I have no idea if this
>will fix the problem you're seeing.
>
>Jay
>
I'll try that. But the player does seem to be seeing the ground entity.
But it appears he's bouncing off it. The player touches the moving plat,
gets kick up, gravity takes over, and the plat catches up to the
falling player and the cycle repeats.
This is just a guess, but I think this has something to do with the
interpolation of the plat's position and speed. The client sees the
movement as a smooth due to the client-side interpolation. But since the
server physics seems to be run far less often that the client frame
rate, I think the server is 'stair-stepping' the position of the plat
causing the player to skip up everytime the plat's position gets updated
on the server. Maybe you could confirm this guess. If this is indeed the
case, I would be tempted to add code to do the needed interpolation
server-side, but I need to know what to use for the 'time since the last
physics update' on the server side to do the necessary interpolation
between physics frames. I'm guessing there is a global variable
somewhere to get this.
BTW: why would the m_vecVelocity read as 0 on the server for a moving plat?
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] jerky platforms
I don't buy that. The plats in Q2 and in HL1 both worked properly in mp. Plus, because the plats are a predicted entity on both the client and server, there is no reason for the movement to be messed up the way it is. And this doesn't explain why the classname and velocity information is grossly different between client and server. For that matter, why is the server wrong and not the client? If anything, it should be the other way around since the plat runs on the server side. I'm familiar with the playermovement code. I have a jetpack and grapple in my mod which work very smoothly. The problem is the playermovent goes to hell when the ground entity velocity information gets applied (specifically when there is a positive Z velocity). The question is why. Simple. The player is the only entity in the engine that is completely different from any other entity. All player movement, is done via gamemovement; and is predicted on the client. Even the vphysics shadow is basically just a hack, it's on the server only. Secondly, there is a bug with this (or incomplete code rather) that's been around since Dave 'Zoid' Kirsch wrote the shared PMOVE (or gamemovement) system for quakeworld, where the client doesn't properly know all the collision for the other entities, at the time that it's needed. It's documented in the q1/q2 engine source somewhere. Essentially, the player acts like it's own 'god'. It decides where and when it can move, and making other entities push it around, happen AFTER it decides if it can or not. So when the player is on the plat, the gamemovement code already makes gravity suck it down. So then the plat goes up, and it tries to push the player up, well the player is applying gravity, and on the client thinks there's nothing there (it can't see the platform completely) so it applies gravity and pushes itself down. Now, the server is trying to tell the player; okay there's an entity trying to move us up, so it "teleports" the player. Now, remember, the player movement code is all teleportation, it doesn't really have velocity in the same manner, because it doesn't move the same way that all other entities do. The only way to truly overcome this is to make the player move via forces instead of shifting origin directly, so the player can be simulated at the SAME TIME as every other entity, instead of before or after it. It's a major flaw that this engine has inherited from an engine created 10 years ago. The vphysics shadow doesn't really help much either, it's perfectly fine in singleplayer where there is no client side prediction, but when you get hl2mp with prediction on, that's why you jump around when you stand on a box, and whatnot. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] jerky platforms
I have been trying to figure out why the platforms are so jerky in their motion. I've discovered a few of things: First, for some reason the client shows the platform as class "func_platrot" which is correct. But the the server lists the same entity as "func_plat" (the base class). I discovered this by accident by printing the classname of the ground entity indentified in the ClassifyPosition() routine. (I remade the map to force all the plats to func_plat and this problem went away, but the other problems remained.) Second, if you print the m_vecVelocity of the ground entity, the client shows the correct velocity, but the server always shows it as being 0. This can't be right since the plats are moving correctly. I'm not sure what's happening here. () Maybe something is resetting it to zero before the print statement in ClassifyPosition? Third, the jerkiness seems to be from the player being kicked up into the air (sorta like going up a stair step) and then falling back to the plat. The result is that the FL_ONGROUND flag is oscillating randomly (along with the ground entity switching from NULL, to the platform, and back to NULL) while the platform is in motion. The weird thing is that the code used to navigate stairs doesn't seem to be the thing that's doing this. Any ideas? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Jerky Movement when player is on moving lift/elevator.
I've been fighting that problem for a very long time. In fact, I'm actually having to come back to it yet again. I think this issue has appeared in the forums several times before with no resolution. The jerkiness is quite real in the motion of the player. Entities placed on plats jerk severely (even worse than players do). It looks awful. I've looked at the code a number of times to get things to move smoothly with no luck. It seems that the BaseVelocity code which is supposed to help objects move on plats doesn't work very well. I'm not sure why. I'll try the smoothstairs trick to hide the problem for now, but I would rather get to the root of the problem instead of just masking it. It's interesting that the hl2mp seems to work ok. I haven't tried it myself, but it wouldn't be the first thing that works properly in hl2mp but not in the SDK. The weapon viewmodel skipping/jerkiness is another example. Incidently, it was suggested that the viewmodel problem be fixed by making the viewmodel code client-side only. I actually started to do this, but I then came to the conclusion that that solution was a major hack -- especially when essentially the same code seems to work with multiplayer version of the SDK, but not with the regular version of the SDK. I still don't know what the multiplayer version is doing differently to make the viewmodels work correctly. Finally, I wish that Valve would roll back their changes to the SDK tools. The latest version of the tools do not work properly. If you're not going to fix them, then at least go back to a version that did work. It's not nice doing unsolicited updates, installing broken code, then just leaving it that way. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Viewmodel skipping animation saga - continued
This is a very old problem -- One to which no solution has yet been found. The problem is with the viewmodel skipping and jerking in its animation playback. I traced the problem to the server and client fighting over m_flCycle, m_nSequence, m_flAnimTime, m_flPlaybackRate networked variables. In particular, the client sets these variables and then a short time later (lag time) the server also sets these variables since they are networked. The result is an animation skip/jerk. The obvious fix is to block the server from changing the value of these variables and let the client do the viewmodel animation independantly from the server. However, this is proving exceedingly difficult to do. I changed the viewmodel class's send table as follows: IMPLEMENT_SERVERCLASS_ST_NOBASE(CBaseViewModel, DT_BaseViewModel) SendPropModelIndex(SENDINFO(m_nModelIndex)), SendPropInt (SENDINFO(m_nBody), 8), SendPropInt (SENDINFO(m_nSkin), 10), // SendPropInt (SENDINFO(m_nSequence), 8, SPROP_UNSIGNED), SendPropInt (SENDINFO(m_nViewModelIndex), VIEWMODEL_INDEX_BITS, SPROP_UNSIGNED), // SendPropFloat (SENDINFO(m_flPlaybackRate), 8, SPROP_ROUNDUP, -4.0, 12.0f), SendPropInt (SENDINFO(m_fEffects), 10, SPROP_UNSIGNED), // SendPropInt (SENDINFO(m_nAnimationParity), 3, SPROP_UNSIGNED ), SendPropEHandle (SENDINFO(m_hWeapon)), SendPropEHandle (SENDINFO(m_hOwner)), // SendPropInt( SENDINFO( m_nNewSequenceParity ), EF_PARITY_BITS, SPROP_UNSIGNED ), SendPropInt( SENDINFO( m_nResetEventsParity ), EF_PARITY_BITS, SPROP_UNSIGNED ), SendPropInt( SENDINFO( m_nMuzzleFlashParity ), EF_MUZZLEFLASH_BITS, SPROP_UNSIGNED ), END_SEND_TABLE() As I understand the SDK docs, the ST_NOBASE should prevent the base class variables (namely m_flCycle, m_flSequence, etc. from CBaseAnimating) from being sent to the client. However, what I'm finding is that they are still get transmitted. I also tried |SendPropExclude(…) on the variables, but they are still getting sent to the viewmodel. The only way I found to stop the server from screwing with the viewmodel was to go into the CBaseAnimating class and strip m_flCycle, m_nSequence, etc. completely from the network variables list and remove the prediction completely. Arrgh. There has to be something that I'm missing, or something that isn't working as advertised. Any Ideas? | ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] m_angEyeAngles gets corrupted on client
This is an old problem that I've never been able to fully fix. The
problem is that that when you watch a another player look up and down,
the model animation jerks violently and randomly. As a test, I added a
print function to watch the value of m_angEyeAngles[PITCH] on the
screen as I looked up and down. The print statement was added to on the
server side and client side as follows:
**server side
void CSDKPlayer::PostThink()
{
BaseClass::PostThink();
QAngle angles = GetLocalAngles();
angles[PITCH] = 0;
SetLocalAngles( angles );
// Store the eye angles pitch so the client can compute its
animation state correctly.
m_angEyeAngles = EyeAngles();
if (m_angEyeAngles[PITCH] > 180.0f)
m_angEyeAngles -= QAngle(360.0f, 0, 0);
m_PlayerAnimState->Update( m_angEyeAngles[YAW], m_angEyeAngles[PITCH] );
// TEST PITCH
Msg("test: server: %f\n", m_angEyeAngles[PITCH]);
}
** client side
void C_SDKPlayer::UpdateClientSideAnimation()
{
// TEST PITCH
Msg("test: client: %f\n", m_angEyeAngles[PITCH]);
// Update the animation data. It does the local check here so this
works when using
// a third-person camera (and we don't have valid player angles).
if ( this == C_SDKPlayer::GetLocalSDKPlayer() )
m_PlayerAnimState->Update( EyeAngles()[YAW],
m_angEyeAngles[PITCH] );
else
m_PlayerAnimState->Update( m_angEyeAngles[YAW],
m_angEyeAngles[PITCH] );
BaseClass::UpdateClientSideAnimation();
}
The results were the the server side values moved smoothly up and down
as the player pitch changed. But on the client, the values did something
like this while the view angle is moving down:
0
1
5
10
12
87 <--skip
15
20
-32 <--skip
-5 <--skip
25
54 <--skip
27
..etc..
Notice the wild skips in what should be a monotonic increase in values.
As another test, I added yet another print function in the dt_recv
function RecvProxy_FloatToFloat which is handling the networked variable
for pitch. It shows that the correct value for pitch is being received
by the client. So the pitch value is getting seriously corrupted
somewhere between the client receiving the pitch value in the dt_recv
code and when it finally reaches C_SDKPlayer::UpdateClientSideAnimation().
Any ideas?
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Steam Service Closing Unexpectedly
I've also had multiple Steam icons sitting on my toolbar. This started about a weerk or so ago. It requires that all the instances be closed and Steam restarted from scratch in order to launch anything. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] viewmodel animation skipping problem has returned
Actually, I didn't do anything to make the 3rd person work. The 3rd person seemed to work without any changes. It's not jittery at all. But the old EyeAngle pitch bug is still there which has never been patched in the SDK. But the problem I'm seeing isn't with the 3rd person view. Rather it's with the 1st person viewmodel. It's easily seen when viewing the shotgun model during its reload animation. But the other weapons do it as well during their fire sequence (it's just not as obvious). There was something done in the hl2mp_dll code to fix the problem, but I can't figure out what. (The hl2mp_dll code isn't used in the 'start from scratch' version of the SDK.) I tried to figure this out a number of times, and the nearest I came to solving it was that I found that it seems to have something to do with the m_flCycle variable skipping. It seems to be the result of the client trying to resync to the server since this is an interpolated networked variable. But I don't understand the nuances of the animation and how the game manages networked variables well enough to come up with a fix. Weird, if you start from that option the 3rd person view is fine. Maybe something you did to fix the 3rd person animations in the HL2DM code is having an adverse effect on the "start from scratch" code. On 11/12/05, Matthew Lewis <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: / />/ This is an old bug that I never found a solution for. It involves the />/ viewmodel animation skipping in multiplayer games. The problem was />/ present in early versions of the SDK, but disappeared in later versions. />/ About a week ago, I decided to move my mod over to the "Start a mod from />/ scratch (advanced users)" flavor of the mod builder. The previous />/ version of my mod was based on the more generic "modify half-life 2 />/ multiplayer" flavor. Now the viewmodel animation skipping problem has />/ returned. So it seems that the viewmodel animation is handled />/ differently depending on which option you select to start your mod. I />/ would really like to stay with the "build from scratch" version, but the />/ animation skipping is really annoying. Has anyone ever found out why />/ this happens and what to do about it? /> ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] viewmodel animation skipping problem has returned
This is an old bug that I never found a solution for. It involves the viewmodel animation skipping in multiplayer games. The problem was present in early versions of the SDK, but disappeared in later versions. About a week ago, I decided to move my mod over to the "Start a mod from scratch (advanced users)" flavor of the mod builder. The previous version of my mod was based on the more generic "modify half-life 2 multiplayer" flavor. Now the viewmodel animation skipping problem has returned. So it seems that the viewmodel animation is handled differently depending on which option you select to start your mod. I would really like to stay with the "build from scratch" version, but the animation skipping is really annoying. Has anyone ever found out why this happens and what to do about it? BTW, the last time I fought this problem, I found that the problem seems to stem from the client and the server falling out of sync and then snapping back with the m_flAnimTime variable (maybe). ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player model always faces east.
I am having trouble with some recompiled player models. I took the female_03 model, decompiled it, added a new skin, and recompiled it. The model works fine in the HL model viewer, and it works in the game. But it soon became apparent when other players joined the server that the model never changes yaw. It always seems to face east (0 degrees yaw). I'm thinking it might be because it uses (?) the 8-way run animation. If so, then it seems that the problem might lie somewhere in the CBasePlayerAnimState:: routines. In particular, maybe ComputePoseParam_MoveYaw() has a problem. I don't see anything obvious. This has me quite stumped. Any ideas? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] re: Ragdoll causes Assert (ragdoll_shared.cpp: 274 pCollide)
Sounds likely. But the thing is that the decompiler didn't produce a .phy file. I was also unable to find one in the sample player models provided in the SDK. I read thru the .qc files looking for a hint as to where the phy file might be, but didn't find one. There must be one somewhere. The question is 'where?". It sounds like your process isn't producing an equivalent .phy file. Try using the original file. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Ragdoll causes Assert (ragdoll_shared.cpp: 274 pCollide)
I am trying to figure out why the ragdoll model causes an Assert() to be thrown. What I did was take one of the HL2 models (in this case the humans/group03/female03.mdl) and decompile it. I changed the qc file so that the model would have multiple skins and recompiled it using studiomdl. The model looks fine in the model viewer and plays well in the game until the player dies and the model goes into ragdoll mode. The game then throws an Assert() "ragdoll_shared.cpp: 274 pCollide". It would seem that this has some to do with a missing collision model. But I don't know how to fix it. I recompiled everything the decompiler provided me. Any suggestions on how to fix this? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] XSI SMD exporter problem
I know that this is not strictly a coding issue, but it's significant enough that it is holding up progress on my mod and the Valve-ERC forums were no help. The problem I'm having is trying to attach a weapon model to the hands model provided in the SDK. The weapon model is skinned and has a simple skeleton (a bone for the gun body and one for the clip). I merged this model with the hands model and set the parent bone of the weapon as a child of the Bip01_R_Hand (sp?) node in the model hierarchy. I then froze all the modeling operations. The weapon animates work just fine in XSI. But when you export it, the exporter breaks the hierarchy assignment between the weapon and the right hand node which causes the animations to go terribly wrong. You can verify that this is happening by looking at the generated reference SMD file and seeing that the weapon is now assigned to node -1 rather than the r_hand node (which is 43 in my case). If you try to go ahead and compile the SMD file and view it in the model viewer, you'll see the weapon staying down at the player's side rather than following the motion of the r_hand. I think the problem might be that the exporter isn't recognizing that the two meshes (one for the hand model, the other for the weapon) belong to the same skeleton by virtue of the parenting of the weapon to the hand. Instead, the exporter seems to be treating these as two seperate models with independent skeletons. I can probably fix this by merging both meshes, but that screws up the vertex assignments which makes pasting new weapons into existing hand model/animation sets a real pain. Is there a way around this? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] platform trigger touch not working in SDK
Of course, now that I actually read your first email, I see that you
were having trouble with platforms, not triggers.
Are you using a func_plat? If so, you'll see in CFuncPlat::Precache()
that it spawns a plat_trigger to detect the player moving onto the plat.
When you said you didn't see the platform's Touch() function getting
called, did you mean CPlatTrigger::Touch()?
If not, put a breakpoint in that and see if you hit that. Otherwise, I'd
try visualizing the plat_trigger and seeing where it is.
I guess I could have been a bit clearer. The tracer I put was in the
CPlatTrigger::Touch() function as so:
void CPlatTrigger::Touch( CBaseEntity *pOther )
{
Msg("Trigger Touch!\n");
// Ignore touches by non-players
if ( !pOther->IsPlayer() )
return;
.etc
I'm not sure how you would visualize the PlatTrigger. I tried turning on
the "showtriggers", but it nothing showed for the platform. My other
triggers did show.
If push comes to shove, I'll just delete the PlatTrigger code and use an
explicite func_trigger to make the platform work. But it would be nice
if the plats would work like they used to. In the first version of my
mod, I deleted the plattrigger and created a touch function for the
platform itself which worked just fine. But I decided to give the SDK
version another try. Maybe that wasn't such a good idea.
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] platform trigger touch not working in SDK
Has anyone gotten the platforms to work with their default touch triggers? I've been playing with them off and on over the last few weeks and have yet to get them to trigger properly. I put a message in the touch() function which shows it never gets called despite having a player jumping up and down on top of the platform. The trigger is getting set up, but it just doesn't work. It's probably something simple, but so far I haven't been able to find what's wrong. I'm guessing that it's a bounding box issue, but the tracer code I put in shows that the bbox is getting set properly. Any ideas? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: Annoying view model animation glitch
I have no idea how to fix that despite having fought with it for over a week. The animation problem is not limited to just the shoot sequence for the shotgun. All of the animation sequences suffer from the problem to some extend. The shotgun reload animations are especially vulnerable it seems. I was able to trace the problem to the interpolation/prediction code and two networked variables: m_flAnimTime and m_flCycleTime. The problem is that the animation sequence is started with the m_flAnimTime and m_flCycleTime being set to reflect the new animation sequence. But then the interpolation/prediction code makes adjustments to the values in an apparent effort to resynchronize the client to the server. It's the jump in time that causes the animation to skip (m_flAnimTime causes the most dramatic skips). The reason is that the jumps are on the order of about +/- 0.1 to 0.5 seconds. This doesn't sound like much, but when you consider that many of the viewmodel animation sequences are only 0.2 to 0.4 seconds long, then you can begin to see why the skips are so dramatic. The skipping is at it's worst when the m_flAnimTime jumps backwards in time because this causes the animation sequence to skip directly to the last frame. When the skip happens near the start of the sequence, the client sees this as a missing animation sequence. But what really happened was that the sequence went from frame 1 or 2 directly to the last frame. Just for fun, I removed m_flAnimTime and m_flCycleTime from the interpolation and prediction code. The problems stopped. But I'm not sure what new problems this was going to create, so I put them back. I sure would like to hear from anyone who has found a way around this issue. --- *Juha Beck * hlcoders@list.valvesoftware.com /Wed Mar 16 12:20:09 200/ I've played around with the mp sdk for a while, and I've noticed that when one shoots (rapidly) with the shotgun, the shoot animation doesn't always get played correctly. I found out that SendViewModelMatchingSequence() doesn't get called when it happens, but SendViewModelAnim(), the function where SendViewModelMatchingSequence() should be called from, seems to be called correctly (I could be wrong though). I'm sure others have experienced this too, but do anyone know how it could be fixed? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] SDK ladders not working
Has anyone been able to get ladders to work using the SDK code? I have had nothing but trouble with them. The func_usableladder entity doesn't work at all and func_ladder causes server crashes on spawn (on linux anyway). I tried the ladder prefab in Hammer and it didn't work, nor does following the examples given in the SDK docs. The problem with the func_usableladder seems to be that the player isn't attaching to the ladder. The ladder is ignoring the player completely. Any ideas? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] "Pure Virtual method called" server crash
I installed all the patches from the latest SDK and recompiled on my
linux system. Now when I start the linux server it instantly crashes
with the error "Pure virtual method called... teminate called without
active exception". The core file shows the the error is occuring when
the InvokeMethod function is executed (game_shared/igamesystem.cpp::264):
void IGameSystem::PreClientUpdateAllSystems()
{
InvokeMethod( &IGameSystem::PreClientUpdate );
}
The linux server was working prior to the latest SDK update. Any ideas?
(RH8.0-2.4.28/gcc-3.4.3)
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.5.2 - Release Date: 2/28/2005
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Underwater sound continues to loop after water death
There seems to be a bug with the "player.swim" sound continuing to loop after respawn if the player dies underwater. Is there a way to fix this? I can't seem to find anything to force this sound to stop playing except for using the "stopsound" command in the console. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.3 - Release Date: 1/24/2005 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] moveable Spawnpoints
This is easy. All you need to do is modify the EntSelectSpawnPoint() function in player.cpp to include your tank entity as a valid spawnpoint. The trick is adjusting the player position relative to the tank so that he doesn't spawn inside a solid. But that shouldn't be too hard to do. The easy way is to just spawn directly above the top of the tank and drop down on top of it. EntSelectSpawnPoint() returns a pointer to a CBaseEntity. The coordinates of the returned entity are then copied to the player's coordinates. What you need to do is to have a dummy CBaseEntity whose coordinates are set to the tank's, plus whatever offset you add, and then have EntSelectSpawnPoint () return a pointer to the modified dummy entity. An even better solution is to have regular info_player_spawn points which have target names assigned to match the names of the tanks. Then just modify the coordinates of these named spawn points to match the named tank before returning from the function. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.3 - Release Date: 1/24/2005 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] BUG:: Eyeangle pitch not working on client
I discovered a problem with the Eyeangles on the clientside. It seems
that the pitch angle is getting forced to zero on the clientside. I
traced the problem to the C_SDKPlayer declaration shown below:
C_SDKPlayer::C_SDKPlayer() :
m_iv_angEyeAngles( "C_SDKPlayer::m_iv_angEyeAngles" )
{
m_PlayerAnimState = CreatePlayerAnimState( this, this, LEGANIM_9WAY,
true );
m_angEyeAngles.Init();
AddVar( &m_angEyeAngles, &m_iv_angEyeAngles, LATCH_SIMULATION_VAR );
}
In particular, it seems that the call to AddVar(...) is triggering
something that is resetting the pitch angles to 0. If you comment that
line out, the pitch angle functions as it should. My question is what
does AddVar() do? Can I leave it commented out?
A second question is with the linux dedicated server. I have been trying
to get Steam to connect and install a basic dedicated server on my linux
system. But all I ever get is:
>./steam -update
Checking *bootstrapper* version ...
Connection *Reset*
What's going on here (it's not the firewall)? ($#$&[EMAIL PROTECTED] Steam)
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Can't find factory for entity: rpg_missile
What does "Can't find factory for entity: rpg_missile" mean? I get it in the system console when the game loads. The rpg_missile works just fine as near as I can tell, but the engine seems to feel that something is missing. I am not familiar with the 'factory' concept for entities. I don't remember them being an issue in HL1. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player Animations
Just a follow up listing what I've learned. It seems that the problem lies with the call to UpdateAimSequenceLayers(). Everything works so long as the upper animation is doing the same thing as the lower animation. For example, if the lower activity is set to ACT_RUN and the upper sequence is set to 'run_holding_all', then everything works as expected. However, if the lower activity is set to ACT_RUN and the upper is set to 'shoot_smg1', then the lower animation goes into the ragdoll mode and drags the legs across the floor. So it would seem that there is no way to combine a run animation with a shoot sequence since the shoot sequence is based on the model standing still rather than running. The same goes for trying to play a reload animation while walking or running. Is there is way to make the models work like they did in HL1 where the upper and lower animations were essentially indepedently settable, or do you just not play shoot and reload animations while moving? * Well I tried the suggestions given by the Wavelength site, but as it turns out, I had already made most of the recommended changes already, except for blocking the rendering of the viewmodel in third person mode. After fighting with the problem some more, I finally got the the upper body to render the correct animation, but despite my best efforts, the lower body still refuses to accept the ACT_WALK animation. The lower body is stuck in the ragdoll mode and just drags the legs and feet across the floor during movement. I have also tried to brute force an animation sequence onto the model by altering the "void CBasePlayerAnimState::ComputeMainSequence()" such that it always selects ACT_WALK as the ideal activity and selects "run_all" as the 'animDesired'. It still refuses to accept the lower body animation. I'm out of ideas. Any thoughts? ** ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player Animations
Well I tried the suggestions given by the Wavelength site, but as it turns out, I had already made most of the recommended changes already, except for blocking the rendering of the viewmodel in third person mode. After fighting with the problem some more, I finally got the the upper body to render the correct animation, but despite my best efforts, the lower body still refuses to accept the ACT_WALK animation. The lower body is stuck in the ragdoll mode and just drags the legs and feet across the floor during movement. I have also tried to brute force an animation sequence onto the model by altering the "void CBasePlayerAnimState::ComputeMainSequence()" such that it always selects ACT_WALK as the ideal activity and selects "run_all" as the 'animDesired'. It still refuses to accept the lower body animation. I'm out of ideas. Any thoughts? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player Animations
I tried switching the view mode to thirdperson and discovered that the player animations are stuck in the 'scarcrow' reference pose. Also, I noticed that the third person view is positioned to look sideways to the player rather than from behind. My questions are: * Is anyone else seeing this? (Maybe I changed something I shouldn't have) * What's the magic to get the upper body animation to play a sequence (like shooting) while the lower body continues to run/walk/idle. Right now, if you set an upper body sequence (such as ACT_RANGE_ATTACK_SMG1), it competes with the lower activity (ACT_RUN_RIFLE) causing severe jittering. * I also noticed that the player animation doesn't adapt to moving sideways or backwards like it does in the model viewer. What needs to be done to fix this? I think my problem is that I don't fully understand what's the distinction between an 'activity' versus a 'sequence' and how the two get merged together. Could someone offer some insight to this? Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] fopen and player model sequences
Two questions: First, is there a way to re-enable 'fopen()'? I am trying to generate a log file for testing purposes and it seems that someone thought it would be funny to disable key functions of the stdio library. Very annoying. I'd rather not deal with the Valve file system as it is klunky and gross overkill for simple logging. Second, I tried switching the default player model in the SDK to the female03 model in basic HL2. It seems to work, but I do get an Assert that the animation sequence 'WALK_LOWER' is not found. I'm assuming that the new animations no longer seperate the lower and upper animation sequences like HL1 did -- at least that appears to be the case from viewing the sequences with the model viewer. Can someone confirm this? If so, it looks like mod authors have a lot of work ahead of them to rewrite the player animation routines to accept this new method. Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Drawing additive textures, alpha channels in VGUI panels
Is there a way to draw a texture in VGUI using the equivelent of the old
DRAW_ADDITIVE sprite mode? Currently, my code looks like this:
CHudThing::CHudThing () // contructor
{
m_iArmorIconID = vgui::surface()->CreateNewTextureID();
vgui::surface()->DrawSetTextureFile( m_iArmorIconID,
"vgui/armoricon" , true, false);
}
CHudThing::Paint () // draw the icon in the VGUI panel.
{
// draw icon
vgui::surface()->DrawSetColor(fgColor);
vgui::surface()->DrawSetTexture( m_iArmorIconID );
vgui::surface()->DrawTexturedRect( icon_xpos, icon_ypos, icon_xpos +
32, icon_ypos + 32 );
}
The icon (a converted tga file) is white where it is supposed to show,
and black on the 'transparent' parts. The problem is that the black
areas are showing up as black on the screen, rather than invisible.
Setting the drawing mode to draw_additive would fix the problem, but
there doesn't seem to be a way to do that. I also tried creating the
icon texture with an alpha channel, but it refuses to load. Is there a
way around this?
Thanks.
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] localization() question
I have been trying to get the localization to work in my mod without any success. I added a token file into my mod's resource directory per instructions given in the vgui SDK docs, but for whatever reason it seems to ignore it. The game directory is "mymod", so I named the file "mymod_english.txt". Nothing happened. I also tried "hl2_english.txt" as well. That didn't work either. I'm sure it's something simple, but it has me stumped. I also tried using an existing token file just in case I had some typo that was keeping it from working. HL2 ignored it as well. Also, the vgui docs mention that you can use localize()->AddFile() to add additional token files, but it failed to mention where you should do this. I tried putting this call in the VGUI initialization code in an effort to fix the above problem, but I'm not sure if that's the right place for it. Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] sdk release and a surprise ideas..
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I think the surprise might be that Valve actually delivers something on time. Previous experience has shown 'next week' to actually mean a month. -- [ Picked text/plain from multipart/alternative ] ok.. so with the release of the SDK this week what do you think the surprise will be? I'm betting on HL2 Deathmatch or a couple new playable levels. Any thoughts or ideas? Thanks, David -- -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] HL2 SDK
Well that's certainly disappointing, considering all the promises of how the SDK was going to be made available prior to the release. My mod team disbanded some time ago because the SDK which was 'coming soon' never happened. I really wish Valve wouldn't pull people's chains if they're not going to follow through. Vaporware just isn't cool. >will there ever be a gold, with steam distro, and all? --- "Jeffrey \"botman\" Broome" <[EMAIL PROTECTED]> wrote: >>> Matthew Lewis wrote: >>> > Since Valve plans to start preloading portions of >>> HL2, does this mean >>> > that the promised SDK release is now imminent? >> >> Last I had heard, in an interview with Gabe, he said >> sometime shortly >> after the game is released. So it will probably be >> at least a month or >> two (there hasn't even been a 'Gold' announcement >> yet). >> >> -- >> Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] HL2 SDK
Since Valve plans to start preloading portions of HL2, does this mean that the promised SDK release is now imminent? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] It's official: HL2 will not be released on Sept. 30.
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] This isn't a surprise to anyone who has noticed the absence of the "hl2 is gold" announcement. But according to Valve, they are going to try to make the holidays (as opposed to "We will make the holidays"). Of course, for all of us coders the question is: "How will this affect the release of the SDK?" Considering how tight-lipped Valve has been so far, I'm not really expecting an answer. But my mod team is fealing really frustrated about now and I don't know what to tell them. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Creating and removing entities
99% of the time when you get crashes from an entity that was deleted, it's because some other entity is still trying to reference it. In other words, something is still trying to use the battery even though it's been removed from the world. Some other cases are an owned entity who tries to send feedback to it's owner who is gone. For example, a sentry gun that is trying to add points to a player's score where the player has disconnected. The trick is to be sure to notify any entities in the world that might be trying to use a deleted entity that the entity is now gone and to stop referencing it since the pointers are no longer valid. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] SDK coming soon?
September 30 is rapidly approaching. From earlier announcements it was mentioned that the SDK would be available prior to HL2's release. Is this still true and has a date been set? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] winsock question
|
| I have never seen this happen. Are you sure you aren't looking at netstat
| the wrong way, or that you aren't opening a TCP socket by accident?
|
| Jeroen "ShadowLord" Bogers
|
Here's the actual code:
//-
int CIrisSockets::OpenSocket ( const char *sz_ipaddr, int iPort )
{
char func_name[] = "CIrisSockets::OpenSocket ";
// create a UDP socket.
sockfd = socket(AF_INET, SOCK_DGRAM, 0);
if (sockfd == SOCKET_ERROR)
{
PRINTF( "%s: Could not get socket descripter. '%d'\n",
func_name, WSAGetLastError());
return -1;
}
// assign an ip address and port number to the socket.
address.sin_family = AF_INET;
if (sz_ipaddr)
address.sin_addr.s_addr = inet_addr(sz_ipaddr);
else
address.sin_addr.s_addr = htonl(INADDR_ANY);
address.sin_port = htons(iPort);
// open the new socket for business
if (bind(sockfd, (SockAdr *) &address, sizeof(address)) ==
SOCKET_ERROR)
{
PRINTF("%s: Couldn't bind socket. '%d'\n", func_name,
WSAGetLastError());
CloseSocket();
return -1;
}
return 0;
}
// - end code ---
The netstat command used was "netstat -an". I searched the news groups (deja
news) and found that,
others have experienced the same problem, but no cause or solution was
offered. This code works fine
under linux.
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] winsock question
Does anyone know why winsock2 also opens a TCP socket when you create a UDP socket? It's not hurting anything, but its very strange. (The TCP socket shows up when doing a netstat.) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Tool for Creating TGA files
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] There are a couple of things that can happen to a TGA file. First, is the alpha channel. Second is the picture can be flipped upside-down. And the third (and the most nasty) is that TGA files can have data compression. It's been a while since I messed with the VGUI images, but I seem to remember that the data compression needs to be turned OFF when you save the file. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] pfnPEntityOfEntIndex( 1 )
--- I've seen this in CTriggerCamera::Use. Which entity does it refer to? I originally thought that it was the player, but this: if ( !pActivator || !pActivator->IsPlayer() ) seems to rule that out. Which entity is it pointing at? --- This is in fact the first player in the entity list. Players take slots 1 through 32. I think slot 0 is worldspawn. The code (if (!pActivator .) ) is there in case the 'use' function gets triggered by something other than a player (for example a trigger_multiple or a monster) so that pActivator will have some valid data in it. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] origin problem
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Individual player origins are only sent to clients when the player is in the client's PVS. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] compiling linux .so
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] -- [ Picked text/plain from multipart/alternative ] I give up. I've tried patching the sdk code and got it to compile but it d= oesn't work(unmodified code) - crashes the game talking about not being abl= e to find things. All my attempts to build egcs 1.1.2 have failed, for som= e reason, they always simply fail - error out somewhere durring the build -= same with binutils. Is there anyone with a linux machine out there that I= S able to compile the server library and actually have it work who could gi= ve me a user account so I can ssh in and compile? oh pretty please. -- You need to compile the library file with gcc 2.95 or 2.96. The newer compilers (gcc 3.0 or later) won't work. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] SDK line crashing linux servers
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Excellent! This was frustrating me to no end. I've simply been trying to
tell if a player is connected or not. As you have indicated, when a player
disconnects, the pointer is still valid or not null. I'll stick the
FREE_PRIVATE(pClient) in the clientDisconnect function and see if it doesn't
clear things up.
I think you may have misunderstood some finer points of my last message. First,
adding the FREE_PRIVATE instruction will not fix your problem. It just prevents
problems with bots which is what I assumed you were trying to use when you mentioned
the IsNetClient() call. Let me clarify by first saying that IsNetClient () has nothing
to do with finding out if a client is connected or not. IsNetClient () is a virtual
function that will return true when the player is a human player and return false when
the player is a bot (FakeClient). It has nothing to do with the player's connect
status.
In order to keep track of who's connected or not, you need to know a couple of
things about how the HL engine manages clients. That way you can infer the connect
status even though there is no way to simple ask the engine. First thing you need to
know everything in HL is an edict_t including players. There is an array of edicts
that represent everything in the world including players. The first edict slot (slot
0) is for the worldspawn (the game level) I think. The next 32 slots in the edict
table (slots 1 through 32) are reserved for storing player info. Now this is where
things get messy. Every edict structure has a pointer to a block of memory called
pvPrivateData. This is the memory that holds the class data that the edict has been
assigned to. The edicts themselves have no class. So when an edict has been assigned
to a player, memory is allocated like so:
MyEdict->pvPrivateData = malloc ( sizeof (CBasePlayer) );
The CBasePlayer pointer you get is a copy of the pvPrivateData pointer that has been
type cast to (CBasePlayer *). When you call FREE_PRIVATE(pEdict), you're freeing the
memory assigned to pvPrivateData. But the old pointers are still around which can
cause problems.
There are two things going on here that are hurting you. First is that the engine
sometimes tries to reuse the memory allocated to another client that disconnect
earlier when a new client connects. This can be a source of confusion. It's because of
this that I suggested using the FREE_PRIVATE call to make sure any old clients get
completely cleared out. The engine will allocate new memory as needed when a new
client connects so this call doesn't hurt anything and prevents old data from previous
clients from causing problems.
The second problem is that you still don't have a way to tell when a player is
connected. This involves some trickery. At the end of the
CHalflifeMultiplay:ClientDisconnect() add these two lines:
pClient->v.netname = MAKE_STRING("");
FREE_PRIVATE(pClient);
This frees the memory allocated to the CBasePlayerClass and set's the player's name
to a NULL string. Doing this will allow us to write a routine that will tell us if a
player is connected. Here's the code:
bool IsConnected ( edict_t *plr )
{
int i;
edict_t *pEdict = g_engfuncs.pfnEntityOfEntIndex(1);
CBasePlayer *pPlayer;
if (!plr)
return FALSE;
for (i=1; i < gpGlobals->maxClients; i++, pEdict++)
{
if ((pEdict->v.flags & FL_CLIENT) == 0)
continue;// not a client
if (pEdict->free)
continue;// edict not in use.
if (pEdict == plr)
{
// we found the edict slot that is/was assigned to the player.
// Make some tests to see
// this slot is still active (player connected).
if (strlen(STRING(pEdict->v.netname)) == 0)
{
break; // player has no name assigned. not connected.
}
pPlayer = (CBasePlayer *) pEdict->pvPrivateData;
if (!pPlayer)
{
// player does not have private data assigned to him so he can't be
connected.
break;
}
if (&pEdict->v != pPlayer->pev)
{
// if the pev pointers in the edict and the CBasePlayer class don't
match,
// it means that this player's data has been assigned to someone
else. So
// this player edict is not active, hence player is not connected.
break;
}
if (pPlayer->pev->pContainingEntity != pEdict)
{
// player's pev structure is pointing back to the wrong edict.
Therefore
// this player's pev is out-of-date, hence player is not connected.
break;
[hlcoders] SDK line crashing linux servers
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] The problem is that the CBasePlayerClass memory has been released, but the pointer is still around. This typically happens when you have entities owned by a player that disconnects unexpectantly. The entity then tries to reference the now invalid player using the old pointer and the result is a core dump. This is an old pet peave I've had with Valve for a long time in that there is no definitive call to the engine to ask if a player is fully connected. There is one other thing that will cause problems that you shoud be aware of. I'm assuming that since your asking if the player is a net client that you're trying to tell a player from a bot. You should know that the bot's private data is a different size than a normal player. But the engine fails to free the private data when a bot or player disconnects and instead tries to reuse it. This causes all sorts of strange behaviour and mysterious crashing when running bots. Make sure you call "FREE_PRIVATE(pClient)" at the end of the CHalflifeMultiplay::ClientDisconnect() routine to prevent this from happening. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] estimated release date foe hl2 sdk?
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I seem to remember seeing that the SDK for HL2 will be released ahead of the full game. Is there a target release date for the SDK? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] ERROR: No EXPORT
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] You need to make sure that the EXPORT macro is on all the Think and Touch function declarations. Also, make sure that none of the Think or Touch functions are declared as 'virtual'. Finally, rebuild the whole thing once you make your changes. FYI: That error doesn't seem to be fatal to windows (it may do weird things however), but it will cause the linux server to crash. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Unable to run libraries made with gcc3.2 under RH8.0
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Has anyone been able to compile and run their mod using gcc3.2 under RH8.0? I recompiled my mod with no errors, but the resulting modules no longer run. It either core dumps, or I get the missing API error. I've tried compiling with both gcc and g++ with the same results. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Changing default number of players on a lan server
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Is there a way to change the default number of players on a LAN server? Currently, whenever you start a LAN game using create game, the default number of players always comes up at 8. I would like the default to be 12 to accomodate the bots I have running around when playing offline. If you set the number to 12, whenever you restart the LAN server, its back at 8 again. This is no big deal for people who know how to run a server. But for clueless JoeBlow, I would like to have everything as automatic as possible so I don't have to answer a bazillion emails as to why the bots aren't working as advertised. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] "Your CD-Key is currently in use" error.
It looks like its a bug in the authentication system. This is what happened: I am in the process of publishing the next release of my mod, so I'm doing a lot of connecting/disconnecting from my test server. During one of these connections, I left the game to enter the controls setup menu. If you've done this while watching the server log, you'll see lots of overflow messages from client , and your connection dies a painful death if you stay in setup too long which is what happened in this case. As it turned out, I exited the game once I was done setting up my controls. The server continued to run however. When I tried to reconnect to my server, I started getting the "CD key in use" message. Eventually, as a wild guess, I stopped the server and looked in the 'auth' folder and noticed a .dat file which had a timestamp which coincided with time the problems started so I deleted it and restarted the server. Voila! The problem went away. Now I suppose that this might just be a coincidence in that I restarted the server at the same time the duplicate key (if it really existed) went offline. On the other hand, maybe there's something to restarting a server and deleting errant auth .dat files. At 12:17 AM 9/17/2002 -0500, you wrote: >This is pissing me off. I've been trying to test some new code on my server >and I'm getting the "Your CD Key is in use" message whenever I try to >connect. I haven't copied the CD, nor lent it out to anyone. What's going >here and what can be done? > >___ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Policy change in the user forum?
Is it just me, or did the policy change regarding viewing the archives? For some reason, everytime I try to view the archives, it demands a new login. (Yes, I have cookies enabled.) Also, I can no longer view the other HL archives like I once did (such as hl_announce). What's going on here? Whatever it is, it's extremely annoying. Please fix. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Limiting events to entities in the PVS
Ummm, wrong kind of message. I was refering to event messages (PLAYBACK_EVENT_FULL() ). Actually, it turns out that Scott's solution works perfectly. >Look in common\const.h. Change your MESSAGE_BEGIN() event to use MSG_PVS > >MSG_BROADCAST // unreliable to all >MSG_ONE // reliable to one (msg_entity) >MSG_ALL // reliable to all >MSG_INIT // write to the init string >MSG_PVS // Ents in PVS of org >MSG_PAS // Ents in PAS of org >MSG_PVS_R // Reliable to PVS >MSG_PAS_R // Reliable to PAS >MSG_ONE_UNRELIABLE // Send to one client, but don't put in reliable stream, >put in unreliable datagram ( could be dropped ) >MSG_SPEC // Sends to all spectator proxies ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Limiting events to entities in the PVS
Here's a tough problem. I have an event handler that handles the firing of a lightning gun. The event handler uses a R_BeamEnt entity to draw a lighting bolt from the shooter's weapon off into the direction the shooter is facing. The problem is that it seems the event message is sent to all clients even when the entity triggering the event is outside the PVS. Unfortunately, the entity's origin and angles don't appear to get updated on the client when it's outside the client's PVS so the result is that I have lightning bolts appearing from thin air randomly in the level since the event handler is using obsolete coordinate information. So here's the question: Is there a way to tell if the entity wishing to send the event is in the client's PVS (and hence is receiving coordinate updates about the entity)? Or is there a way on the clientside to tell that the event came from an entity in its current PVS or that the coordinate infomation to that entity is currently valid? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] triApi speed problems
It's not just the triAPI that slows down. Decals will also bring the engine to a crawl. Try this: Walk up to a wall and fire a weapon that leaves a scorch mark decal. Make a few scorch marks (3 to 5) that overlap and fill much of the screen. The frate rate will plummet to single digits. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Anti-cheat code in mods
I don't see how attempting to hide an exploit by not posting its details accomplishes anything. I do know that as a mod author, I can't attempt to fix the problem without details as to what is causing the problem. Let's face it, the hackers who are doing the exploits are probably sharing information among themselves already, and there is no shortage of people using them. It seems that only the mod authors are the ones left out of the loop and ironically are the ones that probably have the best chance at defeating the problem. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] 1109 to contain any code we should know about?
I really think Valve needs to clarify how this steam thing is going to affect mod authors. Two things I gathered from the slide show on the steam website was that they are intending to go to a pay-to-play system for online gaming. I really think that's going to fly like a ton of bricks. The second was an indirect reference to a requirement that mod authors pay a licensing fee and/or royalty for a steam enabled mod. I can just about guarantee that will kill the mod community. While it's true that there is no requirement to use steam at present, the presentation suggests that by the time CS 1.5 comes out that steam be the order of the day. Personally, I don't know what to think about steam. It sorta looks like that .NET evil that M$ is trying to shove down peoples throat. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] HL 1.1.0.9 Update
DANGER! DANGER! DANGER! If the pre-release version of 109 does the same thing that 108 did, then you setting yourself up for a BIG screwing if you install it. When I installed the pre-release version of 108, the 'official' 108 version refused to install because of the version numbers being screwed up. I ended having to completely re-install halflife and all the damn patches from scratch to fix the problem. In other words, do a complete backup of your halflife folder -before- you even think about installing the pre-release patch unless you're looking to shaft yourself bigtime. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] portal engine theory
I'm trying to understand how a portal style game engine works by writing one myself using openGL. I have written code that generates a leafy-BSP tree, but I'm not sure how you get portals out of it. I'm also unclear how you determine if a polygon is inside or outside the world or inside another brush (how is level flooding done?). Does anyone know of a website or book which gives detailed explainations on the techniques used to build a portal engine? Pretty much all the websites I've found so far only give a superficial explanation on how this is done. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] OT: what do langauge microsoft use for their apps?
I have it on good authority (the linux user's group) that Windoze OS's (prior to XP) were written using Mr. Bill's microBasic (circa 1975 vintage). Windoze XP was a complete re-write using interprative COBOL. This was done since M$ wants to move into the business enterprise software market. (Hey, everyone knows COBOL means business!) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Basic Problem, many a hairs lost!
Actually, I would have guessed that the define statement for MAX_PARTICLES has a ';' at the end of it when it shouldn't: #define MAX_PARTICLES 1024 ;
[hlcoders] Another Engine bug: Leaking File Descriptors
Here's another engine bug for ya. It seems that when a level changes, most, if not all of the old file descriptors get left open, while new ones are being created to files that are already open. (Typically, the FD's are to wad files.) Eventually, the task uses up all of the allowed FD's and the engine crashes. This problem occurs on Linux servers. It probably occurs on winbloze as well, but I have no idea how to check that. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] ogc required to play??
"Then the hook only need to listen on the network and it will get the key..." It won't do any good to get hold of the public key. That's the beauty of the public key system. You need both the private key and the public key to decrypt the message. The private key is never sent over the network. Regarding the time required to encrypt a message, Quake2 used RSA to place an encrypted checksum on the player movement commands without any real time penalties. There is no need to use a 128 bit key since even small keys can take many hours to bust -- much longer than any player is going to wait around for. And if the keys are changed with each level, busting a key would be useless since by the time it was broken, a new key would already be in use. The problem of the DLL having access to all the info known by the client is a tough one which is why I was thinking of encrypting the player movement packet as processed by the mod. If the legitimate client DLL encrypted the movement packet before feeding it to the engine, the hack DLL would be SOL. The hack would be forced to try to decrypt the message, modify it, then re-encrypt using the keys known only by the client DLL and the server. The trick here is keeping an outside DLL from discovering the private key of the client DLL. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] ogc required to play??
I'm curious how these DLL hacks work. Any one like to give a brief synopsis? If I know what they're doing, then I have a fighting change to stop it. But if I understand the process, the DLL hack inserts itself between the engine hooks and the mod DLL using the callback tables. (At least for aimbots anyway. The graphic and model hacks are another story.) I'm not how they do that, but I'll assume that's the case. If so, then we have what we call in networking a man-in-the-middle attack in which a hacker can eaves drop on both sides of the conversation. A possible solution to this is to encrypt the player movement packets using a public key algorithm using randomly generated keys on both ends. (Only the client movements being sent to the server would need encryption.) Since RSA's patent has expired, it would be a good choice. The catch to this is that both the server and the client need to incorporate this for it to work. The key wouldn't need to be very large. Just large enough to make hacking a key an unreasonable option. If you wanted to be really evil, you could generate new keys at the end of every level. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Hit Box bug??
I discovered a new oddity while testing a new model. It seems that if you have to hit boxes assigned to group 0, only the first is recognized. I have the hit boxes defined as follows in the .qc file: $attachment 0 "gun" 0 0 0 $attachment 1 "gun" 0 33 0 $hbox 0 "base" -10 -10 0 10 10 48 $hbox 0"gun" -4 -9 -4 4 33 4 $controller 0 "turret" ZR 0 360 $controller 1 "gun" XR -75 75 The hit box to the 'gun' section cannot be hit, while the 'base' hitbox works just fine. The two hitboxes show up when you do the showentities command. Just for fun, I assigned the 'gun' hitbox from group 0 to group 1 and viola! Both hit boxes now work properly. This is no big deal in this case, but I wonder if the problem is somehow related to the inability to headshot a crouched player (hit boxes above the breastline don't seem to work) which is causing a lot of problems. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Valve: Crash bug found
"In any case, these are usually caused by entities in the next map counting on entities in the first map to exist or at least to have gotten to some known state, something that you can interrupt when cheats are enabled. If you're trying to build a mod where this is happening, try disabling entities until you find the offender. Most all of these are caused by either non-level-transition-safe versions of entity pointers (raw CBaseEntity *'s instead of EHANDLE) or a slopply coding practice of directly dereference of an EHANDLE w/o checking for NULL. If it's crashing in the engine, then it's usually something stepping on memory, in which case you're hosed." I plead innocent to the charges. Furthermore, I can reproduce the crash by following the same magic sequence in the original version of the base game (i.e. no mod code at all). However, what I did find was that the crash only occurs when the game is running in OpenGL mode. Software mode and D3D do not crash under the same conditions. So I'm thinking it's a bug somewhere in the video drivers. Now why the video drivers should care about the guy on the bridge is beyond me. FYI, I found the crash also occurs several levels later in the middle of the level as opposed to during a transition so there seems to be more than one way to trigger the crash. In addition, the mode code I have runs in muliplayer mode with a dozen bots running loose for weeks at a time with no crashing on my linux system, and it's pretty darn strict about memory violations. I did find out why Barney was coming back to life during the level change. It seems that entities with scripts still running during a level change get set back to their default state. In the case of the dying barney, his default state is standing up rather than dying on the floor, so it looks like the ASSERT message had nothing to do with the crash. Barney stays dead if you let the script finish before exiting the level. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Valve: Crash bug found
OK, I found have some more information. First, the game is exiting with an
exception 0xc005 at HL! 00484282(). (Like that really tells you
anything.) Secondly, I switched the screen mode over to software rendering
since I was getting tired of winblows locking up when the game puked and I
actually got a useful piece of information: An ASSERT blurted out on the
console. Woohoo! It points to this section of code in the schedule.cpp
module in the CBaseMonster::GetSchedule() function around line 1500.
case MONSTERSTATE_SCRIPT:
{
ASSERT( m_pCine != NULL );
if ( !m_pCine )
{
ALERT( at_console, "Script failed for %s\n", STRING(pev->classname) );
ALERT( at_console, "target %s\n", STRING(pev->target) );
ALERT( at_console, "targetname %s\n", STRING(pev->targetname) );
CineCleanup();
return GetScheduleOfType( SCHED_IDLE_STAND );
}
return GetScheduleOfType( SCHED_AISCRIPT );
---
Now as near as I can tell, what seems to be happening is that when you frag
the scientist who is running a scripted_sequence called 'leaper', before the
script can be run, it does something evil to the to script that the dying
Barney is playing near the exit to the level. You can see this error as the
ASSERT is complaining about Barney's script "crawl_barney" when the level
changes, plus you see Barney is no longer lying on the floor dead - He's
standing up facing the wall once again. So the problem seems to have
something to do with the mechanism that passes the entity state from one
level to the next. It's getting messed up somehow when you kill an entity
that has a script which hasn't been triggered yet. Unfortunately for me, the
scripting and entity passing stuff are both areas I don't know a lot about.
Ordinarily, I wouldn't care about this crash since it requires a rather
specific sets of circumstances to produce it. But I am seeing crashes
further down the line as the game progresses and I can't help but wonder if
they aren't traceble to the same problem.
FYI: The magic function that produces the log file is:
-
FILE *logfile = NULL;
void Tracer ( char *msg )
{
if (logfile == NULL)
{
unlink("mylog.log");
logfile = fopen("mylog.log", "w");
}
if (logfile)
fprintf(logfile,"%s", msg);
}
--
Then anywhere in the code you want a trace statement you put:
--
Tracer("I want this message in a permanent log that won't get lost when this
thing crashes.!\n");
--
My mod is filled with over a hundred of these statements, most of which are
placed at the start of code that the engine is calling. And yes, the log
file gets really big in a big hurry. It grows about 250K per second of run
time.
VALVE: It would be really, really nice if the game would stay attached to
its control terminal and leave it open (when launched from a dos window) so
you could just do a printf and have the messages scroll by. This is the way
it works on Linux and it's very handy.
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Valve: Crash bug found
I've found a set of circumstances that will produce a crash 99% of the time. At first, I thought it was my mod code, but I found that the base game will also crash if you perform the same series of steps. How to crash the base game: *Start the game with the cheats enabled and open the console. *do a "map c1a1f" which brings up the main lobby level (just after the test chamber blows up.) *Do an impulse101 to get your weapons. *Blast the control panel in the reception area to open the big doors. *Use the egon or gauss gun (or any large weapon that will gib quickly) and gib the scientist on the breakaway bridge. You must gib him quickly before the bridge collapses. *Head for the dying barney next to the zombie and exit to the next level. The game will show "loading..." then crash without any explanation. Here are the last few lines in my trace file I made in an effort to try to fix this: DispatchObjectCollsionBox Dispatch touch weapon_9mmhandgun : worldspawn Dispatch touch worldspawn : weapon_9mmhandgun DispatchObjectCollsionBox DispatchObjectCollsionBox DispatchObjectCollsionBox DispatchObjectCollsionBox DispatchObjectCollsionBox DispatchObjectCollsionBox DispatchObjectCollsionBox DispatchObjectCollsionBox DispatchObjectCollsionBox UpdateClientData Get Weapon Data Get Weapon Data done. PlayerEncode Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. Entity Encode ... done. >>Engine crashes.<< The log shows that the next level had loaded with most (if not all) the entities spawned into the level. The game was just about to the point where the control is returned to the player to begin play on the new level. Note that the SysError function does not get called. I've tried to run the program using the debugger, but the context stack is empty (POS ms debugger). Maybe someone can get a handle on what's going here. BTW: if you kill the scientist by letting him fall to his death instead of gibbing him with a weapon, then the engine is happy and no crash results. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] MShitVC++ question
Is there a way to get a stack dump from the MSVC++ debugger. I have compiled with the debug project settings enabled and I am running HL with the +developer 1 switch turned on, but it's crashing with no stack dump. The context stack just has !HL0x488 or some address like that and nothing else. Not very helpful. I have been reduced to putting a bazillion printf's that print to a trace file because there is nothing else to work with. This sucks. If the single player mode would run under linux, this would be so easy to fix. (gcc/gdb rules!) If there is no trick to getting a stack dump, does anyone know what functions are called in the mod DLL between just after GetWeaponData() exits and just before PlayerPreThink() gets called in the client.cpp module? This apears to be when the crash is occuring.
[hlcoders] Particle colors
FYI: I've verified that the particle system is using the palette.lmp file for it's palette. I also found that if you set the color index directly, instead of using the color lookup function call, you'll be much happier for it. The lookup call won't set any RGB value higher than 127 which is why everything was coming out greyish. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Hull3?
There are still issues with the hit boxes left over from the previous release. Basically, the hit boxes don't work very well with crouched players. What I've found is that it's impossible to head shot a player while he's crouched. You have to aim for the center of his chest to score a hit. Anything above that won't score a hit of any type. I'm not sure if this is a hull issue or not. If I understand the process correctly, I think the engine checks for a hit on the player's hull before narrowing down to the individual hit box. If the hull doesn't register a hit, then the hit boxes never come into play. This leads me to believe a crouched player's hull is messed up somewhere, but I can't figure it out. It's very annoying, cuz a lot of players want to snipe at each other and they're usually crouched. Then I have to listen to "Hey WTF?!?! I hit him in the head!" Chances are they did. But the engine won't acknowledge it. I'd be curious if someome found a way around this little problem. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Particle Colors?
I don't think the color functions from the TriAPI are going to work with the particle system. It really does look like the particles are using a fixed palette from somewhere. These are the sample engine calls that supposedly set the particle color: // make a particle particle_t *p; p = gEngfuncs.pEfxAPI->R_AllocParticle( ParticleCallback ); // set its color p->color = gEngfuncs.pEfxAPI->R_LookupColor( r, g, b ); gEngfuncs.pEfxAPI->R_GetPackedColor( &p->packedColor, p->color ); You can try to set r,g,b to some desired color, but what comes out is basically a crap shoot. There has to be a better way. (Anyone know where the palette is stored or how to view it so that the colors might be set directly?) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Particle colors?
What is the trick to setting a particle's color? I've tried using the sample Particles() test code in the entity.cpp file (cl_dll stuff) and resetting the the rgb values to white (255,255,255) but all I get is a dirty grey color. I tried setting it to yellow (255,255,0) but all I get is a dirty grey color. The red color in the sample code comes out a dirty reddish grey. What gives? How do you get a bright white or yellow particle? I'm also curious what the story is with the color being packed in a short. Last time I looked, 24 bits of RGB won't fit into a short. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
