Hey mate

I accidentally cancelled a connection attempt, and see the following loop error in the logs:

21:50:52.360 [StateCollectionThread] ERROR com.simsilica.ethereal.zone.StateCollector - Collection error
com.jme3.network.kernel.KernelException: Endpoint is not connected:UdpEndpoint[1, /127.0.0.1:54212]
	at com.jme3.network.kernel.udp.UdpEndpoint.send(UdpEndpoint.java:125) ~[jme3-networking-3.6.0-SNAPSHOT.jar:3.6.0-SNAPSHOT]
	at com.jme3.network.base.DefaultServer$Connection.send(DefaultServer.java:588) ~[jme3-networking-3.6.0-SNAPSHOT.jar:3.6.0-SNAPSHOT]
	at com.simsilica.ethereal.net.StateWriter.endMessage(StateWriter.java:554) ~[sim-ethereal-1.8.0.jar:?]
	at com.simsilica.ethereal.net.StateWriter.flush(StateWriter.java:568) ~[sim-ethereal-1.8.0.jar:?]
	at com.simsilica.ethereal.NetworkStateListener.endFrameBlock(NetworkStateListener.java:241) ~[sim-ethereal-1.8.0.jar:?]
	at com.simsilica.ethereal.zone.StateCollector.collect(StateCollector.java:286) ~[sim-ethereal-1.8.0.jar:?]
	at com.simsilica.ethereal.zone.StateCollector$Runner.run(StateCollector.java:338) ~[sim-ethereal-1.8.0.jar:?]

Not sure if I did something wrong, just thought I'd write this note in case you can see what's what, Cheers

Hello,

I've noticed that your zone implementation in SimEthereal is a bit newer than your Pager's zone implementation. I think it would help your libraries if you made SimEthereal dependent on the Pager library or even another more generic zone library. This would be necessary in order to allow libraries to utilize your zones in a way that didn't require the added network syncing.

For example, your IsoSurface library could potentially be integrated with SimEthereal in order to allow synchronization of smooth terrain. However, IsoSurface would probably be using SimEthereal's zone implementation unless there was some sort of adapter that IsoSurface defined. This would make IsoSurface then always dependent on a networking library even in the case of single player games.

Symptom: jittery gameplay when using the latest SiO2 and SimEthereal.

I ran my networked game with the latest SiO2 which starts its 'game time' at 0. This was of course being used to timestamp the object updates. However, embedded deep within the bowels of SimEthereal is a case where it's using the raw System.nanoTime() to timestamp outbound messages. This meant that the RemoteTimeSource on the client was reporting really big times that were not compatible with the object update times.

...so the code getting tweened positions from the TransitionBuffers was always maxing out and never getting interpolated values = jitter.

In an attempt to update the sim-eth-es example to support SimEthereal 1.3.0, I've stumbled across the breaking changes introduced in c6272ff
The Problem is that EtherealClient#getTimeSource has a return type of "TimeSource" where stateReciever clearly has a RemoteTimeSource (implementing SynchedTimeSource) as it's timeSource.

I guess it's only a simple overlooking, but it would be nice to fix this so a cast is not necessary.

SimEthereal was built to assume that all objects being managed would be updated every frame even if they weren't moving. Unfortunately, for some physics engines that try to be extra efficient, we don't normally see update notifications for objects that have gone to sleep. Working around this at that level is quite inconvenient and may lead to a bunch of state duplication.

On the other hand, SimEthereal uses this to its advantage by letting this automatically expire objects from zone views. The NetworkStateListener can easily determine if an object is no longer in the player's local view by nature of not having received an update. This is an elegant way to detect this since an object might otherwise be in multiple zones at once (even within the player's view). So receiving no updates for some object is an easy way to guarantee that it does not appear in ANY of the player's visible zones.

There is another related issue to this in that if a zone has no active objects at all (even if it does have children) then it will stop updating completely. The NetworkStateListener doesn't even have a chance to send out the removals in this case and the objects continue to be 'in view' even as the player moves many zones away. That's clearly a bug.

After much thinking about that, I think one enhancement can be made that covers these cases at the expense of a little book-keeping. The idea would have to have the Zone and its current StateBlock to keep track of the children of that zone that have not received updates. Then, similar to removals, we can handle these 'non-updates' in a special way. NetworkStateListener could loop over them and provide no-op style state updates to the SharedObjects, etc. just to update their timestamps. Maybe someday we even think of a more efficient way to send no-ops... but this way is pretty efficient when the baselines are already in sync.