Search the Community
Showing results for tags 'networking'.
Found 9 results
-
I loaded up the multiplayer example but it did not show any signs of being online. How do you use it ? There was no chat on and no signs of being online just a blank walled off room that has an FPS player to walk around and that is it. I was hoping to see a working small example template of a multiplayer game in action just to see how it is done. Instead all there is is a blank FPS walk around room !
-
is there any multiplayer online example yet ?
-
hi everyone ! i am trying connect my game on my C# server , but when i am try connect nothing happens ... and i am try my c# server with C# client , and both are working ... someone know what is the problem ? -
I've spent the last few days creating a simple self contained server browser. It will list all the servers of a specific game, allow the user to select a server and send a callback with the selected info. Requirements: The script from this topic placed in a file here: Scripts/Functions/eventqueuemanager.lua The Script: A simple example: It will create a server and open a server browser window. + Starts the move mode, click to exit it. X closes the window. import("Scripts/Functions/eventqueuemanager.lua") import("Scripts/serverbrowser.lua") local window = Window:Create() local context = Context:Create(window) local server = Server:Create() System:Print("Server1 publish::" .. tostring(server:Publish("Example Temp Test Server", "Testing population of server list from masterserver "))) server:Release() function test(ip,port,close) -- callback function System:Print("Callback") System:Print(ip) System:Print(tostring((close == true) and "close" or "")) end local serverbrowser = serverBrowser("Example Temp Test Server",context,0,0) -- create the serverbrowser serverbrowser:SetCallback(test) -- set callback -- do stuff while true do if window:Closed() then return end if window:KeyHit(Key.Escape) then return end Time:Update() context:SetColor(0,0,0,0) -- need to clear alpha!! or the gui will stay on screen!! context:Clear() EventQueueManager:Update() context:Sync() end serverbrowser:ClearCallback() -- remove callback serverbrowser:Release() -- release everything The server browser will obey the limits of your window. If any part of it is not on screen, it will be pushed back onto it. Edits: -2017-8-24: -Added the ability to directly connect to a ip and port. -Moved the code to put the window into a function and check on server browser creation. -2017-8-25: -Added the abilitiy to automatically resize to fit inside the bounds of the current context
-
The server list seems to fail when attempting to register multiple servers from the same server but different port. Also, it will fail to register if the name is just one word. Example: server = Server:Create() System:Print("Server1 publish::" .. tostring(server:Publish("Einlanders server stub", "Testing population of server list from masterserver "))) server2 = Server:Create(27015) System:Print("Server2 publish::" .. tostring(server2:Publish("Einlanders server stub", "Testing population of server list from masterserver 2"))) client = Client:Create() local servercount = client:CountServers("Einlanders server stub") System:Print("Server Count::" .. tostring(servercount)) for i=0, servercount-1 do remoteServerData = client:GetServer(i) System:Print("Server Name::" .. remoteServerData.address .."#### Description" .. remoteServerData.description) end The Output: Server1 publish::true ERROR Server2 publish::false Server Count::1 Server Name::xxx.xxx.xxx.xxx#### DescriptionTesting pupulation of server list from masterserver
-
When I use Server:Broadcast it does not send the message, it just sends nil. I am sending text to all the clients.
-
Hi! It has been a while. Here's an update on my networking library EvayrNet which is available for C++ users of Leadwerks: While implementing it into the test project in Leadwerks, I saw that the use case had some flaws which made it really hard to debug what's going on. I figured that I should be spending some time on fixing some flaws. After a few weeks I came up with the following upgrades: Debugging class Simulation mode More debugging information available Here's some detailed explanation: Debugging class I was using a lot of "printf" before which made it hard to: Find out where it's being called Disable whenever I don't need it anymore This is when I decided to make a debugging class. I replaced the printf with a custom Print function which allows you to do the same as before - except you can disable any kind of printing whenever you want (like during release builds). I also realized that capturing data is a pretty cool feature to have, which makes it easier to visualize the data you want to debug. For that I created a SaveText function which accepts a string and a filename as arguments so you can separate data like "Pings per interval", "Bytes sent per second", etc. Here is an example what you can do with it: Simulation mode This is an interesting one that I just had to implement. A connection cannot always perfect, and it can be hard to always expect a good outcome (while you might not notice it because of your tests on localhost). This is why I introduced the manipulation of the following networking stats: Minimum latency (in ms) Random latency (in ms) Packet drop percentage Packet duplication percentage It's also very easy to activate and deactivate. All you have to do is NetworkManager::StartSimulation(...) and StopSimulation(). Here is it in the command line when you activate it: More debugging information available At last I added more ways to debug the network statistics to really see what is going on. Are you not receiving data anymore? Are you flooding the network? The following information is now ready to be displayed: Newest ping (either to the server or from a specific client) Average ping (this as well^) Incoming amount of packets per second Outgoing amount of packets per second Packets per second lost Incoming data per second (in bytes) Outgoing data per second (in bytes) Current active connections (primarily for the server) That's... quite a lot more than before! Previously you could only see if you're connected and if you're the server. I hope this information will make it easier for users to visualize traffic and debug any problems they might be having. And of course, you can mix this up with the debugging class to make cool graphs like above! Final words I'm still planning on making some extra information, like on specifics to see what kind of message is creating the amount of bytes send/received. This should help debugging even more. Other than that there are still some enhancements I'd like to put in such as encryption. These can be seen here. I hope you liked this blog post! Next time I will probably be showing how to implement EvayrNet into your C++ Leadwerks project, so you can toy around with it.
-
Thought I could write my first Blog entry and report about my ventures into network programming with Leadwerks, ENet and Lua. Also, provide some source code. Okay, here we go: What I wanted to do My test app should be a client-server setup where clients can connect to the server, see each other's avatar, send chat lines and move around their avatar on a plane. Nothing fancy really, just to get into the topic. The ENet network library (http://http://enet.bespin.org/) should be used, and network functions should be exposed from C to Leadwerk's lua engine (as I wanted to do the main 'game coding' in lua). The clients are intended to run on Windows, while the server should first be run as console app on Win, might later be moved to a remote rented Linux server. The Network Concept For the first testing, I tried to make the server part very "light-weight", and leave many things to the client(s). Probably not the right thing to do for a full scale MMOG (mainly due to cheat concerns) - but, well, this test app is far from that anyway ;-) So, the server will - aside from some administrative tasks - mainly receive messages from a client and distribute to the others. As for the communication, a rather simple protocol layer was created on top of ENet (i.e., a definition of message formats and identifiers). Note that not everything a client sends will be distributed - it would first be checked for (some very basic) consistency. Network Messages Seven network messages were defined, some for client->server or server->client only, some for both ways. The messages are wrapped into ENet's 'ENetPacket' and sent, to be evaluated by the receiver. MSG_TYPE_ID_REQ(a clients requests a unique identification number from the server) MSG_TYPE_NAME (a client sends its chat name) MSG_TYPE_POS (a client or the server sends info about position/rotation of an avatar) MSG_TYPE_CHAT (a client or the server sends info about a chat line) MSG_TYPE_CLIENT_ON (the server sends info about a new client online - also used to inform a new client about existing ones) MSG_TYPE_CLIENT_OFF (the server sends info about a client leaving) MSG_TYPE_CLIENT_ID (the server sends a unique identification number to the client that requsted one) The message formats used would look like so (complete source available below): struct MSG_POS // Sending a client pos and rot info { BYTE cMsgType = MSG_TYPE_POS; UINT16 ClientID; float fPosX, fPosY, fPosZ; float fRotX, fRotY, fRotZ; }; The Server This is a win console C app, which should - with some tweaking - compile and run on Linux also. Actually, I started out with doing it on Ubuntu on a VMWare Player, but moved to Win console later on. Just for the ease of use. The server will detect when a new client connected (using ENet functionality), and wait for the initial 'request for ID' message. After assignment, it informs the other clients about the new one (and vice versa). On server side, only the unique ID and the client's chat name are stored. When receiving e.g. a "Chatline" message, the server would check if the sender's client ID and the message type both are valid, then distribute the message to all clients. Upon disconnection of a client (again using ENet functionality), remaining clients would be informed also. The Client Networking here is done as a two-stage concept: Extending the Leadwerks App with some networking C functions and exposing some of them to lua (where the main 'game programming' is to happen). Note that Leadwerks also comes with the ENet headers and libs, so it is not necessary to include it here. You can just use it in your C code. As for the connection between C and lua, two possibilities must be considered: Calling a (new) network function from lua and calling back from C into lua when e.g. a certain message arrived. Exposing a new function to lua would look like this (returning the connected state of the network): lua_register(Interpreter::L, "NW_IsConnected", NW_IsConnected); extern "C" int NW_IsConnected(lua_State* L) { lua_pushboolean(L, gl_Networking.m_bConnected); return 1; } Preparing a callback from C into lua looked like so (this is a callback when a new client is reported by the server). Note that (obviously) the global function "NW_Callback_Connected" must be present in the lua code, to be called. void Callback_Connected(unsigned short int iID) { lua_getglobal(Leadwerks::Interpreter::L, "NW_Callback_Connected") if (!lua_isfunction(Leadwerks::Interpreter::L, -1)) { lua_pop(Leadwerks::Interpreter::L, 1); return; } lua_pushnumber(Leadwerks::Interpreter::L, iID); /* do the call (1 argument, 0 result) */ if (lua_pcall(Leadwerks::Interpreter::L, 1, 0, 0) != 0) { printf("NW_Callback_Connected ERROR: %s\n", lua_tostring(Leadwerks::Interpreter::L, -1)); return; } } For the test app, several functions were exposed to lua from the added network C code, and also several possible callbacks are provided. To avoid any multi-threading issues, the function "NW_Update()" must periodically called from lua (e.g. in WorldUpdate). Within there, callbacks are then triggered. Callbacks, invoked from network (when NW_Update() called) NW_Callback_Connected(id) // called when we are connected to the network NW_Callback_ClientJoined(id) // called when a client joined the network NW_Callback_ClientLeft(id) // called when a client left the network NW_Callback_ClientPosRot(id,Px,Py,Pz,Rx,Ry,Rz) // called when a client pos/rot message arrived NW_Callback_ClientName(id,name) // called when a client sent its name NW_Callback_ClientChat(id,chatline) // called when a client sent a chatline Functions, to be called from lua NW_Connect() // do this once, e.g. in Script:Start() NW_IsConnected() // call this to see if server connection is established NW_Update() // do this regularly, e.g. in Script:UpdateWorld() NW_SendPosRot(Px,Py,Pz,Rx,Ry,Rz) // when pos/rot changes, send all e.g. 200ms NW_SendName(name) // send your client name once (15 chars max); NW_SendChatline(chatline) // send chatlines (255 chars max) to other clients Within lua, it is then the client's task to respond to e.g. a 'NW_Callback_ClientJoined' message. Like, create a new avatar and move it around. The client is sending its own position every 200ms, to be distributed further by the server. Within the client, only very few measures have been taken to compensate for network lag. It will interpolate incoming positions for remote avatars (moving them with constant speed), but does not really apply such high-sophisticated methods like movement prediction and whatnot. To move one's own avatar, use WASD. To submit a chat line, hit enter (submit with enter again, cancel with esc). Note that as for now, a connection attempt is only done at startup. So the server must be started before any client. Also, 'localhost' as server IP is currently hardcoded. Final Words While I did dive into ENet before, this was my rather first time with all that lua mumbo-jumbo. Actually, after getting used to it, writing scripts in lua is quite fast (relaxing, even). Think I will stick to the idea of doing some basic stuff in C, but adding game logic in lua. Now on to that movement prediction et al! Links A short video, showing the whole mess in action: Link to executables (server+client): http://www.mikoweb.eu/tmp/LWEN_Networking_Exe.zip (10MB) Link to Source (VS2013+LW): http://www.mikoweb.eu/tmp/LWEN_Networking_Source.zip (25MB) Pictures The test app (here, 3 clients and the server running on Win)
-
Welcome to blog Number 2; There is not a lot to discuss here, but I wanted to post an update(mostly so I can track myself. lol) We are just about completed with the Log on server. This actually has nothing to do with LE on the server side. The SQL connection is good, and we are using an sql.lite file for the log on server info. We felt that this would secure it a little better than a standard .CFG or .TXT file for the server host. We will be running a test tonight from a dedicated server to our clients. The client will see the scene I posted in the gallery and the GUI for loging in to the server. Hopefully by next week I will have a short video to add of the end product for login... Then off to the world population. Blog #1 Blog #3
