Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[notarctic]

its pretty annoying zipping the plugin every time I wanna test it

ikr?

[ajf]

its pretty annoying zipping the plugin every time I wanna test it

use 7zip

[iLegend]

it's okay i found out winrar updates the temp file if it doesn't match with the archive one.

anyway is there any way to log a variable or something. for debugging purposes.

[Danikah]

Question about networking in general:

So, these buffers are just numbers sent to clients or the server. And to actually get a working stuff out of it, I should check the buffer we just received, do the actions related to that buffer, and destroy the buffer, right?
But then how do we check for more data? Like, if a player dies, his client sends his death to the server with the buffer '1'. The server gets it, but how can it send the data forward to all clients if all he got that a character died out of the 32, maybe?

[ajf]

Question about networking in general:

So, these buffers are just numbers sent to clients or the server. And to actually get a working stuff out of it, I should check the buffer we just received, do the actions related to that buffer, and destroy the buffer, right?
But then how do we check for more data? Like, if a player dies, his client sends his death to the server with the buffer '1'. The server gets it, but how can it send the data forward to all clients if all he got that a character died out of the 32, maybe?

PluginPacketGetPlayer tells you from which client you got that buffer

[Danikah]

Question about networking in general:

So, these buffers are just numbers sent to clients or the server. And to actually get a working stuff out of it, I should check the buffer we just received, do the actions related to that buffer, and destroy the buffer, right?
But then how do we check for more data? Like, if a player dies, his client sends his death to the server with the buffer '1'. The server gets it, but how can it send the data forward to all clients if all he got that a character died out of the 32, maybe?

PluginPacketGetPlayer tells you from which client you got that buffer

Well, that neither helped nor answered my question.

EDIT: I think I got it.

I could do:

Code: [Select]

PluginPacketSend(packetID, 1);
PluginPacketSend(packetID, PluginPacketGetPlayer);
PluginPacketSend(packetID, 0);
For example as a server to send what data we received from the client when his player died to other clients. Then I just have to read these in order to interpret what happened as a client, like this:

Code: [Select]

if PluginPacketGetBuffer(packetID) == 1 //if a player death happened
{
    playerid = PluginPacketGetBuffer(packetID);
    gib = PluginPacketGetBuffer(packetID);
}No?
I have a feeling it's no. Never understood networking, every 39dll networking tutorial (or just networking tutorials in general) I have ever read so far have seemed ungraspable or under-explained to me.

[ajf]

Question about networking in general:

So, these buffers are just numbers sent to clients or the server. And to actually get a working stuff out of it, I should check the buffer we just received, do the actions related to that buffer, and destroy the buffer, right?
But then how do we check for more data? Like, if a player dies, his client sends his death to the server with the buffer '1'. The server gets it, but how can it send the data forward to all clients if all he got that a character died out of the 32, maybe?

PluginPacketGetPlayer tells you from which client you got that buffer

Well, that neither helped nor answered my question.

EDIT: I think I got it.

I could do:

Code: [Select]

PluginPacketSend(packetID, 1);
PluginPacketSend(packetID, PluginPacketGetPlayer);
PluginPacketSend(packetID, 0);
For example as a server to send what data we received from the client when his player died to other clients. Then I just have to read these in order to interpret what happened as a client, like this:

Code: [Select]

if PluginPacketGetBuffer(packetID) == 1 //if a player death happened
{
    playerid = PluginPacketGetBuffer(packetID);
    gib = PluginPacketGetBuffer(packetID);
}No?
I have a feeling it's no. Never understood networking, every 39dll networking tutorial (or just networking tutorials in general) I have ever read so far have seemed ungraspable or under-explained to me.

...No, you really didn't get it.

A faucet net buffer is a set of bytes. If I do this:

Code: [Select]

var buf;
buf = buffer_create();
I get a fresh buffer, and buf will contain the buffer's ID. The buffer is empty. To add a byte to that buffer, I'll use write_ubyte:

Code: [Select]

var buf;
buf = buffer_create();
write_ubyte(buf, 74);
The "u" in "ubyte" means an unsigned byte, that is, no positive or negative sign. An unsigned byte can be any number from 0 to 255. A signed byte would be a number from -128 to 127. So, now our buffer contains that byte we wrote to it. We're on the server, so let's send that in a packet to everyone on the server:

Code: [Select]

