Also, lines 23 and 25 would cause errors, since you seem to be declaring the type which is not a part of Python. And you have a NameError in your __init__ method (bossname / name).

Not to mention, if you inherit from Entity/PlayerEntity, and you create your own __init__ method, you MUST call the super class' __init__. And there is exactly one argument that those classes take and it is an index, not a userid.

I would strongly recommend running: https://www.jetbrains.com/pycharm/ as it would've picked up all of what satoon mentioned except for the pi constant. I can help you set it up with SourcePython if you'd like (the libraries can be a little tricky).

Also, lines 23 and 25 would cause errors, since you seem to be declaring the type which is not a part of Python. And you have a NameError in your __init__ method (bossname / name).

Not to mention, if you inherit from Entity/PlayerEntity, and you create your own __init__ method, you MUST call the super class' __init__. And there is exactly one argument that those classes take and it is an index, not a userid.

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 underscore -- though it doesn't actually do anything other than signals other programmers that "this variable should be used by this class only".

That being said: if you think nobody else should access an attribute, add an underscore in front of the attributes name. You're often better off not encapsulating anything than encapsulating too much.

You're still passing a second variable on __init__ which will cause an error. In Python, __new__ gets called prior to __init__. Our __new__ class method for Entity/PlayerEntity requires exactly 1 argument, the entity's/player's index. This is where the error would be encountered when you pass too many arguments. There has been minimal discussion about allowing for *args and **kwargs, but no decision has really been made on that.

For now, you can either pass only the index and then, after getting the object's instance, set the name variable:

satoon101 wrote:You're still passing a second variable on __init__ which will cause an error. In Python, __new__ gets called prior to __init__. Our __new__ class method for Entity/PlayerEntity requires exactly 1 argument, the entity's/player's index. This is where the error would be encountered when you pass too many arguments. There has been minimal discussion about allowing for *args and **kwargs, but no decision has really been made on that.

For now, you can either pass only the index and then, after getting the object's instance, set the name variable:

What is your purpose behind hooking think/pre-think? Just wondering if there is a better way to do what you are wanting to do.

There are pre and post event discussions on the forums already. I am interested, though, in what event variables you wish to change. Changing event variable values can be dangerous, as you potentially can break other plugins by doing so.

Hooking Pre/Think is the way to go if you are manipulating entities often. A tick listener is costly since you also have to do all the loop/conversions to find your entity. Also, it allows clean viewmodel, addons change (weapons displayed on players), etc. They are definititely methods we need to add to our data at some point.

satoon101 wrote:What is your purpose behind hooking think/pre-think? Just wondering if there is a better way to do what you are wanting to do.

There are pre and post event discussions on the forums already. I am interested, though, in what event variables you wish to change. Changing event variable values can be dangerous, as you potentially can break other plugins by doing so.

The purpose of hooking the thinks is give the boss the necessary abilities and boss/player specific code that requires being looped onto them.

L'In20Cible wrote:Hooking Pre/Think is the way to go if you are manipulating entities often. A tick listener is costly since you also have to do all the loop/conversions to find your entity. Also, it allows clean viewmodel, addons change (weapons displayed on players), etc. They are definititely methods we need to add to our data at some point.

yes! I also need to prehook Events such as player_death as I need to change certain damage before it's sent to the Event

satoon101 wrote:What is your purpose behind hooking think/pre-think? Just wondering if there is a better way to do what you are wanting to do.

There are pre and post event discussions on the forums already. I am interested, though, in what event variables you wish to change. Changing event variable values can be dangerous, as you potentially can break other plugins by doing so.

player_hurt damage variable as well as the weapon variable used in player_death.

I'm aware that this would mess with other plugins but I require such a feature for my Saxton Hale port.

satoon101 wrote:There is no 'damage' in the player_death event. To change damage, you would want to hook on_take_damage.

Then don't change it in the event, change it in the on_take_damage function. There are very few reasons to ever change event variable values. Also, just cause you change the damage amount in the event, doesn't change the actual damage done to the player. Same with the weapon. You need to change those in on_take_damage.

L'In20Cible wrote:Hooking Pre/Think is the way to go if you are manipulating entities often. A tick listener is costly since you also have to do all the loop/conversions to find your entity. Also, it allows clean viewmodel, addons change (weapons displayed on players), etc. They are definititely methods we need to add to our data at some point.

I don't disagree, and those should be easy to add as, if I remember correctly, they are virtual. I just want to make sure that that functionality is what is needed in this instance.