[SOLVED] 2.19: CIGI entity definition are duplicated

[Amerio.Stephane]

Hi, CIGI entity definition are duplicated:!

eg: you define entity 200 in ig_config.xml => both enity type 200 and 201 will be defined.

Replication: create a new IG cpp project, launch release, load database 1, use CIGI emitter to emit entity 201 -> the entity 201 is spawned but with the definition of entity 200 from the ig_config.xml

[silent]

Hi Stephane,

I think that's somehow expected behavior and it always work that way (since the beginning of IG). I believe it's related to the DIS requirements of how to handle "similar" entities and if no 'strict' match is being found IG can load 'similar' entity in that case.

The question is: what kind of behavior did you expect to occur when there is no strict matching?

Thanks!

[Amerio.Stephane]

Hum, there might have been some confusion here.

For CIGI, the expected behavior has always been a strict match. If the requested type ID is not found, then the entity should be either empty (no representation) or a default defined representation (but not the 'closest' matching ID, there is no such thing in CIGI). In all cases, type ID 0 shall always be empty (no representation).
In the Unigine specific ig_config, there is no way to define a default representation for unknown entity type (again, except for 0). Maybe this could be added, but this is not a request.

So: Type 0 is always empty

Type 127 representation shall not be replaced by Type 100 or Type 120 or Type 126 representation.

Of course, if this behavior is requested by another customer, then maybe just make it configurable in ig_config.

 

For DIS, the common usage is: a 0 in the type 7-numbers means "anything".

So If Type 1.22.33.44.55.0.0 is undefined in ig_config, but 1.22.33.44.00.0.0 exists, then the former can use the latter representation.

Granted, this kind of "joker" is usually only used for the last 3 or 4 numbers, but it is common to just have it for upper classes too. So we could define for example a generic "plane" or a generic "land vehicle".

 

IMPORTANT EDIT: When an type ID is undefined in ig_config, the IG shall still use this ID internally. In the current 2.19, if type 1.22.33.44.55.0.0 is not found, then the entity is no longer reported with its DIS Type ID in the ig_debug_entity_info.

To sum up for DIS, with 1.22.33.44.00.0.0 defined in ig_config, here is the expected behavior:

Emitter uses 1.22.33.44.00.0.0 -> IG shows 1.22.33.44.00.0.0 node , and displays 1.22.33.44.00.0.0 ID 
Emitter uses 1.22.33.44.55.0.0 -> IG shows 1.22.33.44.00.0.0 node , and displays 1.22.33.44.55.0.0 ID 
Emitter uses 1.22.33.44.00.0.1 -> IG shows 1.22.33.44.00.0.0 node , and displays 1.22.33.44.00.0.1 ID 

Currently it's buggy, because:

Emitter uses 1.22.33.44.00.0.0 -> IG shows 1.22.33.44.00.0.0 node , and displays 1.22.33.44.00.0.0 ID : OK
Emitter uses 1.22.33.44.55.0.0 -> IG shows nothing , and displays <some non sensical large number> ID : KO (wrong ID displayed and wrong node)
Emitter uses 1.22.33.44.00.0.1 -> IG shows 1.22.33.44.00.0.0 node , and displays 1.22.33.44.00.0.0 ID : KO (wrong ID displayed)

 

Edited November 15 by Amerio.Stephane

[silent]

Yes, you are right.

CIGI should load entities only in "strict" mode (or at least that behavior should be configurable).

I've created a bug report in our internal tracker to fix this behavior prior to 2.19.1 release.

Thank you for the input!

[silent]

There will be a partial fix for that in version 2.19.1: CIGI will no longer load "non-strict" entities; however, the IG debug will still display "wrong" IDs for DIS entities. Surprisingly, a significant number of changes need to be made for that particular use case, which we are unable to implement at this time.

If displaying DIS entities in the debug window is crucial for you, please submit a separate support request through our helpdesk, so we can discuss details further :) 

Thanks!