FSX Editing Ground Textures for Updated Airport Scenery

[kmanning]

Hi,
I'm wondering if my posts are being posted because I haven't heard any replies to my questions from anyone in 5 days or more, one from Arno, and one from Gary. Lately, every time I come here, I keep getting repeated messages regarding the use of cookies and the consent of it. I've repeatedly clicked that Accept button, I know 6 or 7 times already, and I'm getting tired of being bothered with it when it should only be done one time. This is the information I keep getting repeatedly:

"This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies."

I should only have to click that Accept button just one time, not repeatedly every time I come here. I'm wondering if this is keeping my posts from being posted or having some effect because nobody is answering my questions and replies, and I have 2 so far that I have not heard from anyone, one to Arno, and another one to Gary. Someone let me know if this is being posted. I still have questions about MCX and I'm not getting any answers.

Ken.

 

[GaryGB]

Hi Ken:

Your post is visible, however I did not see an alert that you had posted.

It is possible that I may get some time free in order to refresh my memory on what you have done so far, and to then reply in further detail tomorrow.

GaryGB

 

[GaryGB]

Hi Ken:

Since you now have the C39 P3Dv4 MDL (packaged as a scenery library object and placed via BGLComp) so that it appears above the FSDT FSX MDL-based C32 marker, you now have the task of changing the Material attributes in MCX Material Editor.

IIRC, you have tested changing the MCX Material Editor Bloom and Specular mapped texture Material attributes for both David's 'worked example' FSX MDL-based C39 object, and your own FSX (...and P3Dv4 ? ) MDL-based C39 object.

But IIUC, you have NOT yet configured the other Material attributes of your C39 object to match all those used for the underlying FSDT FSX MDL C32 marking object:

Path: [FSDT install path]\Addon Manager\Simobjects\Misc\FSDT_KDFW\model.KDFW_sett07_sf\KDFW_sett07_sf.mdl

Model Name: sfondo_kdfw_sett07

GUID: {597118d9-fcec-4bb9-b7a4-77eebc96d523}

Markings - Mapped Texture: KDFW_DET10.DDS


I suggest that you refrain from further efforts to change the 'Z-Bias' and 'Layer' settings, since your C39 object is now 'visible' AGL, and instead now focus on trying to implement appropriate Material attribute settings to make the mapped texture Material for your C32 object display properly above the FSDT C32 marking.

You may wish to do that by importing your P3Dv4 MDL-based C39 object and the FSDT C32 object into (2) side-by-side MCX windows.

Remember: You are working with a P3Dv4 MDL-based C39 object (packaged as a scenery library object and placed via BGLComp), so its BGL should be located within a local \Scenery sub-folder paired with a \Texture sub-folder containing any mapped texture Materials.

The top level folder that those local paired sub-folders are located in, should be added as a new 'active' Area, and positioned physically above any FSDT Area ...in the P3Dv4 Scenery Library GUI stack of Area layers.

FYI: The fact that we may opt to use the term "G-Poly" to describe this particular P3Dv4 MDL-based C39 object (packaged as a scenery library object and placed via BGLComp) which is being used as a textured 'flat' 3D object placed upon the terrain and/or a platform surface at KDFW, is a mere 'technicality' at this point.

The P3D Z-Bias Material Property is only used to align a texture Material mapped onto the top face of that object, so that it 'appears' above (or below) other 'flat' 3D objects aligned with the ground surface at that location when rendered in P3Dv4.

GaryGB

 

[kmanning]

Hi Ken:

Your post is visible, however I did not see an alert that you had posted.

It is possible that I may get some time free in order to refresh my memory on what you have done so far, and to then reply in further detail tomorrow.

GaryGB

Hi Gary,

Yes, that'll be okay, and if its by any chance you need more time, you can do so.


Ken.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-799905

Hi Gary,

Yes, that'll be okay, and if its by any chance you need more time, you can do so.


Ken.

Hi Ken:

It looks like our posts may have crossed on the server; my reply is the post directly above your own latter post:

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-799890


GaryGB

 

[kmanning]

Hi Ken:

Since you now have the C39 P3Dv4 MDL (packaged as a scenery library object and placed via BGLComp) so that it appears above the FSDT FSX MDL-based C32 marker, you now have the task of changing the Material attributes in MCX Material Editor.

