Ok this is a weird one. I've got a problem where the 4.0 API is adding rotation animation to all the lightpoints in my files.

I'm reading v15.7 files and re-exporting to v15.7 when done.

Briefly, I've stripped my app down to simply open the file, and re-save it, without doing anything to it.

If I use mgExportDb to export to v15.7, one rotating animation palette entry is created from the first light encountered in the model (even though in the original model it had no animation) and that entry is replicated on to every other light.

If I use mgWriteDb to write out a v16.4 file, things get even worse - every light point creates its own rotation animation palette entry.

I tracked it down to this line:

mgGetAttList(rec, fltLpFlashing, &flashing;, MG_NULL);

By calling that line, the API is adding an animation palette entry to my resulting file for all the light points where that check is called (all of them). Even though I'm not explicitly creating an entry or writing any new attributes. The release notes have this to say:

Note that if you call mgGetAttList or mgSetAttList on a light point node to access a palette attribute and the light point node does not yet have a palette entry associated, a new palette entry will be created, the corresponding index on the light point node will be updated to reference this new palette entry and this new palette entry will be accessed.

It seems that this function is creating animation palette entries with bogus data in them. Instead of putting an animation palette index of -1 in the lightpoints, it looks like it's trying to put 0 instead, and THAT seems to result in the auto-creation of a bogus palette entry. ie. the mere act of looking for an attribute is creating that attribute.

I'm guessing the way around this problem is not to use mgGetAttList directly, but rather to see if the lightpoint has an animation palette entry on it to start with (which would have been auto-created by touching the file with the new API) and if so, go down and look in there to see if the flashing flag is set?

Interesting find... This sounds very much like something is getting initialized wrong. We will take a look. Thanks for bringing it to our attention.

FYI, this is what didn't work - it returns the 'flashing' boolean OK but in the process creates an animation entry for the lightpoint being checked:

mgGetAttList(rec, fltLpFlashing, &flashing;, MG_NULL);

I've now replaced it with this, which does the trick:

mgGetAttList (rec, fltLpAnimation, &animatinglight;, MG_NULL);

if (animatinglight != -1)
{
    mgrec* lightpointanimation = mgGetLightPointAnimation (pDB, animatinglight);
    if (lightpointanimation != MG_NULL)
    {
        mgGetAttList (lightpointanimation, fltLpFlashing, &flashing;, MG_NULL);
    }
}
else flashing = false;

Glad you got this sorted out... A quick reply to your comment:

It seems that this function is creating animation palette entries with bogus data in them. Instead of putting an animation palette index of -1 in the lightpoints, it looks like it’s trying to put 0 instead, and THAT seems to result in the auto-creation of a bogus palette entry. ie. the mere act of looking for an attribute is creating that attribute.

If you re-read the release note you cite, you'll see that the the API is doing exactly what the release note says it will do.To paraphrase the release note in the context of mgGetAttList and apply it to your situation, here is what is happening:

When you call mgGetAttList on the light point node that does not yet have a light point animation palette entry, a new palette entry is created (index 0 for the first one created), the corresponding index on the light point node is updated to reference this new palette entry (index 0, not -1) and this new palette entry will be accessed.

This seems to be consistent with what you have reported. Now you could argue that this behavior is not what you want, but there are many cases where this behavior is desired.

It's a moot point, however, if you write your code to talk directly with the light point palette entries (as you have done). The "compatibility" mode for mgGetAttList and mgSetAttList was designed to make the transition from inline light points to palette-ized light points a little less painful. The right approach is to change your code to deal with light point palettes correctly.