SM Memory exposes your basic cstdlib memory functions for SourceMod plugins to use, giving them more control over memory allocation and deallocation.
With that said, when would you ever want to use an extension that does something like this?
The answer: Never.
SourceMod gives you enoughcontrol already. You shouldn't be using this extension just for the sake of raw pointers.
There are only 2 possible cases I could think of in which this extension would ever be useful.
Case 1:
Spoiler
When disassembling CTFWeaponBase::ApplyOnHitAttributes, victims are checked for a mad milk condition. If they're in said condition, a healing effect is applied (damage * 0.6). However if I were to want to modify that percentage, I would run headlong into an assembly issue:
The address of flt_1196D10 contains the 0.6 floating point value. The value this address is pointing to is being loaded into register xmm0.
If I wanted to alter or patch over the value going into that register, I would have a rough, rough time. There are no immediate loads in SSE, and I'm limited on bytes, so...
I'm given two options here.
A: I scour over .rodata to find another float value that has the percentage I want, but what if I want to make my own cvar to let server owners adjust that value at will?
B: I jmp into and out of my own asm to allow myself more bytes to work with which would probably bring me to the point of insanity.
Both of these options suck, but with SM-Memory, I can just allocate my own pointer and give it the value that I want. I can then patch over flt_1196D10 with my new pointer address.
public void Patch() { // This method *requires* the var to be global, otherwise Very Bad Things will happen! g_Value = cvMilk.FloatValue; Address addr = AddressOf(g_Value); WriteVal(g_Addr, addr); }
public void OnPluginEnd() { WriteVal(g_Addr, g_Old); }
On a scale of 1 to hard, that was about a 3. And there are definitely similar cases out there!
Case 2
Spoiler
You need to allocate an object to pass into an SDKCall as a parameter. I didn't write an example for this one because I couldn't find a prime example. But it can happen!
Case 2.5:
Spoiler
CUtlVectors.
Everyone knows them, yet there is no real feasible way to add or remove values to them.
I made a wrapper to work with them. Valve allocates their memory in their own way, but reallocing them should still work.
ReplyToCommand(client, "Set target %N time to %.2f", target, GetGameTime() + StringToFloat(arg)); return Plugin_Handled; }
Also worth mentioning that you're in control of what you do with the memory, therefore you are responsible for it. There's no safety net, no precautions, no nothing. It's all on you. Everything remains as is even if your plugin unloads. This is why I can't stress this enough when I say that you really shouldn't use this extension unless absolutely necessary.
I can go on and on about how this isn't a safe extension to use, but surely that's gotten through your head. TLDR; only use it for things it's needed for.
Note, if you're running 64-bit SourceMod, you'll need to build the ext yourself. Releases will not work at all with 64-bit servers.