On the subject of this I can sometimes find myself siding with Valve. There are so many plugins for HL2 mods, without this interface, that have been all but ruined. Referred to as RPG mods they infect slowly all the servers of a mod changing everything the developers spent time to balance and giving players unbalanced weaponry and stats. But the players who get these things must grind the server and then they can kill new people with ease. A lot of new people especially if Casual game will not know what a RPG plugin is and will probably blame the bad gameplay on the MOD itself. RPG Plugins are IMO a mod's worst nightmare.
For Valve Official games this is fine because there are so many servers, but for mods a single RPG mod can single handedly ruin a MOD. For example zombie master has pretty much only RPG mod servers, etc. Chris -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LDuke Sent: Saturday, March 01, 2008 12:39 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 ] 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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
