--
[ Picked text/plain from multipart/alternative ]
I think you just append ",mytag" to the sv_tags convar string.
And I second the "Thank you" to Valve from Mattie. And a HUGE "thank you"
if that interface is in the CSS orangebox update.
On Sat, Mar 1, 2008 at 6:04 AM, Saul Rennison <[EMAIL PROTECTED]>
wrote:
> Yeah you just made no sense.
>
> " imagine they added the functions like CreateEntityByName etc. again
> because they thought of themegatag serverbrowser function etc."
>
> Uhm... yes? What is the interface for the server tags anyway?
>
> On 1 Mar 2008, at 12:44, Tobias Kammersgaard wrote:
>
> > --
> > [ Picked text/plain from multipart/alternative ]
> > I imagine they added the functions like CreateEntityByName etc. again
> > because they thought of themegatag serverbrowser function etc.
> >
> > Also, if this doesn't make any sense its because I've had a few
> > beers ;-)
> > (DRUNK ON THE INTERWEBLOLOLOL)
> >
> > Oh Lord.
> >
> > /ScarT
> >
> >
> > On 01/03/2008, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
> >>
> >> --
> >> [ Picked text/plain from multipart/alternative ]
> >> They're not trying to 'thwart' them.
> >> You have to realize it's a matter of priority.
> >>
> >> You typically don't get support for anything that the game is going
> >> to
> >> have
> >> in situations like this. Look at any other game; unless it's
> >> something
> >> that
> >> benefits the host game, or is designed for the host game, you don't
> >> specifically have it.
> >>
> >> The problem is simply, there isn't anyone dedicated to doing
> >> "extra" stuff
> >> like that.Ie: the biggest complaint; lack of a real multiplayer
> >> vehicle.
> >> Well, the hardcore facts are, until valve decides: "Okay, our next
> >> game is
> >> going to be multiplayer vehicular combat" the likeliness of actually
> >> seeing
> >> them sit down and dedicate time AND money to writing a multiplayer
> >> vehicle,
> >> which they aren't going to use is rather slim.
> >>
> >> Does that make sense to you? Think about it this way; it's the same
> >> as
> >> with
> >> a mod.
> >> Are you going to sit there and implement a bunch of features that
> >> you're
> >> not
> >> going to use, just for the sake of "okay, well we aren't using y
> >> feature,
> >> but lets just make people happy and spend x hours on y feature just
> >> so
> >> they
> >> don't bitch, even if it's never going to be used in our mod."
> >>
> >> It's common sense.
> >> -Tony
> >>
> >>
> >> On Fri, Feb 29, 2008 at 6:50 PM, Spencer 'voogru' MacDonald <
> >> [EMAIL PROTECTED]> wrote:
> >>
> >>> I hate to rain on your bash valve parade...
> >>>
> >>> But this is in the Orange Box SDK:
> >>>
> >>>
> >>>
> >>
> //--------------------------------------------------------------------------
> >>> ---
> >>> // Purpose: Interface from engine to tools for manipulating entities
> >>>
> >>>
> >>
> //--------------------------------------------------------------------------
> >>> ---
> >>> class IServerTools : public IBaseInterface
> >>> {
> >>> public:
> >>> virtual IServerEntity *GetIServerEntity( IClientEntity
> >>> *pClientEntity ) = 0;
> >>> virtual bool SnapPlayerToPosition( const Vector &org, const
> >> QAngle
> >>> &ang, IClientEntity *pClientPlayer = NULL ) = 0;
> >>> virtual bool GetPlayerPosition( Vector &org, QAngle &ang,
> >>> IClientEntity *pClientPlayer = NULL ) = 0;
> >>> virtual bool SetPlayerFOV( int fov, IClientEntity
> >>> *pClientPlayer
> >> =
> >>> NULL ) = 0;
> >>> virtual int GetPlayerFOV( IClientEntity *pClientPlayer =
> >>> NULL ) =
> >>> 0;
> >>> virtual bool IsInNoClipMode( IClientEntity *pClientPlayer =
> >>> NULL
> >> )
> >>> =
> >>> 0;
> >>>
> >>> // entity searching
> >>> virtual void *FirstEntity( void ) = 0;
> >>> virtual void *NextEntity( void *pEntity ) = 0;
> >>> virtual void *FindEntityByHammerID( int iHammerID ) = 0;
> >>>
> >>> // entity query
> >>> virtual bool GetKeyValue( void *pEntity, const char *szField,
> >> char
> >>> *szValue, int iMaxLen ) = 0;
> >>> virtual bool SetKeyValue( void *pEntity, const char *szField,
> >> const
> >>> char *szValue ) = 0;
> >>> virtual bool SetKeyValue( void *pEntity, const char *szField,
> >> float
> >>> flValue ) = 0;
> >>> virtual bool SetKeyValue( void *pEntity, const char *szField,
> >> const
> >>> Vector &vecValue ) = 0;
> >>>
> >>> // entity spawning
> >>> virtual void *CreateEntityByName( const char *szClassName )
> >>> = 0;
> >>> virtual void DispatchSpawn( void *pEntity ) = 0;
> >>>
> >>> // This reloads a portion or all of a particle definition
> >>> file.
> >>> // It's up to the server to decide if it cares about this file
> >>> // Use a UtlBuffer to crack the data
> >>> virtual void ReloadParticleDefintions( const char *pFileName,
> >> const
> >>> void *pBufData, int nLen ) = 0;
> >>>
> >>> virtual void AddOriginToPVS( const Vector &org ) = 0;
> >>> };
> >>>
> >>> #define VSERVERTOOLS_INTERFACE_VERSION "VSERVERTOOLS001"
> >>>
> >>> Oh, I wonder what this could be...
> >>>
> >>> virtual void *CreateEntityByName( const char *szClassName ) = 0;
> >>>
> >>> Oh and...
> >>>
> >>> virtual void *FirstEntity( void ) = 0;
> >>> virtual void *NextEntity( void *pEntity ) = 0;
> >>>
> >>> Oh baby! We're getting raunchy now!
> >>>
> >>> Perhaps when CSS gets upgraded to the Orangebox engine this will
> >>> be made
> >>> available. It works in TF2 at least.
> >>>
> >>> Regardless of what valve does to try and limit plug-ins, programmers
> >> will
> >>> find ways around it.
> >>>
> >>> I think valve should welcome plug-ins, not try and thwart them. Not
> >>> everybody wants to make a full blown mod, the original plug-in SDK
> >>> was a
> >>> sad
> >>> joke. With regards to the HudMsg in CSS, I fully agree.
> >>>
> >>> One of what I believed to be AdminMOD's trademark (the pretty center
> >>> says),
> >>> removed from the new game purposely... by the creator of AdminMOD!
> >>>
> >>> But, center says work in TF2... but perhaps I should not speak so
> >>> loudly
> >>> cause valve might hear it, though with the new additions in the
> >> Orangebox
> >>> engine, I think valve is improving. Let's hope it continues.
> >>>
> >>> Bash valve all you want (I do it too!), but they are leaps and
> >>> bounds
> >>> ahead
> >>> of other companies when it comes to customization.
> >>>
> >>> I'll give them credit where it's due.
> >>>
> >>> - voogru.
> >>>
> >>> -----Original Message-----
> >>> From: [EMAIL PROTECTED]
> >>> [mailto:[EMAIL PROTECTED] On Behalf Of LDuke
> >>> Sent: Friday, February 29, 2008 4:50 PM
> >>> To: hlcoders@list.valvesoftware.com
> >>> Subject: Re: [hlcoders] Requesting (again): ent_fire and ent_name
> >>> APIs
> >> for
> >>> Server Plugins?
> >>>
> >>> --
> >>> [ Picked text/plain from multipart/alternative ]
> >>> My point was that that is going to be the only way. Not only has
> >>> Valve
> >>> made
> >>> it clear that mod-specific API items won't be provided, they've
> >>> removed
> >> as
> >>> much as possible the functionality of plugins.
> >>>
> >>> As an example, remember the SpawnEntityByName function (from June
> >>> 2005)?
> >>> That function has long been removed from the codebase. - Alfred
> >>> Spawning entities into a map from a plugin is not supported. -
> >>> Alfred
> >>> We are more concerned with giving people consistent gameplay
> >>> rather than
> >>> any specific cheat problem. You would be amazed at the number of
> >>> people
> >>> that get confused (i.e email us complaining) when joining a HL1
> >>> based
> >>> server with some of the noisier mods (I am looking at the warcraft3
> >>> superhero mod here...). - Alfred
> >>>
> >>> Or another example, the HudMsg that allows you to print text
> >>> anywhere on
> >>> the
> >>> screen? The font definition was intentionally removed from
> >>> ClientSchemes.res to prevent plugins from using HudMsg.
> >>>
> >>> I'm 95% certain they won't add that. Properly done, signature scans
> >> don't
> >>> break that often. I haven't had to find a new signature for CSS
> >>> in a
> >> long
> >>> time. Usually when one of mine is invalid it's because I've
> >>> missed a
> >> wild
> >>> card flag.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Feb 29, 2008 at 1:12 PM, Saul Rennison <
> [EMAIL PROTECTED]
> >>> >
> >>> wrote:
> >>>
> >>>> The problem is, LDuke, Mattie doesn't want to add hacks and
> >>>> signature
> >>>> scans to EventScripts (or whatever he wants it for), as it can
> >>>> break
> >>>> pretty easily with an update or maybe throughout mods. Especially
> >>>> ones
> >>>> that change the core.
> >>>>
> >>>> LDuke wrote:
> >>>>> --
> >>>>> [ Picked text/plain from multipart/alternative ]
> >>>>> That's what I've done...sig scan for the event queue and some of
> >>>>> the
> >>>>> overloads of AddEvent. With CreateNamedEntity, KeyValues, and
> >>> AddEvent,
> >>>> you
> >>>>> can do some cool stuff. For example, I have a trip mine setup
> >>>>> that
> >>>> works
> >>>>> completely based on those three things without need for the plugin
> >> to
> >>>>> monitor players and see which player's tripmine killed which
> >>>>> player.
> >>>>>
> >>>>> It would be nice to have access to those things via plugins
> >>>>> without
> >>>> hacking,
> >>>>> but so far we haven't seen much in the way of access to mod-
> >>>>> specific
> >>>>> functions.
> >>>>>
> >>>>>
> >>>>
> >>> --
> >>>
> >>> _______________________________________________
> >>> 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
> >>>
> >>>
> >>
> >>
> >> --
> >> -omega
> >> --
> >>
> >> _______________________________________________
> >> 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