HI Gary,
I forgot to tell you that I've corrected the problem I was having regarding that black box with the C32 show through. I think it was because I was importing a C39.bgl file rather than using the C39.mdl file, if I remember correctly. There was one instance where I set my C39 several meters above the ground and I discovered that my C39 was transparent for some reason and I could see right through it, and I think that was why I kept seeing the C39 and the C32 all displayed at the same time. Another reason for the C39 and the C32 being displayed at the same time was because the GPW was not making any changes in the altitude I put in. I could put in 5 meters AGL, and it would not make any changes and it was right on the ground as always. The only way I could get my C39 to display on top of the C32 is that I had to use the Convert and Place Object Wizard. The Ground Poly Wizard would not do anything except place my coordinates. That was the only thing it would do. So why is it that my Ground Poly Wizard is not making these attitude changes as well as the scale? Am I doing something wrong?

I suggest that you refrain from further efforts to change the 'Z-Bias' and 'Layer' settings, since your C39 object is now 'visible' AGL, and instead now focus on trying to implement appropriate Material attribute settings to make the mapped texture Material for your C32 object display properly above the FSDT C32 marking.

Probably not. When you say "Material Attributes Settings," is that the information shown in the large window on the right when I make a selection on the left under Properties?

When you say to implement appropriate Material attribute settings, are you saying to set my C39 material settings with that of the FSDT KDFW_DET10.DDS material settings so that they match, or are identical? If not, then what do you mean, or what do I do to set the appropriate material settings?

You may wish to do that by importing your P3Dv4 MDL-based C39 object and the FSDT C32 object into (2) side-by-side MCX windows.

Okay, I've tried this before replying here, and is this what you mean and did I do it correctly?

I imported the KDFW_sett07_sf.mdl file into one opened MCX and my C39 in another opened MCX. Now, to make the information show up, I had to select one of the items on the left in Properties. I selected the KDFW_DET10.dds. I then set my settings in the C39 to match that of the KDFW_DET10.dds.

You are working with a P3Dv4 MDL-based C39 object (packaged as a scenery library object and placed via BGLComp), so its BGL should be located within a local \Scenery sub-folder paired with a \Texture sub-folder containing any mapped texture Materials.

The top level folder that those local paired sub-folders are located in, should be added as a new 'active' Area, and positioned physically above any FSDT Area ...in the P3Dv4 Scenery Library GUI stack of Area layers.

That could be the problem and I've thought about that. But let me show you something that you may not be aware of, since you do not have P3Dv4. Unless there's another way to do it, P3Dv4 will not allow me to place my active Area above the FSDT. See this screenshot:

As you can see, I have KDFW Ground Poly highlighted. Everything above this are the FSDTs or Flightbeam airport Sceneries. These cannot be selected nor edited using the Scenery Library. Notice that the boxes are grayed out. I assume this is what you're referring to when you talking about the active areas.

I've mentioned earlier about a Folder that's located in the Documents Folder called Prepar3D v4 Add-ons and here's a screenshot:

When I open the Fs Dream Team KDFW Folder, there's an addon xml file show here:

Here's what the xml file shows when it's opened:

Notice in this xml file, it shows the addon name, the addon description, the addon category, and the paths for both the Scenery and the Texture folders which is C:\Addon Manager\FsDreamTeam\KDFW\Scenery, for the scenery folder. From what I understand, FSDT uses this method of add ons in their Sceneries. If I were to remove this xml file, it will wipe out the FSDT KDFW airport scenery as though it were not installed.


Now, the problem I'm having is that my C39 keeps disappearing as I've mentioned before. The C39 displays just fine when I first launch the simulator, and here's the screenshot:

To test this problem each time, I would go to Top Down view and zoom out:

I then put the sim in Slew Mode and move South just outside the KDFW airport boundary. Notice my red crosshair just outside the airport:

Now I slew back to my original position, at C39, and zoom in, and notice what's happened to the C39:

