Re: [hlcoders] filesystem_passthru.h -- IBaseFileSystem missing UnzipFile
- I have to use eifaveV02 because new eiface does not have Cmd_Argv()
Using the new SDK headers means porting your plugin to be compatible
with said API changes. Of course, if you use eifaceV02.h against Orange
Box, your plugin will simply crash at best.
If FCVAR_PLUGIN no longer exists, I would not redefine it. It was
probably removed for a reason (unless Valve says otherwise).
ConCommandBaseMgr was removed, see ConVar_Register.
I've personally ported 3 plugins by now -- it's an annoying process at
first and you have to be willing to correct SDK inconsistencies on your
own. For some generic information, see here:
http://wiki.alliedmods.net/Porting_to_Orange_Box
It's got some Metamod:Source stuff mixed in but you can ignore that.
---David Anderson
http://www.bailopan.net/
[EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks, I did that and now even more errors!
- I have to use eifaveV02 because new eiface does not have Cmd_Argv()
function, using eifaceV02.h requires the need to use their namespace
before instantiating any of these classes
- utlbuffer does not define IsX360() function (had to make my own in the
file using #ifdef _XBOX)
- Keyvalues: variable reserved memset call (reserved does not exists and
didn't exist before in the old file) -- removed line
- KeyValues.cpp does not handle wasConditional boolean (had to declare it
myself before hand)
- ICVar: RegisterConCommandBase is now RegisterConCommand
after that I get 1 unresolved external GetCvarIF()
after adding the new libraries to the project I'm getting several unresolved
now:
__pfSqrt
Cvar functions
now I'm getting characterset_t already defined messages everywhere...
arggh
had to put: #include tier1/characterset.h in convar.h
- now FCVAR_PLUGIN is not defined in convar.h, had to redefine it as it was
previously (118)
and finally :
ConCommandBaseMgr does not exist anywhere, require for
server_plugin_convar.h
Urgh, anyone else sorted these new headers out into a working SDK yet?
Sorry for the rant ;)
On 10/21/07, Keeper [EMAIL PROTECTED] wrote:
I go the same error. I just commented out that line.
Keeper
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, October 20, 2007 7:03 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] filesystem_passthru.h -- IBaseFileSystem missing
UnzipFile
--
[ Picked text/plain from multipart/alternative ]
Hello, After updating the SDK with the files from ftp.valvesoftware.com to
update my plugin code, I have hit a dilemma, where two of the files don't
match
filesystem_passthru.h:
has a function
virtual boolUnzipFile( const char *pFileName, const char
*pPath,
const char *pDestination ){ return
m_pBaseFileSystemPassThru-UnzipFile( pFileName, pPath, pDestination ); }
yet the filesystem.h file does not have this function in the
IBaseFileSystem
class,
these two headers were from the valvesoftware ftp
Can anyone locate the correct headers for me ?
thanks!
--
___
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
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
It looks like CGlobalVars changed -- is it possible to get updated files for globalvars_base.h and edict.h? Thanks! --David Anderson http://www.bailopan.net/ Mike Durand wrote: It's on the FTP server now. Sorry for the delay. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bryan Beaudreault Sent: Friday, October 12, 2007 11:32 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Can we please get the tier1_i486 (linux version) as soon as possible? Now that people are starting to get their plugins updated to work with the new version of metamod: source, this will start to draw a gap between linux servers and windows servers. We who host on linux servers won't be able to promote our server as much as windows servers, and this is bad news for new TF2 communities who may not have tons of loyal regulars yet. At that state you need to have ways of differentiating your server from others so that people keep coming back, and the lacking of a linux versions of these plugins severely handicaps linux hosts. Thank you very much Bryan On 10/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello Spencer 'voogru' MacDonald, Thanks for sharing that file with us! With friendly Reguards Ratman2000 - Original Message - From: Spencer 'voogru' MacDonald [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, October 12, 2007 7:30 PM Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? It's not really that hard to look at the file and figure out what's going on. But here: http://www.voogru.com/filesystem_passthru.h -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, October 12, 2007 1:15 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hello, nice, can you share it with us? With friendly Reguards Ratman2000 - Original Message - From: Spencer 'voogru' MacDonald [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, October 12, 2007 6:36 PM Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? I got mine working by just adding the new functions from filesystem.h -Original Message- From: David Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, October 12, 2007 10:19 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? I think we need an updated filesystem_passthru.h as well. ---David Anderson http://www.bailopan.net/ Mike Durand wrote: Added those three. Is anyone else waiting on me for anything other than the Linux version of tier1? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 11, 2007 11:34 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hello Mike, please give us: public/tier1/characterset.h public/tier1/utlbuffer.h public/tier1/tier1.h Thanks with friendly reguards Ratman2000 - Original Message - From: Keeper [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, October 10, 2007 3:19 AM Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? They fill a void. And make a canned game a little more flexible. That being said, Mike: will the upcoming converted source games be available as a beta before they are released? Some are game specific and can't be tested on TF2. Thanks for all the work! Keeper -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony omega Sergi Sent: Tuesday, October 09, 2007 5:11 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? -- [ Picked text/plain from multipart/alternative ] hmm, i seem to think the easiest thing would be. wait for the damned sdk instead of trying to rush it. plugins suck and aren't that important anyway :P ___ 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
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
I think we need an updated filesystem_passthru.h as well. ---David Anderson http://www.bailopan.net/ Mike Durand wrote: Added those three. Is anyone else waiting on me for anything other than the Linux version of tier1? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 11, 2007 11:34 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hello Mike, please give us: public/tier1/characterset.h public/tier1/utlbuffer.h public/tier1/tier1.h Thanks with friendly reguards Ratman2000 - Original Message - From: Keeper [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, October 10, 2007 3:19 AM Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? They fill a void. And make a canned game a little more flexible. That being said, Mike: will the upcoming converted source games be available as a beta before they are released? Some are game specific and can't be tested on TF2. Thanks for all the work! Keeper -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony omega Sergi Sent: Tuesday, October 09, 2007 5:11 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? -- [ Picked text/plain from multipart/alternative ] hmm, i seem to think the easiest thing would be. wait for the damned sdk instead of trying to rush it. plugins suck and aren't that important anyway :P ___ 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
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
Hi Mike, In addition to an updated ienginesound.h, would it be possible to get a tier1_i486.a build? Thanks, ---David Anderson http://www.bailopan.net/ Mike Durand wrote: You should make sure that you have installed VS 2005 SP1 as well as this hotfix: http://support.microsoft.com/?kbid=930198 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, October 08, 2007 5:52 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hello, i now have many errors by compiling my plugin... I hope anybody can help me! ../HL2SDK-TF2/tier1/convar.cpp In file included from ../HL2SDK-TF2/public/tier1/iconvar.h:21, from ../HL2SDK-TF2/public/tier1/convar.h:20, from ../HL2SDK-TF2/tier1/convar.cpp:13: ../HL2SDK-TF2/public/tier1/strtools.h:244: Fehler: wrong number of template arguments (1, should be 2) ../HL2SDK-TF2/public/tier1/strtools.h:24: Fehler: provided for `templateclass T, class I struct CUtlMemory' ../HL2SDK-TF2/public/tier1/strtools.h:244: Fehler: template argument 2 is invalid ../HL2SDK-TF2/public/tier1/strtools.h:247: Fehler: wrong number of template arguments (1, should be 2) ../HL2SDK-TF2/public/tier1/strtools.h:24: Fehler: provided for `templateclass T, class I struct CUtlMemory' ../HL2SDK-TF2/public/tier1/strtools.h:247: Fehler: template argument 2 is invalid In file included from ../HL2SDK-TF2/tier1/convar.cpp:15: ../HL2SDK-TF2/public/tier1/characterset.h:22: Fehler: in Konflikt stehende Deklaration »typedef struct characterset_s characterset_t« ../HL2SDK-TF2/public/tier1/convar.h:41: Fehler: »struct characterset_t« hat eine vorherige Deklaration als »struct characterset_ts« In file included from ../HL2SDK-TF2/tier1/convar.cpp:16: ../HL2SDK-TF2/public/tier1/utlbuffer.h: In member function `void CUtlBuffer::ActivateByteSwappingIfBigEndian()': ../HL2SDK-TF2/public/tier1/utlbuffer.h:153: Fehler: `IsX360' undeclared (first use this function) ../HL2SDK-TF2/public/tier1/utlbuffer.h:153: Fehler: (Each undeclared identifier is reported only once for each function it appears in.) ../HL2SDK-TF2/public/tier1/utlbuffer.h: In member function `void CUtlBuffer::GetTypeBin(T) [with T = float]': ../HL2SDK-TF2/public/tier1/utlbuffer.h:629: Fehler: `IsX360' undeclared (first use this function) In file included from ../HL2SDK-TF2/tier1/convar.cpp:17: ../HL2SDK-TF2/public/tier1/tier1.h: In member function `virtual InitReturnVal_t CTier1AppSystemIInterface, ConVarFlag::Init()': ../HL2SDK-TF2/public/tier1/tier1.h:95: Fehler: »ConCommandBaseMgr« wurde nicht deklariert ../HL2SDK-TF2/public/tier1/tier1.h: In member function `virtual void CTier1AppSystemIInterface, ConVarFlag::Shutdown()': ../HL2SDK-TF2/public/tier1/tier1.h:104: Fehler: 'class ICvar' has no member named 'UnlinkVariables' ../HL2SDK-TF2/public/tier1/tier1.h: In member function `virtual bool CTier1AppSystemIInterface, ConVarFlag::RegisterConCommandBase(ConCommandBase*)': ../HL2SDK-TF2/public/tier1/tier1.h:113: Fehler: 'class ConCommandBase' has no member named 'SetNext' ../HL2SDK-TF2/public/tier1/tier1.h:116: Fehler: 'class ICvar' has no member named 'RegisterConCommandBase' ../HL2SDK-TF2/tier1/convar.cpp:18:40: tier1/convar_serverbounded.h: Datei oder Verzeichnis nicht gefunden ../HL2SDK-TF2/tier1/convar.cpp: At global scope: ../HL2SDK-TF2/tier1/convar.cpp:384: Fehler: prototype for `characterset_t* CCommand::DefaultBreakSet()' does not match any in class `CCommand' ../HL2SDK-TF2/public/tier1/convar.h:201: Fehler: candidate is: static characterset_t* CCommand::DefaultBreakSet() ../HL2SDK-TF2/tier1/convar.cpp:384: Fehler: `characterset_t* CCommand::DefaultBreakSet()' and `static characterset_t* CCommand::DefaultBreakSet()' cannot be overloaded ../HL2SDK-TF2/tier1/convar.cpp:389: Fehler: prototype for `bool CCommand::Tokenize(const char*, characterset_t*)' does not match any in class `CCommand' ../HL2SDK-TF2/public/tier1/convar.h:186: Fehler: candidate is: bool CCommand::Tokenize(const char*, characterset_t*) ../HL2SDK-TF2/tier1/convar.cpp: In function `void ConVar_PrintDescription(const ConCommandBase*)': ../HL2SDK-TF2/tier1/convar.cpp:1165: Fehler: expected primary-expression vor const ../HL2SDK-TF2/tier1/convar.cpp:1165: Fehler: expected `;' vor const ../HL2SDK-TF2/tier1/convar.cpp:1173: Fehler: `pBounded' undeclared (first use this function) make: *** [obj/plugin/tier1/convar.o] Fehler 1 I have replaced ALL files that we have on the FTP. With friendly reguards Ratman2000 - Original Message - From: Mike Durand [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, October 03, 2007 3:06 AM Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hi All- I decided that posting the contents of the files on the Wiki was lunacy. So I made a new user on our FTP site that you can use to get a zip of the headers: ftp.valvesoftware.com user: sourcemod password sourcemod
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
Awesome, thanks :D ---David Anderson http://www.bailopan.net/ Mike Durand wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I added ienginesound.h and strtools.h. I'll add the tier1_i486.a when I can. -Mike - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com hlcoders@list.valvesoftware.com Sent: Mon Oct 08 15:15:26 2007 Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hi Mike, In addition to an updated ienginesound.h, would it be possible to get a tier1_i486.a build? Thanks, ---David Anderson http://www.bailopan.net/ Mike Durand wrote: You should make sure that you have installed VS 2005 SP1 as well as this hotfix: http://support.microsoft.com/?kbid=930198 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, October 08, 2007 5:52 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hello, i now have many errors by compiling my plugin... I hope anybody can help me! ../HL2SDK-TF2/tier1/convar.cpp In file included from ../HL2SDK-TF2/public/tier1/iconvar.h:21, from ../HL2SDK-TF2/public/tier1/convar.h:20, from ../HL2SDK-TF2/tier1/convar.cpp:13: ../HL2SDK-TF2/public/tier1/strtools.h:244: Fehler: wrong number of template arguments (1, should be 2) ../HL2SDK-TF2/public/tier1/strtools.h:24: Fehler: provided for `templateclass T, class I struct CUtlMemory' ../HL2SDK-TF2/public/tier1/strtools.h:244: Fehler: template argument 2 is invalid ../HL2SDK-TF2/public/tier1/strtools.h:247: Fehler: wrong number of template arguments (1, should be 2) ../HL2SDK-TF2/public/tier1/strtools.h:24: Fehler: provided for `templateclass T, class I struct CUtlMemory' ../HL2SDK-TF2/public/tier1/strtools.h:247: Fehler: template argument 2 is invalid In file included from ../HL2SDK-TF2/tier1/convar.cpp:15: ../HL2SDK-TF2/public/tier1/characterset.h:22: Fehler: in Konflikt stehende Deklaration »typedef struct characterset_s characterset_t« ../HL2SDK-TF2/public/tier1/convar.h:41: Fehler: »struct characterset_t« hat eine vorherige Deklaration als »struct characterset_ts« In file included from ../HL2SDK-TF2/tier1/convar.cpp:16: ../HL2SDK-TF2/public/tier1/utlbuffer.h: In member function `void CUtlBuffer::ActivateByteSwappingIfBigEndian()': ../HL2SDK-TF2/public/tier1/utlbuffer.h:153: Fehler: `IsX360' undeclared (first use this function) ../HL2SDK-TF2/public/tier1/utlbuffer.h:153: Fehler: (Each undeclared identifier is reported only once for each function it appears in.) ../HL2SDK-TF2/public/tier1/utlbuffer.h: In member function `void CUtlBuffer::GetTypeBin(T) [with T = float]': ../HL2SDK-TF2/public/tier1/utlbuffer.h:629: Fehler: `IsX360' undeclared (first use this function) In file included from ../HL2SDK-TF2/tier1/convar.cpp:17: ../HL2SDK-TF2/public/tier1/tier1.h: In member function `virtual InitReturnVal_t CTier1AppSystemIInterface, ConVarFlag::Init()': ../HL2SDK-TF2/public/tier1/tier1.h:95: Fehler: »ConCommandBaseMgr« wurde nicht deklariert ../HL2SDK-TF2/public/tier1/tier1.h: In member function `virtual void CTier1AppSystemIInterface, ConVarFlag::Shutdown()': ../HL2SDK-TF2/public/tier1/tier1.h:104: Fehler: 'class ICvar' has no member named 'UnlinkVariables' ../HL2SDK-TF2/public/tier1/tier1.h: In member function `virtual bool CTier1AppSystemIInterface, ConVarFlag::RegisterConCommandBase(ConCommandBase*)': ../HL2SDK-TF2/public/tier1/tier1.h:113: Fehler: 'class ConCommandBase' has no member named 'SetNext' ../HL2SDK-TF2/public/tier1/tier1.h:116: Fehler: 'class ICvar' has no member named 'RegisterConCommandBase' ../HL2SDK-TF2/tier1/convar.cpp:18:40: tier1/convar_serverbounded.h: Datei oder Verzeichnis nicht gefunden ../HL2SDK-TF2/tier1/convar.cpp: At global scope: ../HL2SDK-TF2/tier1/convar.cpp:384: Fehler: prototype for `characterset_t* CCommand::DefaultBreakSet()' does not match any in class `CCommand' ../HL2SDK-TF2/public/tier1/convar.h:201: Fehler: candidate is: static characterset_t* CCommand::DefaultBreakSet() ../HL2SDK-TF2/tier1/convar.cpp:384: Fehler: `characterset_t* CCommand::DefaultBreakSet()' and `static characterset_t* CCommand::DefaultBreakSet()' cannot be overloaded ../HL2SDK-TF2/tier1/convar.cpp:389: Fehler: prototype for `bool CCommand::Tokenize(const char*, characterset_t*)' does not match any in class `CCommand' ../HL2SDK-TF2/public/tier1/convar.h:186: Fehler: candidate is: bool CCommand::Tokenize(const char*, characterset_t*) ../HL2SDK-TF2/tier1/convar.cpp: In function `void ConVar_PrintDescription(const ConCommandBase*)': ../HL2SDK-TF2/tier1/convar.cpp:1165: Fehler: expected primary
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
Everything loads+works just fine now. Thanks for your help, Mike! ---David Anderson http://www.bailopan.net/ Mike Durand wrote: Just out of curiosity: has anyone else gotten close to getting their updated plugin to build/work? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Durand Sent: Thursday, October 04, 2007 11:15 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? OK. I added these: byteswap.h convar_serverbounded.h vstdlib.lib mathlib.lib tier0.lib tier2.lib vstdlib.lib Do you still get an unresolved when you link tier1.lib but don't compile convar.cpp? I would try that route if you haven't already. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Wednesday, October 03, 2007 6:14 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Phew! Still a few more errors... - Looks like CByteswap isn't defined in utlbuffer.h - tier1/convar_serverbounded.h is missing - Unresolved externals while linking: _GetCVarIF, ConMsg, etc not found. do we need new tier0 and vstdlib libs? - Another unresolved link error, to ConCommand::ConCommand when using CON_COMMAND. I can't include both convar.cpp and tier1.lib (since they overlap), but if I cherry-pick code out of convar.cpp then it works. ---David Anderson http://www.bailopan.net/ Mike Durand wrote: They are there now. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Wednesday, October 03, 2007 2:51 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Seems to be compiling after some strtools fixes -- the next step is linking ;) I think we're gonna need a new tier1.lib or convar.cpp. Thanks, ---David Anderson http://www.bailopan.net/ Mike Durand wrote: I've added 'iconvar.h' and 'convar.h'. That should keep those crickets under control until the next compilation error. :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer 'voogru' MacDonald Sent: Wednesday, October 03, 2007 11:42 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? I hear crickets. - voogru. ___ 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
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
Seems to be compiling after some strtools fixes -- the next step is linking ;) I think we're gonna need a new tier1.lib or convar.cpp. Thanks, ---David Anderson http://www.bailopan.net/ Mike Durand wrote: I've added 'iconvar.h' and 'convar.h'. That should keep those crickets under control until the next compilation error. :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer 'voogru' MacDonald Sent: Wednesday, October 03, 2007 11:42 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? I hear crickets. - voogru. ___ 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] TF2 Plugin Headstart? VEngineCvar004?
Phew! Still a few more errors... - Looks like CByteswap isn't defined in utlbuffer.h - tier1/convar_serverbounded.h is missing - Unresolved externals while linking: _GetCVarIF, ConMsg, etc not found. do we need new tier0 and vstdlib libs? - Another unresolved link error, to ConCommand::ConCommand when using CON_COMMAND. I can't include both convar.cpp and tier1.lib (since they overlap), but if I cherry-pick code out of convar.cpp then it works. ---David Anderson http://www.bailopan.net/ Mike Durand wrote: They are there now. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Wednesday, October 03, 2007 2:51 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Seems to be compiling after some strtools fixes -- the next step is linking ;) I think we're gonna need a new tier1.lib or convar.cpp. Thanks, ---David Anderson http://www.bailopan.net/ Mike Durand wrote: I've added 'iconvar.h' and 'convar.h'. That should keep those crickets under control until the next compilation error. :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer 'voogru' MacDonald Sent: Wednesday, October 03, 2007 11:42 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? I hear crickets. - voogru. ___ 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
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
Mike: I think a definition for CCommand is missing. In reply to the abstraction/metamod comment(s): A general abstraction is probably a waste of time, especially if one engine will be deprecated for another. Such a layer is best done on a plugin-by-plugin basis as needed. In that vein, the engine differences are too severe for us to distribute a single Metamod binary, so we will be distributing separate builds for the two engines. While Metamod's API (as always) remains backwards compatible (and will work no matter which build is chosen), obviously Metamod plugins that require HL2 engine API will still need their own changes anyway. As for child plugins having to make users to download alternate builds, MM:S 1.6.0 ameliorates this somewhat by letting you see which engine version is loaded. Normal server plugins may have a tougher time since Valve hasn't changed the IServerPluginCallbacks version number (as of this writing). You can't do the pretty thing and detect+return a different interface on load. Hopefully that will get changed, along with the version number on ServerGameDLL. ---David Anderson http://www.bailopan.net/ Nick wrote: metamod? On 10/2/07, Tony Paloma [EMAIL PROTECTED] wrote: Has anybody thought about creating some sort of abstraction to allow us to use the same DLL/so for both the older engine and the newer one? I was thinking of thinking of taking the adapter approach and creating my own classes that would know which version of the interface to use. I'm interested in other ideas though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Durand Sent: Tuesday, October 02, 2007 6:06 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? Hi All- I decided that posting the contents of the files on the Wiki was lunacy. So I made a new user on our FTP site that you can use to get a zip of the headers: ftp.valvesoftware.com user: sourcemod password sourcemod The only file available is PluginHeaders.zip, which contains hopefully all of the headers you will need to get a head start on updating your plugins. If I've left any important ones please let me know. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Sent: Tuesday, October 02, 2007 3:10 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? any word on this? At 03:55 PM 9/28/2007, you wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Yes, I'll make all of the updated headers needed for building server plugins available when I get back to the office on Tuesday. -Mike - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com hlcoders@list.valvesoftware.com Sent: Fri Sep 28 10:18:35 2007 Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004? -- [ Picked text/plain from multipart/alternative ] Just a gentle reminder-- any chance, Valve, that we can get the definition for the VEngineCvar004? Again congrats on TF2-- I've been playing way too much of it when I should be coding. -Mattie On 9/18/07, Mattie Casper [EMAIL PROTECTED] wrote: Just to compare notes: I had the same findings this afternoon for (a) and (b), though I didn't check out the differences in IServerGameDLL005. As for (b), that vstdlib to vstdlib_s relocation is problematic to manage for existing plugins. It's all a bit of a mess with so many things relocated. From what I can ascertain, any substantial plugin would probably have to wait for the SDK release or maybe a secondary/temporary/bridge library to cover for the missing pieces. I hope a clarification on the deprecation/relocation will come with the SDK update. In an effort to even get a barebones VSP loaded into the TF2 server, I cut a dependency on the GetCVarIF() usage in convar.cpp (one of those relocated/removed exports). After that's done, an empty plugin can load and get the majority of callbacks/interfaces from the server. Unfortunately, though, since the VEngineCvar004 interface is used by TF2, the plugin can't register console commands or variables. I wanted to request that interface because with it, it should be possible to make a a simplistic (possibly CRT-dependent) plugin as a proof-of-concept on TF2. As it stands, all I was able to prototype this afternoon was a poor cousin of a real plugin. Surely there are many more landmines hidden. If others uncover them, please share. A lot of us are really excited about TF2 and would like to get integrated. Again, Valve reps, if you get a breather, please provide the VEngineCvar004 interface definition to tide us over until the SDK update. It might not be anywhere near the whole story, but I think it could be worth the time to copy-and-paste it. Thanks, -Mattie On 9/18/07, David
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
There seems to be more changes than just that; here's my cursory analysis from a whole ten minutes of looking: a) IServerGameDLL005 is not the same as IServerGameDLL005 from the original engine (the last four functions or so are new). I didn't check the other game-provided interfaces. b) vstdlib.dll no longer exports a whole slew of functions. It looks like the intention was, a long time ago, to deprecate it and move exports to vstdlib_s.dll. However the current SDK defines the imports against vstdlib.dll, so we'll need a new import library [?] or some sort of clarification. c) It looks like mods are getting compiled with GCC4/MSVC8 now, which is great news, but a forewarning to people who grab binary signatures: MSVC8 has a tendency to optimize internal function calls down to a non-standard calling convention. Valve said they'd provide the changes once the fires are put out or something, so those are just musings while we wait semi-patiently. --- David Anderson http://www.bailopan.net/ AlliedModders Mattie Casper wrote: -- [ Picked text/plain from multipart/alternative ] Just doing some quick research and it almost looks like we could make some semblance of a working server plugin for TF2 if we had access to the definition of VEngineCvar004. Can we get a copy of this, even if it's not official/beta, just for prototyping purposes? Something along the lines of what was posted last year for ISERVERPLUGINCALLBACKS002http://developer.valvesoftware.com/wiki/Querying_ConVars_from_Server_Pluginswould be great, but even something less formal would help immensely. Thanks in advance, and congratulations on getting the TF2 beta out the door. Just about everyone I've talked to has agreed that it's impressive. If someone else has had better luck figuring out VEngineCvar004, please don't hesitate to share. ;) -Mattie -- ___ 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] Downloadables Bug? VALVE?
I never knew that text could be so intrusive. Is it:
a) The colors (think of the children!),
b) The letters themselves (which could, on occasion, be combined to
form words), or,
c) The fact that they can be arbitrarily positioned?
There's already a way to do b (white, centered), so I'm guessing there
must be something abjectly heinous about the other two. If such is the
case, why not add something for coloring but not positioning, or
something for positioning but not coloring?
---David Anderson
http://www.bailopan.net/
Yahn Bernier wrote:
Alfred and I discussed and there was too much concern that it would be
abused so we're going to leave it out for now. I think there are other
ways for plugins to present info to clients that aren't as intrusive.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of LDuke
Sent: Tuesday, March 13, 2007 12:40 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Downloadables Bug? VALVE?
--
[ Picked text/plain from multipart/alternative ] The downloadables bug
fix is something a lot of plugin developers and server admins are very
happy about having. Thank you.
What about the CenterPrintText font definition is missing from
ClientScheme.res ? Did that just not make it in, or is there some
other reason that it won't be added?
Grant
(L. Duke)
On 2/24/07, Yahn Bernier [EMAIL PROTECTED] wrote:
Sure
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of LDuke
Sent: Saturday, February 24, 2007 6:04 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Downloadables Bug? VALVE?
--
[ Picked text/plain from multipart/alternative ] Another bug that's
been around for a while:
The CenterPrintText font definition is missing from ClientScheme.res
so that a HudMsg doesn't get displayed. One of the guys at Turtlerock
said he'd add it to the to-do list months ago. Would it be possible to
add this fix to the next update also?
I've been trying to show a timer in an unobtrusive place on the screen
for a CAL match plugin for DODS, but there is really no way to do this
right now.
The plugin interface doesn't seem to obey the time parameter so can't
be updated (plus it prints right on top of the flag status icons), the
center say and hint text are too much in the way of the player's view.
It would be an easy fix, just need to add the font definition for
CenterPrintText to the ClientScheme.res file for CSS and DODS.
Thanks,
Grant
(L. Duke)
P.S. This is the definition I've been using to test but the players
have to download a fixed .res file manually:
CenterPrintText
{
1
{
nameTrebuchet MS
tall24
weight900
range0x 0x007F//Basic Latin
antialias 1
additive1
}
}
'
On 2/24/07, Yahn Bernier [EMAIL PROTECTED] wrote:
No ETA, probably in the next few weeks though.
Yahn
--
___
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
Re: [hlcoders] Nov 29 Source Update: New interface?
As an addendum, could we find out what changed for ServerGameDLL006? I'd like to know for backwards compatibility purposes. ~dvander http://www.bailopan.net/ Mattie Casper wrote: Hello, The Source update today mentions Added an interface to allow servers to query most cvar values on the clients. Can someone point me to more details on this? Is it via the existing engine-GetClientConVarValue()? Or is there going to be a new API or mechanism for doing this? Thanks for the details, -Mattie P.S. Just to have them in print, here are the Source updates today that might be of most interest to plugin developers: * Added cvars to let the server prevent clients setting unreasonable network settings: sv_mincmdrate, sv_maxcmdrate, sv_client_predict, sv_client_interpolate, sv_client_interp, and sv_client_cmdrate_difference * Added protection against servers manipulating the cl_restrict_server_commands cvar * Allow servers to execute the play command on clients * Added an interface to allow servers to query most cvar values on the clients * Removed cl_cmdbackup ___ 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] Nov 29 Source Update: New interface?
Thanks for the info! A quick question about the implementation: When this was done for HL1, there were a few problems that were corrected with an eventual second API change. It was impossible to pair the call and the callback, because the callback didn't return the cvar name (later this was fixed and a request ID was added). Also, originally the callback wasn't always guaranteed to fire, for example if the CVAR didn't exist or the client disconnected. Are there any quirks like this in the HL2 version? Thanks, ~dvander http://www.bailopan.net/ Mike Durand wrote: Hi All- Here's some elaboration: There's a new function in IVEngineServer and IServerPluginHelpers called StartQueryCvarValue that the server can use to query cvars on the clients. IServerGameDLL and IServerPluginCallbacks have new callbacks to handle the cvar's value coming back from the client, and their interface versions have been increased. This shouldn't cause any trouble for anyone, but when people pickup the new SDK, they'll have to implement the new callback in their mods in order to get their mods to compile. I'll add some details to the VDC Wiki and the release notes when the next SDK goes out. It shouldn't be a concern before then, but let me know if it is. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattie Casper Sent: Wednesday, November 29, 2006 4:40 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Nov 29 Source Update: New interface? Hello, The Source update today mentions Added an interface to allow servers to query most cvar values on the clients. Can someone point me to more details on this? Is it via the existing engine-GetClientConVarValue()? Or is there going to be a new API or engine-mechanism for doing this? Thanks for the details, -Mattie P.S. Just to have them in print, here are the Source updates today that might be of most interest to plugin developers: * Added cvars to let the server prevent clients setting unreasonable network settings: sv_mincmdrate, sv_maxcmdrate, sv_client_predict, sv_client_interpolate, sv_client_interp, and sv_client_cmdrate_difference * Added protection against servers manipulating the cl_restrict_server_commands cvar * Allow servers to execute the play command on clients * Added an interface to allow servers to query most cvar values on the clients * Removed cl_cmdbackup ___ 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] cl_restrict_server_commands fiasco
You might want to look at public/engine/IEngineSound.h to do it manually. ~dvander http://www.bailopan.net/ Ratman2000 wrote: Hello, we cant use cvar-FindVar(convar)-SetValue(value); becouse its fully Server Side... The Problem is, that we cant force thinks like: play on client side to simple play an sound (mp3 file)... When we force the play command (i cant do any critical thinks with this command...) you become this message on client side: cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/admins/jesus.mp3 Why you have to block this command??? So what can we do to force the client to play sounds??? We havent an solution now... With friendly reguards from Germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 4:06 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Why dont use just use cvar-FindVar(convar)-SetValue(value); I have been using it, becuase it allows you to hook around the sv_cheat flags that would block you with a stright engine-clientcommand. Adam --- LDuke [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I believe that is the exact command that is blocked by this cvar ( engine-ClientCommand( blahblah ) ). On 11/18/06, Nick [EMAIL PROTECTED] wrote: Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting
Re: [hlcoders] cl_restrict_server_commands fiasco
I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ 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 -- - Benjamin Davison -- ___ 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] cl_restrict_server_commands fiasco
Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ 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 -- - Benjamin Davison -- ___ 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
Re: [hlcoders] New SDK Update is Out As Beta
Even if you make a 64bit DLL, there is no 64bit srcds ;) so it's moot. But... You should be able to compile X64 targets with VS2k5 if your Platform SDK (Microsoft's SDK) is the 64-bit compatible one. If you got it with VS2k5 then it should be fine. Just change the target machine in the project options. ~dvander http://www.bailopan.net/ Teddy wrote: Thanks for the SDK update Mike, everythings working beautifully! I've compiled my mod in vs2005 express, and made a linux .so using the 2005 .vcproj. One thing I'm wondering, what do we need to do to compile a 64 bit dll? And will Source SDK Base detect it/support it? And is there any way to do it with vs2005 express? Or will we need professional for that? Thanks! Teddy On 11/2/06, Eric Van Huss [EMAIL PROTECTED] wrote: [ Converted text/html to text/plain ] Yep it's the free one. It compiles and runs HL2MP fine with debug and release builds. You can even run it through the debugger. There are still asserts and missing resources(mentioned previously in this list). You can fix most of the resource bugs my transfering them from certain gcf files. EJ -- From: Adam Foster [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] New SDK Update is Out As Beta Date: Thu, 2 Nov 2006 11:54:54 +0100 On 2 Nov 2006, at 02:05, Eric Van Huss wrote: Using C++ 2005 Express it wouldn't compile. It's a simple fix though! Visual C++ 2005 Express is the free-download one, isn't it? Adam -- Adam Foster - [EMAIL PROTECTED] - http://www.hylobatidae.org/ ___ 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
Re: [hlcoders] VS2003 vs VS2005
Another little thing, Microsoft (last I read) was dropping support for Visual Studio 2003 on Vista, choosing only to support VS2k5 and VB 6.0. I'm not sure if this has changed since then but here's a reference: http://blogs.msdn.com/somasegar/archive/2006/09/26/772250.aspx So it's good to be compatible ahead of time ;) ~dvander http://www.bailopan.net/ Jed wrote: Seeing as the SDK will support VS2005 in upcoming updates whats the low-down on the differences? What exactly are the pros vs. cons for a mod using either version? We're on VS2003 right now and haven't yet swapped to the new code update but if VS2005 has significant advantages we may well swap as part of the shift over to the new code base. Anyone? - Jed ___ 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] Problems with Hl1 SDK being built under VC Express
Hello, The AMX Mod X Dev Team maintains a Visual Studio 2005 compatible port of the HL1SDK. Unfortunately, it is the multiplayer side only, and it looks like you're trying to use the singleplayer code. It'd be better to find a copy of VS2k3 than VS6, as it maintains more backward compatibility than 2k5 does and is easier to use. But if you're interested in the fixed-up multiplayer code to fix up singleplayer as well, it's here (credits for the changes go to Damaged Soul): http://svn.alliedmods.net/viewvc.cgi/hlsdk/?root=amxmodx Or anon SVN access: svn://svn.alliedmods.net/svnroot/amxmodx/hlsdk Hope that helps, ---bail Douglas Temple wrote: -- [ Picked text/plain from multipart/alternative ] Yeah, guess who. It's me again, after dealing with getting the VC 6 header files (which I now have), my new problem (or should I say problems) are as follows: http://rapidshare.de/files/35356326/lotsa_errors.txt.html My problem is that I really don't have the time to go through the SDK and repair all these errors... Would it just be simpler if I acquired a version of VC 6 and used it because I guess that VC Express has changed standards with reagrds to structures... Any help would really be appreciated :) Yours, Douglas -- ___ 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] server plugin port
If the server was started with +ip/+port you can use the ip and port cvars. There's also an IServer interface (public\iserver.h) which looks interesting and accessible from IClient (public\iclient.h) but I've not tried using it. It has a GetUDPPort() call. ---bail http://www.bailopan.net/ Luke Duguid wrote: g;day all, long time reader, first time poster. i have a windows/linux server-side plugin that is capturing CS:S game events relevant game data to a log files. the plugin is using a format of, csdata_host_domain_yy.mm.dd-hh.mm.ss.csv for the logging file, i would like to also add port to the filename. ie. csdata_host_domain_port_yy.mm.dd-hh.mm.ss.csv in case multiple cs:s servers instances of the plugin are runnning on the same physical machine. is their a interface to get the current port of the server from the engine? f not, is this even possible with bsd socket calls? remembering that it does not make sense to query /etc/services as cs;s servers typically do not make use of this on nix configurations. tia, luke use the force duguid On 28-Jul-06, at 7:18 AM, Jeffrey botman Broome wrote: Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] no clue On 7/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Where did you hear that? At 2006/07/27 01:47 AM, Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] Aren't crash dumps related to engine binaries automatically uploaded? It would be cool if Valve would create a publicly accessible symbol server similar to http://msdl.microsoft.com/download/symbols where developers can obtain symbols dynamically. It would even support previous (and BETA) versions of engine DLL in addition to the current version of DLLs released via Steam. See Method B: Symbols The Easy Way: Using Symbol Server... http://www.codeproject.com/debug/postmortemdebug_standalone1.asp -- 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Mathlib.cpp
ahh my mistake, I see now there are functions simply not implemented in asm for linux. sorry ;) ps, if you do implement them, posting them to the list would be cool :) --bail http://www.bailopan.net/ David Anderson wrote: you're just not compiling it right, add -m3dnow and -msse to your flags --bail http://www.bailopan.net/ John Sheu wrote: On Thursday 27 July 2006 2:48 pm, Ondřej Hošek wrote: It's either we care much more about Windows than your alien platform or hey, GCC's better at optimizing than our rewrite to GNU-compatible assembler! Since Valve is the only middleware vendor whose current engine client hasn't been proven to run on Linux by any of its licensors (id's Quake 4 does, see Doom 3; Epic's Unreal II does, see UT2004), I'll be gambling on the probability of the first claim being true. I don't mind re-writing it (rather trivial), but I'm just wondering if there is some master reason for this. If there is, I shall just curse my fate and carry on coding. -John Sheu ___ 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] FW: [hlds_apps] New engine API for CVAR queries
Well, that doesn't make much sense. Despite the fact that Florian will
kill me if I bump the API version again ;] I really think this is a
problem the Engine itself should take care of. Metamod is only a
wrapper. We can't solve (easily) the fact that you don't know if the
query fails or what cvar the query returns.
Nonetheless, Jussi Kivillina and I will come up with something...
P.S. to the person who said this would be good for leagues -- yes, at @
esportsea we've been waiting for something like this. Just note that
since there's no general clcvar change callback, you'll have to query
every few seconds or so, which might generate unnecessary traffic.
---David BAILOPAN Anderson
http://www.sourcemod.net/
http://www.sourcemm.net/
Alfred Reynolds wrote:
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
___
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] To Valve: Developer Forewarning
A hack is a funny thing to call a user message nicely documented in cl_dll/menu.cpp. ~dvander Alfred Reynolds wrote: 3rd party plugins have been using a hack to trigger an unused bit of game code. We provide them with another, maintained, user friendlier version of menus that work across all mods, they need to start using that. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattie Casper Sent: Friday, May 20, 2005 9:42 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] To Valve: Developer Forewarning Alfred or other Valve representative, There are many, many plugin and mod developers displeased at the moment because of your recent decision to change CSS menuing behavior so drastically. I'm not precisely sure why the decision was made to suddenly push such a big change (now rolled-back temporarily) on everyone in the world, but this has wounded our confidence in the support Valve provides to their SDK community. Last night, plugin developers were inundated with yells for help as plugin menuing systems were obliterated in one fell swoop. Those same developers spent frantic hours trying to reverse engineer what caused the problem, all the while trying to communicate the issues to their own users. As far as I can tell, there was absolutely no forewarning. Nothing to indicate to the developer community what could be changed to fix the problem. In turn, there was no warning developers could provide to their users or even early code changes they could make to limit the impact. With some sort of notice, it would have been possible to do a great deal to help the situation. It really comes down to the fact that it's Valve's community of game players that suffer when this happens. If 30% of the servers out there run popular admin mods and those mods suddenly cease to function painfully, people get a much worse impression of steam updates. They, as you know, even come whining to you about why you broke their favorite 3rd party plugin. Now, we certainly aren't asking you to indefinitely support every little feature we use, but we absolutely *must* have forewarning before things changed in sensitive areas-- especially when things are deprecated. Without a heads-up from Valve, the developer community relationship is simply going to crumble into name-calling and constant bickering. None of us want to go that route, but we're going to need better support from Valve in order to avoid it. So, I'm asking nicely for the Valve teams to provide us additional forewarning before making large changes. Deprecating *anything* should be announced well beforehand so that plugin and mod developers can act accordingly. The unannounced update we saw last night simply cannot continue if you care anything about the developer community. Even if you feel something is a hack, you should at least work with us a little more rather than letting us fall onto our own swords. While I appreciate what you guys have done for the developer community, I still think there's more needed or we're all going to suffer. Please give us warning before you change things like this. Thanks for your time. Respectfully yours, -Mattie ___ 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] To Valve: Developer Forewarning
cs_valve - rescue the VALVe development Team from the nasty plug-in haxor terrorists! That made me laugh out loud ;) I think it'd be better if you made it a combination of the two I agree, if Valve could make the built-in more customizeable, it would be an acceptable replacement. The whole escape thing needs to go, and the menu needs to feel more smooth in game (like the ShowMenu ones did). ~dvander Spencer 'voogru' MacDonald wrote: That will almost make me want to play CS:S again. -Original Message- From: Steve Tilson [mailto:[EMAIL PROTECTED] Sent: Friday, May 20, 2005 2:33 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] To Valve: Developer Forewarning Sounds like a nice scenario for a quick mod of cs_office Happy Friday! Alfred Reynolds wrote: snip snip We are not going to be held hostage to 3rd party programmers using triggering out of date and unused game code that isn't part of a published API (i.e part of an exported interface function). - Alfred ___ 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] MenuSelect
Add Access to the users money via IPlayerInfo. It's a generic interface meant to be mod-independant. You would have to be able to derive a special CCSPlayerInfo from it. Same with CS 1.6, you couldn't just get money from the entvars, you had to find the offset from the CBaseEntity base in pvPrivateData (omg hax!)... this is reasonable, since Valve has no reason to abstract that sort of thing. ~dvander Ray wrote: I too am highly disappointed in valve.. Ive spent months of time and many ,many hours trying to make admining our servers an easy thing to do, and making the menus were more for peoples requests to do so, than anything else. The provided api for everything is less than adequate on all accounts. Valve, Alfred, you would Like to know what things are needed? In game menus, not having to hit esq and block my view of the person im about to kick or ban. Leave the menus in ...and allow them to be selectable as to what the command they send on selection the way the esc menus do. The reason the menus are being taken out..is because of the Source TV proxy problem that sending the create menu messages to srctv caused.. Valve had to spend time troubleshooting that..and now the price for there time is to disable something they do not document..other than the 2 dozen source files in the sdk that shows there use. The correct solution is to have the srctv ignore user messages that it doesnt need. (as well as us developers taking the time to not send user messages to bots or hltv) Please provide the radio command menu as is or with programmer selectable commands the same way the esc menus use..Some times being able to hit the menu choices requires quick action... Shutting them down will break everyone's plugin and make it so that administering our servers is a difficult task again. The effects interface seems pretty much an afterthought. Ok for sparks and smoke ..useless for much more, how about bloodstreams and flames and who knows what else. Add Access to the users money via IPlayerInfo. Ray At 12:12 PM 05/20/2005, you wrote: I have to agree that this is a really strange and frustrating approach to take on Valve's part. I'm more disappointed in Valve that there was zero forewarning before they wished to push such a big change onto everyone in the middle of the night. I'm going to start another thread on this topic. -Mattie - Original Message - From: Ray [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, May 20, 2005 6:24 AM Subject: Re: [hlcoders] MenuSelect Its so good to know that Valve cares so much about its customers.. Ive never seen any warning about using a documented SDK user message. From Alfred Reynolds: They are using an undocumented hack to display those menus, this update removes the hack and so they can no longer use it (because the last subsystem that was using it, radio menus, has finally been fixed to be client side). They have a plugin API to display messages to users and get feedback, they should use that. - Alfred They were warned multiple times to not use the hacks they were, so it is upon their own heads. - Alfred ___ 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
Re: [hlcoders] Server Plugins refusing to load
On linux, you can try to use something like strace (you may have to log the output) to catch where calls are messing up. But in the end, it would be very helpful if Valve included some sort of dlerror()/FormatMessage() output when a plugin fails to load. -David BAILOPAN Anderson http://www.sourcemod.net/ Daniel Jennings wrote: Is there any way to tell why my Server Plugins (on Linux dedicated server) are refusing to load? They compile and link correctly but I cannot tell why they wont load. Thank you, Daniel Jennings ___ 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] Server Plug-in Loading Order
What sort of low level hacks are you considering? You may want to look into what Pavol Marko did for SourceMod, a general manager for creating iterated lists of hooks to members in virtual interfaces: http://www.sourcemod.net/devlog/index.php?p=17 (this gives metamod style functionality for things like IVEngineServer and the GameDLL interface). Entities are a bit different, of course, because you need to hook non-virtual things (so far)... Lance can probably tell you more about this if you ask him nicely, he's done it :) ---David BAILOPAN Anderson http://www.sourcemod.net/ Michael Hobson wrote: Alfred, Thank you for the quick reply. At 05:40 PM 2/19/2005, you wrote: They are loaded just after the DllInit() call to the game server dll. What are you doing that requires a particular ordering of load? So the Game DLL's - DLLInit() is called, passing in the engine interfaces and what have you. Then any server plug-ins specified in the mods '/addon' folder get their DLLInit() calls. Then the map begins loading and we start spawning game entities ? The reason I asked is because I am considering some really evil low-level [EMAIL PROTECTED] in order to provide some of the the API hooking functionality that Metamod provided which the server plugin interface does not. Particularly with regard to tracking the game DLL's entity creation and possibly modifying those entities as can be done with Metamod, but there are other ideas I have that are not very concrete yet. Mostly, I'm scoping out capabilities at the moment. - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael A. Hobson Sent: Saturday, February 19, 2005 1:21 AM To: HLCoders Subject: [hlcoders] Server Plug-in Loading Order Jay, Yahn or Alfred: Does the engine load server plug-ins *before* or *after* a mod's game DLL and is this order guaranteed (even on Linux ) ? Michael A. Hobson yahoo: warrior_mike2001 icq: #2186709 mike (at) crusader (dash) services (dot) 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
Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
Your plugin code needs to be able to handle an out of date (or even missing) interface, there are no guarantees that MODs will export the various plugin interfaces. Then why is something rather important like IPlayerInfoManager in public (or even the gamedll)? If the implementation or version is completely arbitrary to anything, shouldn't it be in dlls or something mod-dependent? Anyway, I guess we'll have to work around it. Yay for hacks that should be totally unnecessary :p ~dvander Alfred Reynolds wrote: There needs to be a HL2DM release for it to export these new interfaces (so far only CS:S has had such a release). Hopefully sometime in February. Your plugin code needs to be able to handle an out of date (or even missing) interface, there are no guarantees that MODs will export the various plugin interfaces. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Thursday, January 27, 2005 8:42 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. Hopefully someone can make a comment before this gets overrun with another 40 irrelevant posts of Steam: Technology Failure. Thanks, ~dvander David Anderson wrote: From what I've seen, it seems IPlayerInfoManager on HL2DM is still at version 001 while IPlayerInfoManager on CS:S is at version 002. While all Valve needs to do is recompile, the fact that the version number and interface name are in one string make it very difficult for good backward compatibility. Assuming they were separated, and Valve simply added new functions to the end of the vtable, it wouldn't be a problem. But that's not going to happen. What's the solution to this? Are we going to have to do ugly hacks to check the name's last three digits from X to 001 until we get a valid interface pointer? Other than that, I see nasty compatibility problems in the future. Thanks for any help, -David BAILOPAN Anderson http://www.sourcemod.net/ ___ 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
Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. Hopefully someone can make a comment before this gets overrun with another 40 irrelevant posts of Steam: Technology Failure. Thanks, ~dvander David Anderson wrote: From what I've seen, it seems IPlayerInfoManager on HL2DM is still at version 001 while IPlayerInfoManager on CS:S is at version 002. While all Valve needs to do is recompile, the fact that the version number and interface name are in one string make it very difficult for good backward compatibility. Assuming they were separated, and Valve simply added new functions to the end of the vtable, it wouldn't be a problem. But that's not going to happen. What's the solution to this? Are we going to have to do ugly hacks to check the name's last three digits from X to 001 until we get a valid interface pointer? Other than that, I see nasty compatibility problems in the future. Thanks for any help, -David BAILOPAN Anderson http://www.sourcemod.net/ ___ 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] HL2DM IPlayerInfoManager Out of Date
Yes, I understand this - but it was relatively easy in HL1. Part of the problem is that the interface name and version are concatenated as one string, which makes it more difficult to request older versions iteratively. It's not really a problem requesting things from the engine, since that is assumed to be okay... it's from the GameDLL where it's a problem. And if mod developers and even Valve aren't updating the GameDLL interfaces to their own SDK, it makes sense that an updated engine with old GameDLL interfaces could also break. (Although that's not the case here, since I don't think Engine uses IPlayerInfo). All I'm saying is, it would be better to separate the version/name of interfaces, and that it would be nice if when Valve did update API, they recompiled their own mods (to at least set forth good policy for mod developers). What's the point of releasing public API changes if you're only going to half-support them? But you're right, in the end, the burden is on the Server Plugin author. Which, as I said, rather invalidates the useful-ness of them. Oh well. ~dvander jeff broome wrote: On Thu, 27 Jan 2005 11:42:22 -0500, David Anderson [EMAIL PROTECTED] wrote: I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. I'm not sure I fully understand the problem. Are you attempting to have a single plugin that can support any MOD? (in this case you're saying a single plugin can't support CS:S and HL2DM because it either accesses version 001 or version 002, but not both) My understanding of the Interface version stuff was so that Valve could upgrade the engine interface without breaking old MODs that didn't want to update to the latest SDK (and API). If this is Valve's intent, then that puts the burden on you, the multi-mod plugin creator, to properly handle the engine interfaces used by each MOD. Valve probably should be able to make CS:S and HL2DM both use the same engine interface versions, but this would require lock-stepping the releases so that if CS:S requires a new engine interface, the CS:S upgrade wouldn't be released until the HL2DM team had also done everything necessary to support that engine interface (and vice-versa). Once you add Day of Defeat:S and TFC:S, the updates become fewer and fewer since each update is waiting on the others. Since Valve has no control over outside MOD teams (Natural Selection:Source and others), you would still have to support whatever version of the engine interfaces those MODs are using. 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
Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
Kids these days.. if every scrap of data doesnt have its own class, factory and RPC interface, they call it a hack. ;) Listen here whipper-snapper, you're talking to someone who hand coded portions of his mod in assembly ;] There are some things that are considered good design and other things that are not - requesting iterations of interface versions by decrementing ASCII characters is definitely a hack, and (I certainly hope) it's not Valve's intended use. ~dvander Luke Graham wrote: strcat() strcmp() atoi() char * restoffoo = foo[sizeofstuffidontwant] Strings arent that hard... and they certainly arent ugly hacks. Kids these days.. if every scrap of data doesnt have its own class, factory and RPC interface, they call it a hack. ;) On Thu, 27 Jan 2005 12:43:10 -0500, David Anderson [EMAIL PROTECTED] wrote: Yes, I understand this - but it was relatively easy in HL1. Part of the problem is that the interface name and version are concatenated as one string, which makes it more difficult to request older versions iteratively. It's not really a problem requesting things from the engine, since that is assumed to be okay... it's from the GameDLL where it's a problem. And if mod developers and even Valve aren't updating the GameDLL interfaces to their own SDK, it makes sense that an updated engine with old GameDLL interfaces could also break. (Although that's not the case here, since I don't think Engine uses IPlayerInfo). All I'm saying is, it would be better to separate the version/name of interfaces, and that it would be nice if when Valve did update API, they recompiled their own mods (to at least set forth good policy for mod developers). What's the point of releasing public API changes if you're only going to half-support them? But you're right, in the end, the burden is on the Server Plugin author. Which, as I said, rather invalidates the useful-ness of them. Oh well. ~dvander jeff broome wrote: On Thu, 27 Jan 2005 11:42:22 -0500, David Anderson [EMAIL PROTECTED] wrote: I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. I'm not sure I fully understand the problem. Are you attempting to have a single plugin that can support any MOD? (in this case you're saying a single plugin can't support CS:S and HL2DM because it either accesses version 001 or version 002, but not both) My understanding of the Interface version stuff was so that Valve could upgrade the engine interface without breaking old MODs that didn't want to update to the latest SDK (and API). If this is Valve's intent, then that puts the burden on you, the multi-mod plugin creator, to properly handle the engine interfaces used by each MOD. Valve probably should be able to make CS:S and HL2DM both use the same engine interface versions, but this would require lock-stepping the releases so that if CS:S requires a new engine interface, the CS:S upgrade wouldn't be released until the HL2DM team had also done everything necessary to support that engine interface (and vice-versa). Once you add Day of Defeat:S and TFC:S, the updates become fewer and fewer since each update is waiting on the others. Since Valve has no control over outside MOD teams (Natural Selection:Source and others), you would still have to support whatever version of the engine interfaces those MODs are using. 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 ___ 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] HL2DM IPlayerInfoManager Out of Date
From what I've seen, it seems IPlayerInfoManager on HL2DM is still at version 001 while IPlayerInfoManager on CS:S is at version 002. While all Valve needs to do is recompile, the fact that the version number and interface name are in one string make it very difficult for good backward compatibility. Assuming they were separated, and Valve simply added new functions to the end of the vtable, it wouldn't be a problem. But that's not going to happen. What's the solution to this? Are we going to have to do ugly hacks to check the name's last three digits from X to 001 until we get a valid interface pointer? Other than that, I see nasty compatibility problems in the future. Thanks for any help, -David BAILOPAN Anderson http://www.sourcemod.net/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] GameFrame
I don't feel safe doing some HL stuff in a thread, especially since what I'm doing in GameFrame is _definitely_ not thread safe. My problem is that GameFrame won't fire unless a player is in the server - this makes it difficult for me to beta test things quickly. -David Anderson On Tue, 14 Dec 2004, Ronny Schedel wrote: Depends on what he wants to do. I had never any problems with threads in my past hl1 programms :o) Greets Ronny Ronny Schedel wrote: Just use a thread. Eek! Are the engine functions in the listen server and dedicated server 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 ___ 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] Naming format for Server Plugins
I've seen quite a few people releasing server plugins already and, I don't know if this has been discussed, but would it be a wise idea to create some sort of default naming scheme? With metamod we had myplugin_mm, so maybe we should do myplugin_sp? And since the server can read multiple vdf files in the addons/ folder, it would be wise for people who make plugins to distribute the vdf file with it, named after their plugin (myplugin_sp.vdf). Just a suggestion... UA used to keep a big doc on standards like this. -David Anderson ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Naming format for Server Plugins
Hrm, I guess you like typing a lot more ;] That's ten extra characters, why not just abbreviate it... it also makes it so the actual purpose of the file is later in the name instead of immediate (which is confusing). -David Anderson On Mon, 6 Dec 2004, Jeffrey botman Broome wrote: Marcelo Bezerra wrote: I guess the new standard is serverplugin_myname At least it is what the sdk suggest (the sample is serverplugin_empty). I would agree. The above is much less ambiguous than xxx_sp. What is sp ? Server Plugin? Single Player? Super Powered? :) -- 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] Srcds won't load debug builds
Sorry if this has been answered already... When I load a debug build of my server plugin, srcds brings up a window titled Error that says: Module bin/myplugin.dll is a debug build. Then it exits. I built the sample serverplugin in debug mode fine, did I leave something out in my new project file? Thanks, -David Anderson ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Srcds won't load debug builds
Well, I figured out that I have to attach the debugger _before_ starting srcds. Oops :) -David Anderson On Sat, 4 Dec 2004, David Anderson wrote: Sorry if this has been answered already... When I load a debug build of my server plugin, srcds brings up a window titled Error that says: Module bin/myplugin.dll is a debug build. Then it exits. I built the sample serverplugin in debug mode fine, did I leave something out in my new project file? Thanks, -David Anderson ___ 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] Compiling on Linux
Am I the only one whose SDK is simply missing the Linux libraries required to compile the SDK? The makefiles in src\linux_sdk reference versions of src\lib files that end in _i486.so and they aren't there. Thanks, -David Anderson ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Compiling on Linux
Ahhh, I see, I need to have the game binaries on hand... missed that. Sigh. Thanks. -David Anderson On Sat, 4 Dec 2004, Alfred Reynolds wrote: This document: http://www.valve-erc.com/srcsdk/linux_compiling.html Describes the environment you need to compile the SDK under linux. Note that you also need to setup the base Makefile before being able to compile the SDK. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Saturday, December 04, 2004 9:33 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Compiling on Linux Am I the only one whose SDK is simply missing the Linux libraries required to compile the SDK? The makefiles in src\linux_sdk reference versions of src\lib files that end in _i486.so and they aren't there. Thanks, -David Anderson ___ 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] Using gpGlobals-maxclients
Alfred, is it possible the plugin interface could be extended to do this? The tasking system for most Metamod-plugins I wrote for HL1 used the timer in gpGlobals to work. It was a nice, OS independent way of measuring in sub-second intervals matched with the framerate. Are there any other ways to do this? Thanks, -David Anderson On Fri, 3 Dec 2004, Alfred Reynolds wrote: You don't have any code there to make gpGlobals point anywhere useful The game dll initializes it in CServerGameDLL::DLLInit() but plugins don't have that call so you can't get access to it. Use IServerGameClients::GetPlayerLimits() to get the min and max players for the mod, or record the maxplayers in use for the current map from CEmptyServerPlugin::ServerActivate(). - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Sent: Friday, December 03, 2004 6:40 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Using gpGlobals-maxclients OK how Do I use it? I tried static CGlobalVarsBase dummyvars( true ); // So stuff that might reference gpGlobals during DLL initialization won't have a NULL pointer. // Once the engine calls Init on this DLL, this pointer gets assigned to the shared data in the engine CGlobalVarsBase *gpGlobals = dummyvars; Then did gpGlobals-maxclients, but I'm getting a 0 in return. Does it need to be defined elsewhere? I'm lost :( I'm trying to use this in a plugin. Thanks, Josh (Pimp Daddy) ___ 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] Using gpGlobals-maxclients
Thank you very much, Alfred! -David Anderson On Fri, 3 Dec 2004, Alfred Reynolds wrote: You can use IEffects::Time from the IEFFECTS_INTERFACE_VERSION in the game dll to get access to gpGlobals-curtime. gpGlobals is a crutch and I want to kill it off :) Looking at the class defn for it you only need curtime and maxplayers from it which can be found via other sources, so lets leave it out for now. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Friday, December 03, 2004 9:31 PM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] Using gpGlobals-maxclients Alfred, is it possible the plugin interface could be extended to do this? The tasking system for most Metamod-plugins I wrote for HL1 used the timer in gpGlobals to work. It was a nice, OS independent way of measuring in sub-second intervals matched with the framerate. Are there any other ways to do this? Thanks, -David Anderson On Fri, 3 Dec 2004, Alfred Reynolds wrote: You don't have any code there to make gpGlobals point anywhere useful The game dll initializes it in CServerGameDLL::DLLInit() but plugins don't have that call so you can't get access to it. Use IServerGameClients::GetPlayerLimits() to get the min and max players for the mod, or record the maxplayers in use for the current map from CEmptyServerPlugin::ServerActivate(). - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Sent: Friday, December 03, 2004 6:40 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Using gpGlobals-maxclients OK how Do I use it? I tried static CGlobalVarsBase dummyvars( true ); // So stuff that might reference gpGlobals during DLL initialization won't have a NULL pointer. // Once the engine calls Init on this DLL, this pointer gets assigned to the shared data in the engine CGlobalVarsBase *gpGlobals = dummyvars; Then did gpGlobals-maxclients, but I'm getting a 0 in return. Does it need to be defined elsewhere? I'm lost :( I'm trying to use this in a plugin. Thanks, Josh (Pimp Daddy) ___ 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
[hlcoders] ServerPlugin API
With HL1 metamod, it was possible to hook Engine and GameDLL calls directly because Metamod literally sat in between the engine and gamedll. With HL2's server plugin interface, it appears that it sits on the side, and that you only get a fraction of this power through the IServerPlugin interface. Is this the case? Do we still have the ability to intercept engine/gamedll calls? Or have I missed something in the SDK (I only took a cursory look). Thanks, -David Anderson ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] ServerPlugin API
For example, how would it be possible to hook anything in IServerGameDLL, or say something more useful like IVEngineServer::ChangeLevel or IVEngineServer::CreateEdict or IVEngineServer::LogPrint? -David Anderson On Wed, 1 Dec 2004, Alfred Reynolds wrote: What fraction of power are you missing? The plugin interface should have all the relevant callbacks you need. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Wednesday, December 01, 2004 8:03 PM To: [EMAIL PROTECTED] Subject: [hlcoders] ServerPlugin API With HL1 metamod, it was possible to hook Engine and GameDLL calls directly because Metamod literally sat in between the engine and gamedll. With HL2's server plugin interface, it appears that it sits on the side, and that you only get a fraction of this power through the IServerPlugin interface. Is this the case? Do we still have the ability to intercept engine/gamedll calls? Or have I missed something in the SDK (I only took a cursory look). Thanks, -David Anderson ___ 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] Does HL2 have built-in metamod-like functionality?
Hello! It will be true (just as soon as I write it). Since it is not written yet, then may I make a small request? :) Our modification uses its own modular system and we routed metamod functionality to plugins directly from metamod (we didn't want to do SERVER_COMMAND(meta load plugin)). It will save us thousands of lines of code and hours of debugging with two functions like this: Meta_LoadPlugin() and Meta_UnloadPlugin(). Thanks! ~dvander - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pavol Marko Sent: Tuesday, October 12, 2004 10:34 AM To: [EMAIL PROTECTED] Subject: [hlcoders] Does HL2 have built-in metamod-like functionality? Hello, I remember someone stating that the HL2 engine will have built-in metamod like functionality a while back. Is this actually true? Or is it only a myth? Thanks PM ___ 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] Removing entities
No, they don't. As has been stated before, they are cached internally. When I delete or add spawns, I get spawned at 0,0,0 and then the game crashes. You can CREATE_NAMED_ENTITY() just about anything but a spawn point, and you can REMOVE_ENTITY() only things you created with CREATE_NAMED_ENTITY(). This may have changed since I first found this out (mid February), but try it yourself... -David BAILOPAN Anderson On Fri, 30 Apr 2004, Deadman Standing wrote: 1] You cannot add new spawns dynamically to CS 1.6 anymore. 2] You cannot remove spawns dynamically from CS 1.6 anymore. Double check how you were creating entities as CREATE_NAMED_ENTITY() and REMOVE_ENTITY() work fine in CS 1.6. ___ 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] Removing entities
Some things I found (while making CSDM) on CS entities:
1] You cannot add new spawns dynamically to CS 1.6 anymore.
2] You cannot remove spawns dynamically from CS 1.6 anymore.
3] You can create weapons in two ways - spawning them (in CS 1.6 they will
disappear after 2 seconds though) or by creating fake ones and hooking
Touch()
4] You can remove weapons from CS still... you can look into the archives
and see me begging Alfred to help me with this :] but that was met with
nothing. Calling a weapon's Think() function will destroy it... in
Metamod that's MDLL_Think(edict_t *). I have not tested deleting spawns
because that is no longer useful to me (now I created an algorithm to use
the old spawns and set origins.
Note that this is how you should remove
weapons: Find the weaponbox that has the target weapon model, then
remove the actual entity that has the weapon as the classname, whose owner
is the weaponbox entity.
5] You can test if a player has a shield by seeing what model they have I
think. That is how many AMX Mod * plugins do it.
To spawn weapons in CS what I did was make my own internally cached fake
weapon entities, which are stored in a hash array... then when a player
touches them, I use the item giving code from OLO's fun module.
I'll give you code because I spent weeks figuring this out :] If Valve
decides to break it again in a future update, I will probably quit because
too many people would harass me to fix it :\ but since they are not
obligated to not break it, be aware that this may not work in the future.
-David BAILOPAN Anderson
http://www.amxmodx.org/
Example code for giving a CS weapon:
int iWeapon = ALLOC_STRING(weapon_awp);
edict_t *pWeapon = CREATE_NAMED_ENTITY(iWeapon);
if (FNullEnt(pWeapon))
return;
pWeapon-v.origin = pEntity-v.origin;
pWeapon-v.spawnflags |= SF_NORESPAWN;
MDLL_Spawn(pWeapon);
int solidstate = pWeapon-v.solid;
MDLL_Touch(pWeapon, ENT(pEntity));
if (pWeapon-v.solid == solidstate)
REMOVE_ENTITY(pWeapon);
Example code for destroying a CS weapon:
#ifdef STEAM
#define RemoveWeapon(x) MDLL_Think(x)
#else
#define RemoveWeapon(x) REMOVE_ENTITY(x)
#endif
void DeleteCSWeapon(char *weaponmodel, char *weapon, int player)
{
edict_t *pPlayer = INDEXENT(player);
edict_t *tEnt = FIND_ENTITY_BY_STRING(NULL, classname,
weaponbox);
edict_t *wEnt = NULL;
while (!FNullEnt(tEnt)) {
const char *model = STRING(model);
if (strcmp(model, weaponmodel)==0) {
if (ENTINDEX(tEnt-v.owner)==player) {
wEnt = FIND_ENTITY_BY_STRING(NULL,
classname, weapon);
while (!FNullEnt(wEnt)) {
if
(ENTINDEX(wEnt-v.owner)==ENTINDEX(tEnt)) {
RemoveWeapon(wEnt);
}
wEnt = FIND_ENTITY_BY_STRING(wEnt,
classname, weapon);
} //finding wEnts
} //owners matched
RemoveWeapon(tEnt);
} //weapon matched
tEnt = FIND_ENTITY_BY_STRING(tEnt, classname,
weaponbox);
} //finding tEnts
}
Code for spawning a permanent weapon the ground: build your own give
weapon wrapper :]
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
