Feature Requests

Official Announcements about Source.Python.
User avatar
Ayuto
Project Leader
Posts: 1579
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Feature Requests

Postby Ayuto » Fri Feb 13, 2015 6:38 pm

Dear community,

we would like to use this thread to gather some general ideas, suggestions and improvements.

Please post your thoughts about the current state of our plugin! We are excited to hear them!

Thank you,
Source.Python Development Team
Hedgehog
Member
Posts: 62
Joined: Sun Nov 03, 2013 8:54 pm

Postby Hedgehog » Fri Feb 13, 2015 8:24 pm

Implement this fix, please.

I didn't push it to the main repo by myself because I'm not good in C/C++, so I thought that it would be better if you double check my work, change it in the way you like and then push it to the project repo :)

UPD: Everything is very good, except issue #27, of course if it still not fixed (I'm not sure in this because I have my own temporary fix, which is looks more like very shitty reinvented squared wheel).
User avatar
Ayuto
Project Leader
Posts: 1579
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Sat Feb 14, 2015 6:14 pm

Thanks for reminding! I guess we forgot this post. I have now added your fix! https://github.com/Source-Python-Dev-Team/Source.Python/commit/44155139e1d8a78dfe9646721c50f1f0c429ddd6

Regarding your edit: Since I haven't done much testings on this issue, I would be happy if you could provide us your temporary fix.
Hedgehog
Member
Posts: 62
Joined: Sun Nov 03, 2013 8:54 pm

Postby Hedgehog » Sat Feb 14, 2015 8:57 pm

Thanks :)

There is still an identation problem on lines 71-75.

My solution for names:

Syntax: Select all

from players.entity import PlayerEntity


class PlayerEntityExtended(PlayerEntity):
def __new__(cls, index):
self = super(PlayerEntityExtended, cls).__new__(cls, index)

self._name = None

return self

def update_name(self):
try:
self._name = self.playerinfo.get_name()
except UnicodeDecodeError:
name = ""
for i in tuple(range(0, 64)):
try:
t = getattr(self.pointer, 'get_char')(0xE08 + i)
except UnicodeDecodeError:
break

if ord(t) == 0:
break

name += t

self._name = name

@property
def name(self):
if self._name is None:
self.update_name()

return self._name

I used separated update_name method because I have one extra class to store PlayerEntity objects and I need to update player name when player change it.

Syntax: Select all

from events import Event


@Event
def player_changename(event):
PlayerEntityExtended(index_from_userid(event.get_int('userid'))).update_name()

(Tested on CS:S Linux/Windows)

And I had't work with SayFilter...

By the way, my name on GitHub is Oleg Tsvetkov.
User avatar
Ayuto
Project Leader
Posts: 1579
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Sat Feb 14, 2015 10:05 pm

Well, I wouldn't call this a temporary fix. It's more like a workaround for a specific situation. :p

Anyways, thanks for sharing.
User avatar
satoon101
Project Leader
Posts: 2323
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Mon Feb 16, 2015 3:33 pm

While bug reports are awesome, and we certainly want people to continue with that, this thread's purpose is to gather a list of features not currently implemented into our plugin. Those can be features not implemented on the C++ side or features that are already exposed but not yet wrapped by the Python API.

Bug reports should really be done on the issues list on GitHub anyway, as it is a whole lot easier to keep track of them there. Posting them on the forums is fine, but there is a greater chance of us forgetting about them if they are.
Image
Mahi
Senior Member
Posts: 212
Joined: Wed Aug 29, 2012 8:39 pm
Location: Finland

Postby Mahi » Thu Feb 19, 2015 1:48 pm

"Improving" PlayerEntity

PlayerEntity lacks dozens of useful features, or the features are implemented in an unfriendly way for the people using Source.Python to create plugins.
There's a lot of inconsistency between some properties, and some functions are completely missing.
In my opinion, PlayerEntity should be easy to use, rather than sticking "one-to-tone" to the C++ side.
I know you will disagree with some of these, and some will not get implemented, but here are a few things I'd like to see:

