onConnectRequest conflicting client mods

[Tezuni 2.0]

Code: [Select]

function GameConnection::onConnectRequest(%client, %ip, %lan, %net, %prefix, %suffix, %arg5, %rtb, %arg7, %gamemode, %arg9, %arg10, %arg11, %arg12, %arg13, %arg14, %arg15)

I use that function to check against a user's client component for my gamemode.  If they don't have the current version, they get rejected and served a popup with the download link.  It seems like other client mods which also use this function interfere.  People end up having to delete other client mods which use this function just so it will recognize they have my client mod downloaded.  Any way to fix this?

[Ad Bot]

[Greek2me]

Use a handshake system.

[Xalos]

If everyone used a cooperative system, where one argument were dedicated to client handshakes, then they'd all work.
I.E. you take %arg11 and append your stuff with %arg11 = trim(%arg11 TAB "TEZ Version_Number");
And then you check for a field that starts with your identifier when they connect.

The problem is that for this to work at all, we have to all agree on a standardized system for how it should work.

[Ipquarx]

Use a handshake system.

this

[boodals 2]

An attempt was made to standardize this, http://forum.blockland.us/index.php?topic=271036.0 however it didn't seem to go anywhere.

I had some issues with various mods not giving the function enough parameters, causing incompatibilities, namely DRPG. I had to overwrite (and fix) its function to fix it, but there are still plenty of mods that are breaking compatibility. If we do use some sort of tab separated convention, then we should use an early parameter so that its less likely for a mod to break it. If too many mods start to use it, perhaps use multiple arguments and just append them together.


Someone needs to make a support script which unifies all this and makes it easier for newer coders, maybe as part of Support_Updater since that seems to be fairly reliable and popular. Really, we need a mega-mod like RTB.

[jes00]

An attempt was made to standardize this, http://forum.blockland.us/index.php?topic=271036.0 however it didn't seem to go anywhere.

I had some issues with various mods not giving the function enough parameters, causing incompatibilities, namely DRPG. I had to overwrite (and fix) its function to fix it, but there are still plenty of mods that are breaking compatibility. If we do use some sort of tab separated convention, then we should use an early parameter so that its less likely for a mod to break it. If too many mods start to use it, perhaps use multiple arguments and just append them together.


Someone needs to make a support script which unifies all this and makes it easier for newer coders, maybe as part of Support_Updater since that seems to be fairly reliable and popular. Really, we need a mega-mod like RTB.

Better to just

Use a handshake system.

[boodals 2]

Better to just

There are times where you cant use a handshake. In my RPG, I'm using a custom player shape based off m.dts so that I can modify the animations. This would typically crash anyone on load, so I included the shape files in the client. Anyone without the client would crash if they tried to load, so I have to reject them before they join. Blame TGE, I just work around it.

[Val]

The provided setConnectArgs/onConnectRequest is a very nice way to check for compatibility in clients before accepting a connection. Someone should lead a standardization effort because IMO, no one should have to settle with a handshake method for something that's designed for this purpose.

[Zeblote]

All it really needs is a wrapper script that exposes two methods so you can use it like this:

Code: better connect args (23 lines) package clientside {    //Or anything else that is called when a connection is going to be made    function GameConnection::collectConnectArgs(%this)     {        parent::collectConnectArgs(%this);         ServerConnection.setConnectAr g("rtbversion", "4.05");         ServerConnection.setConnectAr g("var", "value");     } }; package serverside {    //Or whenever your script needs to read the args    function GameConnection::onParsedArgs(%this)     {        parent::onParsedArgs(%this);        if(%this.getConnectArg("rtbversion") !$= "4.05")            %this.delete();     } };

The args could then be serialized as json or some custom format by this script and sent as a single connect arg

[Dannu]

Use the argument in delete to give the client a reason as to why they were rejected.

[Tezuni 2.0]

Use the argument in delete to give the client a reason as to why they were rejected.

Yeah I already give them the download link there. 

So does anyone have a handshake system example?  I know slayer uses it, but that is a lot of code to sift through.

[Dannu]

Slayer's system is actually very logically built up. Look in client folder for appropriately named folders. I'd pull up examples from my folders, but I'm on a phone.

[$trinick]

Roughly:

Server.cs:

Code: [Select]

package handshake {
    function GameConnection::autoAdminCheck(%client) {
        commandToClient(%client, 'handshake');
        %client.handshakeSched = %client.schedule(1000, disconnect, "Handshake Failed");
        parent::autoAdminCheck(%client);
    }
};
activatePackage(handshake);

function serverCmdHandshake(%client) {
    cancel(%client.handshakeSched);
}

Client.cs:

Code: [Select]

function clientCmdHandshake() {
    commandToServer('handshake');
}

Be sure to rename everything to more specific stuff if you're going to copy and paste, but that should tell you the basic logic of a handshake.

[Tezuni 2.0]

Roughly:

Server.cs:

Code: [Select]

package handshake {
    function GameConnection::autoAdminCheck(%client) {
        commandToClient(%client, 'handshake');
        %client.handshakeSched = %client.schedule(1000, disconnect, "Handshake Failed");
        parent::autoAdminCheck(%client);
    }
};
activatePackage(handshake);

function serverCmdHandshake(%client) {
    cancel(%client.handshakeSched);
}

Client.cs:

Code: [Select]

function clientCmdHandshake() {
    commandToServer('handshake');
}

Be sure to rename everything to more specific stuff if you're going to copy and paste, but that should tell you the basic logic of a handshake.

Amazing, adapted it to missionstartphase3ack, to just stop them from loading in without a disconnect.  Works like a charm with a messageboxOK.  Thanks.

[Headcrab Zombie]

Amazing, adapted it to missionstartphase3ack, to just stop them from loading in without a disconnect. 

Wait, what?
There must be some drawback that you (and I) aren't seeing with this method. Because preventing someone from joining without a disconnect message was the whole point of dealing with the problems of using onConnectRequest. If there was a better alternative, someone would had to have found it by now