As you can see, my C39 is gone. I don't know if it was placed below the FSDT or if it just simply was written over by the FSDT Add On Manager. This is the strangest thing I've seen, especially when it shows up perfectly when the sim is first launched. I'm beginning to think that it may have been placed below the FSDT because I've tried this trick. I purposely raised my C39 5 meters, or so, above the ground and did the same test by slewing, going south outside the KDFW airport boundary, and returning, and my C39 was still displayed, but maybe slightly lower. But is was still displayed. This tells me that whenever I go outside the airport boundary, something is placing my C39 a little below the FSDT ground. As long as I stay within the airport boundary, it never happens and my C39 remains displayed. Could it be that since I did not used the Push and Pull tool to raise it a little bit in Sketchup, that may be causing my texture to flip or something? It doesn't seem like that would be the problem since it displays perfectly when the sim is first launched.

Anyway, I've tried those suggestions you posted above and it did not make any difference regarding the C39 disappearing, unless I did not understand you correctly or did not do right. But the texture shows perfectly so I guess this is no concern now.

By the way, I've read over your posts regarding using the open and close delimiters a few more times, and hopefully I got it right this time.

Ken.

 

[GaryGB]

Hi Ken:

Congratulations on your success with updating the KDFW ground markings from C32 to C39 in P3Dv4.


In light of Arno's suggestion to make a FSX G-Poly with a SCASM/ASM 'Type-2' RefPoint instead of the default 'Type-7' here:

https://www.fsdeveloper.com/forum/t...d-poly-wizard-even-for-fsx.442902/post-800121

https://www.fsdeveloper.com/forum/t...d-poly-wizard-even-for-fsx.442902/post-800121

What might be possible is that you keep the intermediate SCA file when the GPW saves. If you change RefPoint type from 7 to 2 in there, then you would be able to add an altitude above AGL in the file. Afterwards you need to compile the BGL again.

...I suggest we now try to update KDFW ground markings from C32 to C39 in FSX via a modified SCASM/ASM G-Poly method.

I will post a detailed work-flow to do this tomorrow (Thursday) using the MCX Ground Polygon Wizard (aka "MCX-GPW").

GaryGB

 

[kmanning]

Hi Ken:

Congratulations on your success with updating the KDFW ground markings from C32 to C39 in P3Dv4.


In light of Arno's suggestion to make a FSX G-Poly with a SCASM/ASM 'Type-2' RefPoint instead of the default 'Type-7' here:

https://www.fsdeveloper.com/forum/t...d-poly-wizard-even-for-fsx.442902/post-800121




...I suggest we now try to update KDFW ground markings from C32 to C39 in FSX via a modified SCASM/ASM G-Poly method.

I will post a detailed work-flow to do this tomorrow (Thursday) using the MCX Ground Polygon Wizard (aka "MCX-GPW").

GaryGB

Hi Gary,

I have not succeeded in getting my C39 to remained displayed in P3Dv4. When I first launch the sim, the C39 is displayed. But when I go flying and return back to the airport and back to the same gate, my C39 is no longer displayed. It goes back to C32. The GPs work just fine in FSX. Maybe after we try this new method you're referring to, that will stop the C39 from disappearing. Did you see my post above showing that?


Ken.

 

[GaryGB]

Hi Ken:

I have congratulated you for successfully updating the KDFW ground markings from C32 to C39 in P3Dv4 by achieving display of your custom C39 G-Poly above the underlying FSDT C32 for flights launched at KDFW, since that is a significant accomplishment in and of itself.

However, I do understand that as you have pointed out, there is indeed an outstanding issue yet to be resolved, as to why your custom C39 G-Poly does NOT display above the underlying FSDT C32 for flights NOT launched at KDFW.

Hopefully tests of alternative methods for G-Poly creation and placement may be able to resolve that outstanding display issue as well.

GaryGB

 

[=rk=]

As you can see, my C39 is gone. I don't know if it was placed below the FSDT or if it just simply was written over by the FSDT Add On Manager. This is the strangest thing I've seen, especially when it shows up perfectly when the sim is first launched. I'm beginning to think that it may have been placed below the FSDT because I've tried this trick. I purposely raised my C39 5 meters, or so, above the ground and did the same test by slewing, going south outside the KDFW airport boundary, and returning, and my C39 was still displayed, but maybe slightly lower. But is was still displayed. This tells me that whenever I go outside the airport boundary, something is placing my C39 a little below the FSDT ground. As long as I stay within the airport boundary, it never happens and my C39 remains displayed. Could it be that since I did not used the Push and Pull tool to raise it a little bit in Sketchup, that may be causing my texture to flip or something? It doesn't seem like that would be the problem since it displays perfectly when the sim is first launched.

This is actually a commonly reported situation and it happened to me when I completed a small payware scenery about a year ago. Everything worked great for FSX and P3D, what could go wrong, I was simulating a early century airport - then the client asked for a chalk line in the grass. Well, my ground polys were long completed, 5 seasons of carefully manicured field grass and I wasn't going to mess that all up. So I decided to do it "quick and dirty" the way Ken is doing it, by just running a simple flat polygon through the GPW. Done it before, works great(ish).
I placed the object with IS3 in FSX:SE and transferred the .bgl to the P3D version, where it didn't show up. Further investigation revealed the polygon below the ground, I believe it was 5 cm, but it might have been 5". Manually elevating it with IS3 cured the problem, that's how I'm able to remember it was some specific number. I am sure the polygon probably does that slight elevation reset, as Ken describes about leaving and returning to the airport - the transition, btw, Ken is the boundary where the scenery reloads - however this elevation distance is so slight and the polygon so simple, who is going to notice, or care, that it intersects the tire halfway between the tread and hub; it works.

The conclusion being, Ken, if you've gotten this far, you probably only need to raise the polygon some 5 cm to achieve your intended results.

 

[GaryGB]

Hi Ken:

Bearing in mind that you are 'mostly' satisfied with the current type of MDL-based C39 decal object which you are now able to display above the FSDT KDFW C32 ground marking in both FSX and P3Dv4, I shall set aside my numerous- and thus far unsuccessful- efforts to display a SCASM/ASM G-Poly that uses the Type-2 RefPt code at an assigned elevation AMSL above the FSDT C32 object.

I am tempted to consider a possibility that placement methods for FSX at KDFW by the FSDT Couatl python-based Addon Manager (BGLMANX.DLL ...which IIUC reads / writes FS code registers directly without working through SimConnect) may be able to over-ride SCASM/ASM placement code for objects intended to be placed AGL, and instead forces such objects to render only "on-ground".



The description you posted of the failure for your C39 decal object to display above the FSDT KDFW C32 ground marking when a flight is launched somewhere outside KDFW, raises questions as to whether you may have a possible display priority object draw order issue.

I consider this to be more likely the case, rather than an issue related to placement elevation changing due to priority loading / retention of P3D default versus FSDT custom local terrain mesh, as AFAIK, all objects placed AGL (and not AMSL) will adjust to the local "ground" elevation of whatever terrain mesh is displayed with (current) top priority in the vicinity of the user aircraft position.

Also, the FSDT terrain mesh contains LODs 2-14, which should be loaded / retained by the rendering engine before most default mesh.


However, it would still be worth trying to place the C39 object via BGLComp using AMSL rather than AGL elevation in Meters, in the event that the FSDT KDFW "platform" ground surface objects (all at 185.12 Meters) are- or are not- 'obeyed' by the P3D rendering engine as the new "ground" elevation being referenced by the BGLComp AGL placement code ...rather than the current local top-priority terrain mesh.

But that probably would still not explain the start location distance-related variation in display of your C39 ground marking object.


This P3Dv4 'variable display' as a function of start location for a BGLComp-placed scenery library object (which IIUC, uses Z-Bias) might prove to be a question for Arno, Holger Sandmann, or rhumbaflappy to answer, as I do not yet have P3Dv4 to test with.

GaryGB

 

[kmanning]

Hi Ken:

Bearing in mind that you are 'mostly' satisfied with the current type of MDL-based C39 decal object which you are now able to display above the FSDT KDFW C32 ground marking in both FSX and P3Dv4, I shall set aside my numerous- and thus far unsuccessful- efforts to display a SCASM/ASM G-Poly that uses the Type-2 RefPt code at an assigned elevation AMSL above the FSDT C32 object.

So are you saying that using the SCASM/ASM that you talked about in the other thread by Arno will not work?

The description you posted of the failure for your C39 decal object to display above the FSDT KDFW C32 ground marking when a flight is launched somewhere outside KDFW raises questions as to whether you may have a possible display priority object draw order issue.

Are you referring to the Scenery Priority because I've wondered the same thing? I'll post this screenshot again, which is shown above, of my Scenery Library in P3Dv4. I think you've mentioned several times about the scenery priority:

