I'm trying to use the API to get the texture path saved in FLT file, but API functions are behaving strange depending on how the path is saved, if the texture file exists or not and if the flt file is located in its original location or not. I explain one simple case:

I have one FLT file called D:\FLT\relPath.flt with one texture in its palette saved with relative path (.\Texture\edf.rgb) and another FLT file called D:\FLT\absPath.flt with the same texture in its palette saved with absolute path (D:\FLT\Texture\edf.rgb).

If I used the API over the file with relative path, I can get the texture path using mgGetTextureName or mgGetTextureSaveName, getting the following results:

mgGetTextureName returns "D:/FLT/Texture/edf.rgb" if texture file exists and "./Texture/edf.rgb" if texture file does not exist.

mgGetTextureSaveName returns "./Texture/edf.rgb" if texture file exists and "./Texture/edf.rgb" if texture file does not exist.

If I do the same with the file that has the texture saved with absolute path (absPath.flt) I get the following:

mgGetTextureName returns "D:/FLT/Texture/edf.rgb" if texture file exists and "D:/FLT/Texture/edf.rgb" if texture file does not exist.

mgGetTextureSaveName returns "./Texture/edf.rgb" if texture file exists and "./Texture/edf.rgb" if texture file does not exist.

Now, I copy the whole folder "D:\FLT" to "D:\FLT2". If I call those functions over "D:\FLT2\relPath.flt":

mgGetTextureName returns "D:/FLT2/Texture/edf.rgb" if texture file exists and "./Texture/edf.rgb" if texture file does not exist.

mgGetTextureSaveName returns "./Texture/edf.rgb" if texture file exists and "./Texture/edf.rgb" if texture file does not exist.

If I do the same with "D:\FLT2\absPath.flt" I get the following:

mgGetTextureName returns "D:/FLT/Texture/edf.rgb" if texture file exists and "D:/FLT/Texture/edf.rgb" if texture file does not exist.

mgGetTextureSaveName returns "../FLT/Texture/edf.rgb" if texture file exists and "../FLT/Texture/edf.rgb" if texture file does not exist.

The problem is that there is no function that always returns the path exactly as it is saved in the flt file, no matter if the flt file is in its original location or not, if the texture path is absolute or relative, neither if the texture file exists or not.

I need to get the string exactly as it is stored in the flt database, but those functions only return that string under certain circumstances but not always.

Is there any way to get the string path exactly as it is saved in FLT file in every situation? Thanks.

Hi-

I am sorry I have not had a chance to reply earlier. Vacation, etc has kept me away from the forum for a while. I am back now and will get some time to look at your problem. Before I start, can you tell me:

1) Are you seeing this in Creator (in a plugin) or in your stand-alone app (or script) ?

2) What version of the OpenFlight API are you using?

Thanks and sorry again for the delay.

1. Stand-alone app

2. API v4.2

Thanks for your help

Hi, sorry for the delay... it took me some time to run through all the permutations you have presented.

After running the test cases, first let me say that I see the same results you do (that's good). Second, these results do suggest that there is a problem in the API (that's not so good). I've attached a chart showing the results you presented (and I confirmed). After analyzing the chart it appears that the 2nd set of results you presented (after copying the files from FLT to FLT2) show the same problems as the first set. Can you please confirm that in case I misread something in your original post? If the 2nd set of results, in fact, don't show anything different than the first set, I believe you've identified two distinct (but related) problems:

1) If the texture name saved in the OpenFlight file is absolute, mgGetTextureSaveName returns a relative name even if the original texture is found.

2) If the texture name saved in the OpenFlight file is absolute, mgGetTextureSaveName returns a relative name when the original texture is not found.

or more generally mgGetTextureSaveName seems to return a relative name no matter what.

The good news is that (with your help) we've corrected this for the next version of the OpenFlight API.

The bad news is that there is no alternative function in the OpenFlight API to help you navigate around this problem. And I am sorry to admit that I cannot think of a workaround that might help you - short of reading the OpenFlight file in raw record format.

Steve, I just tried moving the file to another location to check if there was any difference, but there wasn't. But yeah, the problem is that no matter how you save the path, mgGetTextureSaveName always returns a relative one.

When are you planning to release the next version of the API (which include this correction)?

Thanks