• 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.

P3D v4 Model Not Compiling, String Buffer Too Big

Messages
10,088
Country
us-arizona
Hey all,

My model will not compile. It had parts that had degenerate poly's in it. I fixed them all. But now she will not compile. I get a model of about 1.5 KB to 15 KB. It starts in X file form at 19 megs.

This is the build log;
Found dictionary file: ..\..\bin\modeldef.xml
OutputFile: LJ.mdl
Output file after modification: LJ.mdl
Creating output MDL file: LJ.mdl
CRASHTREE no granularity specified
CRASHTREE completed in 00:00:00.3070176
(0): error :
(0): error : ----------------------------------------------------------------
(0): error :
(0): error : XToMdl.exe Unhandled Application Exception
(0): error :
(0): error : System.Exception
(0): error :
(0): error : String buffer length too big
(0): error :
(0): error : ----------------------------------------------------------------
(0): error :
(0): error : Stack Trace:
(0): error :
(0): error : at Microsoft.FlightSimulator.XmlToMdlLib.FileExporter.WriteStringWithSetSize(String S, Int32 iBufferLength)

(0): error : at Microsoft.FlightSimulator.XmlToMdlLib.MDLProcessingContext.WriteTextureList(ArrayList TextureList)

(0): error : at Microsoft.FlightSimulator.XmlToMdlLib.MDLProcessingContext.WriteModelContents(FileExporter Exporter)

(0): error : at Microsoft.FlightSimulator.XmlToMdlLib.MDLProcessor.WriteExteriorModel()

(0): error : at Microsoft.FlightSimulator.XmlToMdlLib.MDLProcessor.GenerateOutput(FileExporter Exporter)

(0): error : at Microsoft.FlightSimulator.XmlToMdlLib.XmlToMdlLib.Process(Guid& ModelGuid, Stream AnimationData)

(0): error : at Microsoft.FlightSimulator.XToMDL.XToMDL.ProcessInputs()

(0): error : at Microsoft.FlightSimulator.XToMDL.XToMDL.RealMain(String[] args)

(0): error : at Microsoft.FlightSimulator.XToMDL.XToMDL.Main(String[] args)



What do you think?

I have some parts that have no texture on them. But usually they show up anyways in P3D. That was the cool thing about P3D is that untextured parts would show up, where in FSX they do not.

This is with the V4 exporter.

Bill
LHC
 

=rk=

Resource contributor
Messages
4,450
Country
us-washington
A "string buffer" is for text, implying the name of something is too long.
 
Messages
10,088
Country
us-arizona
That doesnt seem to be it. Lowered length of names on long names.

This is just a single engine plane. I have a ton more parts in my Learjet. This should export. But I do not have materials on some of the parts. I'll try that next.

I did test exports last night of small parts and part numbers. That worked to a certain point then crashed it again. X files export at about 20 megs, so its exporting from Max fine. Just not compiling (converting) properly at V4 SDK XtoMDL point.
 
Messages
10,088
Country
us-arizona
Created a large sum (8) of test materials today, attached them to the parts. Same thing. If I compile just the wings and fuselage, its fine.
EDIT: Test Materials are P3D Materials.

I did a test and ran it through the V2.x XtoMDL compiler and it made a part that was 22K KB, but nothing showed in the sim (V4). I also ran the same X files through the V4 final XtoMDL SDK and it produces the MDL at 2KB, which of course is a bad file, also doesnt show, etc, etc.

I can export a few parts, but not the big picture. I cannot seem to lock down what parts are doing this. Only if I start adding parts in does the system crash.

Test Materials have no textures (sheets, DDS files).

My standard export procedure is V4 from Max to X, and V4 from X to MDL.
 
Messages
10,088
Country
us-arizona
The fuselage, seats, panel and landing gear arent mapped... I wonder if thats whats doing it?
 

Pyscen

Resource contributor
Messages
2,993
Country
us-texas
Just a thought...

Could it be the length of the pathname and filename together?
 
Messages
10,088
Country
us-arizona
Just a thought...

Could it be the length of the pathname and filename together?

I just checked my BAT file that I run XtoMDL with and found it was still linked into V2.4 SDK, lol... sigh.. I do not know if it was running V4 SDK XtoMDL. Here I thought all this time it was compiling super models via the newest V4. Thanks Doug. Because of that, I found this.

I re-routed things to a smaller location address (my normal C: location for the Lockheed Martin SDK's is on C:, but V4 is in Program files blah blah blah blah... ) So it rerouted to a shorter name location, still no joy. Still a 2KB file.
 
D

Deleted member 1281

Guest
Bill, assuming that either a) a texture name is too long or b) a part name is too long you could explore something like:

In all cases, work from a test copy of the plane.

1) Select all objects and from the material editor assign a uniform, textureless material. Export. If successful you know it's a texture issue. Thereafter, successively reintroduce your proper materials.

2) Carefully go through your list of objects, testing names for proper length or special characters. Look out for trailing spaces, AFAIK they do count.

3) Select objects "by material" and export the selection until xtomdl throws the error.
 
Last edited by a moderator:
Messages
10,088
Country
us-arizona
I'll try exporting several at a time and see which parts bring up the crash and try to hone in on the ones that seem to be possibly causing this. I already know I can export a few before the crash occurs. I tried exporting more and more and then I hit the limit. For some reason, it was 'various' on the parts clusters. Odd... Like some of these did it, some of those did it also.
 
Messages
10,088
Country
us-arizona
I wondered what would happen if I ran the file through MCX. This is the result. At least MCX gives a few more tidbits of detail


gnfgd.JPG
 

Attachments

  • oit045.JPG
    oit045.JPG
    1.2 MB · Views: 204

Milton_Shupe

Resource contributor
Messages
331
Country
us-newmexico
Bill, when I experienced similar problems, as I recall it was due to exporting a mixture of mapped and unmapped parts during development. Mine did not crash, but some parts would show, some not, and it got weird at times. With that knowledge, once I start mapping, I do not export again until all parts are mapped. Not sure if this helps as I am building for FSX and exporting from gmax.
 
Messages
10,088
Country
us-arizona
Thanks for that, Milton. I am mapping. Going to give it another go as soon as I have everything mapped.

I compiled my Lear again and it compiled fine, so I know its the model, and thats the only detail left that isnt 100% with the SDK is unmapped parts. Only a few, but they have a lot of polygons on them.
 
Messages
10,088
Country
us-arizona
Manfred found it! Mystery solved.
I had added a 'grid' texture to the Diffuse material slot to see if my mapping scale was all good and uniform. I quickly found one online, downloaded it, dropped it into my material slot. And so the problem grew.

This is the name. Manfred had found it via a home made program he created that went into the file looking for long names and man, this was a wopper....
seamless-coordinate-grid-background-graphics-vector-20017926.dds

When I got rid of that texture, the model finally exported; 8 megs instead of 2KB.

It also had a double-attachpoint name (for the landing light) attached, which will also kill an export. This is in 'Object Properties' and is the numbered assignment of landing light, which I had one double named as number 2. Changed one to 3 and exported again and the plane showed up.

In Gmax, if you do that, the plane wouldnt export with a double attachpoint number. This exported but showed up invisible.

So........ for future people that have similar issues... Make sure your textures (JPG's, Bitmaps, etc) do not have MASSIVE names...!

Thanks Manfred. I owe you big time.
 
Top