If you'll noticed, I have my KDFW Ground Poly highlighted, which is where I've been placing the bgls and dds textures, rather than using the FSDT. I've tried it in the FSDT and it gives the same problem. However, notice above my KDFW Ground Poly are the FSDT and Flightbeam studios sceneries. These are at a higher priority than mine, but it will not allow for placing my C39 above those in the list above. Those are placed there by the xml file in the document's folder for the P3D addon. But I've wondered if that could be the problem, as far as scenery priority goes.

I consider this to be more likely the case, rather than an issue related to placement elevation changing due to priority loading / retention of P3D default versus FSDT custom local terrain mesh, as AFAIK, all objects placed AGL (and not AMSL) will adjust to the local "ground" elevation of whatever terrain mesh is displayed with (current) top priority in the vicinity of the user aircraft position.

Well, the MCX GPW seems to place the C39 polygon right on the ground very well, but the C32 was also displayed. It made me wonder sometimes if I could be making it transparent during the convert because I've noticed many times that when it would raise it a few feet above the ground by using the Convert and Place Object Wizard, I can still see right through the C39, even though it's above the C32. But I think it does this when I use the GPW and go back, using the same file, and use the Convert and Place Object Wizard so that I can raise it above the C32. If I use the Convert and Place Object Wizard, and not the GPW, my C39 displayed just fine above the C32, but would be gone when I return from a flight. I understood Arno to say that in the GPW, no matter what altitude I put in, or rather I uncheck the AGL box and enter an altitude , it will not raise my C39, and he was right. That's what I was confused about. I understand that by design, it follows the curvature of the earth and is always displayed at ground level.

If I use the GPW in another airport scenery, payware or default, it places my polygon right on the ground and it displays just fine. It's only in the FSDT that problems like this come up.

However, it would still be worth trying to place the C39 object via BGLComp using AMSL rather than AGL elevation in Meters, in the event that the FSDT KDFW "platform" ground surface objects (all at 185.12 Meters) are- or are not- 'obeyed' by the P3D rendering engine as the new "ground" elevation being referenced by the BGLComp AGL placement code ...rather than the current local top-priority terrain mesh.

I've tried that. In MCX GPW, I unchecked the box AGL, assuming that I can put in the altitude AMSL, which is 607.4 feet or 185.132 meters. I could put in 185.4 but no difference. Even if I put in 600 meters, it was always right on the ground.

This P3Dv4 'variable display' as a function of start location for a BGLComp-placed scenery library object (which IIUC, uses Z-Bias) might prove to be a question for Arno, Holger Sandmann, or rhumbaflappy to answer, as I do not yet have P3Dv4 to test with.

Yes, I sure would like to better understand this as well. Even if the SCASM/ASM has not work, from what I understand you to say, will you still show me how to do this in MCX because I need to know anyway.


Ken.

 

[kmanning]

So I decided to do it "quick and dirty" the way Ken is doing it, by just running a simple flat polygon through the GPW. Done it before, works great(ish).
I placed the object with IS3 in FSX:SE and transferred the .bgl to the P3D version, where it didn't show up.

That sounds basically like what happened to me. I transferred my bgl files from FSX over to the P3Dv4 and guess what, my ground polys would not display. I've always noticed in MCX that there was a selection you can make rather to export, a model or file, as FSX, as P3Dv4, or whatever, and I was concerned that maybe since the bgl files were created for FSX, they would not work in P3Dv4. But they're the same files. They have the same extension so I couldn't understand why they wouldn't work. I tried exporting them in MCX for P3Dv4. I don't recall what happened after that but it probably made no difference.

Further investigation revealed the polygon below the ground, I believe it was 5 cm, but it might have been 5".

How did you determined that it was below the ground?

I am sure the polygon probably does that slight elevation reset, as Ken describes about leaving and returning to the airport - the transition, btw, Ken is the boundary where the scenery reloads

Oh, okay, now that makes more since to me. I didn't even think about that.

The conclusion being, Ken, if you've gotten this far, you probably only need to raise the polygon some 5 cm to achieve your intended results.

