379 replies to this topic

[SapperEngineer]

Oh, that was kind of a doofy move on my part, I thought the loop just looped around doing nothing until the data arrived.

Perhaps I could do

while 1
{
if tcp_recieve(serversocket, 6)
{
do some stuff
break
}

do some more stuff

Also, the list does not come in multiple packets, it's 3 shorts, MSG_STARTBYTE, MSG_ASKFORLIST, and the length of the string in the packet. The client then splits the string by ":" and creates new players based on that, then the client sends MSG_READY_FOR_BROADCASTS and it can start receiving other player's x's and y's.

Thanks once more for the great library and fast responses.

[Medo42]

while 1
{
if tcp_recieve(serversocket, 6)
{
do some stuff
break
}

do some more stuff

Sorry, can't resist

while(!tcp_recieve(serversocket, 6)) {}
do some stuff
do some more stuff

[Zesterer]

Hey , Ive recently started making me 'Swan Song' to GameMaker - an online multiplayer MMOG RPG/Sandbox game. I hope you guys like it, and Im gonna use this, hope its good! XD

[Debels]

I been a 39dll user since a long time ago, I was told to try this other online extension, but at the moment im really confused about this in this aspect:

How do i send a message?

buffer_clear(0);
write_string(0,"Hi!.");
socket_send(socket);

How do i detect if i received a message?

//how do i detect?
read_string(0,10000)

How do i send a message?

buffer_clear(0);
write_string(0,"Hi this is a test to see if it works.");
socket_send(socket);

Can some one tell me whats wrong with this codes or tell me how

Edited by Debels, 23 May 2012 - 01:58 AM.

[Medo42]

I been a 39dll user since a long time ago, I was told to try this other online extension, but at the moment im really confused about this in this aspect:

How do i send a message?

buffer_clear(0);
write_string(0,"Hi!.");
socket_send(socket);

How do i detect if i received a message?

//how do i detect?
read_string(0,10000)

How do i send a message?

buffer_clear(0);
write_string(0,"Hi this is a test to see if it works.");
socket_send(socket);

Can some one tell me whats wrong with this codes or tell me how

Faucet Networking is not a drop-in replacement for 39dll and is different in several ways. For example, there is no default buffer 0, you have to create and destroy your own buffers. In order to reduce the writing, every socket has a built-in send buffer and a built-in receive buffer though, so you can just write directly to the socket.

write_string(socket, "Hi!");
socket_send(socket);

For receiving a string of 10000 bytes, you can use e.g.

if(tcp_receive(socket, 10000)) {
    message = read_string(socket, 10000);
    // ... do something with it
}

For more info, please read the help file.

[Debels]

Faucet Networking is not a drop-in replacement for 39dll and is different in several ways. For example, there is no default buffer 0, you have to create and destroy your own buffers. In order to reduce the writing, every socket has a built-in send buffer and a built-in receive buffer though, so you can just write directly to the socket.

write_string(socket, "Hi!");
socket_send(socket);

For receiving a string of 10000 bytes, you can use e.g.

if(tcp_receive(socket, 10000)) {
    message = read_string(socket, 10000);
    // ... do something with it
}

For more info, please read the help file.

I already readed the help file and i didn't find anything there that answers my questions (in the help file), how do i detect if there's a message?

I don't find this easy to learn and easy to use >.> (and I'm a fast learner!).

[Medo42]

Faucet does not support splitting tcp data into messages - this is something else I should add in the future, since it is a very very common task.

For now though, you have to split the stream of incoming data into messages yourself. One of the most common ways to frame messages is by prefixing them with a length. That means, to receive a message, you first get the length (e.g. 2 bytes, depending on the needs of your protocol) and then as many bytes as the message is long.

In order to do this, you can use tcp_receive(socket, size), which will return true if the requested ammount of data has been received, and false if it hasn't. Once it returns true, you can read the data from the socket's receive buffer. To make a simple (blocking) example:

while(!tcp_receive(socket, 2)) {}
msglen = read_ushort(socket);
while(!tcp_receive(socket, msglen)) {}
// read the message content from the buffer and process it

Of course, in an actual game you will not want to block in this way, but rather check for new messages every step and continue on once no more of them are available. Look at the Pong example program for that (Objects/Client/Begin Step).

Edited by Medo42, 23 May 2012 - 06:45 PM.

[sporefan]

thank you soo much i was getting so confused with 39dll

[creators124]

me to 39DLL:

Me no understand!
ME ANGRY!
ME TRY NO MORE ONLINE PLAYING!

me to Faucet Networking:

ooohhh! SHINY .GEX!
ME KNOW HOW TO DO THIS!
ME LIKE THIS!

please don't stop improving I love it!
and I did my first online test and it worked!
thank you for making online game making much more simpler than 39DLL did for me.
I still don't know what most of the terms mean, eg socket, but I'll look it up and figure out how to do what I want with it!

Edited by creators124, 03 June 2012 - 08:36 PM.

[Medo42]

me to 39DLL:
"Me no understand!
ME ANGRY!
ME TRY NO MORE ONLINE PLAYING! "
me to Faucet Networking:
"ooohhh!
ME KNOW HOW TO DO THIS!
ME LIKE THIS! "
please don't stop improving I love it!
and I did my first online test and it worked! :D
thank you for making online game making much more simpler than 39DLL did for me.
I still don't know what most of the terms mean, eg socket, but I'll look it up and figure out how to do what I want with it!

Thanks, and it is good to hear that you want to learn more. To successfully write online games, you need a firm understanding of TCP and/or UDP. Faucet Networking is intended to make it easy to apply that knowledge, but it can't replace it

[creators124]

me to 39DLL:
"Me no understand!
ME ANGRY!
ME TRY NO MORE ONLINE PLAYING! "
me to Faucet Networking:
"ooohhh!
ME KNOW HOW TO DO THIS!
ME LIKE THIS! "
please don't stop improving I love it!
and I did my first online test and it worked!
thank you for making online game making much more simpler than 39DLL did for me.
I still don't know what most of the terms mean, eg socket, but I'll look it up and figure out how to do what I want with it!

Thanks, and it is good to hear that you want to learn more. To successfully write online games, you need a firm understanding of TCP and/or UDP. Faucet Networking is intended to make it easy to apply that knowledge, but it can't replace it

I know it is not meant to replace it! (except my heart)
I'll look up TCP and UDP to understand them!
THANKS FOR THE TIP!
EDIT:
I made an extremely simple internet connection with object moving.
but when I try to connect from other routers it just keeps on giving me errors!
link to my file:
test1.zip
I'm also trying to integrate a chat system.
I need help!

Edited by creators124, 03 June 2012 - 10:29 PM.

[PrimuS]

Dem, using such a nice extension after several years of using 39dll feels kinda awkward. I love that you can directly manage the sendbuffer/receivebuffer thingy without necessary copying it to an additional buffer and/or clearing it every time you need something.

I've seen some example requests in dis thread, so i made a simple TCP networking system 'skeleton'. (GM8, ~38k) while trying to get used to FaucetNet.
It's somewhat commented, you can just use it and build your game around it. If you want to deal with my crappy code and a lack of optimization, of course.

Actually i just took the pong example and rewrote it for multiple players support, while combining it with some of my own stuff and comments. :3

Edited by PrimuS, 26 June 2012 - 02:18 PM.

[master link]

Hey,

I've been looking into this extension and it's looking really nice, but before I start any big projects with it, I feel the need to ask a few questions.

About how many players can one server hold simultaneously without it overloading? (This is assuming the game is programmed properly and doesn't send messages every step)
For my previous games, I used Simple Online Communication (SOC) but the server would crash when, give or take, 20 players were online. Also, the lag was horrifying with this dll, it rendered it nearly unplayable with a lot of people online.

How does Faucet Networking compare in this regard?

Thanks in advance!

[PoniesForPeace]

Hey,

I've been looking into this extension and it's looking really nice, but before I start any big projects with it, I feel the need to ask a few questions.

About how many players can one server hold simultaneously without it overloading? (This is assuming the game is programmed properly and doesn't send messages every step)
For my previous games, I used Simple Online Communication (SOC) but the server would crash when, give or take, 20 players were online. Also, the lag was horrifying with this dll, it rendered it nearly unplayable with a lot of people online.

How does Faucet Networking compare in this regard?

Thanks in advance!

I don't know, but if you looking for online engines you might want to give http2 dll a try.

[Medo42]

Hey,

I've been looking into this extension and it's looking really nice, but before I start any big projects with it, I feel the need to ask a few questions.

About how many players can one server hold simultaneously without it overloading? (This is assuming the game is programmed properly and doesn't send messages every step)
For my previous games, I used Simple Online Communication (SOC) but the server would crash when, give or take, 20 players were online. Also, the lag was horrifying with this dll, it rendered it nearly unplayable with a lot of people online.

How does Faucet Networking compare in this regard?

Thanks in advance!

This is not an easy question because I don't know SOC, and I don't know how you used it either. FN should definitely not cause crashes or lag with 20 players under normal circumstances.

If you try, you can definitely provoke an "out of memory" crash, e.g. by telling it to receive more data at once than you have free RAM. As for lag, that should depend entirely on your game code. I freely admit that FN is not the most efficient library possible, but I'd be surprised if that was slowing down an actual game in any way (as opposed to a synthetic benchmark). Sending / receiving 20 UDP datagrams or TCP packets per step should be no problem at all. There are often Gang Garrison 2 servers with over 20 people playing without undue lag (just played on one with 26), and GG2 does send a TCP packet to each player in each step.

For the upper bounds, I just tested and managed to send around 90000 UDP datagrams (256 bytes each) per second over loopback. That completely maxes out one CPU core. With TCP the load was around 30% for the same packet/data rate, so this is easier on the CPU for some reason.

Finally, if you do have performance or crashing problems, please report them and I'll try to do something about it. I hope this answers your question

[Drara]

Nice, nice, nice. This looks like a pretty promising alternative to the 39Dll. You say you have made this because 39Dll was not good enough. I wonder whether you woukd tend to say (or have tested) whether this has also better performance than 39Dll?

[Medo42]

Nice, nice, nice. This looks like a pretty promising alternative to the 39Dll. You say you have made this because 39Dll was not good enough. I wonder whether you woukd tend to say (or have tested) whether this has also better performance than 39Dll?

No, I wouldn't.

Neither 39dll nor FN should create any performance issues in real-world use, so comparing raw performance is not very useful imo. If you do want to know my impressions: Some "raw" operations (sending/receiving, without any processing) cause less CPU load in 39dll by a factor of ~2. On the other hand, you tend to need more GML code around 39dll functions, so in actual use FN might have better performance again, but that's speculation. Another point to consider is that FN transfers data in a background thread if it can't be sent/received immediately, which means that data is sent as soon as possible. With 39dll, if a nonblocking send fails, you will typically wait for the next step until you try sending again.

In short, there is no simple answer and I can almost guarantee you that it is irrelevant for your game anyway

[Drara]

No, I wouldn't.

Neither 39dll nor FN should create any performance issues in real-world use, so comparing raw performance is not very useful imo. If you do want to know my impressions: Some "raw" operations (sending/receiving, without any processing) cause less CPU load in 39dll by a factor of ~2. On the other hand, you tend to need more GML code around 39dll functions, so in actual use FN might have better performance again, but that's speculation. Another point to consider is that FN transfers data in a background thread if it can't be sent/received immediately, which means that data is sent as soon as possible. With 39dll, if a nonblocking send fails, you will typically wait for the next step until you try sending again.

In short, there is no simple answer and I can almost guarantee you that it is irrelevant for your game anyway

Hmm, well I'll find out whetehr yous ay the truth or not some day soon xD
The problem is that I'm working on the probably most ressoruce-intersive genre of all when it comes to multiplayer: A full size RTS (working on about 2-3 years on it). I'm trying to optimize the (single player) engine code as good as I can, enabling on my 3.4 Ghz quadcore a few hundred of active units in the game at the same time (even if not all visible on the screen ofcourse). I haven't thought much about multiplayer though. Yet I fear that there will have to be transfered relative huge ammouns of data each step to mentain maybe ~8 computers synchronized, wouldn't it?

[PrimuS]

You don't need loads of data transfer for an RTS, actually. It's way easier to almost entirely predict unit movements clientside, cause you don't really need precise sync like in FPS games.
Plus, you only need that for 8 players.

[master link]

Thanks for the surprisingly fast reply, Medo!
Very helpful stuff, this is going to be interesting to work with.