Assist Needed, couple last pieces of info needed...

[Pierre-Marie Baty]

Originally Posted by BAStumm

pEntity->v.aiment = Entity #7 ("player")
pEntity->v.owner = Entity #7 ("player")

hmmm interesting... Do hostages in CS do this too? Anyone have knowledge of DoD with similar such as the "papers" or "plans" or whatever the secret docs you rescue are?

I just checked in CS, the hostages don't do that (unfortunately for you). Nothing in their entvars seem relevant to tell that this hostage is following someone. I don't know about DoD.

as for cs though, the entity type doesn't change does it? Just the model changes for that ent... I'm just using a findentity function on weapon_c4 and the v.model changes as its planted or dropped or carried.

Yes it does change, and that's your main problem. There is no "bomb" entity, only several ways to represent a bomb in the game.
Like I said, a DROPPED bomb is a "weaponbox" type of entity.
A PLANTED bomb is a "grenade" type of entity
A CARRIED bomb is a "weapon_c4" one, but you could also check if (pPlayer->v.weapons & WEAPON_C4) to tell if a player is carrying a bomb or not.

What about server say messages? Is that just a matter of hooking pfnServerCommand or is there some other way?

It depends on what you mean by "server say" messages. If you are talking about just the ability for the server admin to type "say" in the console then I suppose hooking pfnServerCommand() would work. Although you'd be 100% sure only by hooking the network messages, since this is a type of message that is broadcasted.

Bot chat? No real way to do this for ALL bots is there? Other than grabbing SayText on the fly? Does me no good to get bot chat if it only works for BOBSLEETBOT but not for JOHNSLEETBOT

Yes there is, and in fact you should not do it differently for bots and for real players, since hooking SayText messages is the only orthodox way to go. You should implement a message catcher in your metamod DLL, that would send the integrality of any network message being sent by the game in a buffer of yours, then you are free to look at this message more closely before releasing it. Look in my PodFix plugin for an example of a (simple) message catcher.

[BAStumm]

haven't gotten to bot chat yet still looking into server say, yes I meant when "say" is typed on the console.

I set up to log all pfnMessageBegin along with the various writestring, writebyte etc (all of them) to a file. Upon diggin though around a half gig of text logging I can find no messages that look like a command "say" that was issued on the console. My server has some auto reply stuff (map voting, timeleft, etc) so it spits out server say messages quite often. Are you sure this info is available inside a WriteString or other such? Which is it contained in? ie sayText hudText etc...

/me thinks hooking pfnServerCommand is the only way to do this...

[Pierre-Marie Baty]

...and how do you think pfnServerCommand sends the text over the network to the clients, hmmm ?

[BAStumm]

hmmm.... ok so i hooked pfnServerCommand and just printf() all of them for now to see whats going on. Oddly if *I* kick a player from console it doesn't show but if sturmbot kicks a player it does show. it also shows things like exec map.cfg... Never does it show a say course since it doesn't show kick commands made on console that doesn't surprise me...

[Pierre-Marie Baty]

Yes, because some commands you type in the DS console go directly to the engine, which doesn't bother passing them to the game DLL. This goes for generic commands like "kick", and perhaps "say" indeed. Since these commands are low level commands that are the same for all game DLLs, they are not passing through the game DLL API.. But it's not because you CAN'T hook these messages in the engine<=>gameDLL interface that these messages don't exist. They are simply sent by the engine directly over the network. You can ensure this by using some utility like TCPdump.

Remember how the Half-Life engine works. Every command, every input, everything you type on your keyboard, every move you make with your mouse, be you a client or the server admin in front of his DS console, goes to the engine. The engine then decides if it knows what to do with it, and if so, does its job. In this case, end of the story. If the engine does NOT know what to do with this new input, it passes it forth to the game DLL which is behind, using the API we all know and use, in the hope that the game DLL will know what to do. The game DLL does its job, and the chain is terminated.

Using the gameDLL interface you can only hook those messages which are passing through that interface. In order to hook the others, you'll have to use other methods, such as proxying the whole network traffic between the HL server process and the wire. Personally, I never felt any use in trying these, and my message catching experiences stopped at the gameDLL interface level only, but this is doable. Just a bit harder.

[BAStumm]

