RE: [hlcoders] Examples of uses for IEngine->ServerInsertCommand()
> 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). One solution to your problem that doesn't require an API change is instructing users to write a one-line config file that simply calls your plugin-enabled parser to run on another file. E.g. have the entire contents of autoexec.cfg be "eventscripts_exec autoexec_script.cfg\n". Once you have that arrangement, there aren't any commands that you need to preempt from the top level scripts--load and manipulate the entire autoexec_script.cfg file in memory to perform whatever transforms you need, then feed the entire transformed file to the server in a block. Delayed insertion removes the need for preemptive insertion, and as far as your end users know or care, they're still using Valve's config system. Placement of the entire config into a one-off file isn't seamless, but it's not hard for users to understand and it doesn't require much extra work or drive space. If HL2 calls two script files, say autoexec.cfg and server.cfg, at nearly the same time and they both contain a single call into a one-off, the execution order will appear to be the same to end users even if the second exec comes before or in the middle of the interpreted commands from the first file, since the effect of calling the second file would place its commands after the complete set of commands from the intial file (assuming the whole file interpret-and-stuff mechanism described above and synchronous server command execution). You really don't need out-of-order placement for variable substitution or subscript execution using this scheme--you could even support calls into other files and process them entirely in place before you begin inserting the top level file. You might want to have preemptive insertion for live evaluation of loop conditions, but that problem can also be solved through delayed insertion - keep all commands after the evaluation statement in memory until you get back your result. Simple loop counters can be unrolled in place instantly, and I'm not sure how much complexity a configuration script really needs. My 2 cents, Karl > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED] On Behalf Of Jeremy Swigart > Sent: Friday, June 10, 2005 6:20 AM > To: hlcoders@list.valvesoftware.com > Subject: 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 > (especiall
Re: [hlcoders] Player info being sent
Thanks for that Mike. On a similar note, are network arrays treated as a single or is each element considered seperate to the engine when it handles network updates? -Thanks ___ 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()
This is also something I've considered-- I was just discussing this in my forum. Obviously writing my own 'exec' (and a lot of surrounding overhead) is a way I can achieve what I want without Valve providing the appropriate mechanism. It's not terrible to force all users to use a different .cfg file system, but it's certainly not the idea behind EventScripts, or really what other plugin authors might need. Other plugin authors trying to write commands that order properly won't find very good ROI on rewriting an exec (they just have to live with it). EventScripts itself is supposed to just extend the console with a bunch of new commands -- we'd all prefer if it didn't require admins to change how they're doing things today if they want them to work. Even if they did so (as you say, I suspect a lot of users could live with it), all it takes is for them to forget and add lines to the traditional .cfg files (which a lot of rental sites provide web access to, edit-wise) and things get out of order again. Also keep in mind that people also use aliases to stack commands in groups into the command buffer. I don't have a lot of recourse in those situations other than providing my own 'alias' handler in the script preprocessor and disallowing use of the conventional one if the user wishes things to order properly. Anyway, it's certainly doable if my user base is comfortable with changing their current paradigm and I reinvent the wheel a few times, but that's definitely quite far out of line with what EventScripts was supposed to be. I.e. I just want to add powerful console commands that should work fine in any server.cfg, autoexec.cfg. I know I have to move 'out of that realm' if Valve's not able to provide the InsertCommand() API, but that won't solve the problem for any plugin but my own (unless they also re-invent the wheel to solve this). All in all, I have options, and I appreciate the suggestions (keep 'em coming, by all means!), but mostly my available options involve circumventing Valve and creating my own independent engine. I'd, of course, much rather work with them and interoperate. And to do so, I need this one easy and accessible command and it will open a world of possibility for console commands. On the platforms where EventScripts works best, already administrators are able to recreate a huge number of plugins simply using .cfg files and some popular admin plugins. See this thread for examples: http://www.sourcemod.net/forums/viewtopic.php?t=898 Thanks again for your suggestions, -Mattie - Original Message - From: "Karl "XP-Cagey" Patrick" <[EMAIL PROTECTED]> To: Sent: Saturday, June 11, 2005 8:58 AM Subject: RE: [hlcoders] Examples of uses for IEngine->ServerInsertCommand() 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). One solution to your problem that doesn't require an API change is instructing users to write a one-line config file that simply calls your plugin-enabled parser to run on another file. E.g. have the entire contents of autoexec.cfg be "eventscripts_exec autoexec_script.cfg\n". Once you have that arrangement, there aren't any commands that you need to preempt from the top level scripts--load and manipulate the entire autoexec_script.cfg file in memory to perform whatever transforms you need, then feed the entire transformed file to the server in a block. Delayed insertion removes the need for preemptive insertion, and as far as your end users know or care, they're still using Valve's config system. Placement of the entire config into a one-off file isn't seamless, but it's not hard for users to understand and it doesn't require much extra work or drive space. If HL2 calls two script files, say autoexec.cfg and server.cfg, at nearly the same time and they both contain a single call into a one-off, the execution order will appear to be the same to end users even if the second exec comes before or in the middle of the interpreted commands from the first file, since the effect of calling the second file would place its commands after the complete set of commands from the intial file (assuming the whole file interpret-and-stuff mechanism described above and synchronous server command execution). You really don't need out-of-order placement for variable substitution or subscript execution using this scheme--you could even support calls into other files and process them entirely in place before you begin inserting the top level file. You might want to have preemptive insertion for live evaluation of loop conditions, but that problem can also be solved through delayed insertion - keep all commands after the evaluation statement in memory until you get back your result. Simple loop counters can be unrolled in place
Re: [hlcoders] Examples of uses for IEngine->ServerInsertCommand()
I'm pretty sure the command queue works the same as most of these games since
Quake. All 'exec' does is place all of the lines into the command queue in the
proper order. Then the command handler will take each command independently off
of the queue. At that point, they're not a 'block' or anything, they're just
individual commands that happen to be placed in the queue in a sequence. When
any individual command is processed, it can still insert commands at the front
of the queue and have it execute before the (former) next command is scheduled
to do so. This is almost certainly why an 'exec' or 'alias' within a cfg file
happens before continuing with other lines in the .cfg file-- they pretty much
always insert their looked-up lines into the front of the queue (these built-in
commands are basically a limited form of 'variable expansion' already). In order
to create other commands that can behave the same way, we need something like
ServerInsertCommand() rather than one that adds to the end of the queue.
So in short, I'm 95% certain that this command is exactly what the community
would need for this purpose.
-Mattie
- Original Message -
From: "Jeremy Swigart" <[EMAIL PROTECTED]>
To:
Sent: Friday, June 10, 2005 9:20 AM
Subject: 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
[hlcoders] Steam and OGL Fog
Hey, Was just wondering when or if the problem with Steam and OGL Fog, where additive textures are screwed up will be fixed. Thanks. -DarkNight- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Steam and OGL Fog
the fog uses an adtive base (at least in the code your own for hl1) so it wont be any time soon for that one, in regards to hl2, lets ask the experts... --- Aaron Zinghini <[EMAIL PROTECTED]> wrote: > Hey, > > Was just wondering when or if the problem with Steam > and OGL Fog, where > additive textures are screwed up will be fixed. > > Thanks. > > > -DarkNight- > > > > ___ > To unsubscribe, edit your list preferences, or view > the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > http://ammahls.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Steam and OGL Fog
Why is it that in WON HL this was never a problem? There was something in Steam that stuffed it up. -DarkNight- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Steam and OGL Fog
I took some screen shots for a mod i droped after Digital Extreams came after me, in won that has aditive entitys, and they seemed to stand out - is this waht you mean ( http://mods.moddb.com/gallery/image/9432/ ) Adam --- Aaron Zinghini <[EMAIL PROTECTED]> wrote: > Why is it that in WON HL this was never a problem? > There was something in > Steam that stuffed it up. > > > > -DarkNight- > > > > ___ > To unsubscribe, edit your list preferences, or view > the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > http://ammahls.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
