Motive 2.2.0 Support

[vincentscode]

Hi, unfortunately I am having issues using this library with the newer Motive Tracker Software (2.2.0).
The connection can be established without issue but a new model_type cannot be handled by this library:

Getting data descriptions
Traceback (most recent call last):
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\protocol\ModelDefinitionsMessage.py", line 60, in deserialize
    impl = self._implementation_types[model_type]
KeyError: 5

resulting in a ValueError: Unknown model definition type.

I do notice that this library appears to be unmaintained, but as this is so much easier to use I really hope this can be easily fixed, maybe even by myself.

Any input on this would be highly appreciated!

The full log is pasted below:

Connecting to 10.100.25.27
Getting server info
Server application: Motive
Server version: Version(major=2, minor=2, build=0, revision=0)
Synchronizing clocks
First echo: RTT 1.43ms, server time 742.2
Echo     6: RTT 1.02ms (min 1.00ms), server time 742.2s, dt  0.012s, correction  0.259ms, drift  21.993ms/s, new skew:  0.000ms/s
Echo    50: RTT 1.07ms (min 1.00ms), server time 742.3s, dt  0.067s, correction  0.078ms, drift   1.166ms/s, new skew:  0.000ms/s
Echo    76: RTT 1.00ms (min 1.00ms), server time 742.3s, dt  0.042s, correction -0.113ms, drift  -2.726ms/s, new skew:  0.000ms/s
Getting data descriptions
Traceback (most recent call last):
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\protocol\ModelDefinitionsMessage.py", line 60, in deserialize
    impl = self._implementation_types[model_type]
KeyError: 5

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\user\Documents\Python Scripts\optitrack\main.py", line 27, in <module>
    client = natnet.Client.connect(server_name)
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\comms.py", line 418, in connect   
    return cls._simple_connect(server, logger, timeout)
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\comms.py", line 401, in _simple_connect
    return cls._setup_client(conn, server_info, logger)
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\comms.py", line 354, in _setup_client
    model_definitions_message, _ = conn.wait_for_message_with_id(protocol.MessageId.ModelDef)
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\comms.py", line 155, in wait_for_message_with_id
    return protocol.deserialize_payload(message_id, payload), received_time
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\protocol\common.py", line 271, in 
deserialize_payload
    return _registry.deserialize_payload(*args, **kwargs)
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\protocol\common.py", line 221, in 
deserialize_payload
    message = message_type.deserialize(payload_data, version)
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\protocol\ModelDefinitionsMessage.py", line 231, in deserialize
    models.append(_registry.deserialize(data, version))
  File "C:\Users\user\AppData\Local\Programs\Python\Python310\lib\site-packages\natnet-0.1.0-py3.10.egg\natnet\protocol\ModelDefinitionsMessage.py", line 62, in deserialize
    raise ValueError('Unknown model definition type {}'.format(model_type))
ValueError: Unknown model definition type ```

[vincentscode]

After some research the dev branch as well as https://github.com/nickdelgrosso/python_natnet/ and https://github.com/smorad/python_natnet/ appear to have made some progress towards this.
The issue does not appear when using the development branch (as Key 5 is assumed to be a Camera there and thus no longer unhandled).
Is there any reason for this to not be part of the main branch?

[mje-nz]

Hey thanks for the feedback, unfortunately I haven't had access to the Optitrack system I developed this project on for years now. From memory, I was part-way through some big changes on the dev branch at the time. At this point, quite a few people have reported bugs, and some of them have fixed their bugs in their own forks, so I'm not sure which version is most up-to-date now. Sorry!

[vincentscode]

I see, thanks for the heads-up!
For my use-case the dev branch is working great with no issues so far, so if anyone is experiencing the same issue that is a good solution for now.