Hi,
I am in the process of moving over to the new SpiderMonkey and seem to now have a problem in that Quaternions need to be registered with the serializer (which they cant do as they are not marked as Serializable).
Am I missing something subtle? They seemed to work with the old SpiderMonkey without having to explicitly register them.
Matt
It’s fixed this afternoon and will be in the next nightly… in a few hours I guess.
And just for the record in case anyone else stumbles across this… you can register non @Serializable classes you just have to specify your own serializer at the time. So:
Serializer.registerClass( Quaternion.class, new FieldSerializer() );
…should have worked. At least, in theory. I have not tried it.
Mythruna didn’t hit this one because I turn my quats into three angle floats to save 4 bytes. Sorry it didn’t get noticed sooner.
Thanks for fixing it so fast. Totally forgot about the ability to specify serializers.
I have not even started my message optimisation yet…does Spider Monkey do anything automatically in this respect, for example does it reduce a boolean down to a byte (or even a bit?), or am I best off just looking at the code to figure this out!
Matt
It reduces things down pretty well, though never sub-byte. So a boolean is a byte, etc…
I want to provide bit streams at some point but that is a decent amount of work and requires thorough testing before it replaces Serializer. But bit streams would provide very efficient packing if the API supports range specification of some kind.
By the way… the fast fix was actually a pre fix because @normen already reported the same issue to me a few hours before. 
So I was lucky.
I am having a few teething problems with this; probably my stupidity but…
When first connection my clients the sequence of messages is as follows:
On the server connectionAdded method I send a handshake message.
This message is received on the client and in turn sends a request for the world details
However, this second message never gets there. There is not error but looking at the client in the message received method it has an id of -1 (which I guess means that it is not yet initialised).
I see that the connectionAdded method is called before the connection has completed and therefore the connection is in an invalid state. I am guessing that I should not use the client until I get the registration method? I think this is different to the old spider so may be worth documenting?
Matt
I’d need to see more of your code to be sure.
Old SpiderMonkey may have let you do all kinds of weird things but then half the time drop them on the floor for not being ready to receive them. At any rate, in new SpiderMonkey, the client blocks on send if the connection isn’t ready yet. So code should be simple.
On the server, connectionAdded isn’t called unless the client is fully connected. I’m not sure why your message doesn’t make it to the other side but maybe there are some warning logs?
If you can reduce it to a simple test case it would be helpful. Mythruna does a similar set of handshakes without issue… so there some hidden gotcha that we need to root out.
I was looking at the code
[java]// Best to do this outside of the synch block to avoid
// over synchronizing which is the path to deadlocks
if( addedConnection != null ) {
log.log( Level.INFO, “Client registered:{0}.”, addedConnection );
// Now we can notify the listeners about the
// new connection.
fireConnectionAdded( addedConnection );
// Send the ID back to the client letting it know it’s
// fully connected.
m = new ClientRegistrationMessage();
m.setId( addedConnection.getId() );
m.setReliable(true);
addedConnection.send(m);
} [/java]
I think it is because I try to use the client before the client registration method is received, so I am guessing that the client has not yet been assigned his Id, so will not be accepeted when sending messages.
I have changed this to send my message when the client gets its connected event and it all works. If my above assumption is incorrect then I will look to getting a simple test case together.
The client is supposed to block on send() if it isn’t fully connected… but yeah, prior to that any client ID you see will be -1… but received messages should have it all set right.
So it makes me curious what is going on in your case.