Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
On Sun, 30 Jan 2005 21:39:54 -0800, Alfred Reynolds <[EMAIL PROTECTED]> wrote: > There needs to be a HL2DM release for it to export these new interfaces > (so far only CS:S has had such a release). Hopefully sometime in > February. > > Your plugin code needs to be able to handle an out of date (or even > missing) interface, there are no guarantees that MODs will export the > various plugin interfaces. What is the best way to determine the interface version? If it's an ugly hack, can you add a GetInterfaceVersion method? Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
> Your plugin code needs to be able to handle an out of date (or even > missing) interface, there are no guarantees that MODs will export the > various plugin interfaces. Then why is something rather important like IPlayerInfoManager in "public" (or even the gamedll)? If the implementation or version is completely arbitrary to anything, shouldn't it be in "dlls" or something mod-dependent? Anyway, I guess we'll have to work around it. Yay for hacks that should be totally unnecessary :p ~dvander Alfred Reynolds wrote: There needs to be a HL2DM release for it to export these new interfaces (so far only CS:S has had such a release). Hopefully sometime in February. Your plugin code needs to be able to handle an out of date (or even missing) interface, there are no guarantees that MODs will export the various plugin interfaces. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Thursday, January 27, 2005 8:42 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. Hopefully someone can make a comment before this gets overrun with another 40 irrelevant posts of "Steam: Technology Failure". Thanks, ~dvander David Anderson wrote: From what I've seen, it seems IPlayerInfoManager on HL2DM is still at version 001 while IPlayerInfoManager on CS:S is at version 002. While all Valve needs to do is recompile, the fact that the version number and interface name are in one string make it very difficult for good backward compatibility. Assuming they were separated, and Valve simply added new functions to the end of the vtable, it wouldn't be a problem. But that's not going to happen. What's the solution to this? Are we going to have to do ugly hacks to check the name's last three digits from X to 001 until we get a valid interface pointer? Other than that, I see nasty compatibility problems in the future. Thanks for any help, -David "BAILOPAN" Anderson http://www.sourcemod.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 ___ 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] HL2DM IPlayerInfoManager Out of Date
I'm missing the days of coding server side plugins from HL1 already. - voogru. -Original Message- From: Alfred Reynolds [mailto:[EMAIL PROTECTED] Sent: Monday, January 31, 2005 12:40 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] HL2DM IPlayerInfoManager Out of Date There needs to be a HL2DM release for it to export these new interfaces (so far only CS:S has had such a release). Hopefully sometime in February. Your plugin code needs to be able to handle an out of date (or even missing) interface, there are no guarantees that MODs will export the various plugin interfaces. - Alfred ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] HL2DM IPlayerInfoManager Out of Date
There needs to be a HL2DM release for it to export these new interfaces (so far only CS:S has had such a release). Hopefully sometime in February. Your plugin code needs to be able to handle an out of date (or even missing) interface, there are no guarantees that MODs will export the various plugin interfaces. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Anderson Sent: Thursday, January 27, 2005 8:42 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date > I don't like bumping threads but this issue is rather important, as > if Valve isn't even going to comply with their own API then > server-plugins are essentially doomed. > > Hopefully someone can make a comment before this gets overrun with > another 40 irrelevant posts of "Steam: Technology Failure". > > Thanks, > ~dvander > > David Anderson wrote: > > From what I've seen, it seems IPlayerInfoManager on HL2DM is still > > at version 001 while IPlayerInfoManager on CS:S is at version 002. > > > > While all Valve needs to do is recompile, the fact that the version > > number and interface name are in one string make it very difficult > > for good backward compatibility. Assuming they were separated, and > > Valve simply added new functions to the end of the vtable, it > > wouldn't be a problem. But that's not going to happen. > > > > What's the solution to this? Are we going to have to do ugly hacks > > to check the name's last three digits from X to 001 until we get a > > valid interface pointer? Other than that, I see nasty > > compatibility problems in the future. > > > > Thanks for any help, > > > > -David "BAILOPAN" Anderson > > http://www.sourcemod.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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
At least the person I was talking to has a sense of humour, not to mention being confident enough in his own opinion to tell me to bugger off nicely :D Lance - I did, and I like it. The technique is now in my toolbox of tricks, so thanks. Jeff - if you mean my post, then I agree ;) The other troll in this thread is actually malicious, whereas Im just being silly. On Fri, 28 Jan 2005 13:23:34 -0600, jeff broome <[EMAIL PROTECTED]> wrote: > Flamebait. Don't feed the trolls. :) > > 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] HL2DM IPlayerInfoManager Out of Date
Flamebait. Don't feed the trolls. :) 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] HL2DM IPlayerInfoManager Out of Date
> Kids these days.. if every scrap of data doesnt have its own class, > factory and RPC interface, they call it a hack. ;) were not asking little kids to put their 2 cents so who let you in? All we want is for vavle to give some feedback on this issue. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
> Kids these days.. if every scrap of data doesnt have its own class, > factory and RPC interface, they call it a hack. ;) Have you ever looked at my stuff? :P ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HL2DM IPlayerInfoManager Out of Date
> Kids these days.. if every scrap of data doesnt have its own class, > factory and RPC interface, they call it a hack. ;) Listen here whipper-snapper, you're talking to someone who hand coded portions of his mod in assembly ;] There are some things that are considered good design and other things that are not - requesting iterations of interface versions by decrementing ASCII characters is definitely a hack, and (I certainly hope) it's not Valve's intended use. ~dvander Luke Graham wrote: strcat() strcmp() atoi() char * restoffoo = &foo[sizeofstuffidontwant] Strings arent that hard... and they certainly arent ugly hacks. Kids these days.. if every scrap of data doesnt have its own class, factory and RPC interface, they call it a hack. ;) On Thu, 27 Jan 2005 12:43:10 -0500, David Anderson <[EMAIL PROTECTED]> wrote: Yes, I understand this - but it was relatively easy in HL1. Part of the problem is that the interface name and version are concatenated as one string, which makes it more difficult to request older versions iteratively. It's not really a problem requesting things from the engine, since that is assumed to be okay... it's from the GameDLL where it's a problem. And if mod developers and even Valve aren't updating the GameDLL interfaces to their own SDK, it makes sense that an updated engine with old GameDLL interfaces could also break. (Although that's not the case here, since I don't think Engine uses IPlayerInfo). All I'm saying is, it would be better to separate the version/name of interfaces, and that it would be nice if when Valve did update API, they recompiled their own mods (to at least set forth good policy for mod developers). What's the point of releasing public API changes if you're only going to half-support them? But you're right, in the end, the burden is on the Server Plugin author. Which, as I said, rather invalidates the useful-ness of them. Oh well. ~dvander jeff broome wrote: On Thu, 27 Jan 2005 11:42:22 -0500, David Anderson <[EMAIL PROTECTED]> wrote: I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. I'm not sure I fully understand the problem. Are you attempting to have a single plugin that can support any MOD? (in this case you're saying a single plugin can't support CS:S and HL2DM because it either accesses version 001 or version 002, but not both) My understanding of the Interface version stuff was so that Valve could upgrade the engine interface without breaking old MODs that didn't want to update to the latest SDK (and API). If this is Valve's intent, then that puts the burden on you, the multi-mod plugin creator, to properly handle the engine interfaces used by each MOD. Valve probably should be able to make CS:S and HL2DM both use the same engine interface versions, but this would require "lock-stepping" the releases so that if CS:S requires a new engine interface, the CS:S upgrade wouldn't be released until the HL2DM team had also done everything necessary to support that engine interface (and vice-versa). Once you add Day of Defeat:S and TFC:S, the updates become fewer and fewer since each update is waiting on the others. Since Valve has no control over outside MOD teams (Natural Selection:Source and others), you would still have to support whatever version of the engine interfaces those MODs are using. 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] HL2DM IPlayerInfoManager Out of Date
On Thu, 27 Jan 2005 12:43:10 -0500, David Anderson <[EMAIL PROTECTED]> wrote:
Yes, I understand this - but it was relatively easy in HL1. Part of the
problem is that the interface name and version are concatenated as one
string, which makes it more difficult to request older versions
iteratively.
It's not really a problem requesting things from the engine, since that
is assumed to be okay... it's from the GameDLL where it's a problem.
And if mod developers and even Valve aren't updating the GameDLL
interfaces to their own SDK, it makes sense that an updated engine with
old GameDLL interfaces could also break. (Although that's not the case
here, since I don't think Engine uses IPlayerInfo).
All I'm saying is, it would be better to separate the version/name of
interfaces, and that it would be nice if when Valve did update API, they
recompiled their own mods (to at least set forth good policy for mod
developers). What's the point of releasing public API changes if you're
only going to half-support them?
Hello all, it's my first-time post on this list.
Allow me to drop my two cents on this issue:
A practical solution is to make use of as much engine interfaces as
possible, and as few game DLL interfaces as possible. Whenever a game DLL
interface is required, only the most important facilities should be used,
meaning here those that are not likely to change anytime a new version of
the interface is out.
A possible way of loading game DLL interfaces with some flexibility (to a
certain extent of course), would be to require from the game the interface
we want with a somewhat higher version number than the one we expect, then
gradually fall back until the interface version is found. This also allows
generic plugins to be used on various game DLLs, provided the order of the
function pointers in the interface doesn't change much.
For example:
// plugin interface loader
#define LOAD_SINGLE_INTERFACE(type,name,version,provider,halt_on_error) \
name = (type *) provider (version, NULL); \
if (name == NULL) \
{ \
Warning (PLUGIN_NAME " - unable to load version #" version " of the "
#type " interface as \"" #name "\"!\n"); \
if (halt_on_error) return (false); \
} \
else if (interface_verbose) Msg (PLUGIN_NAME " - " #type " interface
(version #" version ") loaded at 0x%x as \"" #name "\"\n", name);
then
virtual bool CPlugin::Load (CreateInterfaceFn interfaceFactory,
CreateInterfaceFn gameServerFactory)
{
bool interface_verbose = true;
char interface_name[64];
int interface_version;
// get one interface from the engine
LOAD_SINGLE_INTERFACE (IVEngineServer, engine,
INTERFACEVERSION_VENGINESERVER, interfaceFactory, false);
// get some particular interface we want to use from the game DLL
for (interface_version = 9; interface_version > 0; interface_version--)
{
sprintf (interface_name, "ServerGameDLL00%d", interface_version);
LOAD_SINGLE_INTERFACE (IServerGameDLL, gamedll, interface_version,
gameServerFactory, false);
if (gamedll != NULL)
break; // stop trying as soon as a suitable interface is loaded
}
// rest of Load() function follows...
return (true); // return true so as to enable the engine to load this
plugin
}
So far, my main concern is to see Valve update the HL2MP server DLL to
support the IBotManager interface (which is unexistent by now).
Note: you can learn the different interfaces available from a game DLL along
with their particular version number by hex editing the server DLL.
--
Pierre-Marie Baty
Bots-United: http://www.bots-united.com
Bots-United forums: http://forums.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] HL2DM IPlayerInfoManager Out of Date
strcat() strcmp() atoi() char * restoffoo = &foo[sizeofstuffidontwant] Strings arent that hard... and they certainly arent ugly hacks. Kids these days.. if every scrap of data doesnt have its own class, factory and RPC interface, they call it a hack. ;) On Thu, 27 Jan 2005 12:43:10 -0500, David Anderson <[EMAIL PROTECTED]> wrote: > Yes, I understand this - but it was relatively easy in HL1. Part of the > problem is that the interface name and version are concatenated as one > string, which makes it more difficult to request older versions iteratively. > > It's not really a problem requesting things from the engine, since that > is assumed to be okay... it's from the GameDLL where it's a problem. > And if mod developers and even Valve aren't updating the GameDLL > interfaces to their own SDK, it makes sense that an updated engine with > old GameDLL interfaces could also break. (Although that's not the case > here, since I don't think Engine uses IPlayerInfo). > > All I'm saying is, it would be better to separate the version/name of > interfaces, and that it would be nice if when Valve did update API, they > recompiled their own mods (to at least set forth good policy for mod > developers). What's the point of releasing public API changes if you're > only going to half-support them? > > But you're right, in the end, the burden is on the Server Plugin author. > Which, as I said, rather invalidates the useful-ness of them. Oh well. > > ~dvander > > jeff broome wrote: > > On Thu, 27 Jan 2005 11:42:22 -0500, David Anderson <[EMAIL PROTECTED]> > > wrote: > > > >>I don't like bumping threads but this issue is rather important, as if > >>Valve isn't even going to comply with their own API then server-plugins > >>are essentially doomed. > > > > > > I'm not sure I fully understand the problem. Are you attempting to > > have a single plugin that can support any MOD? (in this case you're > > saying a single plugin can't support CS:S and HL2DM because it either > > accesses version 001 or version 002, but not both) > > > > My understanding of the Interface version stuff was so that Valve > > could upgrade the engine interface without breaking old MODs that > > didn't want to update to the latest SDK (and API). If this is Valve's > > intent, then that puts the burden on you, the multi-mod plugin > > creator, to properly handle the engine interfaces used by each MOD. > > > > Valve probably should be able to make CS:S and HL2DM both use the same > > engine interface versions, but this would require "lock-stepping" the > > releases so that if CS:S requires a new engine interface, the CS:S > > upgrade wouldn't be released until the HL2DM team had also done > > everything necessary to support that engine interface (and > > vice-versa). Once you add Day of Defeat:S and TFC:S, the updates > > become fewer and fewer since each update is waiting on the others. > > > > Since Valve has no control over outside MOD teams (Natural > > Selection:Source and others), you would still have to support whatever > > version of the engine interfaces those MODs are using. > > > > 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] HL2DM IPlayerInfoManager Out of Date
Yes, I understand this - but it was relatively easy in HL1. Part of the problem is that the interface name and version are concatenated as one string, which makes it more difficult to request older versions iteratively. It's not really a problem requesting things from the engine, since that is assumed to be okay... it's from the GameDLL where it's a problem. And if mod developers and even Valve aren't updating the GameDLL interfaces to their own SDK, it makes sense that an updated engine with old GameDLL interfaces could also break. (Although that's not the case here, since I don't think Engine uses IPlayerInfo). All I'm saying is, it would be better to separate the version/name of interfaces, and that it would be nice if when Valve did update API, they recompiled their own mods (to at least set forth good policy for mod developers). What's the point of releasing public API changes if you're only going to half-support them? But you're right, in the end, the burden is on the Server Plugin author. Which, as I said, rather invalidates the useful-ness of them. Oh well. ~dvander jeff broome wrote: On Thu, 27 Jan 2005 11:42:22 -0500, David Anderson <[EMAIL PROTECTED]> wrote: I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. I'm not sure I fully understand the problem. Are you attempting to have a single plugin that can support any MOD? (in this case you're saying a single plugin can't support CS:S and HL2DM because it either accesses version 001 or version 002, but not both) My understanding of the Interface version stuff was so that Valve could upgrade the engine interface without breaking old MODs that didn't want to update to the latest SDK (and API). If this is Valve's intent, then that puts the burden on you, the multi-mod plugin creator, to properly handle the engine interfaces used by each MOD. Valve probably should be able to make CS:S and HL2DM both use the same engine interface versions, but this would require "lock-stepping" the releases so that if CS:S requires a new engine interface, the CS:S upgrade wouldn't be released until the HL2DM team had also done everything necessary to support that engine interface (and vice-versa). Once you add Day of Defeat:S and TFC:S, the updates become fewer and fewer since each update is waiting on the others. Since Valve has no control over outside MOD teams (Natural Selection:Source and others), you would still have to support whatever version of the engine interfaces those MODs are using. 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] HL2DM IPlayerInfoManager Out of Date
On Thu, 27 Jan 2005 11:42:22 -0500, David Anderson <[EMAIL PROTECTED]> wrote: > I don't like bumping threads but this issue is rather important, as if > Valve isn't even going to comply with their own API then server-plugins > are essentially doomed. I'm not sure I fully understand the problem. Are you attempting to have a single plugin that can support any MOD? (in this case you're saying a single plugin can't support CS:S and HL2DM because it either accesses version 001 or version 002, but not both) My understanding of the Interface version stuff was so that Valve could upgrade the engine interface without breaking old MODs that didn't want to update to the latest SDK (and API). If this is Valve's intent, then that puts the burden on you, the multi-mod plugin creator, to properly handle the engine interfaces used by each MOD. Valve probably should be able to make CS:S and HL2DM both use the same engine interface versions, but this would require "lock-stepping" the releases so that if CS:S requires a new engine interface, the CS:S upgrade wouldn't be released until the HL2DM team had also done everything necessary to support that engine interface (and vice-versa). Once you add Day of Defeat:S and TFC:S, the updates become fewer and fewer since each update is waiting on the others. Since Valve has no control over outside MOD teams (Natural Selection:Source and others), you would still have to support whatever version of the engine interfaces those MODs are using. 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] HL2DM IPlayerInfoManager Out of Date
I don't like bumping threads but this issue is rather important, as if Valve isn't even going to comply with their own API then server-plugins are essentially doomed. Hopefully someone can make a comment before this gets overrun with another 40 irrelevant posts of "Steam: Technology Failure". Thanks, ~dvander David Anderson wrote: From what I've seen, it seems IPlayerInfoManager on HL2DM is still at version 001 while IPlayerInfoManager on CS:S is at version 002. While all Valve needs to do is recompile, the fact that the version number and interface name are in one string make it very difficult for good backward compatibility. Assuming they were separated, and Valve simply added new functions to the end of the vtable, it wouldn't be a problem. But that's not going to happen. What's the solution to this? Are we going to have to do ugly hacks to check the name's last three digits from X to 001 until we get a valid interface pointer? Other than that, I see nasty compatibility problems in the future. Thanks for any help, -David "BAILOPAN" Anderson http://www.sourcemod.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] HL2DM IPlayerInfoManager Out of Date
From what I've seen, it seems IPlayerInfoManager on HL2DM is still at version 001 while IPlayerInfoManager on CS:S is at version 002. While all Valve needs to do is recompile, the fact that the version number and interface name are in one string make it very difficult for good backward compatibility. Assuming they were separated, and Valve simply added new functions to the end of the vtable, it wouldn't be a problem. But that's not going to happen. What's the solution to this? Are we going to have to do ugly hacks to check the name's last three digits from X to 001 until we get a valid interface pointer? Other than that, I see nasty compatibility problems in the future. Thanks for any help, -David "BAILOPAN" Anderson http://www.sourcemod.net/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
