optimization. The updateList was cloned also and needs to
be cleared out and the update flag reset as if freshly
initialized. Thanks for lightbringer for pointing out the
problem and solution.
Added some gating to the endpoint closure to try to delay
some NPE I'm seeing caused be a race condition somewhere when
client and server in the same VM and shutting down at the same
time.
Closing the underlying kernel didn't wake up any readers
and so the read() operation in the adapter was never returning.
KernelAdapter.close() was modified to call join() after closing
the underlying kernel so that the method won't complete until
all of the threads are done.
Then the kernels were modified to wakeup the readers (and this
is now standardized in a base class method) so that they don't
hang forever.
but it could catch the user unaware for any registered non-leaf
class. When a class has a field of a specific final type then
the type information is implicit in the outer object... and
the proper serialization information can be written. It is then
sometimes useful to register a generic serializer for something
like Enum to catch these cases. However, there are many times where
the type cannot be implicitly known and so must be specifically
registered. Prior to this fix, having a generic Enum serializer
registered would cause problems on the reading end because it
wouldn't know what real enum class to use.
Now we catch the issue on the write side where enough information
is known to properly report this to the user. Only a few Bothans
died to bring this info.
* Added key remapping for GLFW key constants
* Rename AppSettings.getGammaCorrection() to isGammaCorrection()
* Use LWJGL3 artifacts from maven
* Minor compatibility changes for LWJGL 3.0.0b
* Fixed some minor bugs in LwjglWindow
In one case, closing a client while it was already closing on
another thread (say because the server is shutting down and
you are exiting at the same time) would cause an NPE if you
caught it just right. Now the thing checking and setting the
connection state is synchronized to avoid the race.
The other more subtle one was caused by sending out the 'connected'
event before the services were all started. It's quite common for
application code to start doing stuff when the 'connected' event comes
through like sending messages and stuff. If the services hadn't been
fully started then even the serializers might not be registered yet...
and that = bad.
Now the client doesn't send the 'connected' event until the services
are started. This should be safe and one could argue that it's more
'correct' but there is some small chance that it screws up certain
use-cases. However, if a real use-case comes up that's not solved by
a service then we can always add some kind of prestarted event.
Sometimes, when the BetterCharacterControl is not moving, it flickers due it physics being always active. The reason for it being always active is that on the prePhysicsTick method it always set the rigidBody's linear velocity (and the method PhysicsRigidBody.setLinearVelocity(Vector3f) reactivates the physics each time is called).
The fix consist on just comparing if the current velocity and the setting one aren't the same and, thus, not setting it (using ZERO_TOLERANCE instead 0 to best results).
used to either watch traffic or debug serialization
issues, etc..
Went ahead and instrumented the service manager while
I was at it... and fixed a potential NPE in the AbstractService's
toString() method.
Fixed a bug in the DefaultClient where it couldn't be shutdown
if attempted before the services had been started.
