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):
>
> // 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
>
>
> _______________________________________________
> 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
