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 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& CUtlVector<T, >>>>>>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 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 >> >> >>_______________________________________________ >>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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