Igniting a player
Currently you ignite a player by calling 'Ignite' on him and later 'IgniteLifetime', 0 to end the ignition, which is really impractical.
You end up calling Delay() to stop the burning, so why not just have a method that takes the duration of the ignition as a parameter.
player.burn(5), and use a negative value or similar for infinite burn.

Freezing a player
Personally, I'd like to see a similar function to ignite: player.freeze(duration)
Currently I'm calling Delay(duration, setattr, 'player', 'freeze', False) all the time, which is not just impractical, but looks awful.
I can just subclass PlayerEntity to define the burn function, but having a property called player.freeze gives me a headache when trying to come up with a freezing function.
At least rename the property to player.frozen or similar, so freeze can be used as a method.
Same goes for noclip.

Pushing a player, teleporting a player, changing player's view coordinates, blinding a player, ...
All of these, and many more, could be methods of PlayerEntity.
Calling player.set_view_coordinates(x, y, z) or even player.set_angle(x, y, z) would make things much easier.
Overall adding a lot of stuff into PlayerEntity would make the plugins much more capable and I think it would drag more people to code the plugins.
Counter-Strike is all about the players, there's not really much else to do (well, bomb planting and similar aside), so having a powerful PlayerEntity class means a lot, imo.
User avatar
satoon101
Project Leader
Posts: 2323
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Thu Feb 19, 2015 2:31 pm

For now, the only one I will respond to is burning. Your <PlayerEntity>.burn(5) is already available with <PlayerEntity>.ignite_lifetime(5.0)

That actually works for all entities (BaseEntity), not just players.
https://github.com/Source-Python-Dev-Team/Source.Python/blob/master/addons/source-python/data/source-python/entities/managers/engines/orangebox/CBaseAnimating.ini#L15
https://github.com/Source-Python-Dev-Team/Source.Python/blob/master/addons/source-python/data/source-python/entities/managers/engines/csgo/CBaseAnimating.ini#L4

*Edit: actually teleporting should just be <PlayerEntity>.origin = <Vector> This also works with BaseEntity.
https://github.com/Source-Python-Dev-Team/Source.Python/blob/master/addons/source-python/packages/source-python/entities/entity.py#L296
Image
User avatar
satoon101
Project Leader
Posts: 2323
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Feb 20, 2015 2:27 am

As far as freeze is concerned, I do agree that we should probably change the name of that property. Though, frozen doesn't really seem to fit to me since you're not really frozen. Maybe 'still' or 'stuck' works better (trying to think of something better than either of those).

Ignite is already a built-in function, which is why we provide that via data. I would prefer to keep written in functions to a minimum, and freeze(<duration>) doesn't sound like a good idea to me. Once we change the name, you should just sub-class and create a freeze and unfreeze methods yourself if it is necessary for your plugin.

I agree that we should probably look to incorporate set_view_coordinates (akin to get_view_coordinates), set_view_vector (akin to get_view_vector), and set_view_entity (akin to get_view_entity/get_view_player). I also want to add the angle property just like we currently have the origin property.

There are tons of things that have nothing to do with players in CS, so I am not really sure what you mean by that sentence. I think BaseEntity/PlayerEntity (and now WeaponEntity) are already pretty darn powerful, we just need to work on documenting all the functionalities we have for them. Could they be improved? Certainly, and we do fully intend to do so. Thank you for all of your suggestions.
Image
User avatar
L'In20Cible
Project Leader
Posts: 917
Joined: Sat Jul 14, 2012 9:29 pm
Location: Québec

Postby L'In20Cible » Fri Feb 20, 2015 8:35 am

satoon101 wrote:*Edit: actually teleporting should just be <PlayerEntity>.origin = <Vector> This also works with BaseEntity.

satoon101 wrote:I also want to add the angle property just like we currently have the origin property.


Unfortunately, this won't work for a player (and some other entities such as projectiles that I know of) cause the related properties are excluded. The only workaround is to dynamically calls CBaseFlex::Teleport (offset 109/110 in the CCSPlayer dispatch table) which accepts 3 parameters: origin, angles, velocity (passing NULL/None to any of them is keeping the current value).
User avatar
L'In20Cible
Project Leader
Posts: 917
Joined: Sat Jul 14, 2012 9:29 pm
Location: Québec

