Re: [hlcoders] This should not be possible, yet it works!?
On Tue, Jan 11, 2005 at 04:35:26AM -0500, Lance Vorgin wrote: A plugin should have all of the capabilities of the server module. It makes the game more fun, more diverse, and all around stronger. I just can't imagine any reason to close off things from plugin authors besides jealously guarding your code (or hiding your crappy code :P). Any mod that disables useful plugins from interacting with it frankly deserves to die at the hands of its incredibly short-sighted developers. Regarding your example: plugin authors wouldn't modify player health... That's a really, really bad example, but then again, it's a really bad point as well. Mod-specific plugin and libraries for plugins have always worked, and always will as well. The health was only an example, the point was that mod authors should be able to do anything they want with their entity classes. There should be another way (interfaces) for plugins to interact with the game logic. And why would it require the mod author to impliment things he never uses? Well gee, I don't recall plugins shipping with HL2. Why did they impliment the plugin interface if they never use it? Hell, they should have just built the client, server, engine, and all supporting libraries into one monolithic binary! I mean they have everything available to them, why should they give other people capability to build on their work with puny mods, as the peasants call them. Is it really that tough to release your class definitions and include some symbol info? Give us some singletons? Is it really that hard? No, it's not, and it'd help everybody. Do you really want to recompile every server plugin for every single mod where they will be used? Valve already made some good interfaces to the engine. They should also make a few standard interfaces for common entity functions. These interfaces could then be implemented by the mod entities where applicable. Then plugins have to be able to query these interfaces from entities. This would allow mod authors to modify their entities all they want, and implement the interfaces that apply to them. Maarten -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] This should not be possible, yet it works!?
Us plugin authors should be able to do anything we want with _our_ entities, as well. Do you really want to recompile every server plugin for every single mod where they will be used? Yes. Valve already made some good interfaces to the engine. They should also make a few standard interfaces for common entity functions. These interfaces could then be implemented by the mod entities where applicable. Then plugins have to be able to query these interfaces from entities.This would allow mod authors to modify their entities all they want, and implement the interfaces that apply to them. Or the entity class defintion could be open, and none of that would be necessary and would allow for complete and total entity modification / access. Both would be fine if you feel like implimenting some interface, but after all that work it still wouldn't be nearly as useful as simply uploading your header files. And do remember, when I say plugin I don't mean these little admin tools - I mean NeoTF type stuff. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] This should not be possible, yet it works!?
Lance Vorgin wrote: Us plugin authors should be able to do anything we want with _our_ entities, as well. Hey Lance, I saw your stuff on sourcemod.net... http://www.sourcemod.net/forums/viewtopic.php?t=441 ...slightly scary (as far as platform specific and prone to crash with updates), but still pretty cool. :) -- 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] This should not be possible, yet it works!?
I am reading that post and almost faints of the type of code, i feel such a newbie. === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Jeffrey botman Broome Verzonden: woensdag 12 januari 2005 20:46 Aan: hlcoders@list.valvesoftware.com Onderwerp: Re: [hlcoders] This should not be possible, yet it works!? Lance Vorgin wrote: Us plugin authors should be able to do anything we want with _our_ entities, as well. Hey Lance, I saw your stuff on sourcemod.net... http://www.sourcemod.net/forums/viewtopic.php?t=441 ...slightly scary (as far as platform specific and prone to crash with updates), but still pretty cool. :) -- Jeffrey botman Broome ___ 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] This should not be possible, yet it works!?
Platform specific: Absolutly none of that is needed at all in linux - just put a pointer to a func in the format of the first callback in the vtable and call the original like a normal one :) this is on the stack, not in ecx. Quite nice, though I question the speed Prone to crashes on updates: It's more bulletproof that most other code out there being so simple and all, and will only crash if used incorrectly or the interfaces update, in which case the whole plugin is fubar :P But yeah, it's quite nasty. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] This should not be possible, yet it works!?
On Mon, Jan 10, 2005 at 01:12:40PM +0100, S. Hendriks wrote: Rofl, i think its a bi-directional thing here ;) You either change your mod code and destroy plugins... Or plugins force you to code how the sdk is intended to be used... Ie, derive from classes and not just hack into them :P These classes are internal to the game logic (the mod) and you (should) have no business using them. It should even be possible to remove all entity classes in a mod and start from scratch. :-) Obviously this is not useful for plugin authors, but realise that things you may want to view/modify in a plugin may not exist in some mods at all. Example: Perhaps someone makes an instagib mod and removes the health and armor from a player. Players are either alive or dead. What should happen if a plugin tries to modify the health of a player then? Of course there are ways to handle any example like that, but it would require the mod author to implement things he never uses. Perhaps a few interfaces can be defined that a mod author can choose to implement, if they apply to an entity. Maarten -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] This should not be possible, yet it works!?
A plugin should have all of the capabilities of the server module. It makes the game more fun, more diverse, and all around stronger. I just can't imagine any reason to close off things from plugin authors besides jealously guarding your code (or hiding your crappy code :P). Any mod that disables useful plugins from interacting with it frankly deserves to die at the hands of its incredibly short-sighted developers. Regarding your example: plugin authors wouldn't modify player health... That's a really, really bad example, but then again, it's a really bad point as well. Mod-specific plugin and libraries for plugins have always worked, and always will as well. And why would it require the mod author to impliment things he never uses? Well gee, I don't recall plugins shipping with HL2. Why did they impliment the plugin interface if they never use it? Hell, they should have just built the client, server, engine, and all supporting libraries into one monolithic binary! I mean they have everything available to them, why should they give other people capability to build on their work with puny mods, as the peasants call them. Is it really that tough to release your class definitions and include some symbol info? Give us some singletons? Is it really that hard? No, it's not, and it'd help everybody. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] This should not be possible, yet it works!?
Bots do not have to modify data, they only need to read it ;) I am still doing it the 'proper' way for viewing/walking to vectors, or any kind of processing data. The only thing i am limited to is with reading data. This 'hack' gives me the ability to read the data i need to make my bot function :) === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Maarten van der Zwaart Verzonden: dinsdag 11 januari 2005 9:15 Aan: hlcoders@list.valvesoftware.com Onderwerp: Re: [hlcoders] This should not be possible, yet it works!? On Mon, Jan 10, 2005 at 01:12:40PM +0100, S. Hendriks wrote: Rofl, i think its a bi-directional thing here ;) You either change your mod code and destroy plugins... Or plugins force you to code how the sdk is intended to be used... Ie, derive from classes and not just hack into them :P These classes are internal to the game logic (the mod) and you (should) have no business using them. It should even be possible to remove all entity classes in a mod and start from scratch. :-) Obviously this is not useful for plugin authors, but realise that things you may want to view/modify in a plugin may not exist in some mods at all. Example: Perhaps someone makes an instagib mod and removes the health and armor from a player. Players are either alive or dead. What should happen if a plugin tries to modify the health of a player then? Of course there are ways to handle any example like that, but it would require the mod author to implement things he never uses. Perhaps a few interfaces can be defined that a mod author can choose to implement, if they apply to an entity. Maarten -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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] This should not be possible, yet it works!?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lance Vorgin Sent: 11 January 2005 09:35 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] This should not be possible, yet it works!? A plugin should have all of the capabilities of the server module. It makes the game more fun, more diverse, and all around stronger. I just can't imagine any reason to close off things from plugin authors besides jealously guarding your code (or hiding your crappy code :P). Any mod that disables useful plugins from interacting with it frankly deserves to die at the hands of its incredibly short-sighted developers. Regarding your example: plugin authors wouldn't modify player health... That's a really, really bad example, but then again, it's a really bad point as well. Mod-specific plugin and libraries for plugins have always worked, and always will as well. And why would it require the mod author to impliment things he never uses? Well gee, I don't recall plugins shipping with HL2. Why did they impliment the plugin interface if they never use it? Hell, they should have just built the client, server, engine, and all supporting libraries into one monolithic binary! I mean they have everything available to them, why should they give other people capability to build on their work with puny mods, as the peasants call them. Is it really that tough to release your class definitions and include some symbol info? Give us some singletons? Is it really that hard? No, it's not, and it'd help everybody. ___ 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
[hlcoders] This should not be possible, yet it works!?
Yea I still wasn't able to add CBaseEntity to my project with what you said :( Has anyone else gotten this to work? I wasn't able to compile that bot either, quite a few compiler errors. Josh ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] This should not be possible, yet it works!?
It works, you should be more specific on your compiler errors. For instance, are you sure you extracted the bot/plugin into the utils/ directory? === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Josh Verzonden: dinsdag 11 januari 2005 14:47 Aan: hlcoders@list.valvesoftware.com Onderwerp: [hlcoders] This should not be possible, yet it works!? Yea I still wasn't able to add CBaseEntity to my project with what you said :( Has anyone else gotten this to work? I wasn't able to compile that bot either, quite a few compiler errors. Josh ___ 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] This should not be possible, yet it works!?
mod authors should *not* be limited or restricted by plug-in authors. plug-in authors *should* be limited and restricted by mod authors :) On Mon, 10 Jan 2005 11:38:00 +0100, S. Hendriks [EMAIL PROTECTED] wrote: So in short, as long as everybody does not touch the cBaseEntity and cBasePlayer but make an own class to derive from it, the plugins will be safe... The irony! :) === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Jeffrey botman Broome Verzonden: maandag 10 januari 2005 0:13 Aan: hlcoders@list.valvesoftware.com Onderwerp: Re: [hlcoders] This should not be possible, yet it works!? S. Hendriks wrote: This question is for Valve guys actually; ...but others can answer it also. My concern is, how does Valve think about this, and , will this cause trouble later on the road? I can see problems arise when a mod update has some updates in the cBaseEntity and cBasePlayer classes, and we are basicly messed up? This only works because you have a definition of the CBaseEntity and CBasePlayer class. As long as MOD teams don't change these, things will probably work fine. As soon as someone adds or removes member variables and/or functions to these classes, your plugin's version of these classes will differ from the MOD's version of these classes. If it was a perfect world, there would be some way to freeze these classes in the SDK so that MOD authors would not touch them. Since you can't do that, you can't guarantee that things won't crash when you start accessing variables or functions within a class that you don't have a proper class definition for. There has been some speculation that MOD's COULDN'T change CBaseEntity even if they wanted to because the engine depended on this class (i.e. was also compiled with this class definition). If a MOD team changed CBaseEntity, the engine's definition would differ from the MOD's definition and the game would crash. No proof of this theory was presented and I have not been able to find any engine interface that relied on the CBaseEntity class definition as it exists in the SDK source code (but I haven't spent a lot of time looking so perhaps the engine does have a dependency on CBaseEntity). Also, with the VAC going to hit the scene again, this might get caught as 'a cheating program'? Obviously this is not the intention! No. VAC checks for modified code on the clients. VAC doesn't check for hacks on the server (there really isn't a good way to do this). Server operators are completely free to install their own plugins that give them special abilities that aren't available to other clients. For example, I could create a plugin that constantly refreshes my health when it gets low. This plugin would allow me to cheat, but would only allow me to cheat on my own server. Anybody that had installed Admin-MOD for Half-Life knows what types of things are possible through plugins, but these aren't caught by VAC. -- Jeffrey botman Broome ___ 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] This should not be possible, yet it works!?
Rofl, i think its a bi-directional thing here ;) You either change your mod code and destroy plugins... Or plugins force you to code how the sdk is intended to be used... Ie, derive from classes and not just hack into them :P === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Hasan Aljudy Verzonden: maandag 10 januari 2005 13:09 Aan: hlcoders@list.valvesoftware.com Onderwerp: Re: [hlcoders] This should not be possible, yet it works!? mod authors should *not* be limited or restricted by plug-in authors. plug-in authors *should* be limited and restricted by mod authors :) On Mon, 10 Jan 2005 11:38:00 +0100, S. Hendriks [EMAIL PROTECTED] wrote: So in short, as long as everybody does not touch the cBaseEntity and cBasePlayer but make an own class to derive from it, the plugins will be safe... The irony! :) === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Jeffrey botman Broome Verzonden: maandag 10 januari 2005 0:13 Aan: hlcoders@list.valvesoftware.com Onderwerp: Re: [hlcoders] This should not be possible, yet it works!? S. Hendriks wrote: This question is for Valve guys actually; ...but others can answer it also. My concern is, how does Valve think about this, and , will this cause trouble later on the road? I can see problems arise when a mod update has some updates in the cBaseEntity and cBasePlayer classes, and we are basicly messed up? This only works because you have a definition of the CBaseEntity and CBasePlayer class. As long as MOD teams don't change these, things will probably work fine. As soon as someone adds or removes member variables and/or functions to these classes, your plugin's version of these classes will differ from the MOD's version of these classes. If it was a perfect world, there would be some way to freeze these classes in the SDK so that MOD authors would not touch them. Since you can't do that, you can't guarantee that things won't crash when you start accessing variables or functions within a class that you don't have a proper class definition for. There has been some speculation that MOD's COULDN'T change CBaseEntity even if they wanted to because the engine depended on this class (i.e. was also compiled with this class definition). If a MOD team changed CBaseEntity, the engine's definition would differ from the MOD's definition and the game would crash. No proof of this theory was presented and I have not been able to find any engine interface that relied on the CBaseEntity class definition as it exists in the SDK source code (but I haven't spent a lot of time looking so perhaps the engine does have a dependency on CBaseEntity). Also, with the VAC going to hit the scene again, this might get caught as 'a cheating program'? Obviously this is not the intention! No. VAC checks for modified code on the clients. VAC doesn't check for hacks on the server (there really isn't a good way to do this). Server operators are completely free to install their own plugins that give them special abilities that aren't available to other clients. For example, I could create a plugin that constantly refreshes my health when it gets low. This plugin would allow me to cheat, but would only allow me to cheat on my own server. Anybody that had installed Admin-MOD for Half-Life knows what types of things are possible through plugins, but these aren't caught by VAC. -- Jeffrey botman Broome ___ 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] This should not be possible, yet it works!?
If you're willing to detour, nobody's restricted by anybody :D ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] This should not be possible, yet it works!?
mod authors should *not* be limited or restricted by plug-in authors. plug-in authors *should* be limited and restricted by mod authors :) Why should *anyone* be restriced by *anyone*? Hacking classes renders the purpose of object oriented programming somewhat useless... ;) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] This should not be possible, yet it works!?
There are instances when working on a mod that you need to alter the base class though. One example would be a round reset system. Unless you want to search for every possible entity by name to reset them, you'd want to add a reset function at base level, so you can just call base-reset or what have you. That's just one example of why you'd need to modify base classes, out of possible hundreds. -omega -Original Message- From: Christian Marschalek [mailto:[EMAIL PROTECTED] Sent: January 10, 2005 7:28 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] This should not be possible, yet it works!? mod authors should *not* be limited or restricted by plug-in authors. plug-in authors *should* be limited and restricted by mod authors :) Why should *anyone* be restriced by *anyone*? Hacking classes renders the purpose of object oriented programming somewhat useless... ;) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] This should not be possible, yet it works!?
I still see the reason. You could derive your entities from the baseclass and put a reset in that entity. When you want to reset stuff, you could put that in an own baseclass even so you derive from 2 classes.. Imo, there is no excuse to alter the baseentity or baseplayer class. === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Tony omega Sergi Verzonden: maandag 10 januari 2005 13:36 Aan: hlcoders@list.valvesoftware.com Onderwerp: RE: [hlcoders] This should not be possible, yet it works!? There are instances when working on a mod that you need to alter the base class though. One example would be a round reset system. Unless you want to search for every possible entity by name to reset them, you'd want to add a reset function at base level, so you can just call base-reset or what have you. That's just one example of why you'd need to modify base classes, out of possible hundreds. -omega -Original Message- From: Christian Marschalek [mailto:[EMAIL PROTECTED] Sent: January 10, 2005 7:28 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] This should not be possible, yet it works!? mod authors should *not* be limited or restricted by plug-in authors. plug-in authors *should* be limited and restricted by mod authors :) Why should *anyone* be restriced by *anyone*? Hacking classes renders the purpose of object oriented programming somewhat useless... ;) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 ___ 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] This should not be possible, yet it works!?
Dunno if this applies to HL2 coding(I swear, if I don't get MSVC 2003 soon*grumble*) but pretty much half the crap I added to my MOD required me to add members to CBaseEntity. All plugin authors need to do is update their plugin everytime the mod is updated, mod authors make the declaration of those classes available on their website, just like with their FGD. simple. -- ** Draco Coder for Perfect Dark http://perfectdark.game-mod.net ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] This should not be possible, yet it works!?
That would be a most ideal situation. I just hope it will also compile fine when you give me your class ,w ithout the contents of possible functions... === Stefan Hendriks FunDynamic RealBot http://www.fundynamic.nl http://realbot.bots-united.com http://www.bots-united.com === -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Draco Verzonden: maandag 10 januari 2005 13:57 Aan: hlcoders@list.valvesoftware.com Onderwerp: Re: [hlcoders] This should not be possible, yet it works!? Dunno if this applies to HL2 coding(I swear, if I don't get MSVC 2003 soon*grumble*) but pretty much half the crap I added to my MOD required me to add members to CBaseEntity. All plugin authors need to do is update their plugin everytime the mod is updated, mod authors make the declaration of those classes available on their website, just like with their FGD. simple. -- ** Draco Coder for Perfect Dark http://perfectdark.game-mod.net ___ 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
[hlcoders] This should not be possible, yet it works!?
This question is for Valve guys actually;
There is a problem with accessing cBaseEntity and cBasePlayer from a
plugin. This is know, and there is no 'clean' way of doing this right?
Some guy, figured out , by luck/chance/knowledge?, to get a plugin
compiling and working with cBaseEntity and cBasePlayer access. Actually
it came down to this:
Include the _GAME flag to the compiling dependies (in the project
settings)
The following 2 lines at the top of a source file:
// HACK HACK HACK : BASEENTITY ACCESS
#include cbase.h
#include baseentity.h
// HACK HACK HACK : BASEENTITY ACCESS
And eventually to gain the acces itself:
// HACK HACK - cBaseEntity stuff - START
// HACK 1: GET TO BASE ENTITY FIRST
pBot-pBaseEntity = CBaseEntity::Instance(pEdict);// get the player
entity
pBot-pPlayerEnt = NULL;
if ( pBot-pBaseEntity pBot-pBaseEntity-IsPlayer() )
{
// HACK 2 : GET TO PLAYER ENTITY
pBot-pPlayerEnt = static_cast CBasePlayer * (
pBot-pBaseEntity );
}
else
{
// fail
Msg(Could not set pBaseEntity and pPlayerEnt!\n);
}
if (!pBot-pPlayerEnt)
{
// fail here
Msg(Failed to set pPlayerEnt);
}
// end method of SteveC
// HACK HACK - cBaseEntity stuff - END
The guy (SteveC) did all this stuff, i merely tried to understand it and
all i can think of is that somehow the compiler gets fooled or something
with the _GAME flag. I need to understand this better.
My concern is, how does Valve think about this, and , will this cause
trouble later on the road? I can see problems arise when a mod update
has some updates in the cBaseEntity and cBasePlayer classes, and we are
basicly messed up?
Also, with the VAC going to hit the scene again, this might get caught
as 'a cheating program'? Obviously this is not the intention!
If you are interested in the source of information:
http://forums.bots-united.com/showthread.php?t=3369
Personally i fixed / slammed up an own template to get bots working
basicly (has the very basic needs), which can be found here
:http://forums.bots-united.com/showthread.php?t=3377
You can also find source files in both posts if interested.
Any comments!?
===
Stefan Hendriks
FunDynamic RealBot
http://www.fundynamic.nl
http://realbot.bots-united.com
http://www.bots-united.com
===
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] This should not be possible, yet it works!?
S. Hendriks wrote: This question is for Valve guys actually; ...but others can answer it also. My concern is, how does Valve think about this, and , will this cause trouble later on the road? I can see problems arise when a mod update has some updates in the cBaseEntity and cBasePlayer classes, and we are basicly messed up? This only works because you have a definition of the CBaseEntity and CBasePlayer class. As long as MOD teams don't change these, things will probably work fine. As soon as someone adds or removes member variables and/or functions to these classes, your plugin's version of these classes will differ from the MOD's version of these classes. If it was a perfect world, there would be some way to freeze these classes in the SDK so that MOD authors would not touch them. Since you can't do that, you can't guarantee that things won't crash when you start accessing variables or functions within a class that you don't have a proper class definition for. There has been some speculation that MOD's COULDN'T change CBaseEntity even if they wanted to because the engine depended on this class (i.e. was also compiled with this class definition). If a MOD team changed CBaseEntity, the engine's definition would differ from the MOD's definition and the game would crash. No proof of this theory was presented and I have not been able to find any engine interface that relied on the CBaseEntity class definition as it exists in the SDK source code (but I haven't spent a lot of time looking so perhaps the engine does have a dependency on CBaseEntity). Also, with the VAC going to hit the scene again, this might get caught as 'a cheating program'? Obviously this is not the intention! No. VAC checks for modified code on the clients. VAC doesn't check for hacks on the server (there really isn't a good way to do this). Server operators are completely free to install their own plugins that give them special abilities that aren't available to other clients. For example, I could create a plugin that constantly refreshes my health when it gets low. This plugin would allow me to cheat, but would only allow me to cheat on my own server. Anybody that had installed Admin-MOD for Half-Life knows what types of things are possible through plugins, but these aren't caught by VAC. -- 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] This should not be possible, yet it works!?
My concern is, how does Valve think about this, and , will this cause trouble later on the road? I can see problems arise when a mod update has some updates in the cBaseEntity and cBasePlayer classes, and we are basicly messed up? I guess all MODs will have to make their CBaseEntity and CBasePlayer classes available for plugin authors to see -- ** Draco Coder for Perfect Dark http://perfectdark.game-mod.net ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] This should not be possible, yet it works!?
That'd be the reasonable thing to do. It'd also be horribly, amazingly, infinitly wonderful if they virtual'd more things and exposed more useful singletons to us. Please guys - help out :/ It'd be a horrible idea for VAC to scan servers - the diversity of servers is what keeps the game semi-fresh. Someone ought to try that CBaseEntity idea. I would, but I don't have enough drive space to compile a mod atm. You heard me :( ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
