Apparently every time I reload the plugin, I get one more error (although the exact same error) from player_spawn, and always one player_spawn succeeds. So first time I load the plugin -> player_spawn succeeds. Second load -> one player_spawn succeeds and one error is raised due to connection being ...

I've been working on a new Hero-Wars based Warcraft mod for CS:GO with Predz. I took an approach where I create a Database class which connects to the SQL database in its __init__ . The database object is initialized in the plugin's load() function. In the unload() function, I call t...

I tested the player.is_fake_client() a little more, and figured that it's false for bots only when they join the server, after that it works fine. So when the player_spawn triggers before bot is even in on any team, that's when player.is_fake_client() is unreliable. So probably not S...

Yeah it seems to be a Source engine bug. Still, any possible fixes are welcome! An other bug which I'm not sure if it's SP or Source engine: player.is_fake_client() seems to return False even on bots. Is this intended behaviour? I just ended up using player.steamid == 'BOT' for now, ...

I'm using the following plugin to test this with the latest release at this time : from events import Event from players.entity import Player from players.helpers import index_from_userid @Event('player_death', 'player_spawn', 'player_disconnect', 'player_activate'...

You need to execute the "mp_restartgame <delay>" command on the server. This code restarts the round 1 second after typing "!restart": from engines.server import engine_server from events import Event @Event('player_say') def on_player_say(event): if event...

Ayuto wrote:Alright, I have updated the conversion functions once again to raise an exception instead of returning None in case of a failed conversion. The main post has been updated as well.

Thank you for your feedback!

Awesome work, looking good!

Thank you very much for all the effort!

To be honest, when I decided to return None I was a bit C/C++ driven, where it's common to return "false" on failure and "true" on success

Good point, but I'd say we want to be pythonic here, not cppic!

I think I'm with Doldol here, I'd prefer an error with try/except way more than getting None. If I'm trying to convert an userid to an index and it fails, I expect and exception to be raised instead of getting None. It's not like int('hi') returns None either. I agree that getting rid of the extra a...

Since there's no performance issues yet, I would just go with the len(PlayerIter(team)) solution. Today's computers are way faster than you can even understand, the duration is barely milliseconds. If you end up with performance issues, that's when you figure out the bottleneck and start improving t...

This is awesome! Nice update guys

Say I want to give player ammo every time he jumps, if he doesn't have full ammo already: from entities.helpers import index_from_inthandle from events import Event from players.entity import PlayerEntity from players.helpers import index_from_userid from weapons.entity import WeaponEntity @Event de...

I went ahead an removed the first event_test branch. I won't be home for a few days, so please feel free to test this out and let us know if you find any issues or if it works perfectly fine. Once we get confirmation, it looks good enough for me to merge into master. I've spent 5+ hours with the ne...

Nice release! Few improvements to the Python code: global _smokestack _smokestack = None You don't need the global keyword here, as it's already global. You do need the keyword when you're setting it on line 42 though, since we're in a function by then. The way you're getting the bomb (conditionless...

Again new release is out, version 1.1: https://github.com/MarkusMeskanen/EasyPlayer/releases/tag/v1.1 I've switched to useing userIDs for caching instead of the entities' indexes, since userIDs cannot be reused like indexes can. Thanks to Ayuto for pointing this out. Also, EasyPlayer's method shift_...

I have created a new branch for the __getitem__ implementation. https://github.com/Source-Python-Dev-Team/Source.Python/commit/06658ab791b3db65cd83356798d5ac5f86f7fb21 I think the event system is the same on all branches. Some weeks ago I checked the offset of the KeyValues object and it was the sa...

The plan is to implement __getitem__ and __setitem__. If we still keep the get_<type>/set_<type> methods it's absolutely backwards compatible, because it's just an addition. Sounds really good, perfect not to say. Hopefully you'll also add some kind of to_dict() method or a way of iterating over th...

I don't mean to be nosy or annoying, but any news on this? Do you guys have any future plans? I would love to code some SP plugins, but I'd like to know the new syntax etc. before I start

If we are going to make any changes, it should be so that they are the correct type. Making it just like ES where everything is a string value and we have to typecast anyway seems pointless to me, which is the main reason this was never done in the first place. Honestly, I am going to test the play...

Do we really want to convert them automatically? That's a yes from me, if it has any weight! I like automatic conversion, but if we do that we should do it consistently. For example we do not provide a Entity.get_property method, but Entity.get_property_<type>, although we know the types in that ca...