P3D v4 Model Not Compiling, String Buffer Too Big

#1
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
 
#3
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.
 
#4
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.
 
#9
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.
 
#10
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:
#13
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.
 

Milton_Shupe

Resource contributor
#17
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.
 
#18
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.
 
#19
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