Raised This Month: $51 Target: $400
 12% 

damage listening event...


Post New Thread Reply   
 
Thread Tools Display Modes
XAD
Senior Member
Join Date: Mar 2004
Location: Sweden
Old 01-27-2005 , 14:25  
Reply With Quote #21

Quote:
Originally Posted by BAILOPAN
The real problem is, as I said they would earlier (but no one listened to me), is that Valve isn't complying with their own APIs.

IPlayerManagerInfo001 in HL2DM and 002 in CS:S. It's already happening, and they don't even respond to my inquery on hlcoders. Is it really our fault if Valve is going to change things and then not recompile their stuff?
No, I think you miss the point BAILOPAN... IPlayerManagerInfo002 is back compatible with IPlayerManagerInfo001... They have "exposed" new functions wich doesn't require you to recompile, not even when doing hooks like me... That's what we (me and vancel) try to tell you ;-)

Or did I miss something?? What did Valve change or is not complying with??

/X

PS! I run my "old" serverplugin after the server upgrade with hooks without recompiling it...
XAD is offline
theqizmo
Member
Join Date: Oct 2004
Old 01-27-2005 , 14:55  
Reply With Quote #22

Quote:
[Thu Jan 27 11:48:22 2005] FAIL: IPlayerInfoManager *gsPlayerInfoManager [PlayerInfoManager002]: 0x0
[Thu Jan 27 11:48:22 2005] IPlayerInfoManager *gsPlayerInfoManager [PlayerInfoManager001]: 0x45B10428
CSS works fine, as they had compiled support in for 002, but BAILOPAN is 110% correct: Valve is ignoring *their own* API. HL2DM doesn't even work with the new interface. Go figure.
theqizmo is offline
Send a message via ICQ to theqizmo Send a message via AIM to theqizmo Send a message via MSN to theqizmo
XAD
Senior Member
Join Date: Mar 2004
Location: Sweden
Old 01-28-2005 , 02:56  
Reply With Quote #23

[quote="theqizmo"]
Quote:
CSS works fine, as they had compiled support in for 002, but BAILOPAN is 110% correct: Valve is ignoring *their own* API. HL2DM doesn't even work with the new interface. Go figure.
Do I miss something important here??
Valve is not ignoring the new interface, it's only that they do not use the new functions and therefore do not need to update HL2DM...
This exactly what I was talking about... you DON'T have to updates you mods (or plugins) when valve releases the new interface versions ONLY if you use the new functions. BUT if you are using the solution BAILOPAN suggest then your mod or plugin will kill the system as it requires you to use the LATEST version. THIS is what I mean with back-compatible, that you can use the previous version of the mod implemented interface...

Ie. we now have version 2 out but all plugins using version 1 still works with both mods using version 1 and 2. Of course you won't be able to use plugins requiring version 2 with mods using version 1 as the mod hasn't coded the new functions yet (sort of obvious).

So Valve doesn't have to update HL2DM to version 2 as it will still work. Updating CSS was probably the reasons to why they updated the interface to version 2, due to all request by plugin developers and maybee because they don't want us to make to ugly hacks directly in the data structures (as "we" did for CS1.6 to change health and other stuff).

/X
XAD is offline
BAILOPAN
Join Date: Jan 2004
Old 01-28-2005 , 03:50  
Reply With Quote #24

Those APIs are designed to be public, therefore, the Engine version and GameDLL version should match at all times. Logically, and in theory, the Engine could request a GameDLL interface like IPlayerInfoManager and not get the right version. What happens then?

Moreso, it's a problem for cross-mod compatibility. If a mod hasn't implemented the latest API, there's no reason you should bother supporting it if you need that API.

The end of the matter is, the interfaces that sift between the GameDLL and Engine should always, no matter what, be in agreement. I don't care if virtual table entries can just be tacked on for backward compatibility, if anything, that's a design idiosyncracy inherent in the way compilers implement vtables. That's irrelevant - what's relevant is that if Valve is making changes to their public API, there should be conformity, as it's expected the Engine and GameDLL's shared API should match no matter what.
__________________
egg
BAILOPAN is offline
XAD
Senior Member
Join Date: Mar 2004
Location: Sweden
Old 01-28-2005 , 05:22  
Reply With Quote #25

Quote:
Originally Posted by BAILOPAN
Those APIs are designed to be public, therefore, the Engine version and GameDLL version should match at all times. Logically, and in theory, the Engine could request a GameDLL interface like IPlayerInfoManager and not get the right version. What happens then?
The public engine interfaces are in eiface?? Why would the engine need the new game info version 2 functions?? Yes they could code it to use it but the idea of the engine is to be mod independent which is why they defined the eiface classes that are required to be followed by the mods...

