Just like the official language of aviation is the English language (ICAO) as well as the agreed and accepted etiquette of this BMS forum is communicating in English, why deviate and depart from this?

The only welcome input would be perhaps additional information and comments related to the issue of the proper Romanization of the labels and names from specific local languages on BMS maps, charts and other flight support materials.

Here is this related to KTO:
https://www.korean.go.kr/front_eng/roman/roman_01.do

https://en.wikipedia.org/wiki/Revised_Romanization_of_Korean
https://en.wikipedia.org/wiki/Romanization_of_Chinese
https://en.wikipedia.org/wiki/Romanization_of_Japanese#:~:text=The romanization of Japanese is,(d)%CA%91i%5D).

Just like the official language of aviation is the English language (ICAO) as well as the agreed and accepted etiquette of this BMS forum is communicating in English, why deviate and depart from this?

The only welcome input would be perhaps additional information and comments related to the issue of the proper Romanization of the labels and names from specific local languages on BMS maps, charts and other flight support materials.

Here is this related to KTO:
https://www.korean.go.kr/front_eng/roman/roman_01.do

https://en.wikipedia.org/wiki/Revised_Romanization_of_Korean
https://en.wikipedia.org/wiki/Romanization_of_Chinese
https://en.wikipedia.org/wiki/Romanization_of_Japanese#:~:text=The romanization of Japanese is,(d)%CA%91i%5D).

The thread is here …good beginning but not much progress. Some of the participants perhaps even MIA. An important topic to continue.
https://www.benchmarksims.org/forum/showthread.php?33056-Air-Base-Lighting

Here is the link to some old goodies:
http://www.zianet.com/baldeagle/LE_HelpIndex.htm
Perhaps you will find info there helpful and the content worth saving and preserving.

Please also take a closer look at the part “Importing 3DS Files”. It has some pertaining information about textures.

Being able to visually observe the difference will be more or less just as effective as a statistical analysis, but much quicker than writing a program to do that analysis.

I think process of selection of the texture and subsequent maping of uvw coordinates are pretty much clearly shown in LOD Editor.

ID of the texture or multiple textures are noted in Root Node and then subsequently are also referenced for each and every Culled Primitive (CP). (right click)

Notice that if there are several textures each texture is coded 0; 1; 2 ; etc etc. with texture ID in the brackets. I do not know this for sure (sorry!) but perhaps in the LOD file they are also noted 0 1 2 …etc and not with true texture ID.

Now when TexMap button is selected corresponding texture is displayed in the separate window and outline of selected CP is visible in blue.

Button Edit Verts is in actuality also UV editor and moves each vertex of said CP on the texture

0; 0 of coordinates in in left upper corner and max range of the coordinates is in right bottom 1 ;1
vX and vY is exact position of vertex with 6 decimal points accuracy.

If necessary I can insert shots from LODEditor ilustrating each step. I must assume that each and every value is written to LOD file.

I hope this is of some help in your quest or else I misunderstood your question and I should not have been writing all this.
Thanks for your work anyway.

Maybe figuring out how it knows which ones to use for different parts of the model will provide the answer, but that will require some hefty analysis of a few thousand UV coords, so it will take a little time to figure it out.

How about choosing simple LOD with single texture and replacing it with other texture carrying some unique number so you can perhaps trace (locations) with HexEditor? I guess also that to facilitate examination LOD needs to be isolated by saving it out the DB.
Sorry if that is not what you after.

Hi MorteSil

Truly admire your project and I wished I had more direct knowledge to help to sort this problem with textures.

What I would like to offer here is just general hunch and unfortunately pretty blind direction for investigation. For clues look in readmes included in LodEditor 6.23 as well as consider the fact that LE was using Open GL to view models and associated textures. That was separate program OGLOD which was opening in separate window. The other hint would be to look at your current OS your GPU and its drivers and its interaction with DDS format. Progress is happening fast and as we speak and many things have changed since LOD format was introduced and all this may be legacy incompabillity with current specifications.

Good luck with your project and endavor and maybe others could chip in some more specific and helpful advice.

I think links are ok, but there might be a problem with paths on tiles. Thank you for bringing this to our attention and we will work on fixing it for the next update.

PMC Tactical has that tutorial in downloads. See under documentation.
http://www.pmctactical.org/f4/downloads.php

Just post approx coordinates of those anomalies and they can be fixed.

I understand your concern and purpose of the export/import function well. It is and ethical issue and as such involves much more than technical solution.

Perhaps, local community 3d devs should have a say, or vote, which way they want this to be. Or, perhaps there might be a way to protect the models with password. However, all that may not work, or matter anyway.

All rather agree, that there is no such a thing as perfect protection against copyright violation. But, what is working, is community awareness and high sensitivity to publicly call out, disapprove and not support such a behaviour by simply walking and staying away from iffy mods and models. Here at BMS, sadly we had some applicable situations, but after some laud, vigorous and public dispute it was resolved to common satisfaction and right attitudes have prevailed.

All is just 2c of mine…. Others may have other ideas.

Meanwhile, let me again thank you for your time and willingness to program this tool for BMS.