Skip to content
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

Add support for sending gameevent to specific client. #505

Merged
merged 2 commits into from May 13, 2016

Conversation

psychonic
Copy link
Member

@psychonic psychonic commented May 8, 2016

I also initially planned on adding support for blocking existing events, per client on-the-fly, but API was getting complex and potentially inefficient. (This can still be added at some point). The net effect of that can still be achieved by blocking existing events with a prehook, saving event data, and then resending to the desired clients (not ideal, but doable).

Only tested on TF2 in Windows

@@ -31,6 +31,8 @@

#include "EventManager.h"
#include "sm_stringutil.h"
#include "PlayerManager.h"

Copy link
Contributor

Choose a reason for hiding this comment

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

So is this blank line needed?

Copy link
Member Author

Choose a reason for hiding this comment

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

...

@psychonic
Copy link
Member Author

Thinking about it more, it shouldn't be necessary to add any further hooking. Even copying the event data in the "workaround" can be avoided, since you can use Event.FireToClient in an event prehook.

Pattern would be something like:

public Action Ev_SomeEventPre(Event event, const char[] name, bool dontBroadcast)
{
    for (int i = 1; i <= MaxClients; ++i)
    {
        if (IsClientBlah(client))
            event.FireToClient(i);
    }

    return Plugin_Handled;
}

@Kenzzer
Copy link
Member

Kenzzer commented May 9, 2016

So event.BroadcastDisabled = true; is no longer required?
If we do event.FireToClient(i); before, or return Plugin_Handled does it? I'm thinking about death message in tf2.

@psychonic
Copy link
Member Author

psychonic commented May 9, 2016

I don't fully understand the question, but this is a better example of the above, if you don't want to actually block the event serverside.

public Action Ev_SomeEventPre(Event event, const char[] name, bool dontBroadcast)
{
    for (int i = 1; i <= MaxClients; ++i)
    {
        if (IsClientBlah(client))
            event.FireToClient(i);
    }

    event.BroadcastDisabled = true;

    return Plugin_Continue;
}

When you only block broadcast, it stops the event from going to clients, but the server will still do any processing that it may have for the event (such as the log line for player_death). If you block the event itself, that gets blocked, too. I hope that clarifies things.

IClient *pClient = pPlayer->GetIClient();
if (!pClient)
{
return pContext->ThrowNativeError("Sending events to fakeclients is not supported on this game (client %d)", client);
Copy link
Member

Choose a reason for hiding this comment

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

There are super rare cases where a client can be connected but still have an invalid net channel (KAC/SMAC used to cause crashes in convar queries). Despite this, everything looks fine.

:shipit:

Copy link
Member Author

Choose a reason for hiding this comment

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

Pics or it didn't happen.

Copy link
Member

Choose a reason for hiding this comment

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

Ironically it was part of the code you refactored 😄

https://hg.alliedmods.net/releases/sourcemod-1.3/rev/82cfdef347cc

@psychonic psychonic merged commit 20c9815 into master May 13, 2016
@psychonic psychonic deleted the per-client-event-send branch June 4, 2016 13:28
@Kenzzer Kenzzer mentioned this pull request Jan 3, 2017
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.

None yet

4 participants