On Windows the variant_t argument, which has the size of 20 bytes, gets copied to the stack instead of a single pointer that gets pushed to the stack. Thus, we need to add a few fake arguments, so we don't mess up the stack: # bool CBaseEntity::AcceptInput( const char *szInputName, CBaseEntity *pAct...

You can check the servers that have the public variable "sp_version". However, Source.Python itself doesn't track any servers.

Could you please post the output of "sp info". Also, to which ini-file have you added the data (I'm assuming some CBaseEntity.ini in Source.Python's data files). You get the KeyError if you specify the convetion, because it's case-sensitive (use upper case). Also, you don't necessarily nee...

Here is some other things I find weird: In a PagedMenu if I add Text( it counts as an option which means the numbers get weird. I don't know if I'm doing it wrong. Yes, that's the intended behaviour. if I return the menu object, it overwrites any currently opened menu. Not sure how that would work,...

I guess it's the file to reconstruct the CBaseEntity class. When the file is parsed, SP already assumes THISCALL plus the this pointer is added automatically to the arguments.

You don't need to specify the convention. It's already thiscall in that data file.

Well, I also need to credit Peace-Maker. He's currently integrating my DynamicHooks library into a SourceMod extension: https://forums.alliedmods.net/showpost.php?p=2588686&postcount=589 While doing this, he figured out that the stack isn't 16-byte aligned when calling the hook handler. That's n...

The assembly part is only required for CS:GO on Windows due to LTCG. This option does some speed improvements by storing the delay in the xmm1 register instead of pushing it onto the stack. It's also possible to grab this value with SP, but is this actually required?

I can't really tell, but I don't think so.

I didn't move that property, because it's not shared across all entities. You can use this as a workaround for now.

It's time for another development status update! :smile: ⋅ Fixes: ⋅  Fixed Player.clan_tag offsets for CS:GO. ⋅  Fixed Unicode problems with config files. ⋅  Fixed CFlashbangProjectile::Detonate offset (CS:GO). ⋅ Additions: ⋅  Added CBasePl...

I have fixed the typo, thanks! I'm glad it's working.

So, you would like to stop rounds from terminating? IIRC, there is a convar to do that in some games. For which game do you need that? If the convar does not exist you will need to hook CCSGameRules::TerminateRound.

I'm might be a little bit late to the party, but I still would like to drop my thoughts here. First of all, I still think retrieving whether or not the player is dead is the bottleneck due to the slow implementation of looking up properties dynamically. I just did a quick test and was able to prove ...

Try this: import core import memory from memory import Convention from memory import DataType from memory import NULL from memory.hooks import PreHook from entities.helpers import pointer_from_edict from players import PlayerGenerator server = memory.find_binary('server') if core.PLA...

I will take a look at it when I get home next week.

Thanks for the updated info. One more question: what's your SP version? I guess it lags, because of accessing the dead-property.

Code?

Looks like the 32 bit version of libffi is missing. Please check the installation instructions on our wiki.

No, there is no immunity system and no plans have been made so far.