Problems with networking.

[full latch]

I'm trying to get online multiplayer to work, but there always seems to be a problem. I made a post before about network not working on gx games and that was resolved thanks to TabularElf. But now I have more problems.

First, nothing worked when I was using network_create_server with network_type_ws. But that was an easy fix because all I had to do was use network_create_server_raw and the other functions that go with it.
Then I had to figure out the stuff with the ip/url, and when I got that right I was able to connect to different devices... accept when I tried it on gx games. It always gave an error on the client side saying something like "Can't connect through a insecure web socket" or something so I assumed it was because I used the "raw" functions.
Everything still worked locally until something happened (I don't really know what I did to make it stop working). One day I was testing all the network stuff, and it wouldn't work right. It made the connection just fine and there were no errors, but in the console it said something like "Receiving network data, but gms unpack doesn't like it! dropping!".

What is happening?!?

Also I did publish the game (it's not finished) so if you want to try it out you can. (its still fun even without online support)
https://gx.games/games/2ggal7/mini-splatoon
It's a 2d version of Splatoon.

[full latch]

I could really use some help. I have no idea how to fix this.

[uneven wadi]

I would like to help, but honestly i dont really understand the issue.

could you supply some code you're using, what console logs say things are doing, etc. because as is i'd basically just be shooting into the dark

[paper robin]

It's uh, been a lil while

Hard to say, I don't mess with websockets enough to fully give a proper answer

[uneven wadi]

really the best place to start looking would be to find out what is causing Receiving network data, but gms unpack doesn't like it! dropping!
Additionally if this output is directly from GM, this really needs a better debug output and I'd back feature request for this to be better improved as to what caused the issue.

[paper robin]

I will say

Can't connect through a insecure web socket

On websites with SSL (basically the lock icon), you need to have your server be able to handle/terminate a secure websocket packet

Since they're encrypted

This is where ngnix can handle it for you

[uneven wadi]

it's a gx game, thought those all were forced as secure

i guess the use of raw gives the ability to break out of that

[paper robin]

I'm talking about where the server is hosted

[uneven wadi]

oh right

[paper robin]

The server also has to behind SSL

And the server also needs to terminate the connection

It works fine on localhost because well, there is no SSL out of the box

[full latch]

this is the server console:
Client(1) Connected: ::ffff:192.168.86.243
Socket(1): WebSocket handshake completed, switching to WS protocol.
Client(2) Connected: ::ffff:192.168.86.243

[paper robin]

Yeah that doesn't give us anything

[full latch]

Ok maybe I should just try the normal network function again instead of the raw ones.

Is it even worth it to try to use WebSockets?

[paper robin]

There's plenty of worth yeah

I just think it's good to try and slowly take a step back and get it working again

...Do you have source control by any chance?

[full latch]

No.

What exactly is that for?

[paper robin]

A way of keeping backups of your project/code (small or big)

Involving only changes that you've made

• on the cloud

• you can reverse to any point in time of said changes (that were comitted)

[full latch]

I do duplicate my project every so often.

[paper robin]

Yeah that works too

[full latch]

I can look at the code in my older projects.

[paper robin]

Source control is a lot easier since you don't need to duplicate anything

You can just, roll back

Or make a separate branch and experiment over there

https://www.youtube.com/watch?v=UZG-P68xWio

But that's not important right now

Try getting your localhost setup working first