legobear154

I am not able to test this, but perhaps window_get_height() and window_get_width() will help you. Just get the width and height and use those values to find the edge of the screen. Hope that helps!

You are very welcome I didn't figure I had to ask for permission but I had seen people get angry before so I try and be safe than sorry. And I am glad it was as simple as that. I may not own GM Studio yet but I am glad to be able to help everyone I hope everything in your newest version works for everyone! It sucks that GM Studio free is so limited, but it is what it is I guess. Best if luck to you!

To anyone having troubles with Faucet Networking in GM Studio. I think I have a solution, I got the pong example working on localhost with GM Studio Free. Add an external name to all of the functions. The external names, as far as I know, are the same as the names of the functions themselves. I did that and It has solved all my problems. I am not able to export the modified extension because of me using the free version of GM Studio, but maybe someone will be able to. I hope this helps anyone that is having issues!

PS: I have not done extensive testing.

Edit: I remade the extension in extension maker with all of the external names added and it appears to work in Studio as well, and if I get medo's permission I will put it up for download

2DLuis' network programmer provided this possible explanation:

However if they are mixing them that's most likely the cause
Might be that SFML splits up the package into several ones (Which it does if WinSock can't send all of it in one) resulting in 39dll not being able to read the message properly
That's the only reason it wouldn't work as far as I'm aware (Considering it worked just fine with a local connection)

I have not used SFML or attempted a c++ server, but I do know that 39dll uses little-endian, so perhaps make sure your SFML server is using little-endian. If your endianness is not set to little-endian, the server will send data wrong. I found this on the SFML site http://www.sfml-dev....ork-packets.php (I didn't read the entire page so I am not sure if it will be of much help or not) but I hope this helps you.

Interesting. I'll have to check with spacechase0, the project's server programmer, to see which endianess he's using. While I hope endianess is the cause, I doubt that it is since the server works fine on localhost. 2DLuis' programmer's explanation seems more consistent with the data.

If by localhost your meaning client and server on the same computer, it would work because the computer would have the same endianess. And yes, I agree 2DLuis' explanation seems more constant. I just figured I would put my 2 cents in so you have more things to help. If you get the server working, would you mind explaining what you did to fix it? I am thinking on working with SFML to create a server for a couple of my projects seeing as it seems to be a very nice library. Anyways, I hope you find a solution!

I have not used SFML or attempted a c++ server, but I do know that 39dll uses little-endian, so perhaps make sure your SFML server is using little-endian. If your endianness is not set to little-endian, the server will send data wrong. I found this on the SFML site http://www.sfml-dev....ork-packets.php (I didn't read the entire page so I am not sure if it will be of much help or not) but I hope this helps you.