Skip to content

Conversation

@Kenzzer
Copy link
Member

@Kenzzer Kenzzer commented Nov 28, 2024

Another Address PR!

The idea and implementation is primarily @dvander's, this PR just makes the bridge to SM.
In order to use the new virtual address :

#define VIRTUAL_ADDRESS
#include <sourcemod>
#include <sdktools>

If enabled, plugins need to ensure their SDKCalls are using the new SDKType_VirtualAddress, whether they're on 32bits or 64bits. Otherwise the plugin will most definitively crash the server.

Marking as draft for now until I can get a few server operators to try this out. Extra natives idea are welcomed !

@rtldg
Copy link
Contributor

rtldg commented Feb 23, 2025

Can you also add this:

		} else if (vc->retinfo->vtype == Valve_VirtualAddress) {
			void *addr = (void *)vc->retbuf;
			return g_pSM->ToPseudoAddress(addr);
		} else {

to here

} else if (vc->retinfo->vtype == Valve_Bool) {
bool *addr = (bool *)vc->retbuf;
if (vc->retinfo->flags & PASSFLAG_ASPOINTER)
{
addr = *(bool **)addr;
}
return *addr ? 1 : 0;
} else {
cell_t *addr = (cell_t *)vc->retbuf;
if (vc->retinfo->flags & PASSFLAG_ASPOINTER)
{
addr = *(cell_t **)addr;
}
return *addr;

This would allow things like calling CreateInterface with SDKCall() and actually having a usable result.

@Headline
Copy link
Member

@Kenzzer @rtldg anything else you guys can think of? Going to mark ready for review - plugin interface would instead be

#include <sourcemod>
#include <sdktools>
#include <virtual_address>

@Kenzzer
Copy link
Member Author

Kenzzer commented Sep 21, 2025

I think this is great, and indeed much better than the define.

@Kenzzer Kenzzer force-pushed the virtual_address branch 2 times, most recently from ab34ad7 to dffd568 Compare November 7, 2025 15:01
@Kenzzer
Copy link
Member Author

Kenzzer commented Nov 7, 2025

A big thanks to @Malifox for taking the first step into trying this PR with a well established plugin, which helped me hunt down a ton of bugs.

@Kenzzer Kenzzer marked this pull request as ready for review November 7, 2025 15:29
@Kenzzer Kenzzer merged commit 6439769 into master Nov 13, 2025
4 checks passed
@Kenzzer Kenzzer deleted the virtual_address branch November 13, 2025 12:23
cafeed28 pushed a commit to cafeed28/sourcemod that referenced this pull request Dec 2, 2025
In the current ongoing effort for sourcemod to fully support 64 bits, we are introducing "virtual address".

# Explanation

Because SourcePawn does not yet support a 64 bits-wide type it's been impossible for any plugins to hold addresses in regular 32-bits wide variable.

A first attempt at solving this issue was made in commit ce1a4dc therein dubbed "PseudoAddress", however this turned out to be an unsatisfactory solution, as any 'high' address if offsetted could turn invalid (or outright be impossible to map).

This leaves us with three alternatives :
- New type
- Convert Address into a handle
- Virtual Address

A new type is the most destructive solution, as it entails breaking every single Address related method. While that solution is still not off the table, we're reserving it as the last attempt should this commit fail.

Converting into a handle type is a good compromise between a brand new type whilst also preserving the Address methods. However, this comes with two issues: the first being that you can no longer offset Address, the second is that we would require authors to free the handle type which will be very confusing. This will likely not be implemented.

# Virtual address

Under a reasonable assumption, we've noted that the average plugin is unlikely to play with more than 4 GB of memory; this shouldn't be too surprising as all valve games were once 32bits and therefore limited to 4GB. Assuming this stays mostly true and a plugin isn't interested with the mapped memory of lesser known modules (like soundlib or matlib), it is fair to assume plugins are unlikely to access more than 4GB of mapped memory. Working with this in mind, we map the memory the plugins are likely to access to our custom virtual address ranges (from 0 to 4Gb, the values of which can fit on 32bits variable). If any memory was missed and plugins were to try an access it later those ranges will be late-mapped to our virtual address ranges until we run out of them.

In order to use virtual addressing, whether on 32 bits or 64 bits. Plugins must now "#include <virtual_address>", as well as use the new SDKCall_VirtualAddress, SDKType_VirtualAddress, LoadAddressFromAddress & StoreAddressToAddress where it's appropriate to.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Needs Testing untested by author

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants