Military AI Works

John, I placed the DCA textures in my equivalent of your static objects folder, and the fence textures appeared. The next question; why would the textures appear when placed in the static objects texture folder and not appear when placed in the Luke texture folder? Just curious. Thanks for pointing me in the right direction, appreciate it.

Paul

It depends where you have the fence object library.bgl Paul. You obviously have it in your static objects scenery folder and the corresponding texture folder is where it would expect to find the texture and from you are saying, it has. It should also work with the texture in the Hill\texture folder but only if the fence object library is in the Hill\scenery folder. Mine isn't. Is yours - probably not?

John

Along with what John says it also depends what loads first your static objects folder or your Luke folder. If the static objects folder is loaded first then the textures need to be in that texture folder.

This is why we got the global Libs package together.

To save space and trouble, if you have ALL object lib folders loaded before any scenery folders then you do not need the libs in the individual scenery folders, nor their textures.
I can understand that people might be a bit worried about deleting them and the scenery not working but there is a very safe way to prove it.

Rather than deleting the lib from the scenery folder add a new folder in there called 'ARCHIVE' e.g. \Xanadu\scenery\ARCHIVE.
Then just move the lib from \Xanadu\scenery to \Xanadu\scenery\ARCHIVE and test the scenery. When you have proved that there is no issue you can safely remove the contents of the ARCHIVE folder.

When doing this exercise over your whole system I recommend Everything from https://www.voidtools.com/ easy way to search for files in multiple locations. When I cleared my system out I once found an object in 32 separate scenery folders.

Thanks for the information, very helpful. I place scenery object libraries like the MAIW Scenery Library Objects as far down in the FSX scenery library as possbile, just above the generic scenery that comes with FSX. Individual scenery packages are toward the top of the list when opening the FSX scenery library. My understanding is this is how the files should be organized/ordered, correct? My understanding is that by having files organized in this way the generic scenery and third party libraries load before individual scenery, also correct? Sorry if this is very basic.

Paul

You are correct on both counts.
The reason why you had the problem this time was that the lib in Static Objects was loaded so it ignored the duplicate lib in the Luke folder. This you proved in the process to fix the problem.

You had no textures for either installation of the lib. However the reason that they didn't show when you added them to the Luke scenery was that the lib in the Luke scenery is ignored so the textures are never called for.

It therefore goes that you can delete the lib and the textures from the Luke folder as all they are doing is taking up space and may lead to confusion in the future.

Thanks for the explanation Steve, makes sense. However it does bring up another question. A number of the recent packages have used FS9 scenery in FSX. The instructions that come with the packages usually say something like download and install the FS9 scenery, then delete and substitute specific files to make the scenery work in FSX. However, what happens if the FS9 scenery comes with Scenery Library Objects for FS9. Is the FS9 Scenery Library Objects file installed in the FSX Addon Scenery folder and activated in FSX? I'm a little unclear about what to do with the Scenery Library Objects for FS9 in FSX.

Paul

OK, this is what I understand but somebody with better knowledge on this subject will correct me if I am wrong in any aspect.

The base line is that FS9 libs will work in FSX. The only known issues are textures that involve transparency sections, as FSX operates differently in this aspect. The rule here is that if there were problem libs then FSX versions were created.
So the libs will be fine if you have a lib active in FSX. If you are concerned that you don't want FSX libs and FS9 libs mixed up then the solution is quite simple.

If you have a Static Objects folder in FSX for libs then create a 'Static Objects FS9' folder and activate it next to the existing folder making sure that its layer number is one higher, and therefore priority number one lower, than the existing lib. The reason for this is that you can now keep them separate and if you get/find an FSX version of the FS9 lib you can simple add it and remove the older one.
The reason that the layer number of the FSX version is lower is purely so if you mistakenly have both versions installed the FSX one will load first and the FS9 one will be ignored.

What I believe is that the FSX versions of the FS9 libs have kept the same guid numbers for all its objects. This is the only way that an FS9 scenery installed in FSX will still still display the objects after the lib swap. The reason is that the object guid is hardcoded into the bgl. So if the guid is not the same no object appears.

So lets take this a little further.
You have installed the FSX version of the MAIW Global Libs pack. Therefore any FS9 scenery that contains any libs that are contained in the MAIW Global Libs pack can be removed, and their textures. Same principle here. Rather than just plain deleting them it is always better to create those ARCHIVE folders and move the files into those. Much easier to recover if you have an issue. Very easy to finally remove once you are happy.

Now finally the penalty for using FS9 libs in FSX. I am no expert here but it would seem to be connected to the complexity of the objects and the number in view at any given time. If there are very few simple objects in view then the cost in performance is likely to be negligible. However if you have dozens of FS9 HAS objects it seems to me that there is likely to be a bigger cost. Exactly how much only a modeller would be able to quantify.

However it should be remembered that when FSX came out there was many, many stories on how bad the performance was on PCs compared to FS9 and consequently everything had to be optimised for FSX. Things have moved on a bit since then and if you still have the PC performance that you had in 2006 then you have bigger problems. Trouble is people have difficulty leaving behind info that has become irrelevant.
In a nutshell they will not cause you problems. If they did somebody has already converted it.

I think I covered it, even though I made it very boring. I could have made it shorter and simpler with a specific example but I have tried to make it a generic answer.

Very well expressed Steve. That's exactly how I have my libraries set up in FSX.

As you say, FS9 objects with a transparency in them, for example, trees and fences. will not usually display correctly in FSX. The other common problem is co-planar flickering where textures for doors, windows or signs, for example, will flash because they are on the same plane as the underlying wall or door and FSX can't decide which one to display uppermost.

John

Thank you Steve for the recent and massive repaint upload of all current F-35 operators. Since the JYAI model was released, much has happened real world with the F-35 and great to replicate that movement in the sim.

I use the P3Dv5 version
I installed the F-35 packages
Only 1 F-35 at Eglin base
Luke base is empty
The traffic files are in the right place

Anyone got any ideas?

I checked Luke yesterday (P3Dv5) and there are around 20-30 F-35s present using this package, though I needed to recompile the airfield for v5 to get rid of the stock buildings which make a mess of the MAIW airfield! But it sounds to me like you may have a stray FS9 traffic file in there somewhere which will suppress some or all of your AI traffic. It’s worth checking with AIFP.

TimC340 wrote: ↑30 Jul 2022, 03:32 I checked Luke yesterday (P3Dv5) and there are around 20-30 F-35s present using this package, though I needed to recompile the airfield for v5 to get rid of the stock buildings which make a mess of the MAIW airfield! But it sounds to me like you may have a stray FS9 traffic file in there somewhere which will suppress some or all of your AI traffic. It’s worth checking with AIFP.

What is the current F-35 package A,B,C that you are using?
I am a bit confused

Now I see the F-35 squadron at Eglin, but nobody is flying
What is the active period?

Check the flight plan in AIFP. You can then edit it to give the flying rate you want. Make sure your traffic slider in P3D is set to 100%!

Edit: I have two F-35 flight plans for Eglin; one for the F-35As and one for the F-35Cs (both as issued by MAIW). The first has 25 aircraft of the 58th FS, the second has 16 aircraft of VFA-101.

I am grateful for your help

TimC340 wrote: ↑30 Jul 2022, 11:11 Check the flight plan in AIFP. You can then edit it to give the flying rate you want. Make sure your traffic slider in P3D is set to 100%!

Edit: I have two F-35 flight plans for Eglin; one for the F-35As and one for the F-35Cs (both as issued by MAIW). The first has 25 aircraft of the 58th FS, the second has 16 aircraft of VFA-101.

Specifically, which are the two F-35 flight plans files?

I’m not at my computer right now, but both files have ‘Elgin’ in the name.