• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Problem with Hanger Model

Thanks, Ron!

Hopefully... checking the registry on where the SDK v1.4 is installing to will give us a clue on what directory/ file it is looking for.

Yes. I can confirm that the P3D SDK v1.4 is installed (within the Regedit) as above:

\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\LockheedMartin\Prepar3D_SDK (no space)

Which points to \Program Files (x86)\Lockheed Martin\Prepar3D SDK v1.4.4747.0\

which would then point to Environment Kit\Modeling Kit\3DSM7\plugins\XtoMDL.exe

Everything appears to be pointed correctly - and initializes properly for @TBryson2 - but once attempting to Compile - This is when this error occurs.
 
ronh said:
Sorry to be late, The only thing I can suggest is look in the registry for the SDK you want to use (assume v1.4)
Blender2FSXP3D gets the main folder from there then tacks on Environment Kit\Modeling Kit\3DSM7\plugins\XtoMDL.exe.

You say v4.5 works but not v1.4

The only difference is the way LM has the registry for v2.x and 3.x (32 bit)

HKLM\software\Wow6432Node\LockheedMartin <--- v 1.4

and

HKLM\software\Wow6432Node\Lockheed Martin <-- with a space

You should see setupPath there. Make sure this agrees with where your real SDK actually is.

And it is XtoMDL.exe not XtoXML.exe
Click to expand...

Sorry for the delays Ron. Thank you for the explaination, but for me (maybe) a bit ambiguous. I need specifics. The examples above (mostly) make sense, but is that the complete line in the registry?

My "HKLM\software\Wow6432Node\Lockheed Martin\" "SetupPath" has C:\Program Files (x86)\Lockheed Martin\Prepar3D SDK 1.4.4747.0\
My "HKLM\software\Lockheed Martin\" SetupPath" has C:\Program Files\Lockheed Martin\Prepar3D v4 SDK 4.5.12.30293\

Neither SetupPath's have the XtoMDL.exe in the line and (other than) "default value not set" are the only entries in either place.

Those are the correct address for each SDK

TB2
 
TBryson2 said:
Sorry for the delays Ron. Thank you for the explaination, but for me (maybe) a bit ambiguous. I need specifics. The examples above (mostly) make sense, but is that the complete line in the registry?

My "HKLM\software\Wow6432Node\Lockheed Martin\" "SetupPath" has C:\Program Files (x86)\Lockheed Martin\Prepar3D SDK 1.4.4747.0\
My "HKLM\software\Lockheed Martin\" SetupPath" has C:\Program Files\Lockheed Martin\Prepar3D v4 SDK 4.5.12.30293\

Neither SetupPath's have the XtoMDL.exe in the line and (other than) "default value not set" are the only entries in either place.

Those are the correct address for each SDK

TB2
Click to expand...

It's not in the registry (XtoMDL),... that is specifically within the Toolset script.

TB can you give a full directory tree screenshot of the "HKLM\software\Wow6432Node\Lockheed Martin\" location?

There appears to be a space within your Lockheed(SP)Martin directory within the registry right? or is this a typo?
 
Last edited:
Interesting find. Attached is the registry and an image of the file directory. The one that works HAS a space in it (HKLM\software\Lockheed Martin\) but the one that does NOT work has no space!

I added a space (just to see what happens) and I cannot initialize it in Blender anymore. Add the space back in, and it will initialize. Odd.


Image 5.jpg
 
OK...

As Ron stated, the "\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\LockheedMartin\Prepar3D_SDK (no space) is where it should be pointed at which I confirmed. You posted showed otherwise before, but your latest shows no space between. Your latest post showing the registry with no space is correct.

So, now we are back to square one. From your screenshot, we can also confirm that the "Environment Kit" is showing and correct for the Script to point where the "XtoMDL.exe" is supposed to be. I assume that you have seen the XtoMDL within the "..\Environment Kit\Modeling SDK\3DSM7\Plugins\.." directory?

