Skip to content

Documentation for callbacks #134

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
Closed

Conversation

gsmj
Copy link
Contributor

@gsmj gsmj commented Mar 6, 2024

  • Added documentation for callbacks

pysamp/actor.py Outdated
that streamed the actor in.
:returns: No return value.

.. note:: This callbackcan also be called by NPC.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some simple space-errors here and there. Could you go through these before we add?

@dennorske
Copy link
Collaborator

And in order to get these on sphinx, I will need to set up a proper pipeline and config to read the event-docs ^_^

@dennorske
Copy link
Collaborator

dennorske commented May 22, 2024

As mentioned on discord DM with you,
we call these events instead of callbacks, and they are used subscribe to things like callbacks behind the scenes.

In the API itself, they look like this now:

    @event("OnActorStreamIn")
    def on_stream_in(cls, actorid: int, forplayerid: int):
        """This callback is called when an actor is streamed in\
        by a player's client.
        :param int actorid: The ID of the actor.
        :param int forplayerid: The ID of the player\
        that streamed the actor in.
        :returns: No return value.
        .. note:: This callbackcan also be called by NPC.
        """
        return (cls(actorid), Player(forplayerid))

...But they are part of our OO Pysamp 2.1 API. The way you use them is not how they look in the API, but rather what the decorator does (and returns) to the methods we decorate. Imagine we use that event as an example:

@Actor.on_stream_in
def my_event_handling_function(actor: Actor, player: Player):  
    # see the expected types, these are the same as the ones we return from that event above
    pass

That means the documentation needs to reflect what the event "decorates" and returns, instead of what they are expecting behind the scenes. The user should not have to handle playerid's or actorid's, but rather the objects themselves.

@dennorske dennorske added this to the 2.1.0 milestone May 22, 2024
@gsmj
Copy link
Contributor Author

gsmj commented Dec 30, 2024

new: #140

@gsmj gsmj closed this Dec 30, 2024
@dennorske dennorske mentioned this pull request May 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants