Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
-- [ Picked text/plain from multipart/alternative ] FYI-- I started a page on the wiki and filled out a few of the steps needed to convert plugins to the new model. I'm not quite awake, so I apologize in advance for any incoherencies: http://developer.valvesoftware.com/wiki/Orange_box_server_plugins Please correct and add your own experiences there. I know there's a good bit left out. Like others here, I was able to get at least one of my plugins (a minor one) to build/compile/load/work on Windows TF2 srcds. -Mattie On 10/4/07, Mike Durand [EMAIL PROTECTED] 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?
--
[ Picked text/plain from multipart/alternative ]
Hey Ratman--
I didn't have that problem. My console commands worked just fine like this
with no change involving the macro:
CON_COMMAND(my_version, Logs/prints plugin version.)
{
engine-LogPrint(MY_PLUGIN_VERSION \n);
Msg(MY_PLUGIN_VERSION \n);
}
If you leave yours as they were for earlier Source, what error are you
getting? Did you overlook updating your convar.h?
-Mattie
On 10/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello Mattie,
thats a nice idee!
Have you a solution for Commands like:
CON_COMMAND_F( my_test, Test GameDLL Command, FCVAR_GAMEDLL )
{
UTIL_LogPrintf( Test ok! );
}
Or for :
CON_COMMAND( my_test2, Test Command 2 )
{
UTIL_LogPrintf( Test 2 ok! );
}
Becouse the compiler gives errors so we have to add the args param to it!
I think thats a think that have to add to your wiki page!
With friendly Reguards
Ratman2000
- Original Message -
From: Mattie Casper [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Friday, October 05, 2007 10:57 AM
Subject: Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
--
[ Picked text/plain from multipart/alternative ]
FYI-- I started a page on the wiki and filled out a few of the steps
needed
to convert plugins to the new model. I'm not quite awake, so I apologize
in
advance for any incoherencies:
http://developer.valvesoftware.com/wiki/Orange_box_server_plugins
Please correct and add your own experiences there. I know there's a good
bit
left out.
Like others here, I was able to get at least one of my plugins (a minor
one)
to build/compile/load/work on Windows TF2 srcds.
-Mattie
On 10/4/07, Mike Durand [EMAIL PROTECTED] 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
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
-- [ Picked text/plain from multipart/alternative ] FYI-- to be sure other plugin authors are aware (some of you definitely are), the old school: engine-Cmd_Argv(i) engine-Cmd_Args() engine-Cmd_Argc() commands are no longer available from the server. Console commands now get their arguments via an extra parameter passed to the CON_COMMAND(). The argument is an instance of the CCommand class and typically is passed as args if you use the built-in CON_COMMAND macro. As such, the corresponding code would be (notice the change in case): args.Arg(i) args.ArgS() args.ArgC() I happen to have macro'd those references anyway so the swap was fairly easy, but some plugins might need to search/replace/refactor to make this compile properly. Not a minor change (especially for plugins with 100+ console commands), but feels a lot cleaner than accessing the global arguments through the engine which always felt odd. There are more gotchas, but I didn't note all of them so far. I have more plugins to port and am not quite finished with my first-- there was a missing method in the engine interface, InsertServerCommand, which I've asked to have restored. If others did manage to note the changes they needed, please share. :) -Mattie 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
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 Anderson [EMAIL PROTECTED] wrote: 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_Plugins would 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 -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] TF2 Plugin Headstart? VEngineCvar004?
-- [ 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
Re: [hlcoders] TF2 Plugin Headstart? VEngineCvar004?
-- [ Picked text/plain from multipart/alternative ] 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 Anderson [EMAIL PROTECTED] wrote: 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_Plugins would 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 -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] New VDC Page - Querying ConVars from Server Plugins
It's working very well, Mike. Thanks for the update ahead of the SourceSDK update. -Mattie - Original Message - From: Mike Durand [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, December 20, 2006 6:39 PM Subject: [hlcoders] New VDC Page - Querying ConVars from Server Plugins This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hi All- It looks like a lot of people are anxious to use the new functions to query convars from server plugins. And since I'm not quite ready for another SDK release I have made a VDC page that describes the changes that need to be made to iserverplugin.h. http://developer.valvesoftware.com/wiki/Querying_ConVars_from_Server_Plu gins Please let me know if you have any questions, problems, concerns, etc. -Mike -- ___ 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] 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 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
Re: [hlcoders] cl_restrict_server_commands fiasco
Identifying the individual commands to block is a hard problem, which makes me wonder if this isn't why Valve just went with the nuke switch regarding backwards compatibility and blocked everything. (Or perhaps they discovered a filesystem exploit in the field using the client's console. I doubt that, though, or this wouldn't have been optional.) When I tried to name off the individual commands that are simply too valuable not to have access to (connect, playgamesound, etc, etc), the list gets very long. In the end, it even included the infamous alias and bind commands. Even though these are evil commands for griefing players, for the very same reason, they're important for white hat administrators when they need to help newbies out. I run a number of newbie servers for my beta testing and I've found that new players have no grasp of the console and are very confused with how to bind anything custom or interesting (for stats, +jetpacks, etc). Giving the server access to help them bind (at their request) is an important tool we have to improve usability in the game. In addition, it's awfully helpful to get notified of +/- sorts of custom commands by creating, for example, a +jetpack alias on the client that sends the command to the server. In those cases, warning the user of the alias/bind (and allowing them to block it) would be an appropriate remedy. I wanted to respond before this thread died away completely, but this has really hurt the community in ways I couldn't have envisioned before. Typically, when Valve updates something major internally, it breaks things and plugin authors scramble to fix them. Often, the coders accept blame because they were using some unsupported trick or prying in areas Valve doesn't recommend. This time however, plugin authors are being blamed when they're using the supported commands they were given long ago. In the past, plugin writers have been yelled-at (by Valve even) when plugins doing unsupported things break lots of servers. Yet now everyone was using a supported API and with one flick of a switch, it was killed quietly without any nod to how impactful it would be. It's had a very dampening effect on the scripting community, blowing away swaths of popular scripts that relied, indirectly, on engine-ClientCommand(). True, the command is unreliable, it's risky, and half of its functionality works server-side, but that doesn't change the fact that it was heavily used in the field. As a platform, Source surely can't violate backwards compatibility like this without giving us some sort of new alternative (or identifying existing alternatives). Hopefully Valve will either unrestrict the most secure commands or code server-side replacements for those we've lost. At the very minimum, Valve should do better in communicating major regressions in backwards compatibility. If they can do that, it will at least prepare those gaming communities that stick around for the inevitable breaks. Best of luck, -Mattie http://mattie.info/cs/ - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 1:18 AM Subject: 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
[hlcoders] ent_setname bug - Can Valve fix?
Alfred or other Valve representative, It appears that the handy testing console command ent_setname does not work properly in Source games. By default it works well if you are looking at the entity (picker mode), but if you try to set an entity's name in this form: ent_setname oldname newname It will not rename it. It appears that the command detects the 2nd argument because it disregards what I'm looking at, but it doesn't do any name changing and says things like: Set the name of oldname to oldname Thanks for your help, and let me know if this looks like something you could fix. It could really make my life easier while designing and developing. Thanks again for your time, -Mattie ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ent_setname bug - Can Valve fix?
Indeed, looks like an easy fix. Yet, this is not for a mod-- this is for
existing CS:S and HL2DM development. We would need it fixed by Valve in the way
you recommend (or however they deem fit).
Thanks,
-Mattie
- Original Message -
From: Aaron Schiff [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Sunday, April 23, 2006 9:02 PM
Subject: Re: [hlcoders] ent_setname bug - Can Valve fix?
--
[ Picked text/plain from multipart/alternative ]
If you're a coder, it's a simple fix...anyway, it's a modside fix:
if ( (ent-GetEntityName() != NULL_STRING
FStrEq(engine-Cmd_Argv(1), STRING(ent-GetEntityName( ||
(ent-m_iClassname != NULL_STRING FStrEq(engine-Cmd_Argv(1),
STRING(ent-m_iClassname))) ||
(ent-GetClassname()!=NULL FStrEq(engine-Cmd_Argv(1),
ent-GetClassname(
Change the 1s to 2s instead of doing ent_setname oldname newname, you can
do ent_setname newname oldname...which was initially how it was intended to
be implemented:
Arguments: {new entity name} {entity_name} / {class_name}
--
ts2do
--
___
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] Re: Trapping Sprays (Ray)
Please fire the event. That'd be great! To all plugin writers (and mod writers), I highly encourage you to create an event.res file and fire as many events as you can. Events are the lifeblood for the EventScripts plugin, and the more events that admins can script against, the better. -Mattie http://mattie.info/cs/forums/ http://www.eventscripts.com/ - Original Message - From: c0ldfyr3 [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, November 21, 2005 1:24 PM Subject: Re: [hlcoders] Re: Trapping Sprays (Ray) Ok, updated to 1.1.0 B check out the http://spraymod.c0ld.net website for info. And im not using any offsets, at all, my plugin cannot be broken in the foreseeable future but just as an idea, I can add a FireEvent for it in my plug-in so it can be intractable with other plug-ins, hows that sound ? - Original Message - From: Ray [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, November 17, 2005 11:21 PM Subject: Re: [hlcoders] Re: Trapping Sprays (Ray) Its not a problem it self..but since its using an offset etc it can be easily broken by any update. An event from valve would at least still keep functioning...presumably At 09:16 AM 11/17/2005, you wrote: What is it with people and events ? Events are not the way forward people, they suck, their very slow and their all post. With virtual function hooks, its just as easy and cleaner and if you dont want to hook something you dont have to. You can also stop the function from continuing, nice for say instead of player_say dont ya think. Every single bit of MM for HL1 was function hooking So if we change everything over to events, plugins are going to get very restricted. - Original Message - From: Ray [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, November 17, 2005 11:46 AM Subject: RE: [hlcoders] Re: Trapping Sprays (Ray) Yes, but thats not a Valve interface and its a virtual function hook and not the 'proper' way to do things. How hard would it be to pump a player_spray event into the listener? At 10:53 PM 11/15/2005, you wrote: It sounds like there is already a solution and sample code. - Alfred Ray wrote: Come on Alfred, Could you answer this request please? At 07:51 PM 11/15/2005, you wrote: I've now ported this from my Beta release to the new core release V1.1.0zf of Mani Admin Plugin. Regards Mani www.mani-admin-plugin.com -- Message: 1 Date: Mon, 14 Nov 2005 18:39:03 -0500 To: hlcoders@list.valvesoftware.com From: Ray [EMAIL PROTECTED] Subject: Re: [hlcoders] Trapping Sprays Reply-To: hlcoders@list.valvesoftware.com Actually, what I would like to do is figure out a way to add it to Beetlesmod. I have looked at Nemods code and Its beyond my understanding (im a newb programmer for MSVisual and Im using VS 6..so It doesnt compile) All Im looking for is a way to trap it and get location info and do the same type thing...get all the players that sprayed within a small radius. ___ 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
[hlcoders] Many thanks to Valve and Alfred!
I love the new update. Not least because of the new addition of the API InsertServerCommand(): Actually, there is one change (nothing that would break a plugin). We added this function: virtual void InsertServerCommand( const char *str ) = 0; To the end of the IVEngineServer interface (at Mattie's request). - Alfred Thanks a lot guys! I've already incorporated support for this in EventScripts v0.9.0, released last night. This is an excellent exhibition of Valve's support for the plugin community. Thanks again for helping out so quickly! -Mattie ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Examples of uses for IEngine-ServerInsertCommand()
Thanks for the suggestion, but, as you may have guessed, this has been
considered. ;) Yet, creating an entire scripting engine isn't the goal of
EventScripts. There are lots of different scripting engines out there, and they
definitely have their place for administrators who understand coding.
EventScripts is trying to be the middle-ground between a structured/scoped
language and the console commands they know and love. As I mentioned below, ES
doesn't yet support looping and the like and may never do so--- it's not
intended to be a full-powered scripting language.
With EventScripts, we're trying to enhance the console commands so that even
everyday normal console/rcon commands and normal autoexec.cfg/server.cfg files
can take advantage of very simple logic and variable expansion. We don't need
everything a scripting language can do, we just want some basic enhancements to
the command console. Most of these console enhancements would be along the lines
Valve was already been moving, e.g. with setinfo and incrementvar.
Yet, even in the case of a full blown scripting language, not having
InsertCommand() means that any scripts/commands that you wished to invoke via a
normal Valve cfg file would have the same ordering problem if they needed to
pass commands back to the server (e.g. exec, changelevel, kickid, etc). These
commands would execute *after* the current .cfg file was totally resolved and
not in-place. This wouldn't be intuitive and would likely cause problems! It
wouldn't be a problem if you didn't allow the console to launch scripts, but the
server console is a great place for invoking things like that (especially
remotely).
*** TO CLARIFY, this isn't a problem just for scripting engines! *** It's a
problem for ANY PLUGIN that uses console commands and needs to interact with the
console. Let's say I wrote a console command mattie_exec that took Con_Argv(1)
and passed it to exec with a different directory prefix (e.g. my mod's
directory).
// server.cfg
mattie_exec blah.cfg
exec load_plugins.cfg
// end of server.cfg
Now, the mattie_exec command, all it does is call engine-ServerCommand(exec
matties_mod\blah.cfg\n). In this case, the console would execute like this:
1. (contents of server.cfg added to the queue around LevelInit())
2. mattie_exec runs (places exec mattie_mod\blah.cfg at end of queue)
3. exec load_plugins.cfg runs (all plugins activated, configured, etc)
4. exec mattie_mod\blah.cfg runs
You see that even though the mattie_exec command was placed in a certain order
in the cfg file, it's irrelevant. Any server commands those commands rely upon
cannot be activated until after the entire .cfg file has been processed. This
means that if the load_plugins.cfg relied upon any settings created in
blah.cfg, there's no way at all to get it to work short of bypassing the plugin
commands.
Admittedly, this is a simple example, but it underscores the issue outside of a
scripting context. Plugin console commands could be calling back to any number
of other console commands. We all have access to ServerCommand(), right? Well,
just like Valve, we need it's sister command in order to create proper console
commands. Sometimes we don't care about ordering, so ServerCommand() might be
appropriate, but many times ordering *will* be important. We truly need
ServerInsertCommand(), and I hope everyone can see that.
Thanks for your help and for reading this far,
-Mattie
- Original Message -
From: Jeremy Swigart [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Friday, June 10, 2005 7:17 AM
Subject: Re: [hlcoders] Examples of uses for IEngine-ServerInsertCommand()
Have you considered using a scripting language such as lua or
gamemonkeyscript or another one that supports fake threading?
Specifically you might be interested in their ability to execute over
many frames, yet still be written in a top down manner. Here's an
example of GMS, which I use in my bot.
/ server.cfg
if(sv_gravity 800)
{
exec(reset_grav.cfg);
echo(gravity reset);
yield(); // suspend execution of the script till the next frame, can
also do sleep() commands
}
else
{
echo(gravity is fine);
}
echo(this happens the frame after the gravity is reset, or right away
if the exec didnt happen);
Everything you do and much more would be possible using the features
of an existing scripting language, and with it you'd get the power of
conditionals, tables, loops, and much more.
Just an idea.
J
On 6/9/05, Mattie Casper [EMAIL PROTECTED] wrote:
As promised, this email contains examples of the sorts of things that plugin
authors cannot manage in Source without some method to insert commands at the
beginning of the server command queue. This ability is vital for any plugin
wishing to create meta console commands. I.e. commands like alias, exec,
incrementvar, etc.
Variable expansion --
EventScripts makes extensive use of variable expansion for its console
commands, and it's crippled without
Re: [hlcoders] Interface method request: engine-ServerInsertCommand()
Alfred, when you get a moment, can you let me know how this discussion is going? Even if your team could provide a different interface (rather than IEngine), it would solve the crying of many a poor admin. Changing the engine interface is not necessary, that's just the most logical place for it, as I suspect you'd agree. In my forums for EventScripts I have admins clamoring for this support. I've had over 4000 downloads of my plugin (Linux and Windows combined). Yet, without Valve support and exposure of this function, EventScripts will remain a shadow of its true potential. On some platforms, EventScripts is severely crippled and there's really nothing I can do. Without ServerInsertCommand(), I just can't provide my users the functionality they need. Anything you can do to help would be intensely appreciated, Alfred. I'm going to follow-up this email with some examples of the sorts of things that are impossible for plugin authors without this. I know you guys must use it a great deal internally or you couldn't provide 'alias' or 'exec', so I'm hoping you can see the clear value of this to us. Please open it for plugin writers so we can help you extend your console commands. Thanks, as always, for your help, -Mattie - Original Message - From: Alfred Reynolds [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, April 11, 2005 11:59 PM Subject: RE: [hlcoders] Interface method request: engine-ServerInsertCommand() I can suggest it to the team but as its such a base interface we hadn't planned on altering it any time soon. - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattie Casper Sent: Monday, April 11, 2005 8:37 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Interface method request: engine-ServerInsertCommand() Thanks, Alfred, for responding. No-- I'm looking for something different. IVEngineServer::ServerCommand() places the command at the _end_ of of the command buffer. I need the same function that the 'exec' command would use to place a command at the _beginning_ of the command buffer. Without an InsertAtFront or something similar, in-line variable expansion is not possible (without lots of command ordering issues). Thanks a lot for considering my request-- it's quite important to the community using the EventScripts plugin, and will likely come in handy for mods down the road. Thanks again, -Mattie - Original Message - From: Alfred Reynolds [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, April 11, 2005 5:58 PM Subject: RE: [hlcoders] Interface method request: engine-ServerInsertCommand() Are you looking for IVEngineServer::ServerCommand() which will run a command on the server? - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattie Casper Sent: Sunday, April 10, 2005 7:59 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Interface method request: engine-ServerInsertCommand() This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Valve reps, Is there any way you can extend the IVEngineServer interface to provide ServerInsertCommand() (or some other relevant name)? It would work a lot like the old Quake engine's command buffer function (Cbuf_InsertText) that allows a console command to be inserted at the front of the buffer. I assume a similar function exists in the HL2 engine, because, as far as I know, exec would need something like that to work correctly. If you could expose this function, it would allow my server plugin to cleanly support in-line variable expansion for my concommands. Thanks so much for your help, -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 ___ 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] Examples of uses for IEngine-ServerInsertCommand()
As promised, this email contains examples of the sorts of things that plugin authors cannot manage in Source without some method to insert commands at the beginning of the server command queue. This ability is vital for any plugin wishing to create meta console commands. I.e. commands like alias, exec, incrementvar, etc. Variable expansion -- EventScripts makes extensive use of variable expansion for its console commands, and it's crippled without InsertCommand(). There's no way to arrange for expanded commands to execute right away before the rest of a config file. For example, let's say I added the following lines to a .cfg file (e.g. server.cfg): // server.cfg // let's say 'mypluginvar' is a variable exposed by my plugin mypluginvar ClanMatch expandvars echo *** mypluginvar equals %mypluginvar% echo *** The above line should say mypluginvar equals ClanMatch echo *** server.cfg is completely done. should see nothing else. // end server.cfg So, if my plugin's 'expandvars' command expanded variables in the string provided to it and then passed it back to the server, the only mechanism it can use is ServerCommand(). This will place it AFTER everything else in the queue. As such, the output would be: *** The above line should say mypluginvar equals ClanMatch *** server.cfg is completely done. should see nothing else. *** mypluginvar equals ClanMatch This is definitely not what someone writing a .cfg file would be expecting. They expect the commands to go in order of writing. EventScripts supports a great deal of variable expansion, but there's no support for intuitive ordering. This example is trivial compared to the complicated scripts people are creating. It really weakens the plugin when admins can't trust that your variables will be expanded properly in relation to other commands in the cfg file. - Conditional expressions -- - EventScripts supports conditional expressions. These are also hindered without InsertCommand(). The order of execution again gets all out of phase. For example, let's say I added the following lines to a .cfg file (e.g. server.cfg): // server.cfg // let's say my plugin exposes an exec_if command exec_if sv_gravity 800 then reset_grav.cfg echo *** sv_gravity was set back to 800 by increase_grav.cfg exec_if sv_gravity 800 then something_wrong.cfg // end of server.cfg In this case, the plugin command exec_if would test the condition sv_gravity 800 and then use, sadly, ServerCommand() to place exec reset_grav.cfg in the queue where it could reset the gravity back to 800. Unfortunately, this goes to the very end of the queue, so the rest of the server.cfg executes first. This means the second conditional will STILL see sv_gravity incorrectly because it goes through the server command queue like this: 1. exec_if 2. echo 3. exec_if 4. exec reset_grav.cfg 5. exec something_wrong.cfg #5 should never happen-- and #4 should happen before the 'echo' does. Yet we can't do this because InsertCommand() isn't yet available to plugin writers. - Loops -- -- EventScripts does not yet support loops, but these would also be possible if Valve provided a way to insert commands at the beginning of the queue. Without it, you cannot be certain that the loop lines will execute before the next line in a script. -- Enhanced versions of alias, exec, etc - EventScripts doesn't do this yet, but if I wanted to create an enhanced version of these Valve commands, the new commands will always be deficient without InsertCommand(). For example, if we wanted to write an optimized exec command that cached the .cfg file in memory on the first execution and then always ran it from memory whenever called (to avoid refetches from disk): // server.cfg memexec only_changes_on_reboot.cfg exec load_plugins.cfg // end of server.cfg In this case, simulating exec is impossible if I wish to maintain the order of a .cfg file. I.e., we can't cycle through the lines of the file and have them inserted at the beginning of the command queue like Valve does. This means that anytime we try to add the lines, they'll always fall *after* every other line in the .cfg file. Order is important at times for plugins and the like, and without that we just can't improve upon the console commands very well. - Anyway, I'm going to stop now because this is getting so long that I'm sure no one will read it. ;) Rest assured that all of these things and more would be possible if Valve enhanced the Source SDK to include a mechanism for adding commands to the beginning of the queue. Anyone curious about using EventScripts, you can find my forums here: http://www.sourcemod.net/forums/viewforum.php?f=20 Thanks for reading this far. Maybe it will give other coders some ideas, too, -Mattie
Re: [hlcoders] MenuSelect
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
[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
Re: [hlcoders] To Valve: Developer Forewarning
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, we're not asking for hostages. We're just humbly asking for, at a minimum, warnings. Ideally, we'd like discussion about the implications, but a warning is our minimum requirement. Please see the relevant section of my initial email, I quote here: Now, we certainly aren't asking you to indefinitely support every little feature we use, but we absolutely *must* have forewarning before things change in sensitive areas-- especially when things are deprecated. Keep in mind that we're all very grateful for the work you guys do on the SDK. It's been invaluable. It's just that in order for the community to remain healthy we're going to have to work together. Thanks for your time and assistance, -Mattie - Original Message - From: Alfred Reynolds [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, May 20, 2005 2:29 PM Subject: RE: [hlcoders] To Valve: Developer Forewarning That is part of the leaf code of the mod, not an exported API. Assuming that CS:S uses the same code that we ship in the SDK is wrong (because they won't match). Injecting network messages and assuming the same implementation in a binary you don't control is not going to work. We have provided a stable, consistent (across all mods) API for plugins to message users. We have already added new functionality to this interface at the request of plugin authors, a quick email discussion with us and I am sure we can find a middle ground. Also note that plugins already use the exported API for HL2MP (and other 3rd party mods I suspect). 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 Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Friday, May 20, 2005 11:19 AM To: hlcoders@list.valvesoftware.com Subject: 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
[hlcoders] Plugins loaded into the client?
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] As a plugin developer, I quite frequently test my server plugins on a local listen server while I'm developing. When I go to play games, though, I'm reminded that the plugin is still there when the plugin's concommands are still accessible. No big deal most the time, but some of the language in the recent Steam announcements about 'cheat detection' make me worry that plugin developers might get penalized for accidentally leaving a random serverplugin_empty DLL in their cstrike/addons folder (since these will load happily into the hl2.exe process). My question: will server plugins be exempt from the detection? If not, since the client is automatically loading the plugin into the process space, is it possible that developers could be penalized for accidentally loading their plugin? Just a random thought, thanks for any input you might have, -Mattie -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Interface method request: engine-ServerInsertCommand()
Thanks, Alfred, for responding. No-- I'm looking for something different. IVEngineServer::ServerCommand() places the command at the _end_ of of the command buffer. I need the same function that the 'exec' command would use to place a command at the _beginning_ of the command buffer. Without an InsertAtFront or something similar, in-line variable expansion is not possible (without lots of command ordering issues). Thanks a lot for considering my request-- it's quite important to the community using the EventScripts plugin, and will likely come in handy for mods down the road. Thanks again, -Mattie - Original Message - From: Alfred Reynolds [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, April 11, 2005 5:58 PM Subject: RE: [hlcoders] Interface method request: engine-ServerInsertCommand() Are you looking for IVEngineServer::ServerCommand() which will run a command on the server? - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattie Casper Sent: Sunday, April 10, 2005 7:59 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Interface method request: engine-ServerInsertCommand() This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Valve reps, Is there any way you can extend the IVEngineServer interface to provide ServerInsertCommand() (or some other relevant name)? It would work a lot like the old Quake engine's command buffer function (Cbuf_InsertText) that allows a console command to be inserted at the front of the buffer. I assume a similar function exists in the HL2 engine, because, as far as I know, exec would need something like that to work correctly. If you could expose this function, it would allow my server plugin to cleanly support in-line variable expansion for my concommands. Thanks so much for your help, -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
[hlcoders] Interface method request: engine-ServerInsertCommand()
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Valve reps, Is there any way you can extend the IVEngineServer interface to provide ServerInsertCommand() (or some other relevant name)? It would work a lot like the old Quake engine's command buffer function (Cbuf_InsertText) that allows a console command to be inserted at the front of the buffer. I assume a similar function exists in the HL2 engine, because, as far as I know, exec would need something like that to work correctly. If you could expose this function, it would allow my server plugin to cleanly support in-line variable expansion for my concommands. Thanks so much for your help, -Mattie -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] net_showevents, please mark it as a cheat
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I was just doing some research for EventScripts and stumbled upon the net_showevents client command. I'd like to request that this be made a 'cheat' command. This command will display game events as the client receives them. The problem is that this is too much information for players to have. For example, knowing the details of a bomb_planted or player_hurt event is probably a bit unfair. It's even handier information for a player when they've set developer 1 so that console messages are output to the top left of the screen. As a result, they get on-screen notification of what bombsite the bomb is planted at, and, even worse, the health of other players from player_hurt. Even knowing that someone was hurt by your 'shot-in-the-dark' hegrenade is probably too powerful (let alone knowing their life total afterwards). Anyway, just my $.02, -Mattie -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] net_showevents, please mark it as a cheat
You should be able to see it in the console and/or the top left (via developer 1) if you're on an active server. Just use net_showevents 1. -Mattie - Original Message - From: Daniel Jennings [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, April 02, 2005 3:25 PM Subject: Re: [hlcoders] net_showevents, please mark it as a cheat When I turned on net_showevents it didn't display anything in the console? - Original Message - From: Mattie Casper [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, April 02, 2005 11:00 AM Subject: [hlcoders] net_showevents, please mark it as a cheat This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I was just doing some research for EventScripts and stumbled upon the net_showevents client command. I'd like to request that this be made a 'cheat' command. This command will display game events as the client receives them. The problem is that this is too much information for players to have. For example, knowing the details of a bomb_planted or player_hurt event is probably a bit unfair. It's even handier information for a player when they've set developer 1 so that console messages are output to the top left of the screen. As a result, they get on-screen notification of what bombsite the bomb is planted at, and, even worse, the health of other players from player_hurt. Even knowing that someone was hurt by your 'shot-in-the-dark' hegrenade is probably too powerful (let alone knowing their life total afterwards). Anyway, just my $.02, -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
[hlcoders] CSS Linux dedicated servers lack setinfo console command
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hello, Any particular reason that Linux dedicated servers are missing the 'setinfo' command? Am I just overlooking it? Is there another alternative? (I notice the incrementvar and decrementvar commands exist, however.) If there is no way to create variables Linux similar to setinfo, can we get this remedied as soon as possible? Thanks, -Mattie -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash
Yep, though this is a little slow-going since it requires a player connection /
dedicated server to reproduce the issue.
I see two different problems since the latest Valve update. I can obtain crash
dumps if anyone is particularly keen on them. Yet, since the addon produces this
on any Windows dedicated server I tried, this should be unnecessary.
First was a crash and this is when srcds.exe was launched in GUI mode. It's a
read access violaton on 0x0040:
0040()
AdminServer.dll!025012d7()
kernel32.dll!7c81eb33()
AdminServer.dll!024db411()
vstdlib.dll!00877101()
AdminServer.dll!025012c6()
AdminServer.dll!024cc89d()
dedicated.dll!10004bd6()
dedicated.dll!10018903()
dedicated.dll!10018957()
For a Windows console dedicated server, the crash appears to have morphed into
an infinite loop that eats all the server CPU cycles-- not sure if the latest
Valve update causes that or if trying to get a debugger involved has changed the
nature of the problem slightly.
-Mattie
- Original Message -
From: Daniel Jennings [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Saturday, March 26, 2005 9:24 PM
Subject: Re: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash
Have you run it through a debugger to check the stack when it crashes?
- Original Message -
From: Adam amckern Mckern [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Saturday, March 26, 2005 5:13 PM
Subject: Re: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash
are your runing the lattest build of ded server, and
have you thought of adding a break point?
--- Mattie Casper [EMAIL PROTECTED] wrote:
Events are caused within events all the time---
people use events to do all
sorts of things: kick players, make people swap
teams, teamkill punishment, etc.
Even if server event reentrance is a problem, we
need some Valve documentation
saying this is forbidden or dangerous.
To clarify three points:
1. I'm not interested in specifically kicking a
player. I'm interested in doing
X during an event where X is anything the
administrator wants. So if he wants to
kick a player that's his thing. I, personally, am
not trying to kick anyone
during an event. I'm letting people run semi-special
config files during an
event.
2. The crash doesn't just happen when plugin code
specifically kicks someone. It
can happen when a player is kicked via some
administrative plugin, by the
console, etc. It just needs to happen at the around
the time an event calls
ServerExecute.
3. The example below is the smallest example I made
to reproduce the problem.
I'm no newbie to coding-- I've considered all sorts
of workarounds. Like
scheduling things independently via GameFrame,
avoiding the ServerExecute, etc.
Unfortunately, these alternatives are
substandard/messy and, really, I just need
someone at Valve to say this is a bug, we'll fix
it or ServerExecute during
an event is unsupported because of X and we'll
document it as such going
forward. If I've missed existing documentation to
this effect, I'm hoping
someone on the list can point me to it. (Educated
guesses stated as if they were
fact won't help me, though.)
Thanks,
-Mattie
cheeseh wrote:
-
I am guessing that when you kick a player another
event is triggered
that tells that the player was kicked/left the
server. You cannot have
two events fire inside each other, I am taking this
from the old net
message code that was from HL1, you could not have
two messages start
before they end.
Instead of kicking the player there, try raising a
flag (try storing a
global boolean variable and the player id) and check
it on startframe
(or GameFrame () as it is now in HL2 I think) when
the flag is true,
kick the stored player id, then set the flag to
false. In the event code
replace it with setting the boolean to true and
setting the playerid to
the userid.- Original Message -
From: Mattie Casper [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Saturday, March 26, 2005 9:25 AM
Subject: FireGameEvent, kickid, ServerExecute, crash
Hello,
I've found what seems, for me, to be a really
annoying bug in CSS (and
probably mods). The following problem happens
regardless of whether you use
IGameEventListener or IGameEventListener2.
My Windows server crashes 98% of the time with the
following code in a
listener/plugin:
void CEmptyServerPlugin::FireGameEvent( IGameEvent
* event )
{
const char * name = event-GetName();
if (FStrEq(name, player_changename))
{
if(tester_cvar.GetInt()==1)
{
Msg(Kicking ya.\n);
int userid = event-GetInt(userid);
char szMessage[1024];
sprintf(szMessage, kickid %d Go
away.\n, userid);
engine-ServerCommand(szMessage);
if (tester2_cvar.GetInt()==1
Re: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash
Alfred-- I have stepped through my code, but I haven't stepped through this particular callstack as I don't have any symbols for this. This is a Server Plugin for CSS. The code I provide below is very simple and it'd be easy for most anyone to reproduce. I can provide an entire sample project if someone is interested, but I'd be surprised if that was necessary. I actually do need to perform ServerExecute. Here's why: 1. The EventScripts plugin will execute an administrator's config file upon a particular event. (E.g. exec player_say.cfg, round_start.cfg, etc) 2. I provide some console commands that support expanding variables if those console commands are run within an event. These are event-specific variables (like what's provided in the IGameEvent, like userid, etc). 3. If those console commands aren't executed right away, the event information will be lost (or, potentially, leaked since I don't know when I need to stop expanding variables if I exit the event). For example, an administrator might provide a player_changename.cfg that performs something like this: es kickid event_var(userid). The 'es' console command will expand all strings that begin with event_var to be the value passed in with the IGameEvent. So this might expand to an immediate kickid 3 console command. (In this particular example, the server will crash much like the plugin sample I listed below.) I can't read these IGameEvent values if the event has already passed (without lots of pain and potential to break backwards compatibility for my users). Why is it inappropriate to call ServerExecute? It's used in other places within the SDK, particularly when loading config files (which is exactly what I'm doing). I'd really like to know why the call below crashes the server. Is there any additional information I can provide to help get the answer to this question? Thanks for any insight you can provide, and let me know if you have any difficulties reproducing the problem. -Mattie FYI-- Anyone interested in the minutae of EventScripts, which is growing in interest in the community: http://www.sourcemod.net/forums/viewtopic.php?t=908 - Original Message - From: Alfred Reynolds [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, March 27, 2005 4:49 PM Subject: RE: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash Oh, and don't run ServerExecute(), you don't need to do that (it shouldn't crash anything, but it isn't appropriate for you to call that). - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alfred Reynolds Sent: Sunday, March 27, 2005 1:23 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash Looks like a null pointer is trying to be de-referenced. Have you stepped the code and verified that this is not the problem? - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattie Casper Sent: Sunday, March 27, 2005 10:20 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash Yep, though this is a little slow-going since it requires a player connection / dedicated server to reproduce the issue. I see two different problems since the latest Valve update. I can obtain crash dumps if anyone is particularly keen on them. Yet, since the addon produces this on any Windows dedicated server I tried, this should be unnecessary. First was a crash and this is when srcds.exe was launched in GUI mode. It's a read access violaton on 0x0040: 0040() AdminServer.dll!025012d7() kernel32.dll!7c81eb33() AdminServer.dll!024db411() vstdlib.dll!00877101() AdminServer.dll!025012c6() AdminServer.dll!024cc89d() dedicated.dll!10004bd6() dedicated.dll!10018903() dedicated.dll!10018957() For a Windows console dedicated server, the crash appears to have morphed into an infinite loop that eats all the server CPU cycles-- not sure if the latest Valve update causes that or if trying to get a debugger involved has changed the nature of the problem slightly. -Mattie - Original Message - From: Daniel Jennings [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, March 26, 2005 9:24 PM Subject: Re: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash Have you run it through a debugger to check the stack when it crashes? - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, March 26, 2005 5:13 PM Subject: Re: [hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash are your runing the lattest build of ded server, and have you thought of adding a break point? --- Mattie Casper [EMAIL PROTECTED] wrote: Events are caused within events all the time--- people use events to do all sorts of things: kick players, make people swap teams, teamkill punishment, etc. Even if server event reentrance is a problem, we need some Valve
[hlcoders] FireGameEvent, kickid, ServerExecute, crash
Hello,
I've found what seems, for me, to be a really annoying bug in CSS (and probably
mods). The following problem happens regardless of whether you use
IGameEventListener or IGameEventListener2.
My Windows server crashes 98% of the time with the following code in a
listener/plugin:
void CEmptyServerPlugin::FireGameEvent( IGameEvent * event )
{
const char * name = event-GetName();
if (FStrEq(name, player_changename))
{
if(tester_cvar.GetInt()==1)
{
Msg(Kicking ya.\n);
int userid = event-GetInt(userid);
char szMessage[1024];
sprintf(szMessage, kickid %d Go away.\n, userid);
engine-ServerCommand(szMessage);
if (tester2_cvar.GetInt()==1)
{
// Crashes the server
engine-ServerExecute();
}
}
}
}
Basically, this silly code causes a player to get kicked immediately when he
tries to change his name. He certainly does get kicked, but the server crashes
immediately after.
This is just the sample reproduction code, but the problem shows itself at a
much deeper point in my EventScripts plugin when users are kicked in the middle
of an event. It can happen at times regardless of whether the event handler is
doing the kicking (i.e. another plugin or user could be kicking the player while
my event handlers are firing). I believe it is a timing or threading issue
because if I place a Windows Sleep(100) after the above ServerExecute call, the
crash usually doesn't happen.
Avoiding ServerExecute() is not really an option for me because I truly need the
command (not necessarily kick) executed immediately (typically an exec of a cfg
file). Regardless, the documentation places no caveats on when ServerExecute()
can be called, so I haven't been afraid to do so when needed.
Anyone have any recommendations or thoughts here?
Thanks for your help,
-Mattie
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: FireGameEvent, kickid, ServerExecute, crash
Events are caused within events all the time--- people use events to do all
sorts of things: kick players, make people swap teams, teamkill punishment, etc.
Even if server event reentrance is a problem, we need some Valve documentation
saying this is forbidden or dangerous.
To clarify three points:
1. I'm not interested in specifically kicking a player. I'm interested in doing
X during an event where X is anything the administrator wants. So if he wants to
kick a player that's his thing. I, personally, am not trying to kick anyone
during an event. I'm letting people run semi-special config files during an
event.
2. The crash doesn't just happen when plugin code specifically kicks someone. It
can happen when a player is kicked via some administrative plugin, by the
console, etc. It just needs to happen at the around the time an event calls
ServerExecute.
3. The example below is the smallest example I made to reproduce the problem.
I'm no newbie to coding-- I've considered all sorts of workarounds. Like
scheduling things independently via GameFrame, avoiding the ServerExecute, etc.
Unfortunately, these alternatives are substandard/messy and, really, I just need
someone at Valve to say this is a bug, we'll fix it or ServerExecute during
an event is unsupported because of X and we'll document it as such going
forward. If I've missed existing documentation to this effect, I'm hoping
someone on the list can point me to it. (Educated guesses stated as if they were
fact won't help me, though.)
Thanks,
-Mattie
cheeseh wrote:
-
I am guessing that when you kick a player another event is triggered
that tells that the player was kicked/left the server. You cannot have
two events fire inside each other, I am taking this from the old net
message code that was from HL1, you could not have two messages start
before they end.
Instead of kicking the player there, try raising a flag (try storing a
global boolean variable and the player id) and check it on startframe
(or GameFrame () as it is now in HL2 I think) when the flag is true,
kick the stored player id, then set the flag to false. In the event code
replace it with setting the boolean to true and setting the playerid to
the userid.- Original Message -
From: Mattie Casper [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Saturday, March 26, 2005 9:25 AM
Subject: FireGameEvent, kickid, ServerExecute, crash
Hello,
I've found what seems, for me, to be a really annoying bug in CSS (and
probably mods). The following problem happens regardless of whether you use
IGameEventListener or IGameEventListener2.
My Windows server crashes 98% of the time with the following code in a
listener/plugin:
void CEmptyServerPlugin::FireGameEvent( IGameEvent * event )
{
const char * name = event-GetName();
if (FStrEq(name, player_changename))
{
if(tester_cvar.GetInt()==1)
{
Msg(Kicking ya.\n);
int userid = event-GetInt(userid);
char szMessage[1024];
sprintf(szMessage, kickid %d Go away.\n, userid);
engine-ServerCommand(szMessage);
if (tester2_cvar.GetInt()==1)
{
// Crashes the server
engine-ServerExecute();
}
}
}
}
Basically, this silly code causes a player to get kicked immediately when he
tries to change his name. He certainly does get kicked, but the server crashes
immediately after.
This is just the sample reproduction code, but the problem shows itself at a
much deeper point in my EventScripts plugin when users are kicked in the
middle of an event. It can happen at times regardless of whether the event
handler is doing the kicking (i.e. another plugin or user could be kicking the
player while my event handlers are firing). I believe it is a timing or
threading issue because if I place a Windows Sleep(100) after the above
ServerExecute call, the crash usually doesn't happen.
Avoiding ServerExecute() is not really an option for me because I truly need
the command (not necessarily kick) executed immediately (typically an exec of
a cfg file). Regardless, the documentation places no caveats on when
ServerExecute() can be called, so I haven't been afraid to do so when needed.
Anyone have any recommendations or thoughts here?
Thanks for your help,
-Mattie
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
