Source.Python forums

I suggest that for normal events, if an userid is present also custom properties will be sent like sp_index and sp_player which contain the index and the player object respectively. Furthermore, all this code should be implemented on the C++ side.

The implementation could look like this:
1) Loop though the .res files
2) Register any event that contains "userid" for this special "lookup"
3) When the event fires and is in the lookup list, try to grab the player object and index and stuff it into sp_index and sp_player
4) Send the modified event to the scripts

Pros:

• Redundant code in scripts is avoided. Most of the time you want to implement player-related code for player_xxx events (or any events that contain "userid" for that matter)
• Having the code in C++ should actually be faster then doing it in python though a Python -> c++ - > Python call multiple times (and considering player events are used in a lot of addons, this probably makes a difference regarding CPU-time

Cons:

• Adds overhead - if these "extended" features are not used, it's wasted CPU-time
• May not be fully reliable

Original discussion arised here:

your-name-here wrote:

Mahi wrote:

Syntax: Select all

userid = GameEvent.GetInt('userid')
    player = Player.EdictOfUserid(userid)
    index = Engine.IndexOfEdict(player)

This part really stresses me, if we're actually never going to use userid or player, why not just have a single function GetIndex('userid')? Even if it was stupid and unlogical to have such, and even if SP is not meant to be "easy to use", that would just make things so much easier for everyone, and it would already be stupid NOT TO do it like that? Ofc. anyone could define it by themselves, to do all those 3 lines in one function, but it'd be simply easier if it was built-in.

Because GetIndex isn't inside IGameEvent as a function, nor would it be valid for all game events. We're providing a 1-1 translation of every C++ function to Python. It's 1-2 extra lines of code. We're not asking for the world from you, so I don't see why you are so stressed out over this.

Well, I guess we can write a GetEdictOfUserid function which would solve this issue. It's less work than doing everything else you suggested Omega :P, and would solve the issue completely.

I vote no on this. All of this will be more easily done with the API once we get further along. Again, we do not want this plugin to hold people's hands constantly.

Satoon

Omega, have you seen [wiki]EasyPlayer[/wiki] ?

Monday wrote:Omega, have you seen [wiki]EasyPlayer[/wiki] ?

Syntax: Select all

myPlayer = EasyPlayer(GameEvent.GetInt('userid'))
myPlayer.index

It just simplifies the C++/Python and Python/C++ calls, it doesn't 'handle' them for more speed actually.

If you are concerned about speed gains with 1 extra call, you have bigger problems with your addon. People have to understand that Source Python doesn't add on extra cruft to Python -> C++ calls.

I have no issue with a GetIndexOfUserid being implemented. I do have a huge issue with creating Extended Event variables.

Satoon

satoon101 wrote:I have no issue with a GetIndexOfUserid being implemented. I do have a huge issue with creating Extended Event variables.

Satoon

I second this, I'm fine with a GetIndexOfUserid.

satoon101 wrote:I have no issue with a GetIndexOfUserid being implemented. I do have a huge issue with creating Extended Event variables.

Satoon

I'll agree with this.

GetIndexOfUserid also seems like a solution to cut this down a little bit. In any case, thanks for considering.

Good to notice that people actually highlight ideas, and unlike most plugin developers, you guys actually consider suggestions...

And GetIndexOfUserid would do the trick more than well enough, returning all 3, player, userid AND index would be just waste of cpu imo, since you would rarely need all 3, or even 2 of them.

Mahi wrote:And GetIndexOfUserid would do the trick more than well enough, returning all 3, player, userid AND index would be just waste of cpu imo, since you would rarely need all 3, or even 2 of them.

Indeed, which is why this will not be considered. A lot of extra work for very little payoff, when one simple command will suffice.

Satoon