Show Posts
301
Modifications / Re: Editing arenas
« on: April 30, 2014, 03:33:10 AM »
The first error that you get is the result of Serge's GMF decompiler and the second error which you have yet to see is also the result of an issue in Serge's GMF decompiler. You would have gotten both of these even if you hadn't replaced the saw with the grinder... That said, I think it would be of some benefit to people if I explain how I was able to figure this out and how you can fix both of these errors (both are pretty minor and Serge's tools are still by far the best options for compiling AND decompiling).
For the first error, you're getting the following error message:
This is telling you that while reading one of the *MAP_AMOUNT lines, it found the text "*MAP_DIFFUSE" instead of either the floating point number (decimal) or the "*MAP_AMOUNT" label. In some cases, this is enough information to solve the problem (like if it was a spelling mistake or something dumb like Error #2). In this case, however, it isn't exactly obvious yet but it will undoubtedly come in handy later. It is also worth noting that at this point in time, there isn't much point in clicking the Yes button because you know everything is going to be thrown off by this error. That is to say, because the compiler has already read the text "*MAP_DIFFUSE", it isn't going to find it when it tries to read the next line (it will instead grab the next word in the next line causing this problem to cascade down your file every time you hit yes (things will get skipped however so you aren't actually going line by line down the file)). TTYTT, I have yet to run into a situation that requires me to hit yes on this dialog so I doubt that any of you will either.
The next dialog that appears doesn't have much value to us but its good to know that the compiler isn't still trying to compile our broken GMF in the background. For completeness, the dialog looks like this:
The third and last dialog is usually the most helpful. Basically, it gives you the next 63 characters (after the stuff that has already been read) so that you have an idea of where you are in the file and to make debugging easier. Your dialog looks like this:
Unfortunately, the information that got dumped is identical for all of the textures in this GMF so it doesn't really tell us which one is causing the problem. Without any prior knowledge of what the culprit is after seeing this, you would have to add a unique identifier that doesn't cause the compiler to crash for a different reason. When I first ran into this problem, I changed the rightmost digit of the *UVW_U_OFFSET line into a 1 and then I kept incrementing that number for each of the following *UVW_U_OFFSET lines. After doing this, I then ran the compiler again to see which section was screwed up. In your case, it would have been the Texture for Material 0. That texture looks like this:
Now that we know the general location of our error, we can look back at the first dialog's message to determine what went wrong. Earlier, we observed that the problem had to be one of two things. Either there was a problem with the value or a problem with the label. Because there is clearly a number between *MAP_AMOUNT and *MAP_DIFFUSE and we didn't screw up any of our whitespace, we know that the problem can't be as a result of our value. So what could be possibly be wrong with the *MAP_AMOUNT label? It was spelt correctly... As it turns out, we're looking at the wrong line and, believe it or not, this happens a lot to programmers. We should actually be looking at the line above this because the *BITMAP line read our *MAP_AMOUNT label (sort of like what happens when we hit yes on the first dialog). Now that we're looking at the right line, the problem should be pretty obvious. The decompiler didn't list any sort of image file so the compiler assumed that *MAP_AMOUNT was the name of our file.
The compiler should actually put placeholder text in when this happens because the GMF files that came with the game do. I'd recommend typing "(null)" (without quotes) for the value of *BITMAP. The texture should now read:
This is telling you that while reading one of the *MAP_AMOUNT lines, it found the text "*MAP_DIFFUSE" instead of either the floating point number (decimal) or the "*MAP_AMOUNT" label. In some cases, this is enough information to solve the problem (like if it was a spelling mistake or something dumb like Error #2). In this case, however, it isn't exactly obvious yet but it will undoubtedly come in handy later. It is also worth noting that at this point in time, there isn't much point in clicking the Yes button because you know everything is going to be thrown off by this error. That is to say, because the compiler has already read the text "*MAP_DIFFUSE", it isn't going to find it when it tries to read the next line (it will instead grab the next word in the next line causing this problem to cascade down your file every time you hit yes (things will get skipped however so you aren't actually going line by line down the file)). TTYTT, I have yet to run into a situation that requires me to hit yes on this dialog so I doubt that any of you will either.
The next dialog that appears doesn't have much value to us but its good to know that the compiler isn't still trying to compile our broken GMF in the background. For completeness, the dialog looks like this:
The third and last dialog is usually the most helpful. Basically, it gives you the next 63 characters (after the stuff that has already been read) so that you have an idea of where you are in the file and to make debugging easier. Your dialog looks like this:
Unfortunately, the information that got dumped is identical for all of the textures in this GMF so it doesn't really tell us which one is causing the problem. Without any prior knowledge of what the culprit is after seeing this, you would have to add a unique identifier that doesn't cause the compiler to crash for a different reason. When I first ran into this problem, I changed the rightmost digit of the *UVW_U_OFFSET line into a 1 and then I kept incrementing that number for each of the following *UVW_U_OFFSET lines. After doing this, I then ran the compiler again to see which section was screwed up. In your case, it would have been the Texture for Material 0. That texture looks like this:
Code: (Lines 37-58 of rwarena3.gmf) [Select]
*TEXTURE
{
*MAP_NAME Map #2
*MAP_CLASS Bitmap
*BITMAP
*MAP_AMOUNT 1.000000
*MAP_DIFFUSE
*MAP_TYPE Screen
*UVW_U_OFFSET 0.000000
*UVW_V_OFFSET 0.000000
*UVW_U_TILING 1.000000
*UVW_V_TILING 1.000000
*UVW_ANGLE 0.000000
*UVW_BLUR 1.000000
*UVW_BLUR_OFFSET 0.000000
*UVW_NOISE_AMT 1.000000
*UVW_NOISE_SIZE 1.000000
*UVW_NOISE_LEVEL 1
*UVW_NOISE_PHASE 0.000000
*BITMAP_FILTER Pyramidal
*BITMAP_MAP_CHANNEL 1
}
Now that we know the general location of our error, we can look back at the first dialog's message to determine what went wrong. Earlier, we observed that the problem had to be one of two things. Either there was a problem with the value or a problem with the label. Because there is clearly a number between *MAP_AMOUNT and *MAP_DIFFUSE and we didn't screw up any of our whitespace, we know that the problem can't be as a result of our value. So what could be possibly be wrong with the *MAP_AMOUNT label? It was spelt correctly... As it turns out, we're looking at the wrong line and, believe it or not, this happens a lot to programmers. We should actually be looking at the line above this because the *BITMAP line read our *MAP_AMOUNT label (sort of like what happens when we hit yes on the first dialog). Now that we're looking at the right line, the problem should be pretty obvious. The decompiler didn't list any sort of image file so the compiler assumed that *MAP_AMOUNT was the name of our file.
The compiler should actually put placeholder text in when this happens because the GMF files that came with the game do. I'd recommend typing "(null)" (without quotes) for the value of *BITMAP. The texture should now read:
Code: (Lines 37-58 of rwarena3.gmf (fixed)) [Select]
*TEXTURE
{
*MAP_NAME Map #2
*MAP_CLASS Bitmap
*BITMAP (null)
*MAP_AMOUNT 1.000000
*MAP_DIFFUSE
*MAP_TYPE Screen
*UVW_U_OFFSET 0.000000
*UVW_V_OFFSET 0.000000
*UVW_U_TILING 1.000000
*UVW_V_TILING 1.000000
*UVW_ANGLE 0.000000
*UVW_BLUR 1.000000
*UVW_BLUR_OFFSET 0.000000
*UVW_NOISE_AMT 1.000000
*UVW_NOISE_SIZE 1.000000
*UVW_NOISE_LEVEL 1
*UVW_NOISE_PHASE 0.000000
*BITMAP_FILTER Pyramidal
*BITMAP_MAP_CHANNEL 1
}
You haven't seen this one yet but, after fixing Error #1, you will.
You'll run into this error every time you recompile something using Serge's GMF Compiler (which is the best option ATM).
Since it is so frequent, you'll probably know what to do to fix it without even looking at the third dialog but I'll show it anyways since it might be the first time you've seen this error.
This dump was much more useful compared to Error #1's dump. We can tell just by looking at it that our problem is at the bottom of whatever comes before the *GEOMOBJECT named "sfz1" (please note that the dump shows the closing parenthesis of the previous object). That means we're looking at the *USE FAR ATTENUATION line of this *LIGHT object:
Looking back at our first dialog, it says that it expected to see an equals sign but ran into the 0 instead. Since the decompiler doesn't add this and the compiler expects it, you'll have to fix it manually by changing that line. When you're done, it should look like this:
You'll run into this error every time you recompile something using Serge's GMF Compiler (which is the best option ATM).
Since it is so frequent, you'll probably know what to do to fix it without even looking at the third dialog but I'll show it anyways since it might be the first time you've seen this error.
This dump was much more useful compared to Error #1's dump. We can tell just by looking at it that our problem is at the bottom of whatever comes before the *GEOMOBJECT named "sfz1" (please note that the dump shows the closing parenthesis of the previous object). That means we're looking at the *USE FAR ATTENUATION line of this *LIGHT object:
Code: (Lines 3251-3273 of rwarena3.gmf) [Select]
*LIGHT
{
*NODE_NAME Omni01
*NODE_TM
{
*NODE_NAME Omni01
*TM_ROW0 1.000000 0.000000 0.000000
*TM_ROW1 0.000000 1.000000 0.000000
*TM_ROW2 0.000000 0.000000 1.000000
*TM_ROW3 -0.000002 50.624680 -0.395003
}
*LIGHT_TYPE Omni
*LIGHT_SHADOWS Other
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_COLOR 0xFFFFFF
*LIGHT_INTENS 1.000000
*LIGHT_ASPECT -1.000000
*LIGHT_ATTNSTART 0.000000
*LIGHT_ATTNEND 0.000000
*LIGHT_TDIST -1.000000
*USE FAR ATTENUATION 0
}
Looking back at our first dialog, it says that it expected to see an equals sign but ran into the 0 instead. Since the decompiler doesn't add this and the compiler expects it, you'll have to fix it manually by changing that line. When you're done, it should look like this:
Code: (Lines 3251-3273 of rwarena3.gmf (fixed)) [Select]
*LIGHT
{
*NODE_NAME Omni01
*NODE_TM
{
*NODE_NAME Omni01
*TM_ROW0 1.000000 0.000000 0.000000
*TM_ROW1 0.000000 1.000000 0.000000
*TM_ROW2 0.000000 0.000000 1.000000
*TM_ROW3 -0.000002 50.624680 -0.395003
}
*LIGHT_TYPE Omni
*LIGHT_SHADOWS Other
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_COLOR 0xFFFFFF
*LIGHT_INTENS 1.000000
*LIGHT_ASPECT -1.000000
*LIGHT_ATTNSTART 0.000000
*LIGHT_ATTNEND 0.000000
*LIGHT_TDIST -1.000000
*USE FAR ATTENUATION = 0
}