Printable View
Hi, I'm having some trouble while experimenting with the Blast Text feature (the UDP send text feature).
After I connect to the server, I get two clients running and my blast/receive code goes:
+Enter pressed
-Blast Text "Blast Text Test" to channel on subchannel 0
+On Text Channel Message (Blasted)
+Subchannel(Oinc) = 0
-End Application
So, I send some text, and when it is received, the application should close, but it does not.
How does blasting text differ from sending text via TCP?
Are you on localhost?
I am connected to DarkKiller's server, but yes, I'm running two clients from the same machine. Is that the problem?
Try having a friend host a server for you. Use Hamachi (https://secure.logmein.com/products/hamachi/list.asp) to make a VPN for testing. I'm not sure DarkKiller's poinc implementation is entirely bug free (well, duh) or working the with the OINC protocol yet.
Well, I also tried it while connecting to Localhost. Doesn't work.
Blasting (UDP) should not differ from sending (TCP).
I set the server up this morning and really did not have time to check on it, I'll test it throughly later. Perhaps I've not enabled UDP on the server.
If you set a name after you connect - the names of two clients cannot be the same or it gives an error (so I was told / found out yesterday). This may be the reason this isn't working for you :).
No, the two names are different. It's a problem with Java right now.
It's probably a UDP issue. I'm slowly working through the bugs right now!
Normally, one problem with UDP is that it isn't guaranteed to arrive at the destination, or in the proper order, correct? This can cause 'jerky' movement or make your character teleport around due to an old message arriving late... but if you sent a number then the position info out to a client, ("123,10,100" (number,x, y) you could have a counter in the client app that would keep track of the latest incoming message (as each message comes in, if the first parsed item is larger then the counter, set the counter to that number, and then make the character move accordingly. If the first parsed item is less then the value of the counter, ignore the message. That should avoid the character teleport that we usually see when using UDP...You could also easily count how many delayed messages the client has received if you add one to a different counter when the incoming message's value is less then the counter...
Hope that makes sense... ;) I know that there are better ways to send position data rather then just X,Y, I was just using that as an example...what I was trying to say was to include a number in the sent info as a way to filter out the old stuff...
OINC seems VERY Yummy so far - thanks for developing it!