For CS:GO, that function's prototype appears to be: Vector Weapon_ShootPosition(Vector &vecOut); def make_function(pointer): return pointer.make_virtual_function(290, Convention.THISCALL, (DataType.POINTER, DataType.POINTER), DataType.POINTER) @EntityPreHook(...

from entities.hooks import EntityPreHook from entities.hooks import EntityCondition from memory import Convention from memory import DataType def make_function(pointer): return pointer.make_virtual_function(290, Convention.THISCALL, (DataType.POINTER, ), DataType.POINTER) @E...

@PreEvent('player_changename') def pre_player_changename(gevent): player = Player.from_userid(gevent['userid']) # Update scoreboard. player.set_name(gevent['oldname']) gevent['newname'] = gevent['oldname'] return EventAction.BL...

Sam wrote:I understand correctly?

void CBaseClient::SetName:

Yes, you are right, didn't notice the simple function

Source.Python: .def("check_origin_in_pvs", &IVEngineServer::CheckOriginInPVS, "Check whether the specified origin is inside the PVS", args("org", "checkpvs", "checkpvssize") ) .def("check_box_in_pvs", &IVEngineSe...

L'In20Cible @PreHook(get_virtual_function(engine_server, 'ClientCommand')) def _pre_client_command(args): """Block name changes started by the server. Pre-hook on IVEngineServer::ClientCommand to block the name changes. """ if args[2] ==...

Jesus... WHAT??? What you gave us is really bad. I wouldn't include this in any Cookbook. I just thought of a better alternative. And without it I suppose someone will use yours instead of the normal way. I respect your imagination of course but do not be impudent accepting your algorithm as the on...

Okay I'm a little bent about iterating over all players in method of one player, but one PlayerDictionary for a whole plugin which will be updated on player connect or disconnect alongside list with all players for iterating over, it is awesome. I'm even scared to do benchmark with PlayerGenerator e...

Also if you have a representation of a cube in 2 points (lower and upper corners) you should determine mins and maxs points. But I too recommend using standard Source.Python function because it takes care for it. Source.Python core: static bool IsWithinBox(Vector& point, Vector& corner1,...

I'm honestly not sure why you think this is better than the current implementation. Read to the end. Removing all the functionality of Entity seems like a horrible idea to me... PlayerMixin inhreted from BaseEntity . That's enough. And I just created a class with just the needed functions for my pl...

Perfect PlayerDictionary must have the following properties: 1. It should be one for the whole plugin. 2. It should add and remove player instances when client connect to the server and disconnects from the server respectively. 3. It should if necessary contains functions related to many players. A...

Of course I can't do it myself, but I still want to try making a Lua bindings.

Edit: Found better variant PyPy(in 4x-6x) faster than Cython with CFFI for c++ bindings.
I just know.a one person who doesn't want to try Source.Python because it is really slow by him opinion.

By the way I noticed that there exists pybind11, and maybe we can replace Boost.Python to pybind 11. Quote from stackoverfow I would recommend PyBind11. I am using it for similar use-case where Python modules calls C++ to perform operations which are costlier and performance extensive. Boost Python ...

In first, what if there will be cache in C++ side classes like CBasePlayer, CBaseEntity and on Python side we will simple retrieve them through BasePlayer(1), BaseEntity(1) respectively. So it will be really standard classes cached by default in C++ and nothing more for fast access. But what about c...

I've come up with something. What if we will have the global cache like L'In20Cible suggested, but very very global. I mean caching at low-level CBaseEntity, CBasePlayer, PlayerMixin in C++ and maybe Python with standard attributes and functions from Source-SDK. And nothing more won't be available t...

Entity.cache isn't even connected with EntityDictionary and this is completely new which located in Entity.class but repeats the EntityDictionary behavior. I still doubt this decision because you answer unconvincingly. I can't avoid using Player.cache even with caching=False because every time when ...

Noticed that the TempEntity.create takes a delay before creating the effect and maybe you can simply do this and behavior will be different: sparks = TempEntity('BeamPoints') sparks.alpha = 255 sparks.blue = 255 sparks.green = 208 sparks.red = 113 #... for i in range(1, 11): ...

2. I'm against moving them. This would break all existing codes that currently import them from there and since they are primarily to use in conjunction of the buttons listeners, having them there really just regroup your imports. Sooner or later you'll have to break existing codes for the best. 4....