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
