Re: [hlcoders] Threaded plugin
Also note that none of the base container classes (CUtlVector for example) are thread safe. - Alfred Ok, so if I want to use any function/class of the engine, I have to manage mutex for every call ? Ex : When I call Msg(), do I have to lock a mutex before, and unlock it after ? Damien ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Threaded plugin
Damien wrote: Ok, so if I want to use any function/class of the engine, I have to manage mutex for every call ? Ex : When I call Msg(), do I have to lock a mutex before, and unlock it after ? That would be the safest thing to do. You could just create your own wrapper for each engine API function that uses some locking mechanism to make sure that only one of these engine calls happens at a time within the context of your plugin. Since you don't have access to the engine source code, there's no simple way for you to tell which engine functions are using global variables (and thus aren't thread safe). -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Linking error when compiling MOD on Linux
OK I've tried another box now, yet I have a feeling something is missing (distro = Gentoo) These lines seem to be the start of the trouble: ../dlls/../public/tier0/memdbgon.h:21:19: tchar.h: No such file or directory ../dlls/../public/tier0/memdbgon.h:29:20: crtdbg.h: No such file or directory Any idea what provides these? I couldn't find them existing as files on the last box which at least got further than this, so a library problem? Here's the full log of the relevant section: Valve Software - vcprojtomake.exe (Aug 11 2005) Memory leak: mempool blocks left in memory: 456 make -f Makefile.mod CC=/usr/bin/gcc CPLUS=/usr/bin/g++ CPP_LIB=/usr/lib/gcc-lib/i386-pc-linux-gnu/3.4.1/libstdc++.a /usr/lib/gcc-lib/i386-pc-linux-gnu/3.4.1/libgcc_eh.a BUILD_DIR=. BUILD_OBJ_DIR=./obj SOURCE_DIR=.. SHLIBLDFLAGS=-shared -Wl,-Map,mod_map.txt -Wl SHLIBEXT=so CLINK=/usr/bin/gcc CFLAGS= -march=pentium -mmmx -O3 -fpermissive -D_LINUX -DNDEBUG -Dstricmp=strcasecmp -D_stricmp=strcasecmp -D_strnicmp=strncasecmp -Dstrnicmp=strncasecmp -D_snprintf=snprintf -D_vsnprintf=vsnprintf -D_alloca=alloca -Dstrcmpi=strcasecmp -Usprintf=use_Q_snprintf_instead_of_sprintf -Ustrncpy=use_Q_strncpy_instead -UPROTECTED_THINGS_ENABLE LDFLAGS=-lm -ldl /root/eftc/game/bin/tier0_i486.so /root/eftc/game/bin/vstdlib_i486.so ARCH=i486 GAME_DIR=/root/eftc/game MOD_CONFIG=hl_DebugEFTCMPWin32 NAME=eftcmp_server XERCES_INC_DIR=/root/xerces-c-src_2_6_0/include XERCES_LIB_DIR=/root/xerces-c-src_2_6_0/lib make[1]: Entering directory `/root/eftc/src/linux_sdk' mkdir -p obj/eftcmp_server/dlls/game_shared mkdir -p obj/eftcmp_server/dlls mkdir -p obj/eftcmp_server/dlls/tier1 mkdir -p obj/eftcmp_server/dlls/public mkdir -p obj/eftcmp_server/dlls/hl2_dll mkdir -p obj/eftcmp_server/dlls/public/keyframe mkdir -p obj/eftcmp_server/dlls/public/tier0 mkdir -p obj/eftcmp_server/dlls/common mkdir -p obj/eftcmp_server/dlls/game_shared/hl2 mkdir -p obj/eftcmp_server/dlls/eftcmp_dll mkdir -p obj/eftcmp_server/dlls/game_shared/eftcmp /usr/bin/g++ -w -I../dlls/../game_shared/hl2 -I../dlls/. -I../dlls/../public -I../dlls/../public/tier1 -I../dlls/../game_shared -I../dlls/../utils/common -I../dlls/../dlls -I../dlls/../../dlls -I../dlls/../dlls/hl2_dll -I../dlls/../dlls/eftcmp_dll -I../dlls/../game_shared/eftcmp -DEFTCMP -DHL2_DLL -DUSES_SAVERESTORE -D_DEBUG -Dfopen=dont_use_fopen -DGAME_DLL -Dsprintf=use_Q_snprintf_instead_of_sprintf -DVECTOR -Dstrncpy=use_Q_strncpy_instead -D_snprintf=use_Q_snprintf_instead -DPROTECTED_THINGS_ENABLE -march=pentium -mmmx -O3 -fpermissive -D_LINUX -DNDEBUG -Dstricmp=strcasecmp -D_stricmp=strcasecmp -D_strnicmp=strncasecmp -Dstrnicmp=strncasecmp -D_snprintf=snprintf -D_vsnprintf=vsnprintf -D_alloca=alloca -Dstrcmpi=strcasecmp -Usprintf=use_Q_snprintf_instead_of_sprintf -Ustrncpy=use_Q_strncpy_instead -UPROTECTED_THINGS_ENABLE -o obj/eftcmp_server/dlls/game_shared/activitylist.o -c ../dlls/../game_shared/activitylist.cpp In file included from ../dlls/../public/tier1/utlmemory.h:33, from ../dlls/../public/tier1/utlvector.h:20, from ../dlls/./cbase.h:40, from ../dlls/../game_shared/activitylist.cpp:8: ../dlls/../public/tier0/memdbgon.h:21:19: tchar.h: No such file or directory ../dlls/../public/tier0/memdbgon.h:29:20: crtdbg.h: No such file or directory In file included from ../dlls/../public/tier1/utlmemory.h:33, from ../dlls/../public/tier1/utlvector.h:20, from ../dlls/./cbase.h:40, from ../dlls/../game_shared/activitylist.cpp:8: ../dlls/../public/tier0/memdbgon.h: In function `char* strdup_dbg(const char*, const char*, unsigned int)': ../dlls/../public/tier0/memdbgon.h:81: error: `_NORMAL_BLOCK' undeclared (first use this function) ../dlls/../public/tier0/memdbgon.h:81: error: (Each undeclared identifier is reported only once for each function it appears in.) ../dlls/../public/tier0/memdbgon.h:81: error: `_malloc_dbg' undeclared (first use this function) ../dlls/../public/tier0/memdbgon.h: In function `wchar_t* wcsdup_dbg(const wchar_t*, const char*, unsigned int)' Etc Etc Etc Thanks, --- Chris Adams -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alfred Reynolds Sent: 01 August 2005 20:43 To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Linking error when compiling MOD on Linux You may need to install the developer packages of your particular GCC version. It has been a while since I was in RPM hell, I have blanked out all the stupid things I was forced to do to make RPM behave. You also look to be using GCC 3.2.2, you need at least 3.4.1 (preferably exactly 3.4.1). - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Adams Sent: Monday, August 01, 2005 12:32 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Linking error when compiling MOD on Linux Humm entirely possible, but I
RE: [hlcoders] Several bugs: particlemgr.cpp (730), CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66)
OK I've done some debugging for the particle error. The text below is my output from when I fire the pistol - the Assert() that it mentions is the line *after* the DevMsg line, so you can see that most of the particles don't cause errors when being sorted, just a few. Looking at the ones that have the problem, the min and max Z values are the same? Please let me know what you think: minZ: -478.00, maxZ: -477.00, flPercent: 0.00, iAddBucket: 31 minZ: -478.00, maxZ: -477.00, flPercent: 0.00, iAddBucket: 31 minZ: -478.00, maxZ: -477.00, flPercent: 1.00, iAddBucket: 0 minZ: -477.00, maxZ: -475.00, flPercent: 0.00, iAddBucket: 31 minZ: -477.00, maxZ: -475.00, flPercent: 0.00, iAddBucket: 31 minZ: -477.00, maxZ: -475.00, flPercent: 0.00, iAddBucket: 31 minZ: -477.00, maxZ: -475.00, flPercent: 1.00, iAddBucket: 0 minZ: -43.00, maxZ: -43.00, flPercent: -1.#IND00, iAddBucket: -2147483617 particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket NUM_BUCKETS minZ: -474.00, maxZ: -472.00, flPercent: 0.00, iAddBucket: 31 minZ: -474.00, maxZ: -472.00, flPercent: 0.00, iAddBucket: 31 minZ: -474.00, maxZ: -472.00, flPercent: 1.00, iAddBucket: 0 minZ: -472.00, maxZ: -464.00, flPercent: 0.00, iAddBucket: 31 minZ: -472.00, maxZ: -464.00, flPercent: 0.125000, iAddBucket: 28 minZ: -472.00, maxZ: -464.00, flPercent: 0.25, iAddBucket: 24 minZ: -472.00, maxZ: -464.00, flPercent: 1.00, iAddBucket: 0 minZ: -474.00, maxZ: -471.00, flPercent: 0.00, iAddBucket: 31 minZ: -474.00, maxZ: -471.00, flPercent: 0.33, iAddBucket: 21 minZ: -474.00, maxZ: -471.00, flPercent: 1.00, iAddBucket: 0 minZ: -472.00, maxZ: -463.00, flPercent: 0.00, iAddBucket: 31 minZ: -472.00, maxZ: -463.00, flPercent: 0.22, iAddBucket: 24 minZ: -472.00, maxZ: -463.00, flPercent: 0.33, iAddBucket: 21 minZ: -472.00, maxZ: -463.00, flPercent: 1.00, iAddBucket: 0 minZ: -473.00, maxZ: -470.00, flPercent: 0.00, iAddBucket: 31 minZ: -473.00, maxZ: -470.00, flPercent: 0.00, iAddBucket: 31 minZ: -473.00, maxZ: -470.00, flPercent: 1.00, iAddBucket: 0 minZ: -469.00, maxZ: -459.00, flPercent: 0.00, iAddBucket: 31 minZ: -469.00, maxZ: -459.00, flPercent: 0.20, iAddBucket: 25 minZ: -469.00, maxZ: -459.00, flPercent: 1.00, iAddBucket: 0 minZ: -56.00, maxZ: -56.00, flPercent: -1.#IND00, iAddBucket: -2147483617 particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket NUM_BUCKETS minZ: -60.00, maxZ: -60.00, flPercent: -1.#IND00, iAddBucket: -2147483617 particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket NUM_BUCKETS minZ: -61.00, maxZ: -61.00, flPercent: -1.#IND00, iAddBucket: -2147483617 particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket NUM_BUCKETS minZ: -62.00, maxZ: -62.00, flPercent: -1.#IND00, iAddBucket: -2147483617 particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket NUM_BUCKETS minZ: -436.00, maxZ: -362.00, flPercent: 0.00, iAddBucket: 31 minZ: -436.00, maxZ: -362.00, flPercent: 0.135135, iAddBucket: 27 minZ: -436.00, maxZ: -362.00, flPercent: 0.797297, iAddBucket: 6 minZ: -436.00, maxZ: -362.00, flPercent: 1.00, iAddBucket: 0 minZ: -442.00, maxZ: -411.00, flPercent: 0.00, iAddBucket: 31 minZ: -442.00, maxZ: -411.00, flPercent: 0.258065, iAddBucket: 23 minZ: -442.00, maxZ: -411.00, flPercent: 1.00, iAddBucket: 0 minZ: -471.00, maxZ: -466.00, flPercent: 0.00, iAddBucket: 31 minZ: -471.00, maxZ: -466.00, flPercent: 0.20, iAddBucket: 25 minZ: -471.00, maxZ: -466.00, flPercent: 1.00, iAddBucket: 0 minZ: -432.00, maxZ: -353.00, flPercent: 0.00, iAddBucket: 31 minZ: -432.00, maxZ: -353.00, flPercent: 0.113924, iAddBucket: 28 minZ: -432.00, maxZ: -353.00, flPercent: 0.784810, iAddBucket: 6 minZ: -432.00, maxZ: -353.00, flPercent: 1.00, iAddBucket: 0 minZ: -442.00, maxZ: -411.00, flPercent: 0.00, iAddBucket: 31 minZ: -442.00, maxZ: -411.00, flPercent: 0.290323, iAddBucket: 22 minZ: -442.00, maxZ: -411.00, flPercent: 1.00, iAddBucket: 0 minZ: -432.00, maxZ: -351.00, flPercent: 0.00, iAddBucket: 31 minZ: -432.00, maxZ: -351.00, flPercent: 0.11, iAddBucket: 28 minZ: -432.00, maxZ: -351.00, flPercent: 0.765432, iAddBucket: 7 minZ: -432.00, maxZ: -351.00, flPercent: 1.00, iAddBucket: 0 minZ: -442.00, maxZ: -411.00, flPercent: 0.00, iAddBucket: 31 minZ: -442.00, maxZ: -411.00, flPercent: 0.290323, iAddBucket: 22 minZ: -442.00, maxZ: -411.00, flPercent: 1.00, iAddBucket: 0 minZ: -470.00, maxZ:
RE: [hlcoders] Several bugs: particlemgr.cpp (730), CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66)
I've done a hackhack for now
particlemgr.cpp 720ish
// Add it to the appropriate bucket.
if( ( maxZ - minZ ) == 0 ) {
// HACKHACKHACKHACKHACK!
flPercent = 0.5;
// The particle is half way between min and max
isn't it?
// (assuming zCoords[iCurParticle] == minZ == maxZ)
// DevMsg( The particle is: %f\n,
zCoords[iCurParticle] );
}
else {
flPercent = (zCoords[iCurParticle] - minZ) / (maxZ -
minZ);
}
---
Chris Adams
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Adams
Sent: 11 August 2005 17:19
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Several bugs: particlemgr.cpp (730),
CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66)
OK I've done some debugging for the particle error.
The text below is my output from when I fire the pistol - the Assert() that
it mentions is the line *after* the DevMsg line, so you can see that most of
the particles don't cause errors when being sorted, just a few. Looking at
the ones that have the problem, the min and max Z values are the same?
Please let me know what you think:
minZ: -478.00, maxZ: -477.00, flPercent: 0.00, iAddBucket: 31
minZ: -478.00, maxZ: -477.00, flPercent: 0.00, iAddBucket: 31
minZ: -478.00, maxZ: -477.00, flPercent: 1.00, iAddBucket: 0
minZ: -477.00, maxZ: -475.00, flPercent: 0.00, iAddBucket: 31
minZ: -477.00, maxZ: -475.00, flPercent: 0.00, iAddBucket: 31
minZ: -477.00, maxZ: -475.00, flPercent: 0.00, iAddBucket: 31
minZ: -477.00, maxZ: -475.00, flPercent: 1.00, iAddBucket: 0
minZ: -43.00, maxZ: -43.00, flPercent: -1.#IND00, iAddBucket:
-2147483617
particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket
NUM_BUCKETS
minZ: -474.00, maxZ: -472.00, flPercent: 0.00, iAddBucket: 31
minZ: -474.00, maxZ: -472.00, flPercent: 0.00, iAddBucket: 31
minZ: -474.00, maxZ: -472.00, flPercent: 1.00, iAddBucket: 0
minZ: -472.00, maxZ: -464.00, flPercent: 0.00, iAddBucket: 31
minZ: -472.00, maxZ: -464.00, flPercent: 0.125000, iAddBucket: 28
minZ: -472.00, maxZ: -464.00, flPercent: 0.25, iAddBucket: 24
minZ: -472.00, maxZ: -464.00, flPercent: 1.00, iAddBucket: 0
minZ: -474.00, maxZ: -471.00, flPercent: 0.00, iAddBucket: 31
minZ: -474.00, maxZ: -471.00, flPercent: 0.33, iAddBucket: 21
minZ: -474.00, maxZ: -471.00, flPercent: 1.00, iAddBucket: 0
minZ: -472.00, maxZ: -463.00, flPercent: 0.00, iAddBucket: 31
minZ: -472.00, maxZ: -463.00, flPercent: 0.22, iAddBucket: 24
minZ: -472.00, maxZ: -463.00, flPercent: 0.33, iAddBucket: 21
minZ: -472.00, maxZ: -463.00, flPercent: 1.00, iAddBucket: 0
minZ: -473.00, maxZ: -470.00, flPercent: 0.00, iAddBucket: 31
minZ: -473.00, maxZ: -470.00, flPercent: 0.00, iAddBucket: 31
minZ: -473.00, maxZ: -470.00, flPercent: 1.00, iAddBucket: 0
minZ: -469.00, maxZ: -459.00, flPercent: 0.00, iAddBucket: 31
minZ: -469.00, maxZ: -459.00, flPercent: 0.20, iAddBucket: 25
minZ: -469.00, maxZ: -459.00, flPercent: 1.00, iAddBucket: 0
minZ: -56.00, maxZ: -56.00, flPercent: -1.#IND00, iAddBucket:
-2147483617
particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket
NUM_BUCKETS
minZ: -60.00, maxZ: -60.00, flPercent: -1.#IND00, iAddBucket:
-2147483617
particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket
NUM_BUCKETS
minZ: -61.00, maxZ: -61.00, flPercent: -1.#IND00, iAddBucket:
-2147483617
particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket
NUM_BUCKETS
minZ: -62.00, maxZ: -62.00, flPercent: -1.#IND00, iAddBucket:
-2147483617
particlemgr.cpp (732) : Assertion Failed: iAddBucket = 0 iAddBucket
NUM_BUCKETS
minZ: -436.00, maxZ: -362.00, flPercent: 0.00, iAddBucket: 31
minZ: -436.00, maxZ: -362.00, flPercent: 0.135135, iAddBucket: 27
minZ: -436.00, maxZ: -362.00, flPercent: 0.797297, iAddBucket: 6
minZ: -436.00, maxZ: -362.00, flPercent: 1.00, iAddBucket: 0
minZ: -442.00, maxZ: -411.00, flPercent: 0.00, iAddBucket: 31
minZ: -442.00, maxZ: -411.00, flPercent: 0.258065, iAddBucket: 23
minZ: -442.00, maxZ: -411.00, flPercent: 1.00, iAddBucket: 0
minZ: -471.00, maxZ: -466.00, flPercent: 0.00, iAddBucket: 31
minZ: -471.00, maxZ: -466.00, flPercent: 0.20, iAddBucket: 25
minZ: -471.00, maxZ: -466.00, flPercent: 1.00, iAddBucket: 0
minZ: -432.00, maxZ: -353.00, flPercent: 0.00, iAddBucket: 31
minZ: -432.00,
Re: [hlcoders] Several bugs: particlemgr.cpp (730), CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66)
Chris Adams wrote: OK I've done some debugging for the particle error. The text below is my output from when I fire the pistol - the Assert() that it mentions is the line *after* the DevMsg line, so you can see that most of the particles don't cause errors when being sorted, just a few. Looking at the ones that have the problem, the min and max Z values are the same? Please let me know what you think: Divide by zero in particlemgr.cpp line 728: float flPercent = (zCoords[iCurParticle] - minZ) / (maxZ - minZ); ...this probably should be... float flPercent = 0.0f; if (abs(maxZ - minZ) 0.1) // avoid nasty divide by zero problem flPercent = (zCoords[iCurParticle] - minZ) / (maxZ - minZ); -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Several bugs: particlemgr.cpp (730), CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66)
El jue, 11-08-2005 a las 11:28 -0500, Jeffrey botman Broome escribió: Chris Adams wrote: OK I've done some debugging for the particle error. The text below is my output from when I fire the pistol - the Assert() that it mentions is the line *after* the DevMsg line, so you can see that most of the particles don't cause errors when being sorted, just a few. Looking at the ones that have the problem, the min and max Z values are the same? Please let me know what you think: Divide by zero in particlemgr.cpp line 728: float flPercent = (zCoords[iCurParticle] - minZ) / (maxZ - minZ); ...this probably should be... float flPercent = 0.0f; if (abs(maxZ - minZ) 0.1) // avoid nasty divide by zero problem flPercent = (zCoords[iCurParticle] - minZ) / (maxZ - minZ); me mode=lame other idea: const EPSYLON = 0.01; float diffZ = maxZ - minZ; if (!diffZ) diffZ = EPSYLON; //avoid divide by zero errors flPercent = (zCoords[iCurParticle] - minZ) / diffZ; if that also crash (maybe the coprocessor dont like really small values): if(!.. can be if (diffZ EPSYLON)... /me ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Several bugs: particlemgr.cpp (730), CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66)
Jeffrey botman Broome wrote: ...this probably should be... float flPercent = 0.0f; if (abs(maxZ - minZ) 0.1) // avoid nasty divide by zero problem flPercent = (zCoords[iCurParticle] - minZ) / (maxZ - minZ); ...and while we're at it, quick optimization (you don't need to sort if there's only one particle). Change this... // Do an O(N) bucket sort. This helps the sort when there are lots of particles. #define NUM_BUCKETS 32 ..to this... if (!pMaterial-m_Particles.m_pNext) // is there only one particle? return; // don't need to sort just one // Do an O(N) bucket sort. This helps the sort when there are lots of particles. #define NUM_BUCKETS 32 -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Problems with 4 teams
I'm trying to create a 4 team mod. There is a problem, that whenever I try to join team 5 (TEAM_GREEN) by changing my cl_playermodel to models/player/green/gman_high.mdl, it changes first to green, then goes back to combine and spawns me with combine soldier model. If i try this exact same thing on TEAM_YELLOW (4)then it switches me to yellow team no problems. I even tried switching the numbers of team yellow to 5 and team green to 4 and still team 5 always breaks. any ideas? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Several bugs: particlemgr.cpp (730), CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66)
Oooh optimization! Thanks :-) --- Chris Adams -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey botman Broome Sent: 11 August 2005 19:24 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Several bugs: particlemgr.cpp (730), CBaseAnimatingOverlay::AddGesture and gamerules.cpp (66) Jeffrey botman Broome wrote: ...this probably should be... float flPercent = 0.0f; if (abs(maxZ - minZ) 0.1) // avoid nasty divide by zero problem flPercent = (zCoords[iCurParticle] - minZ) / (maxZ - minZ); ...and while we're at it, quick optimization (you don't need to sort if there's only one particle). Change this... // Do an O(N) bucket sort. This helps the sort when there are lots of particles. #define NUM_BUCKETS 32 ..to this... if (!pMaterial-m_Particles.m_pNext) // is there only one particle? return; // don't need to sort just one // Do an O(N) bucket sort. This helps the sort when there are lots of particles. #define NUM_BUCKETS 32 -- Jeffrey botman Broome ___ 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
[hlcoders] Copying KeyValues objects
Alright, I have a question about the MakeCopy function.
What I do is iterate through an existing object and I /want/ to copy
over existing values.
Even better, is if you can tell me how to delete a key. Because I tried
RemoveSubKey and it doesn't work; so I am iterating through the object
and skipping the key I want to remove and copying over the new data to
the old object to be used.
KeyValues *Key = SaveData-GetFirstSubKey();
KeyValues *NewData = new KeyValues(Data);
while(Key)
{
// is this the key we don't want?
if(!strcmp(Key-GetName(), RemoveData-GetName()))
{
// do nothing, skip
} else {
// It's not, so let's add it.
KeyValues *NewKey = NewData-CreateNewKey();
NewKey = ItemKey-MakeCopy();
DevMsg(New key name: %s\n, NewKey-GetName());
}
Key = Key-GetNextKey();
}
I end up with an empty NewData object, but my devmsg tells me the
correct values. If I do SetString instead of MakeCopy, it works. But I
don't want to do that... since sometimes my object has different values.
It seems that once it goes onto a new key, it loses the data assigned by
MakeCopy.
--
Kamran A
Get Firefox! Safer, Faster, Better.
http://www.spreadfirefox.com/?q=affiliatesid=0t=85
Down with Internet Explorer! Say NO! to Spyware! Use Firefox
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] FW: [hlds_apps] New engine API for CVAR queries
Original Message
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alfred
Reynolds Sent: Thursday, August 11, 2005 3:06 PM To:
hlds_apps@list.valvesoftware.com; Zeph; Ruiner Subject: [hlds_apps] New
engine API for CVAR queries
With the Half-Life 1: Engine release today we added a new API
function to allow a game server to query the value of clients CVAR
settings.
There was a new function added to the end of enginefuncs_t:
void (*pfnQueryClientCvarValue)( const edict_t *player, const
char
*cvarName );
Calling this function requests the value of cvarName from player. The
result is returned via a callback from NEW_DLL_FUNCTIONS, here is the
complete NEW_DLL_FUNCTIONS definition:
typedef struct
{
// Called right before the object's memory is freed.
// Calls its destructor.
void(*pfnOnFreeEntPrivateData)(edict_t
*pEnt);
void(*pfnGameShutdown)(void);
int (*pfnShouldCollide)( edict_t
*pentTouched, edict_t *pentOther );
void(*pfnCvarValue)( const edict_t *pEnt,
const char *value );
} NEW_DLL_FUNCTIONS;
When the client responds to the cvar request you will get a callback
to
pfnCvarValue() with the edict of the player who is responding and the
cvars values.
This interface is implemented using a new server engine to client
engine network command (so there will be some delay from the request
to the response). This new network protocol has NOT been versioned
(to minimise the impact of its release), if you wish to use it you
must make sure your users have an updated server before they try to
use it.
- Alfred
___
hlds_apps mailing list
hlds_apps@list.valvesoftware.com
http://list.valvesoftware.com/mailman/listinfo/hlds_apps
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FW: [hlds_apps] New engine API for CVAR queries
Wouldn't it be better to have:
void(*pfnCvarValue)( const edict_t *pEnt, const char *cvar, const char
*value );
Instead? In a multi-plugin system, it's easily conceivable you could
have more than one cvar request at a time. The specification doesn't
say whether requests are stacked or if one request overwrites the
last... but either way, your callback won't know which cvar it's getting
information for. If I'm wrong here, please clarify for me :)
---David BAILOPAN Anderson
http://www.sourcemod.net/
http://www.sourcemm.net/
Alfred Reynolds wrote:
Original Message
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alfred
Reynolds Sent: Thursday, August 11, 2005 3:06 PM To:
hlds_apps@list.valvesoftware.com; Zeph; Ruiner Subject: [hlds_apps] New
engine API for CVAR queries
With the Half-Life 1: Engine release today we added a new API
function to allow a game server to query the value of clients CVAR
settings.
There was a new function added to the end of enginefuncs_t:
void (*pfnQueryClientCvarValue)( const edict_t *player, const
char
*cvarName );
Calling this function requests the value of cvarName from player. The
result is returned via a callback from NEW_DLL_FUNCTIONS, here is the
complete NEW_DLL_FUNCTIONS definition:
typedef struct
{
// Called right before the object's memory is freed.
// Calls its destructor.
void(*pfnOnFreeEntPrivateData)(edict_t
*pEnt);
void(*pfnGameShutdown)(void);
int (*pfnShouldCollide)( edict_t
*pentTouched, edict_t *pentOther );
void(*pfnCvarValue)( const edict_t *pEnt,
const char *value );
} NEW_DLL_FUNCTIONS;
When the client responds to the cvar request you will get a callback
to
pfnCvarValue() with the edict of the player who is responding and the
cvars values.
This interface is implemented using a new server engine to client
engine network command (so there will be some delay from the request
to the response). This new network protocol has NOT been versioned
(to minimise the impact of its release), if you wish to use it you
must make sure your users have an updated server before they try to
use it.
- Alfred
___
hlds_apps mailing list
hlds_apps@list.valvesoftware.com
http://list.valvesoftware.com/mailman/listinfo/hlds_apps
___
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] FW: [hlds_apps] New engine API for CVAR queries
You can use MetaMod to provide this de-confliction layer if you need it.
- Alfred
Original Message
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Anderson Sent: Thursday, August 11, 2005 9:46 PM To:
hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] FW: [hlds_apps]
New engine API for CVAR queries
Wouldn't it be better to have:
void (*pfnCvarValue)( const edict_t *pEnt, const char *cvar, const
char *value );
Instead? In a multi-plugin system, it's easily conceivable you could
have more than one cvar request at a time. The specification doesn't
say whether requests are stacked or if one request overwrites the
last... but either way, your callback won't know which cvar it's
getting information for. If I'm wrong here, please clarify for me :)
---David BAILOPAN Anderson
http://www.sourcemod.net/
http://www.sourcemm.net/
Alfred Reynolds wrote:
Original Message
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alfred
Reynolds Sent: Thursday, August 11, 2005 3:06 PM To:
hlds_apps@list.valvesoftware.com; Zeph; Ruiner Subject: [hlds_apps]
New engine API for CVAR queries
With the Half-Life 1: Engine release today we added a new API
function to allow a game server to query the value of clients
CVAR settings.
There was a new function added to the end of enginefuncs_t:
void (*pfnQueryClientCvarValue)( const edict_t *player, const
char
*cvarName );
Calling this function requests the value of cvarName from player.
The result is returned via a callback from NEW_DLL_FUNCTIONS,
here is the complete NEW_DLL_FUNCTIONS definition:
typedef struct
{
// Called right before the object's memory is freed.// Calls
its destructor. void
(*pfnOnFreeEntPrivateData)(edict_t
*pEnt);
void(*pfnGameShutdown)(void);
int (*pfnShouldCollide)( edict_t
*pentTouched, edict_t *pentOther );
void(*pfnCvarValue)( const edict_t *pEnt,
const char *value );
} NEW_DLL_FUNCTIONS;
When the client responds to the cvar request you will get a
callback to pfnCvarValue() with the edict of the player who is
responding and the cvars values.
This interface is implemented using a new server engine to client
engine network command (so there will be some delay from the
request to the response). This new network protocol has NOT been
versioned (to minimise the impact of its release), if you wish to
use it you must make sure your users have an updated server
before they try to use it.
- Alfred
___
hlds_apps mailing list
hlds_apps@list.valvesoftware.com
http://list.valvesoftware.com/mailman/listinfo/hlds_apps
___
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