ok can someone do a sanity check on me? I've been down this road a couple times before but tonight I called on Alfred Reynolds of valve to help me out... He pointed me to this...

			  PF_MessageBegin_I( MSG_ONE, RegUserMsg( "SayText", -1 ), NULL, &sv.edicts[j+1] );
					  PF_WriteByte_I( 0 );
					  PF_WriteString_I( text );
			  PF_MessageEnd_I();

To which I've been testing with:

void pfnWriteString( const char * sz )
{
		if (gpGlobals->deathmatch)
		{
				fp=fopen("phpua_log.txt","a");
				fprintf(fp,"pfnWriteString: %s\n",sz);
				fclose(fp);

Im logging all the damn WriteString messages to a file (along with pfnMessageBegin). Im getting lots of SayText messages... None are server say messages... Yes I opened the console and did some testing "say test" but it doesn't show in my log (phpua_log.txt). Whats the deal with the _I in his code? Im guessing thats just differences between valve and mm code or am I missing something.

Usually I can sort this stuff but I just can't sort this. I've been after this data for almost 2 months now and have been down this road a few times already before tonight and tried this road again tonight after alfreds response but still no luck? What am I missing?

[Lazy]

I just glanced at the topic but I think I may have an idea for some of your questions...

For the first part, after glancing at the code from Alfred it looks like that is part of the engine.

It may be possible to view the text by hooking pfnAlertMessage when its called with at_logged, but it is not possible to block the say from happening.

Just one check you can add to your code to make it more reliable...

- Do a null pointer check after opening a file

Oh, you do not need the pfn prefix on MessageBegin.
pfn Is generally used to prefix function pointers.

[BAStumm]

hell if you guys can offer help im all ears. I got a later message from Alfred such as:

Date: Mon, 9 Feb 2004 21:01:26 -0800
From: Alfred Reynolds <alfred@valvesoftware.com>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Server say (chat) messages
Ahh, it is I who lead you down the garden path. PF_WriteString_I
doesn't ever go through MetaMod (it stays inside the engine) so you
can't intercept it. Um, I don't think there is a good solution.
Perhaps you could use the logmod method of intercepting stdout and
parsing all that text, or try using logaddress_add and parsing the udp
packets you send to yourself.

Any of you got some 1337 haxoring experience that can help with this? If so then phpUA needs you... Please contact me directly... I am the coordinator for this project (the lead) and would welcome your input or your ability to join our team... I am a damn PHP dev not a C coder. I do the MM stuff because noone else wanted too...

phpUA is the future Titan Web side of things. PM prolly understands that.

[Pierre-Marie Baty]

Ah, seeing the email you sent to Alfred I suspect you didn't understand my post completely.

Like Alfred says, it's the way the engine works that doesn't allow you to catch the WriteStrings that are sent by the engine without the game DLL to be aware of it. Read my previous post again EVERYTHING you input to the game or in the DS console goes to the engine FIRST. and ONLY if the engine doesn't know what to do with it, your input is then passed forth to the game DLL. But if your input represents something the engine knows and is told to take care of, such as a "kick" or a "say" server command, the engine does its job and sends bytes over the network without needing to notify the game DLL of it. That's why nothing of the sort passes through the game DLL interface.

To hook the network traffic that is handled at the engine level you must PROXY all the network traffic between the wire and the HL engine process. For example, write a small application that will listen on port 27015 and send all packets it sees to port 27115 on localhost, and set the HL server to listen on that port (27115). Do a bidirectional interface like this. Externally, everything will look like as if your HL Server is installed on port 27015, but in fact it's just your proxy that will be seen, and you will be able to hook all network frames and look for WriteString packets (although at the byte level, but it's better than nothing).

This (proxying) is a method that can work with ANY game engine by the way *hint* *hint*


*edit*
after reading my post again I realize my stupidity: it won't work. The HL engine protocol uses some blowfish cryptography, I completely forgot that. Unless you want to decode all the stream by hand it's useless to go that way. Sorry.

What you can do then, is what Alfred tells you to: proxy not the network traffic of the game, but the network traffic of the log packets. This is exactly the same principle, but it's much simpler: the interface needs only to be unidirectional and you'll decode clear text packets, which is easy.

I'm sure there are other ideas, just don't have time to think about it, lots of {boring} work to do, sorry.

[BAStumm]

Well I've got BuzzKill (Titan, statsme, etc) working on it. He's the one that ported all our tcp stuff to windows. Thanks for trying to dumb it down for me PM but I'm afraid no amount of dumbing down is going to be clear enough to help me write something like this in C.