Well, I've tried that using the Convert and Place Object Wizard in MCX. Five cm would be 1.97 inches, or 0.164 feet, so that should not present a problem as far as being too high off the ground. The ground is 185.132 meters and I've raised it to 185.4 meters. That's 10.5 inches off the ground, which is pretty visible, and I can see a portion of the C32 below the C39. So, that 0.628 Meter increase, or 10.5 inches would be very noticeable pulling up to the gate. You don't notice that when you look at it from the Top Down view. So even with that much of change, when I come back to the gate, my polygon is always gone. I'll go ahead and try that 5 cm increase and see what happens. Thanks for your suggestion.


Ken.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-800496

So are you saying that using the SCASM/ASM that you talked about in the other thread by Arno will not work?

No, I stated that my efforts thus far were unsuccessful, and that I intended to set that matter aside at this time.

FYI: Even if you got the SCASM/ASM G-Poly method to work, the resulting G-Poly would not display with all the other Material Properties of a MDL, thus it may not look sufficiently identical to the FSDT C32 ground marking, and may thus prove to have an unsatisfactory appearance compared to the MDL-based G-Poly (aside from the 'flickering' anomaly seen in FSX top-down view).

I shall not plan to further test the SCASM/ASM G-Poly method for this particular FSDT KDFW airport, and I do not plan to allocate any of my further limited available free time to tutoring you on how to perform that work-flow, because, as I have stated previously on more than one occasion, it is "impractical" to do so.

I suggest that you consider making the best that you can of the current FSX and P3Dv4 MDL-based methods, and wait for the "official" FSDT KDFW update.

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-800496

Are you referring to the Scenery Priority because I've wondered the same thing?

I'll post this screenshot again, which is shown above, of my Scenery Library in P3Dv4. I think you've mentioned several times about the scenery priority:


If you'll noticed, I have my KDFW Ground Poly highlighted, which is where I've been placing the bgls and dds textures, rather than using the FSDT. I've tried it in the FSDT and it gives the same problem. However, notice above my KDFW Ground Poly are the FSDT and Flightbeam studios sceneries. These are at a higher priority than mine, but it will not allow for placing my C39 above those in the list above. Those are placed there by the xml file in the document's folder for the P3D addon. But I've wondered if that could be the problem, as far as scenery priority goes.

As I have informed you previously on more than one occasion, I do not have P3d4 to test with.

However, as I have also mentioned previously, based on a review of available SDK documentation, the P3Dv4 Scenery Library is apparently capable of working exactly the same as the FSX scenery library.

The P3Dv4 Scenery Library is apparently also capable of working with the add-on XML file format to configure scenery library Area layer display priority.

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-798129

https://www.prepar3d.com/SDKv4/sdk/add-ons/add-on_packages.html


This is just an "educated guess", but it seems possible that you are being 'restricted' from exerting full manual control over your P3Dv4 Scenery Library GUI Area layering positions due to your having used the "Prepar3D v4 Add-ons" XML method to link P3Dv4 to your scenery files.

I suggest that you NOT do this, and that you remove any of your own scenery files from such an add-on XML configuration file mechanism.

I would also suggest that you NOT place any of your own scenery files within any sub-folder of the FSDT folder chains to load via such a FSDT add-on XML file.

I would recommend only using the 'standard FSX method' to add a new Area to the top position on the stack of Area layers of the P3Dv4 Scenery Library GUI.

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-800496

Even if the SCASM/ASM has not work, from what I understand you to say, will you still show me how to do this in MCX because I need to know anyway.

Again, I shall not plan to further test a SCASM/ASM G-Poly method for this particular FSDT KDFW airport, and I do not plan to allocate any of my further limited available free time to tutoring you on how to perform that work-flow, because, as I have stated previously on more than one occasion, it is "impractical" to do so.

If Arno is not willing to post a SCASM/ASM code example of how to make such a G-Poly using a Type-2 RefPoint in an otherwise 'working' *.SCA file that can be compiled using SCASM.exe, I shall suggest that you consider making the best that you can of the current FSX and P3Dv4 MDL-based methods, and wait for the "official" FSDT KDFW update.

GaryGB

 

[kmanning]

No, I stated that my efforts thus far were unsuccessful, and that I intended to set that matter aside at this time.

Okay, I see.

As I have informed you previously on more than one occasion, I do not have P3d4 to test with.

I know you don't have it. I just thought you were going to test it out using FSX.

However, as I have also mentioned previously, based on a review of available SDK documentation, the P3Dv4 Scenery Library is apparently capable of working exactly the same as the FSX scenery library.

