Chat example

[Josh]

1. Drag server.lua onto engine.exe.

2. Drag client.lua onto engine.exe.

3. Go to the client window and hit the tilde "~" key.

4. Type in this in and press enter:

connect 127.0.0.1

 

You should see a connection message and test packet in both windows.

 

5. In either program, type this into the console and press enter:

say Hello

 

You can chat back and forth with both programs. It will work over the real internet if you enter your friend's IP address.

 

Spaces in messages are not supported because the parser is not very good. See console.lua to improve it.

[Marleys Ghost]

Thanks Josh will play with that now

 

 

 

 

(Macklebee note : Attached File(s) chat.zip before you ask silly Q's )

[Josh]

When he saw it at first yesterday, I had forgotten to attach the file. Then I went back and attached it, making his post look silly.

[Marleys Ghost]

When he saw it at first yesterday, I had forgotten to attach the file. Then I went back and attached it, making his post look silly.

 

 

I know that, you know that ... but Mack .. well ...

[Marleys Ghost]

For UK keyboard users hit the "@" key instead of the "~" key. Well thats what worked for me.

[VicToMeyeZR]

I did notice it will only transmit the first word. Any space and everything else get truncated

[Rick]

I know you're laid up Josh, but any info on if we are right that the editor doesn't have networking commands and if not do you plan on giving the editor networking commands in the short future? I have plans for networking objects that I'd love to test out.

[Josh]

I am testing the networking commands with the interpreter and need to recompile the editor for it to work. I didn't expect anyone would need networking in the editor right away, but I can add this for you this morning.

[Rick]

That would be great if you could. I have the design of the network object mapped out and would like to start testing.

[VicToMeyeZR]

that would be great.

[Josh]

It's up.

[Rick]

So here is my initial idea for my network objects. I realize this isn't perfect in that you have 2 different sandbox files for client vs server, but I have a few ideas on that. This is a first draft and very raw and unconfigurable at the moment.

 

Network Object

Network Log In Object

Network Chat Object

 

So you would open up 2 Editors. Drop the Network Object into both scenes. For the server configure a setting to mark it as Server. Do the same for client but mark it as Client. The client also has settings for what server to connect to.

 

Then you drag the Network Log In Object in your client scene. This will bring up a GUI that has a textbox for username & password and a button that says Connect. You make the target of this the Network Object and make this the Network Objects target also for 2 way co. When you press connect, it'll send a message to the client Network Object to connect to the server you configured for it, and then once it's connected it'll send a login message passing username & password. The server Network Object will receive this login message and for now return success to the client's Network Object. The client's Network Object will forward the message to the Network Log In Object and display failure/success.

 

Then you drag the Network Chat Object onto the client (& server if you wish to play god). Make the Network Object it's target and it the Network Object target for 2 way communication. This creates a chat gui. When you press enter it'll send a chat message to the Network Object to send to the server's Network Object. The server's Network Object will broadcast this out to everyone but the one who sent it. It hits the client Network Object which forward it to the Network Chat Object to display.

 

Later things like channels and an easy way to make a custom GUI will be added. The Network Object will also be used for character communication as well.

[Josh]

Here's what I propose for a packet format:

 

Byte - number of messages

 

For each message:

 

Byte - message id (chat, player position, keyboard input, etc)

This is followed by whatever data the message uses.

 

So you can pack multiple pieces of information into each packet.

[Rick]

When using the stream I'm not so sure if it really matters to pack multiple messages together.

 

I 100% agree on the byte for the message id though. I assume the steam read functions work in the same order as writing the message?

 

So on the client if I write:

 

WriteInt()

WriteString()

WriteFloat()

 

I wold do:

ReadInt()

ReadString()

ReadFloat()

 

on the packet and it would be correct?

[Canardia]

If there is only 1 message per packet, it's only 1 byte more to send, but the multiple message feature allows you to have the packet sending on its own time interval, which is very important. With a single message per packet you could only send 1 message per interval, but with multiple messages you could send all messages which happened during that interval, so there would be no huge delay between messages if the interval is set to 5 seconds.

 

If you want to make it even more advanced, you could tune the interval according to the network latency. If there is no latency, the interval would go down, and if there is high latency, the interval would go up to prevent total overload of the network connection.

[Josh]

We need to design a basic framework for handling multiple clients with one server. Each client needs a lua table to be associated with it, in the same way a model has an object associated with it. How can each peer be identified? We could put the peers into a table by the object handle. We could also make it possible to retrieve the peer by name, in which case a rule would be needed that no two clients can have the same name on a server.

[Rick]

Yeah on the server I was going to store the peers/ip addresses in a table.

 

As far as the multiple packets, is this network api on a separate thread? Ideally you send packets instantly when you need to send them. No need to lump them together and then send. Why would lumping multiple messages together matter? I should be able to send 20 different packets all with their own messages in 1 cycle of the loop. This is how RakNet worked anyway. I guess I assumed this is how it works in LE also.

[Canardia]

You can't just send something before checking if the network latency is good enough. You would only make it worse if there was some other traffic going on. The network could be also completely down, then you need to wait and collect the messages anyway. That's why you need to collect the packets to be sent, and send them when the latency is good.

 

You should have also different priorities between important messages, like object positions and not so important messages, like chat messages. The object position messages should run at a shorter interval than the chat messages. And if any object position messages are not sent yet, then no chat messages should be sent before them, else people could exploit the system by spamming the chat channel to cause warping of objects and cheating the battle system.

[Josh]

I think as a general thing, one big packet is better than 10 little ones.

[Rick]

You can't just send something before checking if the network latency is good enough.

 

You certainly can. If you don't send packets until the lag is "good" you might not end up sending packets at all. I don't think that approach would work well at all. Maybe I'm just spoiled with RakNet where you just send packets and don't have to worry about it, but I'm guessing LE's implementation is pretty much the same.

 

 

I think as a general thing, one big packet is better than 10 little ones.

 

The problem is you don't want to hold up certain packets to wait to fill it. Like I wouldn't want to hold up a position or rotation packet myself. So I'm not so sure if that's a general rule. From what I was reading and studying things like WoW packets, it seems they send them at given intervals and whenever and don't wait for any certain size or when the lag is low. Lag generally is what it is. Unless something major happens and you hit a big spike, but from my understanding things will get caught up.

 

Again, maybe I was spoiled by RakNet and it handled this for you. Maybe this will be different. Will work on it.

[Josh]

Well, what kind of data do we need to send?

 

-Client contacts server to join game.

-Server allows client to join game.

-Client sends key and mouse input.

-Server sends positions of players, physical objects, projectiles, health info, etc.

-Client or server disconnects.

-Game score, map changes, etc.

 

For example, the server might send ten "messages" in one packet, to update all the player positions. I am pretty sure it would be better to send all ten players' data in one packet than to send it in ten separate packets.

 

My feeling is the number of packets will be much more of a bottleneck than the actual size of the data.

[Rick]

From my understanding the network card can only send x number of bytes in a packet even though you can put more in there. It'll break it out if it's to large into multiple packets and that is a performance hit if it has to do that.

[Josh]

The data transfers we are going to be sending are very small...the whole player update data is probably less than 100 bytes per update. Ethernet packets are capped at 1500 bytes:

http://compnetworkin...mtu-maximum.htm

[Rick]

the whole player update data is probably less than 100 bytes per update.

 

Right, but it sounds like you guys are talking about putting more than 1 message in a packet. So the player update, then some other stuff, then some other stuff and then send it. So would you look at the bytes in your message and if > a certain amount send it?

 

You can try packing messages together, but I think it's more trouble than it's worth. Until I get issues I'm going to just make a packet and send it off. I didn't see issues when using RakNet and that's how I did it so I'll see if the same is true for LE's. I'm thinking the overhead of a packet isn't enough for me to put together a system to try and put together multiple messages in a packet and then send.

[Niosop]

As long as it's using UDP the protocol overhead isn't THAT bad. Of course the blurb about Netwerk says it supports reliable ordered UDP packets which means acknowledgement and sequence number overhead is added so it's approaching the overhead of TCP.