Jump to content

Custom GDB is "Unsupported". Can someone help?


J_128
 Share

Recommended Posts

I am working on trying to get a custom track into LR, but I have run into this problem.  When I try to load it, Lego Racers throws this (rather unhelpful) error: 

LRErr-png.png

I have tried several things:  I considered the possibility that LR didn't like that my visual material and my physics material shared a name, but changing that fixed nothing.  I thought that maybe the game was complaining because my BDB file (which, I discovered [though this was probably already known], sits on top of the GDB and dictates what gets culled when) did not line up at all with my GDB, since it was simply copied from the test track, but swapping BDBs between original tracks didn't raise that error.  Another thought I had was that perhaps the presence of a k_33 (Scale) command was somehow messing something up, but again, adding one to an original track's GDB didn't break it.

 

Looking at my GDB in the Binary Editor, everything looks just fine.  I feel it may also be worth noting that Grappigegovert's Track Editor loads everything flawlessly.

Here's what my GDB looks like as decoded by dead_name's Binary Editor: https://pastebin.com/Y3bZaj4s

And here's my actual GDB: 

 

 

I am completely and totally stumped, so thanks in advance for any help and/or insight you can provide.

Link to comment
Share on other sites

grappigegovert

After taking a quick look, I think the problem is that vertex and/or index ranges can only have a max length of 64 if I recall correctly, and your file goes over that.
You'll have to link the different ranges somehow by setting an offset in the vertex range byte or something like that (It's been a while, I'm not sure).
More on that in this and the next posts:


I think this is the main reason why GDB importers never got far :/.
But now that you mention this error, I think it might be possible to just patch around that limit in the exe . . .

PS
You might want to check out this as well:

 

Link to comment
Share on other sites

Hm, okay.  I didn't know about the max length of 64 (assuming that is actually the case).  However, I'm not totally convinced that that is the case, for there seem to be entries in some of the game's GDBs that would defy that.  For instance, TSTK.GDB has this:

k_2E    // Indices Meta
...
    k_2D    // Indices Range
	(ushort)0
	(ushort)87
    ...

and KTTK.GDB has this:

k_2E	//Indices Meta
...
	k_31    // Vertices Range
	(byte)0
	(ushort)6233
	(ushort)19
	...

I do admit, though, I know very, very little of how the "Indices Meta" section works, so maybe those actually aren't in defiance to the 64 limit. 

 

I have read those posts by Sluicer, especially the one on k_2E,  but I didn't really understand it very well.  Probably largely due to the fact that I don't program in C/C#/whatever language he gave the example in.  BUT, maybe I should carefully reread it and see if I can figure something out.  

Link to comment
Share on other sites

grappigegovert
18 hours ago, J_128 said:

k_2E    // Indices Meta
...
    k_2D    // Indices Range
	(ushort)0                  <-- irange_start   - this range starts at the 0-th index
	(ushort)87                 <-- irange_length  - this range contains 87 indices
    ...

 

Ah, well, it looks like the indices range can be larger than 64 then.

 

18 hours ago, J_128 said:

k_2E	//Indices Meta
...
	k_31    // Vertices Range
	(byte)0                     <-- vrange_offset   - vertex offset
	(ushort)6233                <-- vrange_start    - range starts at 6233-th vertex
	(ushort)19                  <-- vrange_length   - range has 19 vertices
	...

 

The length of this range is 19. The range starts at the 6233-th vertex.

I'll give an explanation of what my understanding is of the gdb-files. (might not be 100% correct):

Going with the above values as an example, they mean:
The 87 next indices starting at the 0-th one (87*3 values, one for each corner of a triangle), reference vertices from the 6233-th onward.
So let's say the first few index values starting at the (0*3)-th one are these:

10
8
15
10
11
9

 

The first 3 indices create a triangle consisting of the 6243-rd, the 6241-st, and the 6248-th vertices. (6233+10-0, 6233+8-0, 6233+15-0)
The next 3 indices create a triangle consisting of the 6243-rd. the 6244-th, and the 6242-nd vertices.
As long as the 0 <= index value < vrange_length(19 in this example), the calculation of the index of the vertex that the indexvalue references is simple: vrange_start+indexvalue-vrange_offset.
if not, the indexvalue references a vertex outside of the [vrange_start,vrange_length] offset.
Looking at sluicer's post now, I get confused again, as it looks like his definitions of vrange and irange are swapped.
I'm not so certain anymore, but I think the calculation of what vertex an indexvalue references is this:

check = indexvalue - vrange_offset
if (check >= vrange_length)
{
  vertex = previous_vrange_start + (indexvalue - previous_vrange_offset)
}
else if (check < 0)
{
  vertex = previous_vrange_start + indexvalue
}
else
{
  vertex = vrange_start + (indexvalue - vrange_offset)
}

I hope you can make something of that, and that this information is even correct, because reading back on all this made me only more confused than before.
The above is also what my track viewer uses, and I believe it displays color-based gdbs correctly. (It screws up on normal-based gdbs, not sure why).

Link to comment
Share on other sites

OHHH, so it's start and length.  I was thinking it was start and end.  That actually makes a whole lot more sense.  Thanks!  I'll have to see what I can do with that.  Someday, custom track importation will be made easy (but it is not this day :old_tongue:).

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.