The 47th datablock... CRASH

#1 Maybe a bad datablock, maybe post the log file.. must have more info to compute...
:)

probably an error in the code..

TomFeni

#2 I can't find the log, I can't boot up the console, and I'm using a Mac. Anyone know what the 47th datablock is?

#3 No one knows how to find the log on a mac? or know what the 47th datablock is?

#4 Tyler, I've never sat down in front of a Mac, but I'm sure that it has some kind of file search function, if it doesn't, well I don't even want to go there.

Anyway, fire up whatever type of file search it has, point it to your Torque directory and have it search for "console.log". I would point you to the example directory, but I'm not totally sure of the directory structure in regards to the Mac version. If it doesn't exist, then I'm not really sure what is happening there.

Again, all of this is based upon the reasonable assumption, that 1) The Mac version of Torque writes the log file in the same way, 2) Mac's can search by extension 3) The file is named the same in the Mac version as it is with the Windows version.

The 47th data block happens to be whatever datablock is being loaded after the 46th. I know that might sound like a smart alec answer, but it's not. There is no specific "order" of certain datablocks, it just happens to be the one that for some reason is crashing your build. If you've added anything as of late, I'd look at whatever that might be (a new static object, a new weapon, anything that would create a new datablock and happens to be the 47th one loaded).

Good luck and hopefully someone with a Mac can give you some additional input.

#5 Here's what I found right after the crash:

Loading compiled script gpgt/3DLessons/Volume1/002_ShapeBase/0_Rendering/RenderingLesson.cs.
Loading compiled script gpgt/3DLessons/Volume1/002_ShapeBase/0_Rendering/RenderingLessonDBs.cs.
Loading compiled script gpgt/3DLessons/Volume1/002_ShapeBase/0_Rendering/RenderingLessonMethods.cs.
 ^^^^^^^ Loaded lesson=> ShapeBase Rendering

Loading compiled script gpgt/3DLessons/Volume1/001_SceneObject/Transforms/TransformsLesson.cs.
Loading compiled script gpgt/3DLessons/Volume1/001_SceneObject/Transforms/TransformsLessonDBs.cs.
Loading compiled script gpgt/3DLessons/Volume1/001_SceneObject/Transforms/TransformsLessonMethods.cs.
 ^^^^^^^ Loaded lesson=> SceneObject Transforms

Loading compiled script gpgt/3DLessons/Volume1/000_SimpleSampleLesson/SimpleSampleLesson.cs.
 ^^^^^^^ Loaded lesson=> Simple Sample Lesson

Executing gpgt/data/missions/lessons/LessonsMisson.mis.
Connection established 2358
*** Sending mission load to client: gpgt/data/missions/lessons/LessonsMisson.mis
Mapping string: MissionStartPhase1 to index: 0
MacCarbFont::create - could not load font -Lucida Console-
Loading platform font failed, trying font fallbacks...

I took it right out of the cd, it came this way. I also only put the last few lines since I can't fit the whole thing.

#6 Make sure your file permissions are not all read-only. I'm going to be rebuilding my G5 over the Christmas break, so I'll see if I can replicate it.

#7 Well, I took a look at every file i could find, I seem to have full access to each file, maybe I should send and email with the file over to ya.

#8 I got exactly the same thing in the console.log file when I tried to use the lessons on Mac OS X Leopard, and it does indeed seem to stop on the 47th Datablock (whatever that datablock actually is).

I thought it might have something to do with the font Lucida Console, but installing that doesn't fix the problem. It still crashes, and the last line is suddenly:

Mapping string: MissionStartPhase1 to index: 0

Looking at the crash log seems to indicate that it's a jpeg issue, but I could be wrong. Sadly, I don't know how to tell *which* jpeg.

Thread 1 Crashed:
0   ???                           	0000000000 0 + 0
1   com.garagegames.torquedemo    	0x002e4a90 jpeg_mem_available + 368
2   com.garagegames.torquedemo    	0x002900c8 jpeg_idct_1x1 + 2968
3   com.garagegames.torquedemo    	0x0029044c jpeg_idct_1x1 + 3868
4   com.garagegames.torquedemo    	0x00283bd0 jpeg_stdio_src + 1296
5   com.garagegames.torquedemo    	0x00282c34 jpeg_start_decompress + 164
6   com.garagegames.torquedemo    	0x000655d8 GBitmap::readJPEG(Stream&) + 200
7   com.garagegames.torquedemo    	0x0006c6bc constructBitmapJPEG(Stream&) + 92
8   com.garagegames.torquedemo    	0x0005c180 ResManager::loadInstance(ResourceObject*, bool) + 208
9   com.garagegames.torquedemo    	0x0007565c TextureManager::loadBitmapInstance(char const*, bool) + 204
10  com.garagegames.torquedemo    	0x000759ec TextureManager::loadTexture(char const*, TextureHandleType, bool, bool) + 108
11  com.garagegames.torquedemo    	0x0007859c MaterialList::load(unsigned int, char const*) + 204
12  com.garagegames.torquedemo    	0x00078640 MaterialList::load(char const*) + 80
13  com.garagegames.torquedemo    	0x002616c4 TSShape::preloadMaterialList() + 100
14  com.garagegames.torquedemo    	0x00115e0c ShapeBaseData::preload(bool, char*) + 844
15  com.garagegames.torquedemo    	0x0013d4bc VehicleData::preload(bool, char*) + 28
16  com.garagegames.torquedemo    	0x00145ecc WheeledVehicleData::preload(bool, char*) + 28

Hope this helps resolve things. I shall see if I can write a script to open all the images and then close them again to eliminate corrupt jpegs as a cause.

Jonathan

#9 FIX: The problem can be bypassed by removing the following file:

gpgt/3DLessons/Volume1/010_GameElements/Vehicles/WheeledVehicle/data/Psionic/jeep1.jpg

I was able to put a replacement file in with the same name (and the same visual content) by loading it up in photoshop, saving it as a PNG file, then completely re-loading the photoshop app again with the PNG file, and saving it as JPG again.

That fixed the problem of stopping on the 47th datablock altogether, and the 3D Lesson Kit worked beautifully after that.

Note: I don't know if it was significant or not, but I unchecked the "save thumbnail with image" box which came up whilst I was saving it back to jpg.

Hope this helped anyone reading this thread.

Jonathan

#10 This is on a Mac, right? Try saving the JPG with baseline compression instead of progressive scan to see if that fixes it.

#11 Yes. This was on a Mac. And yes, that did the trick.

Thanks David. :)

Jonathan

#12 Glad it worked. I remembered seeing something on JPG compression on Macs.

#13 Hey guys, I know I haven't posted on this thread for a while, but I just wanted to say thanks! It worked!