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 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):
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:
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 InsertCom
Re: [hlcoders] Examples of uses for IEngine->ServerInsertCommand()
I could be wrong, but even if ServerInsertCommand() puts the script
command at the front of the queue as opposed to the back, that still
wouldn't be executed until the current script is finished. Sounds like
really what you need is ServerCommandNow() that executes it right now,
so that when the next line of the current script runs, it can be sure
that the results of the script it just invoked is already done. Sounds
like even with ServerInsertCommand() it is gonna be a pain to get the
ordering right.
On 6/10/05, Mattie Casper <[EMAIL PROTECTED]> wrote:
> 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:
> 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,
RE: [hlcoders] Interface method request: engine->ServerInsertCommand()
This is still on my TODO list, so many things to write so little time ;-) - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattie Casper Sent: Thursday, June 09, 2005 5:42 PM To: hlcoders@list.valvesoftware.com Subject: 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: > 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: > > 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 > > > > > > > > > > > > > > > ___ >
