[86287] .FBX import does not copy source textures into the expected userfiles location

[FederFlyer]

I updated to version 10.10.144 yesterday and am experiencing unexpected program behavior.

Prior to updating RealFlight, imported 3D objects resulted in 4 files in the airportobjects folder: .airportobject, .kex, .tga and .dds. After updating to 10.10.144, imported objects result in only .airportobject and .kex. There are no .tga and .dds. Yet, the object is rendered correctly in RealFlight, including the textures.

I've searched my entire drive, but cannot find the texture files. I've restarted Steam, restarted my PC and restarted RealFlight, but it remains a mystery.

Where are the texture files for imported objects?

 

[asj5547]

Look in the color schemes folder.

 

[FederFlyer]

Thanks for the fast response.

The airport objects are not in the ColorSchemes folder. That folder only contains color schemes I have downloaded for aircraft.

I am importing static airport objects (e.g. hangars, buildings, vehicles, etc.). Those files are contained in the AirportObjects folder. But after the program update the TGA and KEX files are nowhere to be found on my PC drive, even though the object displays the correct texture. So the texture info is being saved, just not as separate files.

I'm wondering if the import process has been changed so that the KEX file now includes the texture info. If so, that will be unfortunate, because having separate TGA and KEX files make it easy to edit and clone airport objects.

 

[Ryan Douglas]

@FederFlyer, thank you for this report. You've uncovered a bug that so far appears to be minor. I can explain what's happening.

The .fbx import step where RealFlight should copy the original source images into <Documents>\RealFlight Evolution\... is not working. So, the reason you're not finding the textures but the art still looks correct is because it is referencing them in their original location (e.g., C:\temp\...). You can look at the material definitions in the .airportobject file to see this for yourself.

I'm wondering if the import process has been changed so that the KEX file now includes the texture info.

It's actually the opposite. .kex files used to contain embedded texture references, making it difficult to modify texture paths or filenames. With the advent of the new material definition system, texture references are completely removed from the .kex. It only has a list of materials. Material definitions elsewhere (in a .colorscheme or .airportobject file, for example) specify which textures map to which materials, and where to find them.

The current behavior is a bug and we will fix it. I have filed case 86287 accordingly.

There are some positives here. For one thing, it shows the robustness of the new material definition system, which allows art to reference textures anywhere on disk instead of requiring them to be in specific places and using arcane logic to locate them. For another, only content creators should even observe the current behavior. In my admittedly limited testing thus far, the export process correctly included all the textures in the .rfx, and on import it also worked as expected, copying all the textures into the correct place and updating references in files.

 

[FederFlyer]

Thank you for such a fast and detailed response. The explanation makes sense and I see the reference to the working copy of the TGA in .airportobject file.

And thank you for your many years of being so responsive to RealFlight users. Your efforts are greatly appreciated.

 

[FederFlyer]

Until this issue is fixed, here is the workaround. Copy the texture files into the AirportObjects folder, then update the .airportobject file with the correct pathname for the files.

1. Start RealFlight.
2. Import the object into RealFlight.
3. In the airport editor, select the object.
   • Selecting the object causes RealFlight to create the DDS file(s).
   • The DDS file(s) will be in your working folder, not in the AirportObjects folder.
4. Exit RealFlight.
5. Copy the TGA and DDS texture files from your working folder to C:\Users\ ... \Documents\RealFlight Evolution\Scenery\AirportObjects
6. The AirportObjects folder should now contain the .airportobject, .kex, ,tga and .dds files.
7. Open the .airportobject file in a text editor (e.g. Notepad).
   • There will be one line per TGA file that has the pathname for the TGA file.
   • Change the path of the TGA file(s) to C:\Users\ ... \Documents\RealFlight Evolution\Scenery\AirportObjects\
8. Save the file and see if the object is rendered correctly in the airport editor.

Note: It is not required that texture filenames match the object filename, but it is important that they do match.

• RealFlight will accept texture filenames that don't match the object filename. Whatever texture filenames are listed in the FBX file will be used.
• The limit of just one TGA file per object is no longer true.
  • An FBX file can refer to multiple TGA files.
  • All of the TGA files will be imported, and a DDS file will be created for each TGA file.
