> This API will be in the form of a C++ "interface" class, i.e a completely > virtual class. We have some source code here that allows you to easily > register these interfaces (i.e expose them in your dll) and also some code > to aquire these interfaces from loaded dlls. > > This email is a little premature on my part as I have yet to review the game > dll/engine interface in detail, but to kick things off, what callback do > people want in the interface? A basic set would include: > ClientConnect > ClientDisconnect > ClientCommand > > > are there any new types of callbacks that would be useful (given your > knowledge of the HL1 engine that is)?
I think it will be difficult/impossible to predict which interface functions a plugin application will want/need to get access to. In the ideal specification, plugins would have access to all functions between the engine and the game DLL (in the exact same manner that metamod provides). This can be abused by server admins who want to implement server side cheating, but I would think the number of cases of this would be small. If there was a clever way of letting plugins hook into only the functions that they were interested in (via chaining of some sort), then people writing plugins that only cared about player connects/disconnects could hook into ClientConnect(), ClientDisconnect(). Plugins that only cared about "say" messages could only hook into ClientCommand(). Plugins that only cared about what player model a client was using could hook into ClientUserInfoChanged(), etc. The engine could manage these functions in a similar manner to metamod by keeping a list of which plugins are interested in which functions and calling them in the order that the plugins were loaded (possibly calling the game DLL version first to allow plugins to modify/intercept/change the response from the engine). I think it would be useful to have a command that clients can issue to the server to display the list of all plugins that are running on the server (something that the server operator can't intercept or override). This would allow the client to determine if they are connecting to a server that is running plain vanilla Half-Life code, or connecting to a server that has some unknown plugins running on it (server admin is cheating?). I'm not sure how you'd enforce validity of the plugins in this case though. I could easily create a plugin that says I'm running AdminMOD when in fact, I am running HelpTheServerAdminAimBetterPlugin version 2.1 (especially if this plugin tells the engine it is "AdminMOD v7.3"). Could there be some way of PGP signing the plugins so that only people who create the plugins can register them as who they say they are? I don't know enough about PGP to answer this one. If the goal of the HL2 plugin system is to restrict what plugins are capable of doing (to prevent server side abuse/misuse), I would think that someone could still get around this using a "man-in-the-middle" approach between the Half-Life engine and the game DLL code (unless there's something going on here akin to the Valve-Anti-Cheat code that verifies that a server is actually loading the game DLL code and not some hook DLL code instead). I wouldn't think this would be the case otherwise Valve would have to sign each MOD team's DLL in a similar manner to the way Microsoft digitally signs Xbox games with the secret Xbox private key to allow the Xbox kernel to load those games. I think you could take a look at the existing metamod plugins to get a pretty good idea of what types of applications are desired. Something on the scale of AdminMOD would be a very big job and probably would require a team of people to get it converted over and up and running within the first few months after HL2 is released. Some of the smaller plugins (fakefull for example) could probably be converted over in a weekend (assuming the engine interface for HL2 was similar to the engine interface for HL). Plugins that try to get at too much engine internal information would probably not be easy to convert over, and many plugins are written to adhere to the behaviour of specific MODs (Counter-Strike especially) so they wouldn't port over at all. I would think that people would be more interested in things that other games have that Half-Life did not. For example, Unreal's ability to set up a URL where resources could be downloaded from and automatically redirect the person to that URL instead of downloading resources via the Half-Life server network connection. This is almost impossible with the existing Half-Life interface since the player can't connect to the server (and MOD game code) until all of required resources are available, and you can't send a command to the player's client code telling them where to download the resources until they have connected to the server (Catch-22). This type of situation is obviously better handled at the engine level than at the game DLL level The engine should allow server operators to define a URL of where missing resources can be downloaded from and automatically spawn the player's Internet browser pointing at the appropriate page if the server is configured this way. Another nice feature of Unreal is the ability to have HTTP access built into the engine (and passed along to the MOD game code). This makes the ability to admin the server via web interfaces MUCH easier. Web apps can even get at MOD specific information like "How much money is player X carrying at this moment?" Or which player on the Red team is currently carrying the flag?, etc. I think I'm beginning to wander off of the main topic but if things are going to be extended, perhaps it would be better to get a list of the features that the server admins REALLY want. Maybe have some way of letting people make suggestions on a forum somewhere and, after the top 100 items have been collected, let people vote on them. After the vote is complete, make sure that you can support the top 20 items (not necessarily fully coded, but at least have the engine interface that will allow someone to implement those features). I'm sure if you open this discussion up to the people on the UA forums (don't tell them it came from this list), you'll get lots of feedback (some good, some bad, some indifferent). That might be the best starting point for getting a list of what people would really like to see. Make sure that they also indicate things that Half-Life currently does support that they wouldn't want to go away (not just new items that they want added). Okay, it's getting late, I still have some code that I have to finish debugging before I go home (it's 8:15pm my time, but I've been here since 7:00am) so I'll shut up for now. Jeffrey "botman" Broome _______________________________________________ hlds_apps mailing list [EMAIL PROTECTED] http://list.valvesoftware.com/mailman/listinfo/hlds_apps
