Jonathan

> As I previously stated, scripters shouldn't use a `TransmitFilter`, nor a `SetTransmit` hook as a listener. Both are **not** guaranteed to be called. It all comes down to; when...

It only works because your s_nDLLIdentifier happens to be the same as Source.Python's DLL identifier. There is no guarantee that it will work every time. ConVar_Unregister is a very dumb...

ConVar and Source SDK is so broken that I feel discouraged. > But it's not a coincidence. We assign our `s_nDLLIdentifier` when we call `ConVar_Register`. That ID is ours and...

@jordanbriere Can you confirm this issue on your side? > Please replace with: ``` // See issue #430. // DevMsg(1, MSG_PREFIX "Unregistering ConVar...\n"); // ConVar_Unregister( ); ``` Since the root...

In my environment, the only way to get around this reliably is to load Source.Python after metamod has finished loading. Loading with autoexec.cfg is not a workaround for this. This...

> To be honest, I don't think we should care. There is no point into trying to make a non-issue an issue. I mean, so long as loading SM or...

> At least, not until it becomes one. THere is really no point into focusing on stuff that is unlikely to happens or that never has been reported. Edited: This...

https://github.com/Source-Python-Dev-Team/Source.Python/blob/39ca701839b3a5d7c9f5aaf58156b4d1496246e5/src/core/modules/cvars/cvars.h#L97-L102 🤔

> Works great! Though you forgot a callable check when registering callbacks. The following should raise: > > ```python > ConVarChanged(ConVar("test", "1", "test convar."))(None) > ``` > > Because `None`...

> `test_command` is not a valid ConVar in the first place, so it should not be registered. I've added a check for ConVar. We could also add a check to...