Unigine DIS API does not use the Site ID for Entity identification

[Amerio.Stephane]

From UnigineIG.h:

        static int64_t getEntityIDFromDISID(uint16_t app, uint16_t id) { return id | (app << 16); }
        static void getDISIDFromEntityID(int64_t entity_id, uint16_t &app, uint16_t &id) { app = uint16_t(entity_id >> 16); id = uint16_t(entity_id); }
 

But in DIS, an entity is actually identified uniquely by the trio { SiteID, AppID, EntityID }.

The Unigine API is missing the Site ID. There are certainly other API calls or implementation to be fixed along in this way. We will soon have to deal with the same app running on multiple sites (on the same network), so this will be a huge concern soon.

We also lack a reliable way to distinguish from CIGI and DIS entities in the API (apart from guessing from the ID value.

Thanks!

[silent]

Hi Stephane,

Quote

But in DIS, an entity is actually identified uniquely by the trio { SiteID, AppID, EntityID }.

The Unigine API is missing the Site ID. There are certainly other API calls or implementation to be fixed along in this way.

We plan to take a closer look at the DISConnector plugin in the near future, ahead of the 2.21 release. Improving the Site ID behavior is our main focus at the moment.
However, considering the current target release window for 2.21 (Q1 2025, February or later), we were wondering whether you have a specific deadline by which the Site ID improvements would be required. Having this information would help us better prioritize our development schedule and determine whether it would make sense to address the behavior earlier, for example as part of the 2.20 fix.
 

Quote

We also lack a reliable way to distinguish from CIGI and DIS entities in the API (apart from guessing from the ID value.

Could you please let us know whether this is as critical as the Site ID issue, or if it could be addressed at a later stage?

I will create a ticket in our internal bug tracker for this feature to be added in a future update. There may be a historical reason why it was designed this way, and it could require more effort than a quick change. Also, if you could share a draft of the API - how you think it should ideally be used from the client side, that would be very helpful as well :)

Thank you!

[Amerio.Stephane]

Hum I understand 2.21 has been shifted from December to next year... No worries for us, better stable than rushed, but a 2.20 fix might be needed for some features then.

The most troubling DIS bug at the moment is the one reported in an earlier post about the inconsistencies about the DIS filtering (leading to incorrect DIS entities behavior), and might be directly linked to the incorrect handling of Site/App ID. For the month ahead, we can work by ignoring the site ID altogether (as we can impose it locally to 1), but that won't be a viable way afterwards with out-of-site CGF.

Distinguishing CIGI from DIS: Currently, I have to look at the entity Type ID and check whether some high bit are set, because this is how you implemented it (mangling DIS Type details into one long-long-int). That works ok, just unclean API wise and prone to break if you change your implementation. So an API along Entity::isDIS() or IG::isTypeFromDIS(long long type_id) would be nice.

Rational: we need to know, for every entity in the world, who created it (DIS/CIGI) and all details about it to avoid confusion (Site/App/EntID for DIS, EntID alone for CIGI). We'll also need to find a way to add pertaining details when a DIS entity is intersected by CIGI LOS messages.