• However, if the texture filenames don't match the object filename then you risk overwriting an existing file if there is a file with the same name.
• At this time, the "Manage Use Files" function will not rename or delete the texture files. These operations must be done manually in the AirportObjects folder. This can be tedious and difficult if your AirportObjects folder is cluttered with a lot of mismatched filenames.
• Example of a complete set of files that are named alike.
  • Hangar by John.airportobject
  • Hangar by John.kex
  • Hangar by John 1.dds
  • Hangar by John 1.tga
  • Hangar by John 2.dds
  • Hangar by John 2.tga
• The names in this example are not exactly the same, but are enough alike that they will be grouped together in the Airport Objects folder and thus will be easy to find.

 

[Ryan Douglas]

We believe this is fixed in the new beta. Please test it out and let us know your results!

 

[FederFlyer]

I tested the fix and it does import and create the texture files in the AirportObjects folders. There is still a glitch, though.

Here's what I found:

• Import FBX: Files are imported OK and the DDS is created when the object is selected in the Object Palette. All files reside in the AirportObjects folder and the .airportobject file has the proper pathname for the texture file.
  
  
• Manage User Files > select the object > Delete: Deletes the files properly, including leaving the texture files intact when selecting the option to not delete them.
  
  
• Manage User Files > select the object > Rename > enter new name > click OK: An "unexpected error" is displayed and RealFlight closes.

I don't think the renaming error is a just a result of this week's fix. I was experiencing the "unexpected error' with program closure long before the recent importing issue. If I do any changes or edits in the airport editor, and exit the editor without saving the changes, I experience the error message, then the program closes. I thought maybe it was just an issue with my particular system. But now it is also happening with Manage User Files > Rename.

BTW - Is there a particular place in the forum that you prefer that we report bugs, or is this type of message your preference?

 

[Ryan Douglas]

Thanks for that report! I'm glad to hear the known issues we addressed seem to be better.

Thanks also for the report on the object rename. That's another good find. I am going to create a new thread for that one so I can assign it its own case and keep things distinct.

BTW - Is there a particular place in the forum that you prefer that we report bugs, or is this type of message your preference?

Good question. The beta forum is a great place for reporting bugs in a beta version. Issues related strictly to content creation are a better fit for the Designer's Corner. (Sometimes the lines get a little blurry.) Other, general bug reports are probably best suited to the forum for the specific product version in which they are observed (e.g., "RealFlight Evolution"). But we're not going to be super strict about this. We should see them wherever they end up. But since we're on the topic, I will move this to the general Evo discussion forum.

 

[Ryan Douglas]

Oh, and when you have a chance, can you tell me more about the editor crashes when exiting without saving? The airport editor definitely has some bugs, but I'm not aware of any issues like you mentioned.

 

[FederFlyer]

I tested it today and am no longer experiencing crashes when exiting the airport editor without saving changes. If it occurs again, I will note the specific circumstances.

Here are the circumstances I tested today:

Location​	Type of Airport​	Type of Object​	Select Object and Exit Editor Without Saving Changes
Archipelago	RealFlight Standard	RealFlight Standard	No issue
Archipelago	RealFlight Standard	User Created	No issue
Archipelago	User Created	RealFlight Standard	No issue
Archipelago	User Created	User Created	No issue
Flatlands	RealFlight Standard	RealFlight Standard	No issue
Flatlands	RealFlight Standard	User Created	No issue
Flatlands	User Created	RealFlight Standard	No issue
Flatlands	User Created	User Created	No issue
Sierra Nevada	RealFlight Standard	RealFlight Standard	No issue
Sierra Nevada	RealFlight Standard	User Created	No issue
Sierra Nevada	User Created	RealFlight Standard	No issue
Sierra Nevada	User Created	User Created	No issue

 

[Ryan Douglas]

@FederFlyer, thanks for all that! No changes we made are expected to have that effect, but perhaps it stemmed from something we fixed that was seemingly unrelated.

Hopefully it won't come back, but as you said, let us know if it does with as good a set of reproduction steps as you can manage.

 

[rcflyernc2001]

Well, mine is still crashing and getting a question about if I would like to have a report sent to tech support. It only crashes if I don't do anything with the sim, whether or not I am editing something on a plane, airport, and/or building a new airport. I am not bothered by it, because I know it is user issue and not the RC sim.