Portico would not work due to FOM parser issues (didn't fix, just temporarily
hacked around and undid that change before commit)
Portico encoding helpers were bad, so I went and fixed those and updated the portico version in the repo.
Disco-RPR was not looking at the DIS entity ID and using it to populate the HostObjectIdentifier field - FIXED
Disco-RPR can't tell when a locally created DIS radio changes its ID (it looks like a different radio). Hacked
some temporary stuff to identify changed IDs when CNR default config values are used (1-1-0, 1-1-1 or 0-0-0 for
site-app-entity id). Can detect change from default to non-default, but can’t detect the reverse (if
entity attachment is dropped).
There are some deeper issues here. In CNR/DIS, when a radio attaches to a platform it changes its entity id to
match that of the host platform. Unfortunately there is no way to tell the difference between a TramistterPDU
that has just changed its ID and an entirely different transmitter. This meant that when a change would happen,
it would cause us to register an entirely new HLA object and start updating it.
I've fixed this "mostly" now, but it will only work for CNR applications IF they use the default site/app/entity
id configuration settings. Otherwise, we’ll get duplicate objects. The old ones should time out and go away
eventually, but I’m not going down that rabbit hole.
Many issues here:
Portico would not work due to FOM parser issues (didn't fix, just temporarily hacked around and undid that change before commit)
Portico encoding helpers were bad, so I went and fixed those and updated the portico version in the repo.
Disco-RPR was not looking at the DIS entity ID and using it to populate the HostObjectIdentifier field - FIXED
Disco-RPR can't tell when a locally created DIS radio changes its ID (it looks like a different radio). Hacked some temporary stuff to identify changed IDs when CNR default config values are used (1-1-0, 1-1-1 or 0-0-0 for site-app-entity id). Can detect change from default to non-default, but can’t detect the reverse (if entity attachment is dropped).
There are some deeper issues here. In CNR/DIS, when a radio attaches to a platform it changes its entity id to match that of the host platform. Unfortunately there is no way to tell the difference between a TramistterPDU that has just changed its ID and an entirely different transmitter. This meant that when a change would happen, it would cause us to register an entirely new HLA object and start updating it.
I've fixed this "mostly" now, but it will only work for CNR applications IF they use the default site/app/entity id configuration settings. Otherwise, we’ll get duplicate objects. The old ones should time out and go away eventually, but I’m not going down that rabbit hole.