Also, the script is pointing to is the location of "bglcomp.exe". The location for "bglcomp.exe" (shouldn't matter, the script is looking for "BglComp.exe" specifically) is "..\Environment SDK\BGL Compiler SDK\.."

TB, a shot in the dark, but try right-clicking on each of those ("XtoMDL" and "bglcomp") and see if they are being "blocked" and if they are, unblock them. Shouldn't matter that they don't have the "Run as administrator" boolean box checked, but if you want to do so, do it.
 
Last edited:
Yes, this is becoming a vicious cycle isn't it? I'm quite familiar with troubleshooting, especially from a distance. I'll work with you as much as possible. To answer your questions above,

1. The XtoMDL.exe is within that directory. I also changed the permissions to the entire Lockheed Martin directory so that I have full control. That made no difference.
2. BglComp.exe is indeed in the directory mentioned.
3. Not sure how to see if they are being "blocked". I attempt to run both XtoMDL and Bglcomp as a stand alone, (both platforms) and it only flashes a "command" window for a second, so at least they react in the same manner. Not sure if that helps.
4. I believe the above incorrect address (with the space) is simply because I copied and pasted the address from explorer. It was an oversite and the registry has always had the "no space". Sorry for that confusion, I'll try not to let it happen again. ;)

In doing this digging, I noticed that the directory structure for 4.5 and 1.4 are completely different. I'm not sure if that matters or that has been figured into it. i.e. the XtoMDL in 4.5 is in a subdirectory off of "3ds Max". The XtoMDL in 1.4 is in a sub directory in Modeling SDK. (Not to get too long winded, but can you tell me the difference in the sub directories? In 4.5, it has "3DSM2012, 3DSM2012_x64, 3DMS2014_x64, up to 3DMS2019_x64. I'm assuming the x2012 - x2019 are the years and each one is a newer version respectively?. Also, in the 1.4, it has a similar structure. Same reason?)

I have stated before that the SDK 1.4 works fine in ADE and in MCX. So I don't believe there is an issue with the SDK itself.

If there is anything you need me to send you, or keep digging just let me know. I have successfully been able to use the 4.5 SDK to create the MDL, import it into MCX and then convert it to a FSX MDL that way. Not sure if I'm whacking myself by doing that or not. The original problem is something I can only see in my FSX-SE (which I only use for testing). The original problem does not manifest itself in P3D (4.5)

Good hunting!

TB2
 
TBryson2 said:
In doing this digging, I noticed that the directory structure for 4.5 and 1.4 are completely different. I'm not sure if that matters or that has been figured into it. i.e. the XtoMDL in 4.5 is in a subdirectory off of "3ds Max". The XtoMDL in 1.4 is in a sub directory in Modeling SDK. (Not to get too long winded, but can you tell me the difference in the sub directories? In 4.5, it has "3DSM2012, 3DSM2012_x64, 3DMS2014_x64, up to 3DMS2019_x64. I'm assuming the x2012 - x2019 are the years and each one is a newer version respectively?. Also, in the 1.4, it has a similar structure. Same reason?)
Click to expand...

Between the 2 versions (v4.5 and v1.4) the folders or directories layouts are different, but shouldn't be a problem; the Toolset has locations for the needed files in question. Correct, each year within the directory is the version of 3ds Max. You could change that within the script to correspond to a later version of 3ds Max if you wish. You will have to make sure every location that is referring to the location is identical to each reference of. Yes, v1.4 is structured for the same reasons on the versions of 3ds Max.

TBryson2 said:
I have stated before that the SDK 1.4 works fine in ADE and in MCX. So I don't believe there is an issue with the SDK itself.
Click to expand...

If you are not having any problems using ADE or MCX with P3D SDK v1.4, then I would believe that Blender v2.79b is the source of the problem (maybe how add-ons work). I have seen problems in Blender v2.79b with the Toolset if an SDK was installed after the Toolset was installed/ activated. I'm not sure why though, but the SDK always needed to be installed prior to the Toolset being installed/ activated.

So, I would suggest removing the Toolset from Blender v2.79b. Reboot and then re-installing/ activating the Toolset. When you do re-install the Toolset make sure you have it overwrite any files.

Overwrite.png
 
Hello:

Considering the number of issues TB2 may have incurred with various installations / un-installations / re-installations, I would not rely solely upon the un-install routines provided by commercial or free software packages, or by Windows installer/uninstaller ...to fully remove all residual detritus. :alert:


I suggest using the freeware version of Revo Uninstaller to perform scanning for leftovers after the standard uninstall:

https://www.revouninstaller.com/revo-uninstaller-free-download/


Hope this might prove helpful in the ongoing troubleshooting process. :)

GaryGB
 
THAT DID IT! Removing the toolset, then re-installing it seemed to work! Both SDK's now work! Now I can get on with my previous hassle. LOL! Thanks Doug!

GaryGB, thanks for the tip. I've downloaded it and will test it out shortly. I have no issues with programs that actually help me with routine chores, but leery of just any utility that comes along. I'll take your advice on this one.

TB2
 
Finally!!

After you have mentioned about ADE and MCX working properly with the P3D SDK v1.4 (again), I remembered about the qwerk about add-ons within Blender (not sure or remember if it was version specific or not), jarred my memory (slower than it was before). Very glad that is solved!!

Now, on to Hangar problem!! I had previously compiled it as Gary had done (along with a friend) and I don't remember seeing anything as you did. Will continue this in the other thread!
 
I’ll have to pick this up sometime in the (near?) future. I’ve been too busy, now I may have to run from the hurricane. This has become a low priority as of now.

TB2
 
TB

According to the last update (11:00 pm EDT), looks like from mid through upper coast of Florida will be feeling Dorian, up close.

Be safe, no point in risking it. Completely understandable!
 
Last edited:
Looking at my problem I came across this post, I have the same problem the shiny edges of the face appear shiny cut on a dark, dark texture on a clear texture
I'm also using the P3Dv4 SDK, exporting Blender 2.79 to .DAE and .X formats still has the problem, but with the .3ds export, the problem is solved. But this is not a solution because the model recovers the errors of scale.
I remain convinced that this comes from Blender something must be neglected.

Some glimpses of the problem it is it is even more convainquant when the image moves because its edges sparkle
A.png


B.png


C.png
 
Hello @Cédrice

I don't think your situation matches TB because his problem is with FSX SDK (which he switched to P3D SDK v1.4) only (and still has the problem). His P3D v4.5 version of the hangar works as its suppose to. Blender v2.79b, will not work correctly with P3D v4.5 unless a few things have been done correctly. Are these models using PBR materials and are you trying to export the PBR materials as well through Blender? If so, that will not work. Dae files do not keep PBR materials intact. Also, the areas in question, it appears that the white or gray areas are the problem. You might need to dirty them up somewhat (especially if PBR materials).

You mentioned that you are exporting the model from Blender to a ".dae" format. From there I assume you are then importing into MCX, correct? Again, if using PBR materials, ".dae" files will not keep the PBR materials intact. You also mentioned, about how the texture appears to sparkle, is this a per-pixel basis?

Probably the best thing to help you in your case is to give us the procedures you did after you have imported it into MCX, etc. and maybe include the textures also.
 
Hello,
Thank you for your reply
-I use P3dv4.4 and not the PBR materials in my models
-I do it, I export Blender 2.79b in ".DAE" format and import it into MCX.
- The model is compiled in ".mdl" and then positioned via the "Placement object" button and recompiled in ".BGL" with the "Export scenery" button
_the textures are in ".png" and compiled in "DDS" in MCX.

-I made some attempts with the export of Blender in ".x", the result is the same.
-With the export in ".3ds", there is no problem, but the scale is completely free and the use of shadow is impossible with the models.
 
Hello

I'm not sure what you mean by "... the scale is completely free and the use of shadow is impossible..." when you export to ".3ds"?

If you are using the P3D SDK v4.4 from within MCX (since you are not using PBR Materials), you can use the Toolset (Blender2FSXP3D). From there, you will get a ".mdl file" along with a ".x file" if you wish. Then using MCX, you still can use the "Placement object" button along with the "Export scenery" button and get a ".bgl" file. The ".x file" within Blender may not be compatible with XtoMdl.exe which is a part of the P3D SDK v4.4. The Toolset will access the P3D SDK files accordingly, which will create a ".x file" so that a ".mdl file" can be made.

Another option is to place all the models (.mdl files for each - individually) into a library file (.bgl) then use ADE for placing the models in their locations.

How are the texture files created and saved to a ".png" file to begin with? Is it through Blender or created and brought into Blender (from Photoshop or GIMP)? Might be best if we can see the texture maps.
 
I spent the day doing the tests again without any good results.
For the export in ".3ds" the model is cleaned and good but the scale is completely deranged and incontrolable for the continuation of the development becomes complicated because I use a ground poly for the shadows under the objects 3d

I also exported via (Blender2FSXP3D) without good result.

I created textures with GIMP and I export in .png and introduced in blender

I show you the tests
A.png


Can see the edges that are black

essai_edge.png


With this map the results are identical

essai_edge.png
 
What options when exporting to ".3ds" are being set up at through Blender?

Just wondering, why haven't you updated to P3D SDK v4.5? There were fixes to the texture shading etc. This could be the problem also.
 
Which option should I set Blender before an export "3ds"?

I will try with the SDK 4.5
 
You must log in or register to reply here.
Back
Top