RE: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
Christopher Harris wrote: 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. I think Valve would make a lot of people happy by having a pure setting on the server (like Quake) so that people can filter out servers that are running any kind of plugin at all. No plugin(s) == Pure, for those that want just that. For others that want plugins, they could just uncheck that in the server browser and take their chances with what they connect to. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
--
[ Picked text/plain from multipart/alternative ]
Now that's just a gross exaggeration. I've played ZM from time to time and
most of the popular servers are pure.
On Mon, Mar 3, 2008 at 4:11 PM, Christopher Harris [EMAIL PROTECTED]
wrote:
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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
!), 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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
, 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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
-- [ 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. On Thu, Feb 28, 2008 at 10:47 PM, Tony Paloma [EMAIL PROTECTED] wrote: I agree that Valve does need to offer more interfaces to plugins for things like this. Doing anything with entities is incredibly limited given the provided resources. However, I think each one of these things is a simple vfunc call away to the desired result. ent_fire and ent_name can be accomplished using the AcceptInput virtual function, and give can be done with GiveNamedItem. There is no hooking or sig scanning required unless you meant to do something more advanced like get at the event queue or something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattieC Sent: Thursday, February 28, 2008 9:33 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins? -- [ Picked text/plain from multipart/alternative ] Can you consider adding ent_fire and ent_name API equivalents for Source server plugins? (Ideally these interact via index/pointer rather than name, but if we can name entities by index that would be the same thing, really.) Getting access to the entity event/message queue without hacks/tricks would open many stable doors and I've voiced this opinion in the past. This is one of the biggest deficiencies of the server-side plugin SDK. Ideally, the give API (or any name-based entity creation method) would also be included, but there may be more mod-specific issues for you there, perhaps. Currently without hacks/hooks it's very difficult to emulate this. Is there any reason entity inputs/messaging weren't exposed via interfaces that server plugins can access? If the above is not possible, what kind of things could the Source engine offer for better entity manipulation? Thanks very, very much in advance--- -Mattie http://www.eventscripts.com -- ___ 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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
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. On Thu, Feb 28, 2008 at 10:47 PM, Tony Paloma [EMAIL PROTECTED] wrote: I agree that Valve does need to offer more interfaces to plugins for things like this. Doing anything with entities is incredibly limited given the provided resources. However, I think each one of these things is a simple vfunc call away to the desired result. ent_fire and ent_name can be accomplished using the AcceptInput virtual function, and give can be done with GiveNamedItem. There is no hooking or sig scanning required unless you meant to do something more advanced like get at the event queue or something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattieC Sent: Thursday, February 28, 2008 9:33 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins? -- [ Picked text/plain from multipart/alternative ] Can you consider adding ent_fire and ent_name API equivalents for Source server plugins? (Ideally these interact via index/pointer rather than name, but if we can name entities by index that would be the same thing, really.) Getting access to the entity event/message queue without hacks/tricks would open many stable doors and I've voiced this opinion in the past. This is one of the biggest deficiencies of the server-side plugin SDK. Ideally, the give API (or any name-based entity creation method) would also be included, but there may be more mod-specific issues for you there, perhaps. Currently without hacks/hooks it's very difficult to emulate this. Is there any reason entity inputs/messaging weren't exposed via interfaces that server plugins can access? If the above is not possible, what kind of things could the Source engine offer for better entity manipulation? Thanks very, very much in advance--- -Mattie http://www.eventscripts.com -- ___ 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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
I would like to second this. I have tried creating plugins, and getting stopped at the Sigscanning methods/vtable (And not understanding it which doesnt help), i have given up on making server plugins. A nice exposed API for the entity list / entity functions, etc, would be great (Server side only so you dont expose crap for hackers :P) Saul Rennison 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. On Thu, Feb 28, 2008 at 10:47 PM, Tony Paloma [EMAIL PROTECTED] wrote: I agree that Valve does need to offer more interfaces to plugins for things like this. Doing anything with entities is incredibly limited given the provided resources. However, I think each one of these things is a simple vfunc call away to the desired result. ent_fire and ent_name can be accomplished using the AcceptInput virtual function, and give can be done with GiveNamedItem. There is no hooking or sig scanning required unless you meant to do something more advanced like get at the event queue or something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattieC Sent: Thursday, February 28, 2008 9:33 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins? -- [ Picked text/plain from multipart/alternative ] Can you consider adding ent_fire and ent_name API equivalents for Source server plugins? (Ideally these interact via index/pointer rather than name, but if we can name entities by index that would be the same thing, really.) Getting access to the entity event/message queue without hacks/tricks would open many stable doors and I've voiced this opinion in the past. This is one of the biggest deficiencies of the server-side plugin SDK. Ideally, the give API (or any name-based entity creation method) would also be included, but there may be more mod-specific issues for you there, perhaps. Currently without hacks/hooks it's very difficult to emulate this. Is there any reason entity inputs/messaging weren't exposed via interfaces that server plugins can access? If the above is not possible, what kind of things could the Source engine offer for better entity manipulation? Thanks very, very much in advance--- -Mattie http://www.eventscripts.com -- ___ 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
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
RE: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
--
[ 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
Re: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
--
[ Picked text/plain from multipart/alternative ]
voogru-- That's officially the best news I've heard all day. Thanks very
much for mentioning this-- this is the second time I've wanted to thank you
in the past two days (for another old post of you). I didn't see this in
early OB SDK drops.
I've tested tools-CreateEntityByName() and it works (I see the entity in
the entity list).
Now to see how well the rest of the APIs work to simulate some of the other
features we need.
Huge thanks to Valve for adding this-- I'm already stunned and exceptionally
happy just to see the attempt.
-Mattie
On 2/29/08, 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
[hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
-- [ Picked text/plain from multipart/alternative ] Can you consider adding ent_fire and ent_name API equivalents for Source server plugins? (Ideally these interact via index/pointer rather than name, but if we can name entities by index that would be the same thing, really.) Getting access to the entity event/message queue without hacks/tricks would open many stable doors and I've voiced this opinion in the past. This is one of the biggest deficiencies of the server-side plugin SDK. Ideally, the give API (or any name-based entity creation method) would also be included, but there may be more mod-specific issues for you there, perhaps. Currently without hacks/hooks it's very difficult to emulate this. Is there any reason entity inputs/messaging weren't exposed via interfaces that server plugins can access? If the above is not possible, what kind of things could the Source engine offer for better entity manipulation? Thanks very, very much in advance--- -Mattie http://www.eventscripts.com -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins?
I agree that Valve does need to offer more interfaces to plugins for things like this. Doing anything with entities is incredibly limited given the provided resources. However, I think each one of these things is a simple vfunc call away to the desired result. ent_fire and ent_name can be accomplished using the AcceptInput virtual function, and give can be done with GiveNamedItem. There is no hooking or sig scanning required unless you meant to do something more advanced like get at the event queue or something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattieC Sent: Thursday, February 28, 2008 9:33 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Requesting (again): ent_fire and ent_name APIs for Server Plugins? -- [ Picked text/plain from multipart/alternative ] Can you consider adding ent_fire and ent_name API equivalents for Source server plugins? (Ideally these interact via index/pointer rather than name, but if we can name entities by index that would be the same thing, really.) Getting access to the entity event/message queue without hacks/tricks would open many stable doors and I've voiced this opinion in the past. This is one of the biggest deficiencies of the server-side plugin SDK. Ideally, the give API (or any name-based entity creation method) would also be included, but there may be more mod-specific issues for you there, perhaps. Currently without hacks/hooks it's very difficult to emulate this. Is there any reason entity inputs/messaging weren't exposed via interfaces that server plugins can access? If the above is not possible, what kind of things could the Source engine offer for better entity manipulation? Thanks very, very much in advance--- -Mattie http://www.eventscripts.com -- ___ 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