Postby L'In20Cible » Fri Feb 20, 2015 9:29 am

satoon101 wrote:As far as freeze is concerned, I do agree that we should probably change the name of that property. Though, frozen doesn't really seem to fit to me since you're not really frozen. Maybe 'still' or 'stuck' works better (trying to think of something better than either of those).
To be honnest, rather than being renamed, I think we should remove freeze, jetpack and noclip completely. I don't see the interest to rename all move types and wrapping them as properties. I think we should simply declare movetype as a property:

Syntax: Select all

player.movetype = MoveTypes.NONE
player.movetype = MoveTypes.NOCLIP
# etc...
Mainly cause they are currently "assuming" a movetype when they are defined to False. This can lead to unexpected issue/confusion between plugins.

However, PlayerEntity.frozen would makes sense with:

Syntax: Select all

player.set_property_int('m_fFlags', player.get_property_int(
'm_fFlags') | PlayerFlags.FROZEN)
User avatar
BackRaw
Senior Member
Posts: 413
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany

Postby BackRaw » Fri Feb 20, 2015 12:36 pm

L'In20Cible wrote:
satoon101 wrote:As far as freeze is concerned, I do agree that we should probably change the name of that property. Though, frozen doesn't really seem to fit to me since you're not really frozen. Maybe 'still' or 'stuck' works better (trying to think of something better than either of those).
To be honnest, rather than being renamed, I think we should remove freeze, jetpack and noclip completely. I don't see the interest to rename all move types and wrapping them as properties. I think we should simply declare movetype as a property:

Syntax: Select all

player.movetype = MoveTypes.NONE
player.movetype = MoveTypes.NOCLIP
# etc...
Mainly cause they are currently "assuming" a movetype when they are defined to False. This can lead to unexpected issue/confusion between plugins.

However, PlayerEntity.frozen would makes sense with:

Syntax: Select all

player.set_property_int('m_fFlags', player.get_property_int(
'm_fFlags') | PlayerFlags.FROZEN)


I'd go with that! This makes much more sense (and is more of an "SP way"), setting/getting the PlayerEntity.freeze attribute is much more of an "ES way" to do things lol.

Mahi wrote:Freezing a player
Personally, I'd like to see a similar function to ignite: player.freeze(duration)
Currently I'm calling Delay(duration, setattr, 'player', 'freeze', False) all the time, which is not just impractical, but looks awful.

I disagree with that. Changing a player's/entity's movetype doesn't necessarily mean to be reset after an amount of time...
Burning a player is different, because they burn for a specific amount of time - or until they die (which is a specific amount of time, too).
My Github repositories:

Source.Python: https://github.com/backraw/backraw.sp
User avatar
satoon101
Project Leader
Posts: 2323
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sun Feb 22, 2015 3:42 am

L'In20Cible wrote:
satoon101 wrote:I also want to add the angle property just like we currently have the origin property.


Unfortunately, this won't work for a player (and some other entities such as projectiles that I know of) cause the related properties are excluded. The only workaround is to dynamically calls CBaseFlex::Teleport (offset 109/110 in the CCSPlayer dispatch table) which accepts 3 parameters: origin, angles, velocity (passing NULL/None to any of them is keeping the current value).

I have added CBaseFlex::Teleport locally. I will add it with my next commit (after testing).


L'In20Cible wrote:
satoon101 wrote:As far as freeze is concerned, I do agree that we should probably change the name of that property. Though, frozen doesn't really seem to fit to me since you're not really frozen. Maybe 'still' or 'stuck' works better (trying to think of something better than either of those).
To be honnest, rather than being renamed, I think we should remove freeze, jetpack and noclip completely. I don't see the interest to rename all move types and wrapping them as properties. I think we should simply declare movetype as a property:

Syntax: Select all

player.movetype = MoveTypes.NONE
player.movetype = MoveTypes.NOCLIP
# etc...
Mainly cause they are currently "assuming" a movetype when they are defined to False. This can lead to unexpected issue/confusion between plugins.

However, PlayerEntity.frozen would makes sense with:

Syntax: Select all

player.set_property_int('m_fFlags', player.get_property_int(
'm_fFlags') | PlayerFlags.FROZEN)