The only difference I know is that you have to be in the sim in order to add a scenery, that is, you're at an airport in your aircraft, as opposed to after the loading screen in FSX.

The P3Dv4 Scenery Library is apparently also capable of working with the add-on XML file format to configure scenery library Area layer display priority.

It may be but I haven't figured out how to move my layer above the KDFW FSDT. It won't allow you to do that in the Scenery Library. I'll read over that SDK add-on package.

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-798129

https://www.prepar3d.com/SDKv4/sdk/add-ons/add-on_packages.html

This is just an "educated guess", but it seems possible that you are being 'restricted' from exerting full manual control over your P3Dv4 Scenery Library GUI Area layering positions due to your having used the "Prepar3D v4 Add-ons" XML method to link P3Dv4 to your scenery files.

I suggest that you NOT do this, and that you remove any of your own scenery files from such an add-on XML configuration file mechanism.

I would also suggest that you NOT place any of your own scenery files within any sub-folder of the FSDT folder chains to load via such a FSDT add-on XML file.

I've done all of that some time ago. I'm placing all my work into a folder named KDFW Ground Poly and placed this folder in C:\Lookheed Martin\Prepar3D v4.

I would recommend only using the 'standard FSX method' to add a new Area to the top position on the stack of Area layers of the P3Dv4 Scenery Library GUI.

It's at the top position of the stack of layers, but not above that of KDFW FSDT. That may sound strange but you have to look at the screenshot I've posted above to see what I'm talking about, which I'm sure you already have.

Again, I shall not plan to further test a SCASM/ASM G-Poly method for this particular FSDT KDFW airport, and I do not plan to allocate any of my further limited available free time to tutoring you on how to perform that work-flow, because, as I have stated previously on more than one occasion, it is "impractical" to do so.

I guess I would have to agree since you've said it's impractical. It's just strange why everything worked in FSX but not in P3D. This is just a guess, but it seems to me that P3D has implemented some type of lock-out so that objects created by users will not display, or display properly, in 3rd party add-ons like FSDT and Flightbeam, and why they use that xml method. I would not want you to waste time on this if you know it's impractical. But thanks for helping out, but it all was not for nothing because I did learn many things. When I asked about how to use the SCASM / ASM, it was not necessarily for the purpose of using it with my C39 work. It was for the purpose of learning how to use it, how it works, what it does, and to have a better understanding of what SCASM / ASM is.


Ken.

 

[kmanning]

Hi,

I was wondering if my Alabama Scenery that I have installed in FSX will work in P3Dv4, or do I have to specially get the one for P3Dv4? Mine is version 2 but they do have a version 3 that is for both FSX and P3Dv4. I'm thinking it may pay off just to get the version 3.

Ken.

 

[pinkjr]

So was the method I presented on page 2 "good enough" for this application?

 

[kmanning]

So was the method I presented on page 2 "good enough" for this application?

Hi David,
If you're referring to the ground polys I've been working on, they won't remain displayed using this method in P3Dv4. It worked fine in FSX but it will not remain displayed in P3Dv4 if I go a few miles outside the airport boundaries. Gary stated that he does not have P3D to perform any tests. But if you, or anyone for that matter, has successfully installed these ground polys in P3Dv4, will you let me know. But so far, I haven't heard anyone come forward and state that he has successfully made these ground polys remain displayed after returning back to the airport in P3Dv4. When you test it, it will display when you first launch the sim, but when you go a few miles outside the airport boundaries and return, you may find that your ground poly is not longer displayed. I've done everything I know how to do and they will not work.

Ken.

 

[GaryGB]

Hi,

I was wondering if my Alabama Scenery that I have installed in FSX will work in P3Dv4, or do I have to specially get the one for P3Dv4? Mine is version 2 but they do have a version 3 that is for both FSX and P3Dv4. I'm thinking it may pay off just to get the version 3.

Ken.

Hi Ken:

IIUC, your post quoted above was intended to be posted in your other thread on the topic involving MegaScenery Alabama products:

https://www.fsdeveloper.com/forum/threads/how-do-i-cover-a-portion-of-a-photo-real-image.441699/


I have posted a reply there.


GaryGB

 

[pinkjr]

I don't have P3Dv4 myself. I'll probably get it when v8 comes out. LOL