AlliedModders

AlliedModders (https://forums.alliedmods.net/index.php)
-   Scripting Help (https://forums.alliedmods.net/forumdisplay.php?f=11)
-   -   Access to QueryClientCvarValue() or an analogous function (https://forums.alliedmods.net/showthread.php?t=17173)

JazzX 08-26-2005 21:06

Access to QueryClientCvarValue() or an analogous function
 
So, with great interest I have been anticipating a script-level equilavent to pfnQueryClientCvarValue since it was announced a couple of weeks ago in the follow-ups to the recent HL1 engine updates (VAC2, removal of server's executing alias commands, etc). QueryClientCvarValue() was added in Metamod 1.18, which (after looking at Metamod's souce) is really just an alias for the HL Engine command.

Now, my question is can I get at this in the current version of AMXX? There is no native support for it in 1.55 that I can see (and the errors the compiler gives me seem to confirm this). As I understand it FakeMeta (and specifically engfunc()) would normally be where I'd turn, but from looking at the enum list in fakemeta_const.inc, it doesn't appear there is support for it yet. Does this mean I'm out of luck (beyond hacking it in myself, and recompiling the fakemeta module) AMXX-wise for the time being?

BAILOPAN 08-26-2005 21:40

Yes, it means you are out of luck.

Unfortunately, the API valve provided is not designed well and if they cared about HL1 still, we probably would have boycotted it. I brought up the relevant issues to Alfred Reynolds on hlcoders, who soundly blew me off.

As such, we (the Metamod team) are going to need to add in extra support to make it synchronously usable by Metamod plugins. Until we do this, I'm not going to add support for it in AMX Mod X.

Also: note Fakemeta cannot support this, as it does not have any way to create NewDLL callbacks (which is how you get the cvar value).

I'll discuss how to proceed with Florian, but right now I would recommend that people do not use this API in Metamod plugins, the amount of extra code required is high.

BAILOPAN 08-26-2005 21:51

More info:

The reason this API is unacceptable is because when you receive the value of the cvar, you do not know which cvar you are receiving the value for. If you query more than one cvar at a given time, the order of return is undefined, and you have no way of matching one query to another. You cannot safely make more than one query at once.

Metamod 1.18 provides a PRIMITIVE way to solve this, by creating the function IS_QUERYING_CLIENT_CVAR. This way plugins can check if a query is in progress before making another - obviously, this is not great, because each plugin must maintain a queue of everything itself.

The solution, for Metamod 1.19, will be to create a global queue that locks and caches new queries until the last one has successfully resolved. But this is a lot of work, and most likely won't be done very soon. It also requires a lot of deliberation to get the API right.

Sigh, I love fixing Valve problems.

JazzX 08-26-2005 22:14

Thanks for both quick replies. I found your posts in the HLCoders list while you were probably typing up the second post and agree with your assessment (and with your suggestion to changing pfnQueryClientCvarValue, though I'm not exactly going to hold my breath for Valve to act on it). I'm not sure what we (I'm the maintainer for CAL's match plugin for their NS league) are going to do, but it looks like we'll probably postpone doing cvar checks for the time being.

Thanks again for the help and information.

PM 08-27-2005 05:07

I'd like to add (basic) support for this into AMXx if you don't mind, BAILOPAN. (because I need it in a plugin :D ).

Basically, keep a queue of queries for each player, on StartFrame, if there is a query in the queue and no other plugin is querying that player at the moment, do the engine call; then on the newdll callback, dispatch the result to the plugin and pop the query descriptor off the global queue.

Or something.

evilspy 08-27-2005 06:09

Quote:

Originally Posted by BAILOPAN
The reason this API is unacceptable is because when you receive the value of the cvar, you do not know which cvar you are receiving the value for. If you query more than one cvar at a given time, the order of return is undefined, and you have no way of matching one query to another. You cannot safely make more than one query at once.

Actually. When I think more about it.. order of returns is same as order of queries. These queries are send on reliable channel. Those packets only fail if connection dies. Packets are numbered on server and client handles theim in order so returns should be in same order too.

PM 08-27-2005 06:30

Quote:

Originally Posted by ghost of evilspy
Quote:

Originally Posted by BAILOPAN
The reason this API is unacceptable is because when you receive the value of the cvar, you do not know which cvar you are receiving the value for. If you query more than one cvar at a given time, the order of return is undefined, and you have no way of matching one query to another. You cannot safely make more than one query at once.

Actually. When I think more about it.. order of returns is same as order of queries. These queries are send on reliable channel. Those packets only fail if connection dies. Packets are numbered on server and client handles theim in order so returns should be in same order too.

I trust you, but I remember Alfred saying that results "should" arrive in the same order, but that it's not guaranteed, so I don't know whether we should rely on it.

BAILOPAN 08-27-2005 10:56

Results are guaranteed to arrive unless a player disconnects, but not guaranteed to arrive in the right order.

That means we're clear to do some backend stuff in Metamod to fix it.

Twilight Suzuka 08-27-2005 15:44

I propose we simply design our own system for this.

There is a lot of information in the client that AMXx could use, and a lot of things we could do with it.

For instance, with client side access, you could create actually lines and pictures and such on the client, instead of our hudmessages and VGUI interfaces.

The basic idea is that the client and server techniques for communication are very similar (as one would expect) and thus a system similar to MM could be created to hook into the client.

However, instead of loading/unloading plugins directly on the client, this system would work in concert with MM, sending it information, probably through a socket or message system.

It is, in theory, possible to send your own custom messages, as long as they are caught and don't make it to the engine (where the engine would simply create millions of tiny code snipplets, called bear traps, to try and protect itself, and end up crashing).

With a communication system between a client MM and a server MM in place, we could capture and even alter far more things that simple CVARs and such.

Now, this would not function as a hack, due to the fact there is no memory hacking involved. We're overriding and altering calls, but we are not literally changing processes in an active manner. With a little work, this system would probably not be detected by VAC or a similar system.

As the people in charge of MM are already in AMXx's midst, I'm thinking that a system like this might even be incorporated into MM, in a similar fashion to CD.

If Client MM functions are used, then the new MM would force all players to have client MM turned on (after forcing it down their throats and telling them to change their game dll), otherwise they don't nessasarily need it turned on.

Just an idea, that I'm looking into and that I believe you guys should too.

evilspy 08-27-2005 15:57

:lol:


All times are GMT -4. The time now is 14:27.

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