var buf;
buf = buffer_create();
write_ubyte(buf, 74);
PluginPacketSend(packetID, buf);
packetID is the value of argument1 when plugin.gml is executed, it's the ID given by GG2 to a plugin so that GG2 knows which plugin it is when it tries to send packets. That buffer can now be destroyed if we want, since its value has been copied by GG2 and sent to all of our clients:

Code: [Select]

var buf;
buf = buffer_create();
write_ubyte(buf, 74);
PluginPacketSend(packetID, buf);
buffer_destroy(buf);
Now on the client we want to see if we've got a new message from the server yet. So we'll check if PluginPacketGetBuffer returns -1 or not:

Code: [Select]

if (PluginPacketGetBuffer(packetID) != -1)
Then we can try getting the buffer itself:

Code: [Select]

if (PluginPacketGetBuffer(packetID) != -1) {
    var recvBuf;
    recvBuf = PluginPacketGetBuffer(packetID);
}
We're able to call PluginPacketGetBuffer twice because it only gets you the first buffer in the queue, it doesn't remove it. Now that we have our buffer, let's read a byte from it:

Code: [Select]

if (PluginPacketGetBuffer(packetID) != -1) {
    var recvBuf;
    recvBuf = PluginPacketGetBuffer(packetID);
    var someValue;
    someValue = read_ubyte(recvBuf);
}
someValue should now contain the value of the first byte in the buffer. If this was the packet we sent earlier from the server, it should be 74. Let's say that 74 has some special significance and that we want to respond to it. We could do that like this:

Code: [Select]

if (PluginPacketGetBuffer(packetID) != -1) {
    var recvBuf;
    recvBuf = PluginPacketGetBuffer(packetID);
    var someValue;
    someValue = read_ubyte(recvBuf);
    if (someValue == 74) {
        var sendBuf;
        sendBuf = buffer_create();
        write_ubyte(sendBuf, 31);
        PluginPacketSend(packetID, sendBuf);
        buffer_destroy(sendBuf);
    }
}
This means that if the client receives a packet with its first byte being 74, it'll send a packet back to the server with the first byte being 31. However, at present, this code will just look at the first packet it received and not get rid of it. This means that if we run that code later, it'll just look at the same packet again. So, we need to discard that packet from the queue:

Code: [Select]

if (PluginPacketGetBuffer(packetID) != -1) {
    var recvBuf;
    recvBuf = PluginPacketGetBuffer(packetID);
    var someValue;
    someValue = read_ubyte(recvBuf);
    if (someValue == 74) {
        var sendBuf;
        sendBuf = buffer_create();
        write_ubyte(sendBuf, 31);
        PluginPacketSend(packetID, sendBuf);
        buffer_destroy(sendBuf);
    }
    PluginPacketPop(packetID);
}
Note how I didn't use buffer_destroy here. We don't need to, because PluginPacketPop does that for us. As an additional improvement, if we're running this code every step, it'd only handle one packet at a time, which probably isn't ideal. Let's use a while loop, so we'll look at each packet one by one until there are none left:

Code: [Select]

while (PluginPacketGetBuffer(packetID) != -1) {
    var recvBuf;
    recvBuf = PluginPacketGetBuffer(packetID);
    var someValue;
    someValue = read_ubyte(recvBuf);
    if (someValue == 74) {
        var sendBuf;
        sendBuf = buffer_create();
        write_ubyte(sendBuf, 31);
        PluginPacketSend(packetID, sendBuf);
        buffer_destroy(sendBuf);
    }
    PluginPacketPop(packetID);
}
So, our clients can now handle received packets, and if a packet begins with an unsigned byte of value 74, it will send a packet back to the server with the value 31 as the first byte. Now we just need our server to be able to respond to packets too, so here's code for the server to do that:

Code: [Select]

while (PluginPacketGetBuffer(packetID) != -1) {
    var recvBuf;
    recvBuf = PluginPacketGetBuffer(packetID);
    var someValue;
    someValue = read_ubyte(recvBuf);
    if (someValue == 31) {
        // We got a 31 packet!
    }
    PluginPacketPop(packetID);
}
But wait. What if we want to know which client sent us this packet? How do we know who? Well, for that you'll use PluginPacketGetPlayer, which complements PluginPacketGetBuffer and gets you the Player object for the client that sent us this packet:

