1) I can compile and connect the kryonet examples on my local pc (and use the same ports as used for ror).
Any difference in the code between ror and the examples? Probably it's a setup issue in the code...
2) I can compile and run the ror server and ror client with no issue. After clicking connect the map loads and I actually see the character entity created (but he is unable to move). Enter, F8 and esc keys are accepted as those see to be client side only.
Yes. Enter, F8 and Esc are client side. Walking isn't client side, because the input from the client goes to the server and then travels back to the client, where it is 'allowed' to be processed. Additionally (if the server would send anything) it would correct the player's position, but actually this has nothing to do with your issues...
3) From what I can tell ClientConnector.java has a few overriden methods and I see that the received method gets called but the connected method is never reached. I know this because you have a print statement that would get output to the console if it was reached. I don't know kryonet very well but I would have thought that connected should execute before received?
It's normal behavior that connected is never called.
Try to start a server and connect a client, let's call it client A, and connected another client B. In A's Console you'll see the debugging output about client B connecting to the server.
So you actually receive messages, but you still can't walk? Or do anything? What happens if you connect two clients?
I could reproduce once... only once... when I was debugging somehow (through breakpoints and stepping), but I couldn't reproduce anymore. And I don't even remember what
exactly I did.
The problem with debugging is, that the connection code depends a lot on timeouts and locks and stuff... So if you step through the code, simply by waiting to long on one instruction you could break a lock (for example the TCP registration lock, which waits 'only' 100 ms).
But I have no Idea what one could do instead...
Okey. I've tried out to replace this line:
by this line:
1
| new Thread(client).start(); |
For me it works. But since I've had no issues, it didn't fix anything noticeable for me, obviously
I've been trying to insert some various sleeps on threads to help pinpoint the problem but no luck. My prior post regarding a TCP registration error seems to no longer be a problem (it was a side effect of debugging code I had in place). I'm currently trying to break down the timing of the connect and update thread to see if somehow data is being sent before the connection is established.
Same as above: client A's connect is only called when another client B connects to the server, to which client A is connected to.
<edit>
[snip...]
I confirmed that queue.add(runnable) keeps getting called over and over. I assume on a normal connect this should just get called a single time. I added "System.out.println(queue.peek());" just before queue.add to see what was happening and got a dump like:
Totally normal behavior, I'm sorry...
What the queued listener does is: It takes the listener to which it should redirect to as an argument, and delivers Runnables which call the appropriate Listener's methods (receive, connect, disconnect, etc.). For that I have to give a method for queueing those Runnables. (The 'queue' method).
The reason for that is that I can call and process those Messages in my main loop then (tick method of ClientConnector). There it polls all the Runnables and processes them in the current thread.
[snip...]
This seems to indicate that not only is the list getting added to multiple times (from a single connection attempt) but that occasionally the list is emptied and results in those null lines. In other words a listener is added, something happens and it gets removed from the list, next time through we see a null line, and then the next time a new listener is created. It seems to go on like this indefinitely.
Hopefully I'm on the right track now. I am curious if anyone else running this demo were to insert this line if they would see the same output.
Messages come to the client -> multiple times Runnables for processing the messages come in.
The list is emptied, because the Client's main loop polls out all the runnables
It's not fast enough sometimes, though, that's why it doesn't print null sometimes...
</edit>
