SAPP

[supersniper]

lol here's the tool SmG Clan uses

if you searched you would've found it

http://www.modacity.net/forums/showt...798-Servertool

[Amit]

Contact Jcap for details on its use.

[{XG}Gijs007]

ah yeah I've just noticed that. Would it be possible to get this app?
/sorry off-topic

Your looking for this: http://www.vivid-abstractions.net/pr...tom-edition-2/

[POQbum]

Your looking for this: http://www.vivid-abstractions.net/pr...tom-edition-2/

Thanks man. I've been searching through the release section back 8 pages and didn't see anything. I must of skipped over it

[Kornman00]

It would be more efficient not to wrap functions in further functions. Just assign an address to a function protoype with the correct calling convention (cdecl in this case).

The game is a Release build, so with its optimizations, most game functions take one or more of their parameters by registers. What you're suggesting wouldn't work with them.

[{XG}Gijs007]

Thanks man. I've been searching through the release section back 8 pages and didn't see anything. I must of skipped over it

Your welcome
This is the thread on modacity if you want to discuss it: http://www.modacity.net/forums/showt...Custom-Edition

[Patrickssj6]

The game is a Release build, so with its optimizations, most game functions take one or more of their parameters by registers. What you're suggesting wouldn't work with them.

Those 2 functions he posted can be perfectly be type defined. (I know this is not always the case)

I have even seen type defs with functions that require TLS.

[urbanyoung]

Like kornman said, quite a few functions use registers for one or more of their parameters, it's easier to just embed the assembly call in another function. The performance difference is basically non-existent.

@sehe: That could cause the disconnects, if you bypass the queue you screw up the packet counters and they get out of sync. I used to have a proxy approach (2-3 years ago) but it was a really bad design and so I changed. Most of the relevant code is included, you should basically just need to to update the addresses. I only included the code I use for global messages (ie sv_say server messages). I just included the actual functions, didn't bother with their headers as you can just copy the declaration to one. I'll explain a bit of the code and if you still want some help, I added you on xfire and can send the whole project.

1. Update addresses, there are only three that need updating. You can make that two if you're only interested in server messages, I have the third so I can handle all chat processing.
2. Call the GlobalMessage function (ie GlobalMessage(L"your message, in wide char...")
3. The first bit of GlobalMessage is just used for variable length parameters, WFormatVarArgs is just a memory safe wrapper around _vsnwprintf_s. I'm sure you have code for doing the same thing. It lets you call the function like GlobalMessage(L"Hello %s", player).
4. The next bit just traverses the player list and sends the message to everyone in the server, (*itr)->memoryId is the player's memory id. I think other people call it their machine index or something. The game::ChatData struct is below, you may want to put byte alignment around it.

struct chatData
    {
        DWORD type;
        DWORD player;
        wchar_t* msg;
    };

If you just want sv_say functionality you can basically get rid of DispatchChat and just put the calls to BuildPacket and AddToPlayerQueue in your GlobalMessage function.

@ Patrickssj6, they probably can be type defined but I didn't really see the point.

edit: no they can't, they use registers. See lines 95/96 for BuildPacket and 127/158 for the queue functions.

[Patrickssj6]

Oh now I fully understand what Korn meant: There is no way of creating a function prototype since the original function "changed" through optimizations to use registers. I did know that optimization is quite smart but not that smart xD

Of course one could still inline those two assembly lines before calling the function, or am I missing something here again?

e.g.

_asm MOV EDX,0x7FF8
_asm MOV EAX,output
dwBuildPacket(..., ...)

[urbanyoung]

Oh now I fully understand what Korn meant: There is no way of creating a function prototype since the original function "changed" through optimizations to use registers. I did know that optimization is quite smart but not that smart xD

Of course one could still inline those two assembly lines before calling the function, or am I missing something here again?

e.g.

_asm MOV EDX,0x7FF8
_asm MOV EAX,output
dwBuildPacket(..., ...)

It may work, it would depend on how the compiler builds the function call. I still don't really see why you'd want that mess every time you call the function though, especially for such an insignificant performance gain.