Players are entities. Using m_takedamage allows you to set it so that an entity/player does not take damage. This is a true godmode instead of being tricky with life states. What would be the most convenient way of using m_takedamage? Is there a property for it or should I use player.set_property_b...

How would I ensure that my player_spawn event listener gets called before others? I'm trying to reset every player's gravity to 1.0 whenever they spawn, and I want to make sure it happens before other player_spawn functions modify the gravity again. Here's an easy example code of what I have: # ../p...

I'm happy that you play around with SP, but you should really test your code before posting on the forums -- at least when it comes to code examples! There are some errors in your code. I apologize, I'm used to compiling my code as I did with sourcemod but I don't know how to test-compile with sour...

These are some insanely nice features! Awesome job, thank you very much for these!

We (Python coders in general) don't use parenthesis around if sentences in Python, unless the if sentence is splitted on two lines like so: if (player is not None and not player.isdead and get_healing_target(player).userid == client.userid): medics += 1 But all other paranthesis shou...

The Fade class has been a part of the messages package since its creation. I did test using the numbers you have, but I am receiving errors. So, I lowered the 500 and 482 down to 5 and 2, and it worked like a charm: from colors import RED from events import Event from messages import Fade from play...

Say I want to make player's screen "bloody" by adding a red tint to it, how would this be done?

In eventscripts I would add a tint like so:

I'm debating if I should encapsulate the class members or just leave them public as this will be my first real object-oriented plugin. Rarely should you "encapsulate" (there's no true encapsulation in Python) anything. But if you want, you can mark attributes or methods "private" with a leading und...

BackRaw wrote:Next is dict, and here I'm not sure, Mahi - is it safe to leave __init__ out?

Yes, and you absolutely should. Only define an __init__ if it differs from the super class's __init__.

Edit: Regardless of what pylint says, unless someone can reason why it complains about this.

Satoon might be right about the pylint, but no, you don't have to define __init__ in a subclass if it doesn't do anything different from its super class's __init__. There's absolutely no benefit of doing this. Also, I couldn't find anything about this on PEP8, nor do I personally see why would you e...

Bump! Apparently this code no longer works, I get the MOTD popup but the website doesn't show. Any fix? Using CS:S.

You're better off parsing a string, looking for calculations, rather than trying to use eval on it.

Not to mention, if you compile your code to .pyc on a linux and try to run the same code on windows, won't work. Same for 32-bit vs 64-bit.

Correct me if I'm wrong?

You simply have two methods, get & set, plus a property that makes accessing these easier (but does the same thing). I think the .setter stuff would make code less readable. Don't know about the alpha parameter tho. What's so wrong about having two methods and then a wrapper for both of them as...

I don't mean to be rude at any point of this answer, I'm just trying to say what I think about all this, and I like being kind of "offensive" (making my points clear :grin: ) when trying to prove my point. That being said, here's my personal opinion on this stuff, with some sort of argumen...

Well, I don't think that fully applies in this instance as, in my view, that is for not creating 2 separate and distinct ways of doing the same thing. If we were to fully follow that rule as if it applied fully universally, one could argue that using the Entity/PlayerEntity attributes we add dynami...

We decided that we want to have properties, because we think they are more handy. I completely agree with you. Which is why I'd just go with the "newest" version of using properties, instead of having set and get methods separately. Example: class Example: @property def x(self): r...

The property wraps the 2 methods. This is actually a fairly common practice. We use it quite a bit for Entity/PlayerEntity. Never seen it before, I've only seen people use either properties (usually with the decorator) or set_x() and get_x() methods, but never both (doesn't mean it's wrong or anyth...

Just so you know, we did already implement a get_view_entity method for PlayerEntity along with a view_player property: print(player.get_view_player().name) print(player.view_player.name) Of course, those 2 will return None if the player is not looking at another player. Tha...

Ayuto wrote:Do you perhaps mean "m_fEffects"? Though, that is accessible through <Entity object>.effects.

Well. Dammit. Google even gave me results on "m_Effects" Thanks Ayuto, works fine now