Rage
Beta 3, released March 21th, 2012

So, me and Arkshine decided to create a new module with the purpose of lifting orpheu restrictions by providing unrestricted interaction
with the engine. This time, we made a module called Rage that is a bit harder to use but it's more solid and supports sub-modules so
it should be the final solution for giving the answer to questions like "can I do this ?".

It works as follow :

Let's say we want to use a function that we can't use no matter what with amxx by itself :

First, we need to create a component called handler in C++ that is like a module but its purpose its to handle the management
of the hooking and calling of the function by plugins and rage modules alike. Basically, it links plugins and rage modules
to the function. They are relatively easy to create since we can use one already made as skeleton to create other one.
There must be one per function header. For example:

int CBasePlayerWeapon::AddPrimaryAmmo( int iCount, char *szName, int iMaxClip, int iMaxCarry )

It returns an int, its a member function of class CBasePlayerWeapon, and its arguments types are int char* int int.
So, we would need an handler for it that would take this into account and then we can use the same handler for :

int CBasePlayerWeapon::AddSecondaryAmmo( int iCount, char *szName, int iMaxClip, int iMaxCarry )

Since it has the same header. The function in this case wouldn't need to be exactly a member of CBasePlayerWeapon since all entities are
supposed to be handled the same way.

This way is more painful than in orpheu but it was a must for rage because having no restrictions was a must.
We well give examples for some cases and help you if you need.

Now assuming we have an handler to the function we want to hook we would need to create a file like in orpheu for it.
I will talk about those files in a specific thread so, for now, check in examples to see how they look.

Now assuming we have an handler and a file for the function we can from now call it and hook it in amxx plugins and rage modules with
the natives that rage provides.

At the end, you have this flow :

http://dl.dropbox.com/u/27827560/Dessin7.png


Notes :

- We are releasing this as BETA because we want to have sure that its API is ok to start to create handlers without having to worry
because of future updates that rage might have to take so we would ask for people to try to start creating handlers and sub modules
to test the API and features it might need to get added.

- Rage doesn't have the restriction that made orpheu unable to get to the amxmodx tree so hopefully it can be integrated in amxmodx.
We are open to change it's code to make it fit for it if someone thinks is ok to.

- If you are more into making plugins and not much into C++ you better wait for people creating sub modules that provide functionality directly
to plugins instead of trying to use rage.

- Rage won't come directly with natives for memory patching but it makes it easy to create a module like this http://forums.alliedmods.net/showthread.php?t=23152
as submodule and with support to signatures.

So this is it for now. Expect threads in Code Snippets/Tutorials from now on on teaching how to use this module for specific tasks step by step.

Update:

Beta 2 Changelog:

Added alias handling (now czero uses cstrike files)
Added some functions to FunctionForModule
Fixed some stuff

Beta 3 Changelog:

Fixed problem with long handler filename. (buffer related)
Fixed bug with a hook could not be removed.

Rules for naming handlers

You should use this rules if you are creating a handler that you want to distribute and if it handles everything one is supposed to do.
They are normative so if you are testing or just doing for yourself do as you wish.

[[thiscall|stdcall]__]returnType__argType1_argType2_[...]

Notes :

thiscall is a compiler convention for calling functions that are members of a class. The purpose its to call those functions in the context of an object.
stdcall is a convention that makes the function called responsible for cleaning the stack so in relation to cdecl it makes the code more compact because the code to clean the stack isnt spread around in each calling function
No return, use Void.

Special types :

Code:

---

edict_s*      : Edict
entvars_s*    : Entvars
char*        : String
CBaseEntity*  : CBaseEntity
CBase[...]*  : CBaseEntity

---

Normal types :

Code:

---

bool    : Bool
int    : Int
float  : Float
Vector  : Vector
int&    : Int-ref
[...]&  : [...]-ref
Void*  : ptr
Int*    : Int-ptr
[...]*  : [...]-ptr

---

Examples :

Code:

---

Vector CBaseEntity::FireBullets3( Vector source, Vector dirShooting, float spread, Float distance, int penetration, int bulletType, int damage, float rangerModifier, entvars_s *pevAttacker, bool isPistol, int sharedRand );
int CBaseAnimating::ExtractBbox( int sequence, float *mins, float *maxs );
int UTIL_EntitiesInBox( CBaseEntity **pList, int listMax, const Vector &mins, const Vector &maxs, int flagMask );
CBaseEntity *UTIL_FindEntityInSphere( CBaseEntity *pStartEntity, const Vector &vecCenter, float flRadius );

---

->

Code:

---

thiscall_Vector__CBaseEntity_Vector_Vector_Float_Float_Int_Int_Int_Float_Entvars_Bool_Int
thiscall_Int__CBaseEntity_Int_Float-ptr_Float-ptr
Int__CBaseEntity-ptr-ptr_Int_Vector-ref_Vector-ref_Int
CBaseEntity__CBaseEntity_Vector-ref_Float

---