I like this idea a lot. This actually helps clear up this issue (dev eyes only), as those and godmode are currently the reason I decided on the current implementation:
http://forums.sourcepython.com/showthread.php?585&p=4323&viewfull=1#post4323

We still need to restructure the constants module and expose those in their specific packages. This would be a good time to begin work on that.

We can also add m_fFlags as 'flags' so the last example could just be:

Syntax: Select all

player.flags |= PlayerFlags.FROZEN
Image
User avatar
satoon101
Project Leader
Posts: 2323
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sun Feb 22, 2015 3:51 am

BackRaw wrote:
Mahi wrote:Freezing a player
Personally, I'd like to see a similar function to ignite: player.freeze(duration)
Currently I'm calling Delay(duration, setattr, 'player', 'freeze', False) all the time, which is not just impractical, but looks awful.

I disagree with that. Changing a player's/entity's movetype doesn't necessarily mean to be reset after an amount of time...
Burning a player is different, because they burn for a specific amount of time - or until they die (which is a specific amount of time, too).

Not only that, but 'ignite' and 'ignite_lifetime' are just calling functions that are already accessible from the engine. If there were Freeze and FreezeLifetime functions, we would certainly provide the same access. However, adding that entire functionality to the plugin seems far outside what I think the plugin 'should' be handling.

From a 'looks awful' approach to the Delay example, I would prefer something more like:

Syntax: Select all

class PlayerEntitySubClass(PlayerEntity):

def freeze(self, duration=None):
player.movetype = MoveTypes.NONE
if duration is not None:
tick_delays.delay(duration, self.unfreeze)

def unfreeze(self):
player.movetype = MoveTypes.WALK
Image
User avatar
BackRaw
Senior Member
Posts: 413
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany

Postby BackRaw » Sun Feb 22, 2015 6:12 am

satoon101 wrote:From a 'looks awful' approach to the Delay example, I would prefer something more like:

Syntax: Select all

class PlayerEntitySubClass(PlayerEntity):

def freeze(self, duration=None):
player.movetype = MoveTypes.NONE
if duration is not None:
tick_delays.delay(duration, self.unfreeze)

def unfreeze(self):
player.movetype = MoveTypes.WALK

Yes, thats more like it.
Mahi
Senior Member
Posts: 212
Joined: Wed Aug 29, 2012 8:39 pm
Location: Finland

Postby Mahi » Sun Feb 22, 2015 12:16 pm

This actually sounds really good, better than what I actually requested!
Is it still just an idea, or are you going to implement it already? If so, any eta. on the new update?
User avatar
satoon101
Project Leader
Posts: 2323
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sun Feb 22, 2015 1:55 pm

As always there is no eta, but we will get these implemented in due time. I will actually be away for the next 3 days, so I won't be able to work on anything till Tuesday night at the earliest.
Image
Mahi
Senior Member
Posts: 212
Joined: Wed Aug 29, 2012 8:39 pm
Location: Finland

Postby Mahi » Sun Feb 22, 2015 3:13 pm

Alright, good to know they'll be coming eventually :) Thanks for the answer
User avatar
L'In20Cible
Project Leader
Posts: 917
Joined: Sat Jul 14, 2012 9:29 pm
Location: Québec

Postby L'In20Cible » Sat Mar 07, 2015 5:02 am

Just a heads up, you can now use the following to set the move type of a player:

Syntax: Select all

from entities.constants import MoveType
from events import Event
from players.entity import PlayerEntity
from players.helpers import index_from_userid
from listeners.tick import tick_delays

@Event
def player_jump(game_event):
player = PlayerEntity(index_from_userid(game_event.get_int('userid')))
current_movetype = player.movetype
player.movetype = MoveType.NONE
tick_delays.delay(1, setattr, player, 'movetype', current_movetype)
stonedegg
Senior Member
Posts: 141
Joined: Sun Aug 12, 2012 11:45 am

Postby stonedegg » Sat Mar 07, 2015 12:04 pm

Good job! I guess this will work with BaseEntity as well (freezing prop physics for example)?

Return to “News & Announcements”

Who is online

Users browsing this forum: No registered users and 1 guest