Suggestion: improve CIGI packet processing

[Amerio.Stephane]

Hi, we are frequently in need of modification of how the CIGI packet content are interpreted or how they should be sent.

To give a few examples, working with a 3rd party host on which we have absolutely no control:

• the 3rd party host sends a database ID request that does not match ours and we need to 'rewrite' it (or they simply mis-implemented the standard)
• or it sends a view definition/control for an incorrect view ID or with some buggy values (forget to set the enable flags...)
• or it sends an incorrect IG Ctrl (wrong timestamp, etc)
• or they expect the response to HATHOT extended to include the material code to distinguish grass, concrete, etc

Currently, there is no way for us to fix these inside Unigine and we have to resort to an external "CIGI interceptor" that would catch these and rewrite the messages, where possible (the HATHOT ex case is typically impossible to rewrite). This situation adds a bit of latency and is error prone. 

It would be great, in this sense, if the onReceived<Message> could be extended for example:

• change the signature to return a bool: if returning true, the message will be processed, otherwise simply ignore it
• change the signature so the incoming packet can be modified: it gives us the opportunity to simply rewrite some known incorrect values

Same thing for out-going messages, so we can rewrite them or simply discard them.

And one more suggestion for response packets (HAT, HOT, LOS, etc): give us an opportunity at the moment you have the information to create them, to fill in or modify some fields (typically the material part for HATHOT ex is a good example).

Thanks for your help!

[silent]

Hi Stephane,

Thanks for the suggestion!

These look like valuable additions to IG. From an initial review, they seem fairly straightforward to implement (at least at the design stage, before development begins :D).

I’ll create a feature request in our internal tracker to add callbacks for CIGI packet processing. If everything goes smoothly, we’ll aim to include them in the 2.21 update.