Code: [Select]

while (PluginPacketGetBuffer(packetID) != -1) {
    var recvBuf;
    recvBuf = PluginPacketGetBuffer(packetID);
    var someValue;
    someValue = read_ubyte(recvBuf);
    if (someValue == 31) {
        // We got a 31 packet!
        var player;
        player = PluginPacketGetPlayer(packetId);
        show_message(player.name + " sent us a 34 packet!");
    }
    PluginPacketPop(packetID);
}
...and that should answer your questions, hopefully. I should note that PluginPacketGetPlayer doesn't work at all on the client because the client will only ever receive packets from the server. Its use is for the server to know which client sent it a packet.

[Danikah]

Ooooooh!

Now I understand! Thank you, ajf.
I might not use it in the near future, but at least I have some understanding of it now, or rather, the logic of it.
I could deduce most of the things I want from it. Thank you again!

[ajf]

Ooooooh!

Now I understand! Thank you, ajf.
I might not use it in the near future, but at least I have some understanding of it now, or rather, the logic of it.
I could deduce most of the things I want from it. Thank you again!

Glad to help! I hope this might help others, too, considering how minimal the documentation in the OP is, which assumes an understanding of Faucet Net buffers already.

[ZaSpai]

Question: if a server host uses an unapproved/unauthorized SSP run from ServerPluginsDebug, is a client (excluding a multiclient from the same machine) able to download that unauthorized SSP from the host, or will the attempt to join fail?

[notarctic]

its simple, it wont work. iirc the message you get from loading from using debug describes everything. even if the client manages to join, depending on what you're doing, the client will receive unexpected data or desync or both

[ZaSpai]

its simple, it wont work. iirc the message you get from loading from using debug describes everything. even if the client manages to join, depending on what you're doing, the client will receive unexpected data or desync or both

So essentially the client will need to have the SSP in question in their ServerPluginsDebug as well I probably meant ServerPluginsCache or something nvm it was ServerPluginsDebug for anything to work

Coolies

[ajf]

its simple, it wont work. iirc the message you get from loading from using debug describes everything. even if the client manages to join, depending on what you're doing, the client will receive unexpected data or desync or both

So essentially the client will need to have the SSP in question in their ServerPluginsDebug as well I probably meant ServerPluginsCache or something nvm it was ServerPluginsDebug for anything to work

Coolies

Right.

When the server starts, it finds the MD5 hash of each plugin and generates a new list containing that info, e.g. can_you_feel_the_sunshine@ca77b909b9fdf6655103dcdada4032b0,buffpyro@96fb7f3f779948f40935b89fc3b56399.

The client is sent that list when it connects. It'll then look in three sources, in order:

• ServerPluginsDebug - Looking for <pluginname>.zip
• ServerPluginsCache - Looking for <pluginname>@<md5>
• http://ganggarrison.com/plugins/<pluginname>@<md5>.zip

If your plugin in ServerPluginsDebug happened to have the same name as an actual plugin, and happened to have the same MD5 as an actual version if that plugin (which is unlikely unless it actually is that version of that plugin), then your client would be able to download it from the server fine. Most likely, however, that won't be the case, and it'll bring up an error saying it couldn't find the plugin on the server, unless you had it in ServerPluginsDebug or ServerPluginsCache.

[ajf]

Updated to note v2.7.3's PluginEnvironments.

A summary of the changes can be found here:

btw what changes with the 'plugins run in own environment'?

Ah, I should update the plugin FAQ about that. Basically, we spawn a new PluginEnvironment instance (it's a persistent, invisible object) and do with(env) { execute_file(...); } so any variables you forget to define will end up on that object instead of on GameServer, Client or the weird non-object game_init runs in.

It also means you can now just type 'packetID' and 'directory' to get the packet ID or directory, respectively, since we put those as variables on the object for you. There's also isLocalPlugin and isServerSentPlugin for checking what mode the plugin's running in.

This also gives you a nice place to stick your variables. For my latest plugin, I did this:

globalvar myplugin;
myplugin = id; // this PluginEnvironment object

blah = 3;
foobar = "stuff";

...

if (myplugin.blah) {
    ...
}

[ajf]

The OP now mentions where to find Faucet Networking documentation, by arctic's request. Which is a good idea, since it's not immediately obvious that the docs are in PDF form in the release ZIPs.