March 04, 2024, 01:30:12 pm

The Gang Garrison 2 Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

NOTICE: Wondering where all the forums have gone?

Join the community Discord server!

Pages: 1 [2]

Author Topic: Server-sent plugins FAQ  (Read 52049 times)

notarctic

  • just arctic, what gives?
  • ******
  • Karma: 8
  • Offline Offline
  • Posts: 4888
  • 👎👀 bad aim ba̷̶ ԁ aIm 👎 thats❌ some bad 👎👎aim
    • arcticland
Re: Server-sent plugins FAQ
« Reply #15 on: August 31, 2013, 10:03:42 pm »

its pretty annoying zipping the plugin every time I wanna test it :(
ikr?
Logged
[1:37:51 PM] Derpduck: arctic u need to quote ppl that make shit posts in case they edit them
[4:20:15 PM] Rubeus Hashgrid: i cant discover anything fuck you imageshack

ajf

  • (Ex-?)Developer and forum/web admin
  • *****
  • Karma: 7
  • Offline Offline
  • Posts: 3421
  • she's never quite as dead as you think
Re: Server-sent plugins FAQ
« Reply #16 on: August 31, 2013, 10:07:26 pm »

its pretty annoying zipping the plugin every time I wanna test it :(
use 7zip
Logged
did you know that spinning stars work like this???

I've seen things you people wouldn't believe. execute_strings on fire off the shoulder of Overmars. I watched object-beams glitter in the dark near the room_goto_fix. All those moments will be lost in time, like tears...in...rain. Time to die.

iLegend

  • 2013 Haxxy Award Winner
  • *****
  • Karma: 0
  • Offline Offline
  • Posts: 869
  • Force is always the answer.
    • Mah Resume
Re: Server-sent plugins FAQ
« Reply #17 on: August 31, 2013, 10:12:58 pm »

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.
Logged
<SecretMan> do i put BotAim.gml in plugins folder?
i hear los angeles is pretty good for casual sex with minors

Danikah

  • Guest
Re: Server-sent plugins FAQ
« Reply #18 on: January 29, 2014, 03:20:09 pm »

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?
Logged

ajf

  • (Ex-?)Developer and forum/web admin
  • *****
  • Karma: 7
  • Offline Offline
  • Posts: 3421
  • she's never quite as dead as you think
Re: Server-sent plugins FAQ
« Reply #19 on: January 29, 2014, 07:15:01 pm »

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
Logged
did you know that spinning stars work like this???

I've seen things you people wouldn't believe. execute_strings on fire off the shoulder of Overmars. I watched object-beams glitter in the dark near the room_goto_fix. All those moments will be lost in time, like tears...in...rain. Time to die.

Danikah

  • Guest
Re: Server-sent plugins FAQ
« Reply #20 on: January 30, 2014, 07:58:24 am »

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.
« Last Edit: January 30, 2014, 08:35:01 am by Cerapter »
Logged

ajf

  • (Ex-?)Developer and forum/web admin
  • *****
  • Karma: 7
  • Offline Offline
  • Posts: 3421
  • she's never quite as dead as you think
Re: Server-sent plugins FAQ
« Reply #21 on: January 30, 2014, 03:13:14 pm »

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.
« Last Edit: January 30, 2014, 03:14:31 pm by ajf »
Logged
did you know that spinning stars work like this???

I've seen things you people wouldn't believe. execute_strings on fire off the shoulder of Overmars. I watched object-beams glitter in the dark near the room_goto_fix. All those moments will be lost in time, like tears...in...rain. Time to die.

Danikah

  • Guest
Re: Server-sent plugins FAQ
« Reply #22 on: January 30, 2014, 04:10:08 pm »

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!
Logged

ajf

  • (Ex-?)Developer and forum/web admin
  • *****
  • Karma: 7
  • Offline Offline
  • Posts: 3421
  • she's never quite as dead as you think
Re: Server-sent plugins FAQ
« Reply #23 on: January 30, 2014, 06:10:07 pm »

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.
Logged
did you know that spinning stars work like this???

I've seen things you people wouldn't believe. execute_strings on fire off the shoulder of Overmars. I watched object-beams glitter in the dark near the room_goto_fix. All those moments will be lost in time, like tears...in...rain. Time to die.

ZaSpai

  • Ray Bann's Minion
  • *
  • Karma: 14
  • Offline Offline
  • Posts: 2175
  • "Eeh?! We're just allies!"
Re: Server-sent plugins FAQ
« Reply #24 on: February 26, 2014, 08:10:33 pm »

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?
Logged
Right behind you when you most expect it | classicwell master race

notarctic

  • just arctic, what gives?
  • ******
  • Karma: 8
  • Offline Offline
  • Posts: 4888
  • 👎👀 bad aim ba̷̶ ԁ aIm 👎 thats❌ some bad 👎👎aim
    • arcticland
Re: Server-sent plugins FAQ
« Reply #25 on: February 26, 2014, 10:40:18 pm »

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
Logged
[1:37:51 PM] Derpduck: arctic u need to quote ppl that make shit posts in case they edit them
[4:20:15 PM] Rubeus Hashgrid: i cant discover anything fuck you imageshack

ZaSpai

  • Ray Bann's Minion
  • *
  • Karma: 14
  • Offline Offline
  • Posts: 2175
  • "Eeh?! We're just allies!"
Re: Server-sent plugins FAQ
« Reply #26 on: February 26, 2014, 10:43:33 pm »

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
« Last Edit: February 27, 2014, 02:59:14 am by ZaSpai »
Logged
Right behind you when you most expect it | classicwell master race

ajf

  • (Ex-?)Developer and forum/web admin
  • *****
  • Karma: 7
  • Offline Offline
  • Posts: 3421
  • she's never quite as dead as you think
Re: Server-sent plugins FAQ
« Reply #27 on: February 27, 2014, 07:15:46 am »

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:

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.
« Last Edit: February 27, 2014, 07:17:18 am by ajf »
Logged
did you know that spinning stars work like this???

I've seen things you people wouldn't believe. execute_strings on fire off the shoulder of Overmars. I watched object-beams glitter in the dark near the room_goto_fix. All those moments will be lost in time, like tears...in...rain. Time to die.

ajf

  • (Ex-?)Developer and forum/web admin
  • *****
  • Karma: 7
  • Offline Offline
  • Posts: 3421
  • she's never quite as dead as you think
Re: Server-sent plugins FAQ
« Reply #28 on: July 13, 2014, 06:31:31 am »

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) {
    ...
}

Logged
did you know that spinning stars work like this???

I've seen things you people wouldn't believe. execute_strings on fire off the shoulder of Overmars. I watched object-beams glitter in the dark near the room_goto_fix. All those moments will be lost in time, like tears...in...rain. Time to die.

ajf

  • (Ex-?)Developer and forum/web admin
  • *****
  • Karma: 7
  • Offline Offline
  • Posts: 3421
  • she's never quite as dead as you think
Re: Server-sent plugins FAQ
« Reply #29 on: July 29, 2014, 08:40:21 pm »

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.
Logged
did you know that spinning stars work like this???

I've seen things you people wouldn't believe. execute_strings on fire off the shoulder of Overmars. I watched object-beams glitter in the dark near the room_goto_fix. All those moments will be lost in time, like tears...in...rain. Time to die.
Pages: 1 [2]
 

Page created in 0.032 seconds with 36 queries.