I wasn't expecting a reversal of one heading in the sim when the two independent files were used together - the file names were different, the lat/long positions in the headers were different as were the headings
.Yes, that's all true. But everything is put into a single library file - or two (one for lights and one for bases) if you omit the "_LO" suffix. Please check the third paragraph from the bottom of page 17 of the User Manual. You'll see that the tag is an essential element of library object naming. When you compiled the first .def file you created an object oriented in one direction. When you compiled the second file, you created an object oriented in the opposite direction but, since the element name and the tag were the same, the first filename was duplicated and the first-generated file was overwritten and used for both arrays. If you open the Make Library dialog for your current data, you'll see that there are now two sets of objects, one set suffixed with _05", the other with "_23". Before, you would have had only one set - all suffixed with "_tag".
I didn't appreciate the significance of the word "tag" because I just copied the header line from one of the def file examples as my starting point and assumed it should remain like that.
But you did substitute actual values for everything else in the header line. Why would you assume "tag" should be treated differently - especially in light of the contents of Appendix "C". As well, I'm surprised you didn't find every library object name being suffixed with "_tag" a little suspicious.
For next time, if I put both arrays in a common def file, sharing the same reference position and heading in the header, I presume that a supplementary string needs to be added to each element line to put each light in the right direction?
You can put as many arrays as you like in a single file. Each must have its own header line defining position and orientation and a unique tag - which, as stared in the manual can be any character string you choose. The only firm requirement for the tag is that it be unique for the reason discussed above. Please note also that it's the heading entry in the header line that controls object heading, not the tag or some supplementary data. Indeed, there is no heading entry in any supplementary data. Therefore if you want to have arrays for both ends of the runway in a single .def file, each end must have its own header line.
Given your focus on complex arrays and the issues you've encountered so far, might I suggest a thorough review of Appendix C is in order. I think you'll find everything you need to know is there. And, once you "know" it, you should be able to generate any array you can imagine. Feel free to ask questions if you don't understand something. But please, spend a little time with Appendix "C" first.
Don