Quote:
Originally Posted by BAILOPAN
The end of the matter is, the interfaces that sift between the GameDLL and Engine should always, no matter what, be in agreement.
These two aren't exactly "in between" the GameDLL and the engine (or do you have more info about this)?? They are two different interfaces to two different modules. As long as two modules agree on the interface, the interfaces doesn't have to be the exactly the same... I promise you, you don't want them to have implemented a system where all modules would have to run the same interface versions... With the current system they have implemented support for mods and plugins to NOT crash or have to be updated whenever the engine is updated with more functionality... it's the idea and (probably) the intention so I can't see why you arguing it's wrong or a bad thing???

Of course they need versioning to make sure things works and to be able to upgrade the modules (especially as they will license the engine to other companies) How would you otherwise in a safe way implement libraries that are back-compatible?? This is not strange or wrong...

Regardless, my argument was that making hooks by changing the virtual function pointers is safe and future "proof" but replacing the vtable itself is not...

/X
XAD is offline
theqizmo
Member
Join Date: Oct 2004
Old 01-28-2005 , 06:51  
Reply With Quote #26

Quote:
Originally Posted by XAD
THIS is what I mean with back-compatible, that you can use the previous version of the mod implemented interface...
. . .
So Valve doesn't have to update HL2DM to version 2 as it will still work. Updating CSS was probably the reasons to why they updated the interface to version 2, due to all request by plugin developers and maybee because they don't want us to make to ugly hacks directly in the data structures (as "we" did for CS1.6 to change health and other stuff).
First: the mods are backward compatible, but the interfacing system is poorly implemented, not in the sense that it's a poor choice/idea, but rather, how we get interfaces is poorly implemented. I'm given one interface version, and if that doesn't work, I can't use it. But what if I need that interface?

Then, in that case, I have to specifically go through every version from the latest to the first and try to load each one. Isn't that a bit counter productive? I mean, I have redesigned my interface class so that it automatically will run through every possible version number until it gets a valid pointer, but, this shouldn't be done by every plugin: it should be done by the mod/engine.

I think Valve is ignoring their interfaces, and you say they aren't, but, why should I have to take control of the versioning system of source because a mod author didn't upgrade the API? Or if the mod is out of development?

If I want to run it in that mod, I either have to build my plugin from an older set of headers, or waste cpu cycles on a useless function that could be optimized properly inside somewhere else (not a plugin):

Code:
private:
	void CreateVersionSet( char *szVersion )
	{
		std::string *pString = new std::string;
		std::string InterfaceName;
		std::string VersionNumber;
		
		pString->assign(szVersion);
		InterfaceName = pString->substr(0, pString->size() - 3);
		VersionNumber = pString->substr(pString->size() - 3, 3);
		
		vec.push_back(pString);

		unsigned int uVersion = (unsigned int) atoi( VersionNumber.c_str() );

		if (uVersion != 1)
		{
			while ((--uVersion) > 0)
			{
				std::string NewVersion = std::string(3, ' ');
				
				NewVersion[3] = 0;
				NewVersion[2] = '0' + (uVersion % 10);
				NewVersion[1] = (uVersion > 9) ? ((((uVersion - (uVersion % 10)) % 100) / 10) + '0') : '0';
				NewVersion[0] = (uVersion > 99) ? (((uVersion - (((uVersion - (uVersion % 10)) % 100) / 10)) / 100) + '0') : '0';
				
				pString = new std::string;
				pString->insert(0, InterfaceName);
				pString->insert(InterfaceName.size(), NewVersion);
				
				vec.push_back(pString);
			}
		}
	}

	std::vector<std::string*> vec;
//I will post the macro that accompanies this code if people want it, in fact, I'll post my entire header in a separate topic if necessary
That's a huge waste of cycles (probably more than someone who has a faster way of returning a list like this) when you consider how many interfaces I have to check. (And yes, this should be optimized more, like, trying to load an interface before building the list, and maybe other things, but I've been so caught up in other work that this is what I threw together real fast.)

Honestly, I love the idea with the interface system, but it's ugly right now. It is backward compatible, but only if you force it to be compatible: CSS works in both plugin versions, HL2DM only works with older plugin versions, unless you use a hack like mine.
theqizmo is offline
Send a message via ICQ to theqizmo Send a message via AIM to theqizmo Send a message via MSN to theqizmo
vancelorgin
Senior Member
Join Date: Dec 2004
Location: san frandisco
Old 01-28-2005 , 13:29  
Reply With Quote #27

Quote:
Originally Posted by XAD
Regardless, my argument was that making hooks by changing the virtual function pointers is safe and future "proof" but replacing the vtable itself is not...
*If* you want that function globally hooked - replacing the vtable is your only option (not involving use of an unused var in the class for a ptr or a map of class instances, both of which make me queasy) for single class instance virtual function hooking (read: custom entities).
__________________
Avoid like the plague.
vancelorgin is offline
Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 15:24.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode