Torque crashes soon after loading .dif

#1 Have you got alot of NULL textures on your object. If so try removing them and adding regular textures. If the object has faces that arent visible in the scene after you build the blocks then they will get culled out by map2dif but if you add a Null texture then somthing happens I think with the collision that throws an error like that.

I have had it happen to me and that was the solution if thats not the case then I hope someone else has an answer for you.

Matt

#2 Matt,
I am using Quark 6.3 or 6.4 (Don't remember) to texture, and it is putting it on all walls. Further more I am using Max to build the buildings and them GLB to export them, when this is done all textures are set to 'NONE' and map2dif complains. So I know when I compile the maps that all of the textures are their.

I went into C:\Torque\math\mplane.h and commented out line 233 and recompiled. now everyonce in a while the game glitches, but does not crash. I can only assume that the glitching is when that error would have occured.

This is a good temporary fix, but right now I am only using the engine to look at the models and correct them. When I am ready to build my world, I will have somewhere between 300-1200 buildings. I wonder how often the glitching will occur then?


Thanks for the thought on this. When I have more time I will read through C:\Torque\math\mplane.h and try to understand what is happening.

Cameron

#3 1. What is GLB?
2. What do you mean the textures are set to 'NONE'? Is that the name of a texture, or are none of the faces textured after export? It seems to me that you have to replace the NONE reference with the proper texture reference before compiling.

#4 Desmond,

GLB = Game Level Builder. I am using version 2.21. And yes "None" is the name of the texture exported by GLB when the model was not textured in 3DSM. Yes after texturing in Quark, all the "None"'s are replaced with the appropiate texture name. For that matter if you do not, you can not compile to dif.

I hope this clears up my ealier post for you.


Cameron

#5 Hmmm, I'm wondering if some extraneous planes are being exported from GLB. I had a similar problem when using GTKRadiant...it sometimes would create orphaned planes that would only appear when viewed with QuArK.

#6 The same thing can happen with the other max2map files out there. Building levels in max just seems to cause lots of problems.

@Cameron: does you level have a lot of complex/rounded shapes?

#7 Ok, here is the thing, I am making buildings (exteriors in max using boxes only. I then export them to map files using GLB 2.21. From their I import them to quark and I do sometimes have bad planes...meaning that I will have a box with 7 sides, (of course one side was broken into 2 triangles) so I delete one of the faces on the side that has 2 faces, and everything looks fine. I texture, export to dif and import into game.

I have re-opened the maps and did every check I could find in quark and everything return normal.

I have noticed something strange, sometimes in quark if I re-texture a map then try to export to dif I get a vslink error? Something about nodes being coplanar. I wrote a perl script that would take the brushes from the working map (before it was texture) and add the textures from the map that gives me errors, then quark exports it to dif just fine. So when texturing quark changes some of the points??? Weird! I do not know if it has anything to do with the no plane problem in Torque, but it is strange.


Cameron

#8 Yes its possible that QuArK will change the coordinates.. But I'm curious about your process; you said:

Quote:of course one side was broken into 2 triangles) so I delete one of the faces on the side that has 2 faces,

Are you replacing two triangles with a quad? It's quite possible the four vertices of the quad are not coplanar and therefore were split into triangles in GLB. Perhaps you should be leaving those as triangles?

#9 Interesting,

I just got this error as well and am only using quark (no other 3rd party app) to build my levels. It apparently didn't happen until I started playing around with some textures that were higher than 128x128 in resolution with one of my interiors. I don't know if this is just coincidence or catalyst as I haven't been able to consistently recreate the error. I reomoved the suspicious interior and the problem stopped. I'm using release 1.2 and had never come across this error in earlier releases until now.

(edit-)
Now that I think about it there was a lot of retexturing previously textured brushes with the higher resolution maps. So there might be something there as well.

-Allen

#10 Hmmm... all of my textures are 512x512...could be why I see it so often.