[hlcoders] EHandles valid on server and client?
The basic idea here is that I have a team_account_manager entity which holds team stats. It has a server and client component (C and C_) because id like to be able to access the information from both. I have a networked EHANDLE member in my gamerules which is supposed to keep track of the entity for both server and client. In my gamerules constructor i create the team_account_manager and assign the ehandle to it. Server side i can find the team_account_manager through the ehandle just fine, cast it to my (CTeamAccountManager*) type and use the functions. Here is my problem: Client side id like to find the team_account_manager through the same ehandle, cast it to my (C_TeamAccountManager*) type and use its functions. Unfortunately i cannot find the entity through my networked ehandle. Is this the proper way to use an ehandle? Perhaps my client side entity has a different ehandle? Maybe the team_account_manager is not getting created on the client? Maybe the ehandle is not getting networked correctly? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
I left my server on dm_steamlab overnight: no crash, and no Physical Mayhem
bug. (I'm still reluctant to say it's gone for good after 1 1/2 years of
spending so much of my modding time on this.)
So then I reverted the fix and applied just the assert. The instant I did
changelevel dm_steamlab, the assert hit. This corresponds with previous
findings that dm_steamlab would always cause the Physical Mayhem bug. The
assert involved a prop_physics and a prop_physics_multiplayer, which are
collisiongroups 1 and 17 respectively.
So now question the is, given that dm_steamlab caused the bad code path
instantly, how was Valve ever able to play dm_steamlab WITHOUT hitting the bug?
There would seem to be some other factor at work, that leaves me wary that we
haven't seen the last of this.
-bk
At 2006/05/28 11:51 PM, you wrote:
The particular case Garry reported was with a prop set to
COLLISION_GROUP_PUSHAWAY against another prop set to
COLLISION_GROUP_DEBRIS. The code in hl2mp gamerules returns different
values for:
ShouldCollide( COLLISION_GROUP_PUSHAWAY, COLLISION_GROUP_DEBRIS );
And
ShouldCollide( COLLISION_GROUP_DEBRIS, COLLISION_GROUP_PUSHAWAY );
The code I posted fixes this. The picture vs. the file cabinet in
cs_office is such a case. Vphysics assumes this will not occur; if it
does a bunch of unintended things can happen. (In this particular case
it results in a dangling pointer but there are other possible effects
depending on the callstack and cached collision state at the time of the
bad data coming from the game DLL. That's why it doesn't always crash
or even show up as a problem.)
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 7:29 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)
Yeah part of my real job is engineering support so I
understand the importance of repro steps if engineering
hasn't seen an issue. I'm a bit baffled though, given how
many people have reported it, that Valve hadn't seen it
regularly. (Does Valve have a public HL2DM stress test
server? If so, what's the IP?)
I think you tried to answer my question, but perhaps I didn't
grasp the intracacies of the answer. What scenario does the
CHL2MPRules::ShouldCollide change actually fix? If it's as
simple as one prop hitting another, why doesn't it always break?
Also, earlier when I reported the bouncing still occuring I
had only applied the fix server-side. I've since applied it
client-side as well and for about 20 minutes and counting
I've not seen any physics issues. Too early to call it dead,
but that's promising.
-bk
At 2006/05/28 06:34 PM, Jay Stelly wrote:
Garry sent in a deterministic way to cause some bad physics behavior.
Because of his repro case I was able to fix a bug with the code I
posted below. Personally, I have never been able to reproduce the
behavior you've described. I believe Adrian has seen the
behavior in
HL2DM at some point, but noone at Valve has a set of steps for
recreating the behavior as far as I know. Also, I've looked at the
minidumps you've posted and they don't help diagnose the problem.
Garry's bug had the same characteristic - looking at the
state of the
code after the bug had occurred was not helpful. Being able to
recreate the behavior in a controlled way is the shortest path to
fixing the problem. Sometimes bugs are easy and you can guess the
cause based on the results, but often they are not. In
those cases it
is really desirable to go back through the steps that caused the bug
and analyze what is happening in the code. If you can't do
that then debugging is much more difficult.
More info on what was happening here:
In this case the problem is that the game DLL is not being
consistent
in how it reports collision rules to vphysics.
ShouldCollide(a,b) is
supposed to return the same value no matter how many times
it is called
until you call CollisionRulesChanged() for a or b. Also
ShouldCollide(a,b) must always return the same result as
ShouldCollide(b,a). Vphysics uses this procedure call instead of
storing some kind of matrix of possible collisions. If this
function
does not fulfill it's part of the contract it can cause vphysics to
fail (including crashing).
So given that the problem has similar symptoms to Garry's, it makes
sense for you to instrument your code to test for cases of
the same bug.
The simplest way to do that would be to wrap ShouldCollide() in
src/dlls/physics.cpp:
int CCollisionEvent::ShouldCollide( IPhysicsObject *pObj0,
IPhysicsObject *pObj1, void *pGameData0, void *pGameData1 ) {
int x0 = ShouldCollide_Default(pObj0, pObj1, pGameData0,
pGameData1);
int x1 = ShouldCollide_Default(pObj1, pObj0, pGameData1,
pGameData0);
if ( x0 != x1 )
{
Assert(x0==x1); // break here and
Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)
-- [ Picked text/plain from multipart/alternative ] I don't think the modding hl2:dm code is the exact same as valve's hl2:dm release code On 5/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I left my server on dm_steamlab overnight: no crash, and no Physical Mayhem bug. (I'm still reluctant to say it's gone for good after 1 1/2 years of spending so much of my modding time on this.) So then I reverted the fix and applied just the assert. The instant I did changelevel dm_steamlab, the assert hit. This corresponds with previous findings that dm_steamlab would always cause the Physical Mayhem bug. The assert involved a prop_physics and a prop_physics_multiplayer, which are collisiongroups 1 and 17 respectively. So now question the is, given that dm_steamlab caused the bad code path instantly, how was Valve ever able to play dm_steamlab WITHOUT hitting the bug? There would seem to be some other factor at work, that leaves me wary that we haven't seen the last of this. -bk At 2006/05/28 11:51 PM, you wrote: The particular case Garry reported was with a prop set to COLLISION_GROUP_PUSHAWAY against another prop set to COLLISION_GROUP_DEBRIS. The code in hl2mp gamerules returns different values for: ShouldCollide( COLLISION_GROUP_PUSHAWAY, COLLISION_GROUP_DEBRIS ); And ShouldCollide( COLLISION_GROUP_DEBRIS, COLLISION_GROUP_PUSHAWAY ); The code I posted fixes this. The picture vs. the file cabinet in cs_office is such a case. Vphysics assumes this will not occur; if it does a bunch of unintended things can happen. (In this particular case it results in a dangling pointer but there are other possible effects depending on the callstack and cached collision state at the time of the bad data coming from the game DLL. That's why it doesn't always crash or even show up as a problem.) Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, May 28, 2006 7:29 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Physical Mayhem in progress - no crash! (yet) Yeah part of my real job is engineering support so I understand the importance of repro steps if engineering hasn't seen an issue. I'm a bit baffled though, given how many people have reported it, that Valve hadn't seen it regularly. (Does Valve have a public HL2DM stress test server? If so, what's the IP?) I think you tried to answer my question, but perhaps I didn't grasp the intracacies of the answer. What scenario does the CHL2MPRules::ShouldCollide change actually fix? If it's as simple as one prop hitting another, why doesn't it always break? Also, earlier when I reported the bouncing still occuring I had only applied the fix server-side. I've since applied it client-side as well and for about 20 minutes and counting I've not seen any physics issues. Too early to call it dead, but that's promising. -bk At 2006/05/28 06:34 PM, Jay Stelly wrote: Garry sent in a deterministic way to cause some bad physics behavior. Because of his repro case I was able to fix a bug with the code I posted below. Personally, I have never been able to reproduce the behavior you've described. I believe Adrian has seen the behavior in HL2DM at some point, but noone at Valve has a set of steps for recreating the behavior as far as I know. Also, I've looked at the minidumps you've posted and they don't help diagnose the problem. Garry's bug had the same characteristic - looking at the state of the code after the bug had occurred was not helpful. Being able to recreate the behavior in a controlled way is the shortest path to fixing the problem. Sometimes bugs are easy and you can guess the cause based on the results, but often they are not. In those cases it is really desirable to go back through the steps that caused the bug and analyze what is happening in the code. If you can't do that then debugging is much more difficult. More info on what was happening here: In this case the problem is that the game DLL is not being consistent in how it reports collision rules to vphysics. ShouldCollide(a,b) is supposed to return the same value no matter how many times it is called until you call CollisionRulesChanged() for a or b. Also ShouldCollide(a,b) must always return the same result as ShouldCollide(b,a). Vphysics uses this procedure call instead of storing some kind of matrix of possible collisions. If this function does not fulfill it's part of the contract it can cause vphysics to fail (including crashing). So given that the problem has similar symptoms to Garry's, it makes sense for you to instrument your code to test for cases of the same bug. The simplest way to do that would be to wrap ShouldCollide() in src/dlls/physics.cpp: int CCollisionEvent::ShouldCollide( IPhysicsObject *pObj0, IPhysicsObject
Re: [hlcoders] EHandles valid on server and client?
How are you creating the CTeamAccountManager server-side? Directly through its constructor, or through something else? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] assert since new engine update
WRT:
This is the only place in the SDK where RecvPropArray2 is used, and I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
Note that there is a good reason why you would want a CTeam entity.
Specifically, although the players may contain some of the same data, if
players are out of your PVS you will only have stale data for certain
team members on a team. You won't have any data for a teammate who
hasn't ever been in your PVS.
The CTeam entity exists to allow getting this data down to the client
independent of PVS.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 2:24 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
The following patch fixes the bug by disabling CTeam entirely. I'll
eventually remove CTeam from my mod, as it doesn't do anything, but for
now here's a backwards-compatible fix. (Unfortunately the player that
is reporting crashers since the latest Steam update was not helped by
this fix.)
--- mod/src/dlls/team.cpp 2005/06/11 22:14:30 1.2
+++ mod/src/dlls/team.cpp 2006/05/28 21:20:41
@@ -31,8 +31,11 @@
int SendProxyArrayLength_PlayerArray( const void *pStruct, int objectID
)
{
- CTeam *pTeam = (CTeam*)pStruct;
- return pTeam-m_aPlayers.Count();
+// The RecvPropArray2 in general was seemingly broken in the May
25th-ish core engine update.
+// The CTeam in particular was certainly broken at that time,
however, thankfully it doesn't
+// serve any important purpose.
+// For backwards compatibility with old client, we disable it,
rather than remove it entirely.
+return 0;
}
At 2006/05/28 04:10 PM, Yahn Bernier wrote:
We'll have someone take a look at this with a debug engine and see what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert since new engine update
This appears to be a bug in the core engine that the SDK has no real
control over.
If I add this extra logging:
To the bottom of SendProxy_PlayerList:
Msg(sending player #%d = ent num %d\n, iElement, pOut-m_Int);
To the bottom of SendProxyArrayLength_PlayerArray:
Msg(sending size %d\n, pTeam-m_aPlayers.Count());
To the top of RecvProxy_PlayerList:
AssertMsg(0, UTIL_VarArgs(got player #%d = ent num %d\n,
pData-m_iElement, pData-m_Value.m_Int));
To the second line of RecvProxyArrayLength_PlayerArray:
AssertMsg(0, UTIL_VarArgs(got %d (had %d) players\n,
currentArrayLength, pTeam-m_aPlayers.Size()));
Then server side on join you get:
sending size 0
sending size 1
sending player #0 = ent num 1
And client side you get:
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 1 (had 0) players
c_team.cpp (21) : got player #1 = ent num 1
utlvector.h (210) : Assertion Failed: IsValidIndex(i)
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 0 (had 0) players
So looks like, as originally suspected, this is a crasher issue. I
have
had reports from one person running a release build that they're now
seeing crasher on joining a server. It's possible this is the cause.
This is the only place in the SDK where RecvPropArray2 is used, and I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
At 2006/05/27 04:59 PM, [EMAIL PROTECTED] wrote:
I was just investigating too. It looks like in release mode there's a
chance of it crashing, but not certain. More evidence to support my
ongoing theory that Valve never does debug builds. :)
At 2006/05/27 01:13 PM, Jorge Rodriguez wrote:
Tony omega Sergi wrote:
Is anyone else getting an assert about IsValidIndex since the engine
update?
I've made no changes between updates, and now whenever I run, I get
this at
map start: (when first player connects) inline T CUtlVectorT,
A::operator[]( int i ) {
Assert( IsValidIndex(i) );
return Base()[i];
}
On:
void RecvProxy_PlayerList( const CRecvProxyData *pData, void
*pStruct, void
*pOut ) {
C_Team *pTeam = (C_Team*)pOut;
-- pTeam-m_aPlayers[pData-m_iElement] = pData-m_Value.m_Int;
}
The line marked with the arrow there.
Yes, I get it, but it hasn't crashed anything so I haven't looked
into
it yet.
--
Jorge Vino Rodriguez
___
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list
[hlcoders] Since the last update..
Since the last update, a lot of sounds don't play anymore and the console is spammed with probably missing from file repository/disk errors. And I don't mean after downloading, these are files which ARE there and were not downloaded on join. What's the story? -Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] assert since new engine update
That's interesting - I checked C_BasePlayer and you're right in that it falls
through to C_BaseEntity which uses the m_iTeamNum, which is only transmitted to
PVS-local entities.
However C_Team stills seems to not serve any useful purpose, because the easy
solution would be to change C_BasePlayer to use C_PlayerResource::GetTeam,
which is what I had previously assumed it would do anyway. I was confused,
because I knew my scoreboard correctly identified spectator team changes, and I
see it's already using g_PR-GetTeam correctly, so that would seem to be the
way to go.
Correct me if I'm wrong, but in light of the above, C_Team still seems like a
waste of bandwidth?
At 2006/05/29 01:58 PM, Yahn Bernier wrote:
WRT:
This is the only place in the SDK where RecvPropArray2 is used, and I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
Note that there is a good reason why you would want a CTeam entity.
Specifically, although the players may contain some of the same data, if
players are out of your PVS you will only have stale data for certain
team members on a team. You won't have any data for a teammate who
hasn't ever been in your PVS.
The CTeam entity exists to allow getting this data down to the client
independent of PVS.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 2:24 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
The following patch fixes the bug by disabling CTeam entirely. I'll
eventually remove CTeam from my mod, as it doesn't do anything, but for
now here's a backwards-compatible fix. (Unfortunately the player that
is reporting crashers since the latest Steam update was not helped by
this fix.)
--- mod/src/dlls/team.cpp 2005/06/11 22:14:30 1.2
+++ mod/src/dlls/team.cpp 2006/05/28 21:20:41
@@ -31,8 +31,11 @@
int SendProxyArrayLength_PlayerArray( const void *pStruct, int objectID
)
{
- CTeam *pTeam = (CTeam*)pStruct;
- return pTeam-m_aPlayers.Count();
+// The RecvPropArray2 in general was seemingly broken in the May
25th-ish core engine update.
+// The CTeam in particular was certainly broken at that time,
however, thankfully it doesn't
+// serve any important purpose.
+// For backwards compatibility with old client, we disable it,
rather than remove it entirely.
+return 0;
}
At 2006/05/28 04:10 PM, Yahn Bernier wrote:
We'll have someone take a look at this with a debug engine and see what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert since new engine update
This appears to be a bug in the core engine that the SDK has no real
control over.
If I add this extra logging:
To the bottom of SendProxy_PlayerList:
Msg(sending player #%d = ent num %d\n, iElement, pOut-m_Int);
To the bottom of SendProxyArrayLength_PlayerArray:
Msg(sending size %d\n, pTeam-m_aPlayers.Count());
To the top of RecvProxy_PlayerList:
AssertMsg(0, UTIL_VarArgs(got player #%d = ent num %d\n,
pData-m_iElement, pData-m_Value.m_Int));
To the second line of RecvProxyArrayLength_PlayerArray:
AssertMsg(0, UTIL_VarArgs(got %d (had %d) players\n,
currentArrayLength, pTeam-m_aPlayers.Size()));
Then server side on join you get:
sending size 0
sending size 1
sending player #0 = ent num 1
And client side you get:
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 1 (had 0) players
c_team.cpp (21) : got player #1 = ent num 1
utlvector.h (210) : Assertion Failed: IsValidIndex(i)
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 0 (had 0) players
So looks like, as originally suspected, this is a crasher issue. I
have
had reports from one person running a release build that they're now
seeing crasher on joining a server. It's possible this is the cause.
This is the only place in the SDK where RecvPropArray2 is used, and I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
At 2006/05/27 04:59 PM, [EMAIL PROTECTED] wrote:
I was just investigating too. It looks like in release mode there's a
chance of it crashing, but not certain. More evidence to support my
ongoing theory that Valve never does debug builds. :)
At 2006/05/27 01:13 PM, Jorge Rodriguez wrote:
Tony omega Sergi wrote:
Is anyone else getting an assert about IsValidIndex since the engine
update?
I've made no changes between updates, and now whenever I run, I get
this at
map start: (when first player connects)
RE: [hlcoders] assert since new engine update
It really depends on your MOD. The default CTeam is pretty thin, so you
might be able to roll all of the data into the CPlayerResource object.
They were created to conceptually map onto two different things, where
CPlayerResource was to contain data about players (even for mods with
no team concept) whereas CTeam was to contain data about teams. If
all you care about is who is on what team, then you could certainly
ditch Cteam and only transmit a team number in the CPlayerResource. If
you care about other teamwide stats that can't be recomputed just from
per-player data, then you might still nead it. We expected that team
based mods would derive a subclass from CTeam and add additional
team-specific data to it so that it could be used on the client for the
HUD etc. YMMV.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 29, 2006 12:15 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
That's interesting - I checked C_BasePlayer and you're right in that it
falls through to C_BaseEntity which uses the m_iTeamNum, which is only
transmitted to PVS-local entities.
However C_Team stills seems to not serve any useful purpose, because the
easy solution would be to change C_BasePlayer to use
C_PlayerResource::GetTeam, which is what I had previously assumed it
would do anyway. I was confused, because I knew my scoreboard correctly
identified spectator team changes, and I see it's already using
g_PR-GetTeam correctly, so that would seem to be the way to go.
Correct me if I'm wrong, but in light of the above, C_Team still seems
like a waste of bandwidth?
At 2006/05/29 01:58 PM, Yahn Bernier wrote:
WRT:
This is the only place in the SDK where RecvPropArray2 is used, and
I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
Note that there is a good reason why you would want a CTeam entity.
Specifically, although the players may contain some of the same data,
if
players are out of your PVS you will only have stale data for certain
team members on a team. You won't have any data for a teammate who
hasn't ever been in your PVS.
The CTeam entity exists to allow getting this data down to the client
independent of PVS.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 2:24 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
The following patch fixes the bug by disabling CTeam entirely. I'll
eventually remove CTeam from my mod, as it doesn't do anything, but for
now here's a backwards-compatible fix. (Unfortunately the player that
is reporting crashers since the latest Steam update was not helped by
this fix.)
--- mod/src/dlls/team.cpp 2005/06/11 22:14:30 1.2
+++ mod/src/dlls/team.cpp 2006/05/28 21:20:41
@@ -31,8 +31,11 @@
int SendProxyArrayLength_PlayerArray( const void *pStruct, int
objectID
)
{
- CTeam *pTeam = (CTeam*)pStruct;
- return pTeam-m_aPlayers.Count();
+// The RecvPropArray2 in general was seemingly broken in the May
25th-ish core engine update.
+// The CTeam in particular was certainly broken at that time,
however, thankfully it doesn't
+// serve any important purpose.
+// For backwards compatibility with old client, we disable it,
rather than remove it entirely.
+return 0;
}
At 2006/05/28 04:10 PM, Yahn Bernier wrote:
We'll have someone take a look at this with a debug engine and see
what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert since new engine update
This appears to be a bug in the core engine that the SDK has no real
control over.
If I add this extra logging:
To the bottom of SendProxy_PlayerList:
Msg(sending player #%d = ent num %d\n, iElement, pOut-m_Int);
To the bottom of SendProxyArrayLength_PlayerArray:
Msg(sending size %d\n, pTeam-m_aPlayers.Count());
To the top of RecvProxy_PlayerList:
AssertMsg(0, UTIL_VarArgs(got player #%d = ent num %d\n,
pData-m_iElement, pData-m_Value.m_Int));
To the second line of RecvProxyArrayLength_PlayerArray:
AssertMsg(0, UTIL_VarArgs(got %d (had %d) players\n,
currentArrayLength, pTeam-m_aPlayers.Size()));
Then server side on join you get:
sending size 0
sending size 1
sending player #0 = ent num 1
And client side you get:
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 1 (had 0) players
c_team.cpp (21) : got player #1 = ent num 1
utlvector.h (210) : Assertion Failed: IsValidIndex(i)
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 0 (had 0) players
Re: [hlcoders] Since the last update..
In your mod? In a Valve game? Try running the game that your mod is based off at least once. On 5/29/06, Jay C. [EMAIL PROTECTED] wrote: Since the last update, a lot of sounds don't play anymore and the console is spammed with probably missing from file repository/disk errors. And I don't mean after downloading, these are files which ARE there and were not downloaded on join. What's the story? -Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] assert since new engine update
Ok thanks, sounds good. CTeam does seem appropriate for storing something like
team win counters or whatever, but I still would not want to waste the
bandwidth (even though it should be fairly low) sending the team associations
two different ways, when the client can already figure that list out from the
g_PR. Now that I think about it, the CTeam thing is almost identical to this
KI entry:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Server:_The_client.27s_health_variable_is_pointlessly_sent_across_the_wire_twice.
At 2006/05/29 02:39 PM, Yahn Bernier wrote:
It really depends on your MOD. The default CTeam is pretty thin, so you
might be able to roll all of the data into the CPlayerResource object.
They were created to conceptually map onto two different things, where
CPlayerResource was to contain data about players (even for mods with
no team concept) whereas CTeam was to contain data about teams. If
all you care about is who is on what team, then you could certainly
ditch Cteam and only transmit a team number in the CPlayerResource. If
you care about other teamwide stats that can't be recomputed just from
per-player data, then you might still nead it. We expected that team
based mods would derive a subclass from CTeam and add additional
team-specific data to it so that it could be used on the client for the
HUD etc. YMMV.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 29, 2006 12:15 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
That's interesting - I checked C_BasePlayer and you're right in that it
falls through to C_BaseEntity which uses the m_iTeamNum, which is only
transmitted to PVS-local entities.
However C_Team stills seems to not serve any useful purpose, because the
easy solution would be to change C_BasePlayer to use
C_PlayerResource::GetTeam, which is what I had previously assumed it
would do anyway. I was confused, because I knew my scoreboard correctly
identified spectator team changes, and I see it's already using
g_PR-GetTeam correctly, so that would seem to be the way to go.
Correct me if I'm wrong, but in light of the above, C_Team still seems
like a waste of bandwidth?
At 2006/05/29 01:58 PM, Yahn Bernier wrote:
WRT:
This is the only place in the SDK where RecvPropArray2 is used, and
I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
Note that there is a good reason why you would want a CTeam entity.
Specifically, although the players may contain some of the same data,
if
players are out of your PVS you will only have stale data for certain
team members on a team. You won't have any data for a teammate who
hasn't ever been in your PVS.
The CTeam entity exists to allow getting this data down to the client
independent of PVS.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 2:24 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
The following patch fixes the bug by disabling CTeam entirely. I'll
eventually remove CTeam from my mod, as it doesn't do anything, but for
now here's a backwards-compatible fix. (Unfortunately the player that
is reporting crashers since the latest Steam update was not helped by
this fix.)
--- mod/src/dlls/team.cpp 2005/06/11 22:14:30 1.2
+++ mod/src/dlls/team.cpp 2006/05/28 21:20:41
@@ -31,8 +31,11 @@
int SendProxyArrayLength_PlayerArray( const void *pStruct, int
objectID
)
{
- CTeam *pTeam = (CTeam*)pStruct;
- return pTeam-m_aPlayers.Count();
+// The RecvPropArray2 in general was seemingly broken in the May
25th-ish core engine update.
+// The CTeam in particular was certainly broken at that time,
however, thankfully it doesn't
+// serve any important purpose.
+// For backwards compatibility with old client, we disable it,
rather than remove it entirely.
+return 0;
}
At 2006/05/28 04:10 PM, Yahn Bernier wrote:
We'll have someone take a look at this with a debug engine and see
what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert since new engine update
This appears to be a bug in the core engine that the SDK has no real
control over.
If I add this extra logging:
To the bottom of SendProxy_PlayerList:
Msg(sending player #%d = ent num %d\n, iElement, pOut-m_Int);
To the bottom of SendProxyArrayLength_PlayerArray:
Msg(sending size %d\n, pTeam-m_aPlayers.Count());
To the top of RecvProxy_PlayerList:
AssertMsg(0, UTIL_VarArgs(got player #%d = ent
Re: [hlcoders] Since the last update..
Well by the way he worded it, it seems that it did previously work. There must be a problem with the new update involving GCF files. Garry Newman wrote: In your mod? In a Valve game? Try running the game that your mod is based off at least once. On 5/29/06, Jay C. [EMAIL PROTECTED] wrote: Since the last update, a lot of sounds don't play anymore and the console is spammed with probably missing from file repository/disk errors. And I don't mean after downloading, these are files which ARE there and were not downloaded on join. What's the story? -Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] assert since new engine update
Yup. You guys have the code, so feel free to squeeze down the
networking overhead where you think it's appropriate for what you are
trying to support.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 29, 2006 1:10 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
Ok thanks, sounds good. CTeam does seem appropriate for storing
something like team win counters or whatever, but I still would not want
to waste the bandwidth (even though it should be fairly low) sending the
team associations two different ways, when the client can already figure
that list out from the g_PR. Now that I think about it, the CTeam thing
is almost identical to this KI entry:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Server:_Th
e_client.27s_health_variable_is_pointlessly_sent_across_the_wire_twice.
At 2006/05/29 02:39 PM, Yahn Bernier wrote:
It really depends on your MOD. The default CTeam is pretty thin, so
you
might be able to roll all of the data into the CPlayerResource object.
They were created to conceptually map onto two different things, where
CPlayerResource was to contain data about players (even for mods with
no team concept) whereas CTeam was to contain data about teams. If
all you care about is who is on what team, then you could certainly
ditch Cteam and only transmit a team number in the CPlayerResource. If
you care about other teamwide stats that can't be recomputed just from
per-player data, then you might still nead it. We expected that team
based mods would derive a subclass from CTeam and add additional
team-specific data to it so that it could be used on the client for the
HUD etc. YMMV.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, May 29, 2006 12:15 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
That's interesting - I checked C_BasePlayer and you're right in that it
falls through to C_BaseEntity which uses the m_iTeamNum, which is only
transmitted to PVS-local entities.
However C_Team stills seems to not serve any useful purpose, because
the
easy solution would be to change C_BasePlayer to use
C_PlayerResource::GetTeam, which is what I had previously assumed it
would do anyway. I was confused, because I knew my scoreboard
correctly
identified spectator team changes, and I see it's already using
g_PR-GetTeam correctly, so that would seem to be the way to go.
Correct me if I'm wrong, but in light of the above, C_Team still seems
like a waste of bandwidth?
At 2006/05/29 01:58 PM, Yahn Bernier wrote:
WRT:
This is the only place in the SDK where RecvPropArray2 is used, and
I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
Note that there is a good reason why you would want a CTeam entity.
Specifically, although the players may contain some of the same data,
if
players are out of your PVS you will only have stale data for certain
team members on a team. You won't have any data for a teammate who
hasn't ever been in your PVS.
The CTeam entity exists to allow getting this data down to the client
independent of PVS.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 2:24 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
The following patch fixes the bug by disabling CTeam entirely. I'll
eventually remove CTeam from my mod, as it doesn't do anything, but
for
now here's a backwards-compatible fix. (Unfortunately the player that
is reporting crashers since the latest Steam update was not helped by
this fix.)
--- mod/src/dlls/team.cpp 2005/06/11 22:14:30 1.2
+++ mod/src/dlls/team.cpp 2006/05/28 21:20:41
@@ -31,8 +31,11 @@
int SendProxyArrayLength_PlayerArray( const void *pStruct, int
objectID
)
{
- CTeam *pTeam = (CTeam*)pStruct;
- return pTeam-m_aPlayers.Count();
+// The RecvPropArray2 in general was seemingly broken in the May
25th-ish core engine update.
+// The CTeam in particular was certainly broken at that time,
however, thankfully it doesn't
+// serve any important purpose.
+// For backwards compatibility with old client, we disable it,
rather than remove it entirely.
+return 0;
}
At 2006/05/28 04:10 PM, Yahn Bernier wrote:
We'll have someone take a look at this with a debug engine and see
what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert since new engine update
This appears to
RE: [hlcoders] assert since new engine update
Okay, I found and fixed this issue. An internal data structure was
expanded and the engine.dll was rebuilt against the updated data
structure. However, the MOD headers don't reflect the change nor would
unrecompiled MODs which would assume the old data layout. I reverted
the structure to the old version since the change wasn't necessary going
forward. We will roll out a new engine update with the fix for this
issue shortly. And yes, this bug would have lead to MOD crashes when
using this version of the engine.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 2:24 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
The following patch fixes the bug by disabling CTeam entirely. I'll
eventually remove CTeam from my mod, as it doesn't do anything, but for
now here's a backwards-compatible fix. (Unfortunately the player that
is reporting crashers since the latest Steam update was not helped by
this fix.)
--- mod/src/dlls/team.cpp 2005/06/11 22:14:30 1.2
+++ mod/src/dlls/team.cpp 2006/05/28 21:20:41
@@ -31,8 +31,11 @@
int SendProxyArrayLength_PlayerArray( const void *pStruct, int objectID
)
{
- CTeam *pTeam = (CTeam*)pStruct;
- return pTeam-m_aPlayers.Count();
+// The RecvPropArray2 in general was seemingly broken in the May
25th-ish core engine update.
+// The CTeam in particular was certainly broken at that time,
however, thankfully it doesn't
+// serve any important purpose.
+// For backwards compatibility with old client, we disable it,
rather than remove it entirely.
+return 0;
}
At 2006/05/28 04:10 PM, Yahn Bernier wrote:
We'll have someone take a look at this with a debug engine and see what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert since new engine update
This appears to be a bug in the core engine that the SDK has no real
control over.
If I add this extra logging:
To the bottom of SendProxy_PlayerList:
Msg(sending player #%d = ent num %d\n, iElement, pOut-m_Int);
To the bottom of SendProxyArrayLength_PlayerArray:
Msg(sending size %d\n, pTeam-m_aPlayers.Count());
To the top of RecvProxy_PlayerList:
AssertMsg(0, UTIL_VarArgs(got player #%d = ent num %d\n,
pData-m_iElement, pData-m_Value.m_Int));
To the second line of RecvProxyArrayLength_PlayerArray:
AssertMsg(0, UTIL_VarArgs(got %d (had %d) players\n,
currentArrayLength, pTeam-m_aPlayers.Size()));
Then server side on join you get:
sending size 0
sending size 1
sending player #0 = ent num 1
And client side you get:
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 1 (had 0) players
c_team.cpp (21) : got player #1 = ent num 1
utlvector.h (210) : Assertion Failed: IsValidIndex(i)
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 0 (had 0) players
So looks like, as originally suspected, this is a crasher issue. I
have
had reports from one person running a release build that they're now
seeing crasher on joining a server. It's possible this is the cause.
This is the only place in the SDK where RecvPropArray2 is used, and I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
At 2006/05/27 04:59 PM, [EMAIL PROTECTED] wrote:
I was just investigating too. It looks like in release mode there's a
chance of it crashing, but not certain. More evidence to support my
ongoing theory that Valve never does debug builds. :)
At 2006/05/27 01:13 PM, Jorge Rodriguez wrote:
Tony omega Sergi wrote:
Is anyone else getting an assert about IsValidIndex since the engine
update?
I've made no changes between updates, and now whenever I run, I get
this at
map start: (when first player connects) inline T CUtlVectorT,
A::operator[]( int i ) {
Assert( IsValidIndex(i) );
return Base()[i];
}
On:
void RecvProxy_PlayerList( const CRecvProxyData *pData, void
*pStruct, void
*pOut ) {
C_Team *pTeam = (C_Team*)pOut;
-- pTeam-m_aPlayers[pData-m_iElement] = pData-m_Value.m_Int;
}
The line marked with the arrow there.
Yes, I get it, but it hasn't crashed anything so I haven't looked
into
it yet.
--
Jorge Vino Rodriguez
___
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list
[hlcoders] Re: EHandles valid on server and client?
I'm creating the account manager in the gamerules constructor using: CreateEntityByName( team_account_manager ); This is also where i assign the ehandle to the manager. -Kiran -Original Message- Subject: Re: [hlcoders] EHandles valid on server and client? From: John Sheu [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Organization: The University of Texas at Austin Date: Mon, 29 May 2006 13:53:55 -0500 Reply-To: hlcoders@list.valvesoftware.com How are you creating the CTeamAccountManager server-side? Directly through its constructor, or through something else? -Original Message- Date: Mon, 29 May 2006 01:08:45 -0700 (PDT) From: Kiran Sudhakara [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Subject: [hlcoders] EHandles valid on server and client? Reply-To: hlcoders@list.valvesoftware.com The basic idea here is that I have a team_account_manager entity which holds team stats. It has a server and client component (C and C_) because id like to be able to access the information from both. I have a networked EHANDLE member in my gamerules which is supposed to keep track of the entity for both server and client. In my gamerules constructor i create the team_account_manager and assign the ehandle to it. Server side i can find the team_account_manager through the ehandle just fine, cast it to my (CTeamAccountManager*) type and use the functions. Here is my problem: Client side id like to find the team_account_manager through the same ehandle, cast it to my (C_TeamAccountManager*) type and use its functions. Unfortunately i cannot find the entity through my networked ehandle. Is this the proper way to use an ehandle? Perhaps my client side entity has a different ehandle? Maybe the team_account_manager is not getting created on the client? Maybe the ehandle is not getting networked correctly? -Kiran __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Since the last update..
CS:S, and the files aren't in the GCF's, I'm talking about custom content that was downloaded to clients and worked before the update. Now, without re-downloading, they don't play, it says they don't exist :\ -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED] On Behalf Of Garry Newman Sent: 29 May 2006 20:43 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Since the last update.. In your mod? In a Valve game? Try running the game that your mod is based off at least once. On 5/29/06, Jay C. [EMAIL PROTECTED] wrote: Since the last update, a lot of sounds don't play anymore and the console is spammed with probably missing from file repository/disk errors. And I don't mean after downloading, these are files which ARE there and were not downloaded on join. What's the story? -Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Since the last update..
I has that issue with hl2:ctf way back - for some reason the sounds are there, but dont play - they do play after a reconnect though --- Jay C. [EMAIL PROTECTED] wrote: CS:S, and the files aren't in the GCF's, I'm talking about custom content that was downloaded to clients and worked before the update. Now, without re-downloading, they don't play, it says they don't exist :\ -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED] On Behalf Of Garry Newman Sent: 29 May 2006 20:43 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Since the last update.. In your mod? In a Valve game? Try running the game that your mod is based off at least once. On 5/29/06, Jay C. [EMAIL PROTECTED] wrote: Since the last update, a lot of sounds don't play anymore and the console is spammed with probably missing from file repository/disk errors. And I don't mean after downloading, these are files which ARE there and were not downloaded on join. What's the story? -Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] assert since new engine update
Ok thanks for the updates. I added a KI for that:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Server:_The_client.27s_team_membership_is_pointlessly_sent_across_the_wire_twice.
There seems to be another new crasher at work then in the latest Steam. I'm
getting lots of reports of game crashes as soon as they connect and get past
the client loading screen, but my patch doesn't fix it. I haven't seen this
myself.
At 2006/05/29 05:00 PM, Yahn Bernier wrote:
Okay, I found and fixed this issue. An internal data structure was
expanded and the engine.dll was rebuilt against the updated data
structure. However, the MOD headers don't reflect the change nor would
unrecompiled MODs which would assume the old data layout. I reverted
the structure to the old version since the change wasn't necessary going
forward. We will roll out a new engine update with the fix for this
issue shortly. And yes, this bug would have lead to MOD crashes when
using this version of the engine.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 2:24 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] assert since new engine update
The following patch fixes the bug by disabling CTeam entirely. I'll
eventually remove CTeam from my mod, as it doesn't do anything, but for
now here's a backwards-compatible fix. (Unfortunately the player that
is reporting crashers since the latest Steam update was not helped by
this fix.)
--- mod/src/dlls/team.cpp 2005/06/11 22:14:30 1.2
+++ mod/src/dlls/team.cpp 2006/05/28 21:20:41
@@ -31,8 +31,11 @@
int SendProxyArrayLength_PlayerArray( const void *pStruct, int objectID
)
{
- CTeam *pTeam = (CTeam*)pStruct;
- return pTeam-m_aPlayers.Count();
+// The RecvPropArray2 in general was seemingly broken in the May
25th-ish core engine update.
+// The CTeam in particular was certainly broken at that time,
however, thankfully it doesn't
+// serve any important purpose.
+// For backwards compatibility with old client, we disable it,
rather than remove it entirely.
+return 0;
}
At 2006/05/28 04:10 PM, Yahn Bernier wrote:
We'll have someone take a look at this with a debug engine and see what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert since new engine update
This appears to be a bug in the core engine that the SDK has no real
control over.
If I add this extra logging:
To the bottom of SendProxy_PlayerList:
Msg(sending player #%d = ent num %d\n, iElement, pOut-m_Int);
To the bottom of SendProxyArrayLength_PlayerArray:
Msg(sending size %d\n, pTeam-m_aPlayers.Count());
To the top of RecvProxy_PlayerList:
AssertMsg(0, UTIL_VarArgs(got player #%d = ent num %d\n,
pData-m_iElement, pData-m_Value.m_Int));
To the second line of RecvProxyArrayLength_PlayerArray:
AssertMsg(0, UTIL_VarArgs(got %d (had %d) players\n,
currentArrayLength, pTeam-m_aPlayers.Size()));
Then server side on join you get:
sending size 0
sending size 1
sending player #0 = ent num 1
And client side you get:
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 1 (had 0) players
c_team.cpp (21) : got player #1 = ent num 1
utlvector.h (210) : Assertion Failed: IsValidIndex(i)
c_team.cpp (31) : got 0 (had 0) players
c_team.cpp (31) : got 0 (had 0) players
So looks like, as originally suspected, this is a crasher issue. I
have
had reports from one person running a release build that they're now
seeing crasher on joining a server. It's possible this is the cause.
This is the only place in the SDK where RecvPropArray2 is used, and I'm
currently looking in to just disabling this server-side, since the
whole
CTeam thing looks like a waste of bandwidth. The player ents already
know what team they're on, so why pointlessly send this same info via
another method?
At 2006/05/27 04:59 PM, [EMAIL PROTECTED] wrote:
I was just investigating too. It looks like in release mode there's a
chance of it crashing, but not certain. More evidence to support my
ongoing theory that Valve never does debug builds. :)
At 2006/05/27 01:13 PM, Jorge Rodriguez wrote:
Tony omega Sergi wrote:
Is anyone else getting an assert about IsValidIndex since the engine
update?
I've made no changes between updates, and now whenever I run, I get
this at
map start: (when first player connects) inline T CUtlVectorT,
A::operator[]( int i ) {
Assert( IsValidIndex(i) );
return Base()[i];
}
On:
void RecvProxy_PlayerList( const CRecvProxyData *pData, void
*pStruct, void
*pOut ) {
C_Team *pTeam = (C_Team*)pOut;
-- pTeam-m_aPlayers[pData-m_iElement] = pData-m_Value.m_Int;
}
The line marked with the arrow there.
Yes, I get it, but it hasn't crashed anything so I haven't looked
into
it yet.
--
RE: [hlcoders] Since the last update..
That's not working this time though, I've been getting clients to restart and the same sounds don't work for them when they reconnect. -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED] On Behalf Of Adam amckern Mckern Sent: 30 May 2006 03:28 To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Since the last update.. I has that issue with hl2:ctf way back - for some reason the sounds are there, but dont play - they do play after a reconnect though --- Jay C. [EMAIL PROTECTED] wrote: CS:S, and the files aren't in the GCF's, I'm talking about custom content that was downloaded to clients and worked before the update. Now, without re-downloading, they don't play, it says they don't exist :\ -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED] On Behalf Of Garry Newman Sent: 29 May 2006 20:43 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Since the last update.. In your mod? In a Valve game? Try running the game that your mod is based off at least once. On 5/29/06, Jay C. [EMAIL PROTECTED] wrote: Since the last update, a lot of sounds don't play anymore and the console is spammed with probably missing from file repository/disk errors. And I don't mean after downloading, these are files which ARE there and were not downloaded on join. What's the story? -Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
