Jump to content

GDBump 0.9.0-beta.1


le717
 Share

Recommended Posts

 

This program has been superseded!

Please use WillKirkby's GDBump (C#) program instead.

 

 

 

GDBump is a LEGO® Racers modding tool designed to speed up the process of modifying GDB files. It enables users to translate a specific value of all vertex entries in a file - for example, the Y axis - through a simple interface, instead of having to spend a lengthy amount of time doing it manually. This is useful for moving about objects in the game, particularly those made by the developers that can be difficult to edit otherwise. GDBump is best used in combination with the >LR1 Binary Editor.

 

Usage

GDBump.exe [Axis] [Change value] [input file] [Output file]

 

Axis: The axis you want to edit. Possible values are x, y, z, tu, tv, r, g, b, and a, in both upper and lowercase.

Change value: The positive or negative value of your desired change. Prefixing the value with a tilde (~) will replace all values on the chosen axis with the value instead of editing them. RGBa values will be clamped to valid ranges per format specifications.

Input file: Text file containing decoded GDB format structure, as decompiled using the LR1 Binary Editor. Both absolute and relative paths are supported.

Output file: Destination text file for changed values. Both absolute and relative paths are supported.

 

In case you do not know how to access a command prompt, the easiest way is to browse to your desired folder, press and hold Shift then right-click in a blank area, then select "Open a command window here". Windows 8+ users, you can also click the File tab in Windows Explorer and click "Open Command Prompt".

 

Notes

  • Before 0.9.0 beta 1, the parser was not finished, requiring the input files to be formatted in a special way. Consult this file for an example.

Downloads

 

 

  • Like 5
Link to comment
Share on other sites

Firstly, good work, this will be handy.

Can it only increase or decrease the value in the file or can you just overwrite it as well?

 

Thanks. Jimbob told me "hours of work have been reduced to a few seconds with this tool", so I guess it is useful. :)

 

It can only increase or decrease, but I can make overwrite the value. What if the change value was prefixed with an ~, so ~20 would overwrite all values on the selected axis to be 20? That sound good?

Link to comment
Share on other sites

Fluffy Cupcake

It enables users to increase or decrease a specific value of all vertex entries in a file

To be technical, I think the term for moving a thing in any direction in 3D is called translate.

 

Anyway, good job! :D

Link to comment
Share on other sites

To be technical, I think the term for moving a thing in any direction in 3D is called translate.

Blame Jimbob if you want. :P I asked him to write the summary, but I'll fix that bit up. :)

@, replace option has been added using the form stated, will be in the next release. Still, let me know if that sounds good.

Wow, suddenly feature creep and I have not even had a chance to finish the parser. :o

Link to comment
Share on other sites

Thanks again for making this awesome tool, le! It's been very helpful indeed. I do, however, have a couple of bug reports!

 

1) If a calculation results in a number (I'll call it n) where -1 < n < 1, the output includes an 'e' value which causes LR to crash. Confirmed too, by converting the values to decimals and knocking off the extra unnecessary digits, it worked.
 
2) I've tested X and it works fine, however attempting to change the Z value modified the TU one instead.
 
EDIT: D'oh, stupid me. I was still using your dev version.
Link to comment
Share on other sites

If a calculation results in a number (I'll call it n) where -1 < n < 1, the output includes an 'e' value which causes LR to crash. Confirmed too, by converting the values to decimals and knocking off the extra unnecessary digits, it worked.

 

Can you give me an actual number for me to recreate this with and to how many places you trimmed it? That would help in tracking this down.

 

D'oh, stupid me. I was still using your dev version.

 

So I gather the value changing works correctly in the released version?

Link to comment
Share on other sites

 

If a calculation results in a number (I'll call it n) where -1 < n < 1, the output includes an 'e' value which causes LR to crash. Confirmed too, by converting the values to decimals and knocking off the extra unnecessary digits, it worked.

 

1) Can you give me an actual number for me to recreate this with and to how many places you trimmed it? That would help in tracking this down.

 

D'oh, stupid me. I was still using your dev version.

 

2) So I gather the value changing works correctly in the released version?

1) I think I did a change of 130 on the X-axis of CRJMW.GDB. It was either that or KKJMW.GDB, but most likely CR.

 

2) Yep, it works great thanks. :) That, or the fact that I didn't have { } brackets in my first attempt and added them in on my second.

Link to comment
Share on other sites

I think I did a change of 130 on the X-axis of CRJMW.GDB. It was either that or KKJMW.GDB, but most likely CR.

 

For some reason I cannot recreate this in either file. Can you confirm you are using the released version when this happens? If it does happen again, make immediate note of the file used, the axis, the change value, and the results and report them here. :)

Link to comment
Share on other sites

  • 3 weeks later...

GDBump v0.7.0 is released with the follow changes:

  • Add ability to replace all values with desired value by prefixing with a tilde (~)
  • Added axis and input file validation
  • Force (byte) values to be integers
  • Clamp RGBa values into valid ranges

I have not yet finished the parser, but I felt these changes warranted a release. Hopefully I can get that parser done soon. (I have it started, but it's another script that waay out of date now.) If you come across the first bug reported >here, please report it providing the LR file name, axis, change value, and results. I have not yet reproduced this, but it appears to happen.

 

As a side note for any Python devs (QP :P), I have been writing an API into GDBump for use by other applications in case you need the services it offers. Suggestions and improvements welcome. :)

 

As always, download is in the OP, and, as you do, enjoy.

Link to comment
Share on other sites

  • 2 weeks later...

GDBump 0.9.0 beta 1 is out, with some significant changes:

  • Fix bug where RGBa values would not be clamped if replace mode was used
  • More complete file parser
  • Support any indentation size in a file (as in, it can use tab or space indentation, and that will be used)
  • Other minor changes

The big thing here is the more complete file parser. This means you no longer have to format your files a certain way to process them! :D

 

I have labeled this release has a beta for a few reasons:

  • I still have not tracked down Jimbob's reported bug with e values
  • The full parser is a big deal, and it needs through testing

As always, download is in the OP. :)

Link to comment
Share on other sites

Quisoves Potoo

have found a part of the .GDB format that does appear to be documented yet, and it is completely throws off the editing. I will post what I am seeing in a different topic.

Which part? I could probably help you with it.

Link to comment
Share on other sites

 

have found a part of the .GDB format that does appear to be documented yet, and it is completely throws off the editing. I will post what I am seeing in a different topic.

Which part? I could probably help you with it.

Maybe the alternate GDB files, which have NX, NY and NZ (if I recall correctly) instead of RGB? I never got around to testing those, but I do know that they can be swapped into GDB files using RGB values instead and it'll still work.

Link to comment
Share on other sites

 

 

have found a part of the .GDB format that does appear to be documented yet, and it is completely throws off the editing. I will post what I am seeing in a different topic.

Which part? I could probably help you with it.

Maybe the alternate GDB files, which have NX, NY and NZ (if I recall correctly) instead of RGB? I never got around to testing those, but I do know that they can be swapped into GDB files using RGB values instead and it'll still work.

 

 

(NVM, I'll just post it here. :P)

GAMEDATA/COMMON/RRCM.GDB, lines 33-46, there is a 14 structure section instead of the standard 9 structure section.

 

bigger-section.png

 

The added section seem to be lines 39-42. It has the adverse reaction of making the parser jump to line 142 for the next edit, and putting it one index if (e.g it edits z instead of y). Lines 43-46 appear to be the RGBa values, as already known. It appears this happens more than once in the file.

 

That's all I have. Maybe it is what Jimbob said, but that still does not account for one of the new lines, nor how they appear alongside RGBa instead of replacing them.

Link to comment
Share on other sites

Quisoves Potoo

Strange, that looks nothing like the RRCM.GDB on my computer. Has yours been edited or saved by any programs, such as the Binary Editor or GDBBump? Perhaps you should upload the file so I can look at it.

Link to comment
Share on other sites

https://dl.dropboxusercontent.com/u/58490278/Other/GDBump-RRCM-files.zip

 

The file shown in the picture is RRCM-edited.txt, run though GDBump 0.9 (y axis, replace all values with 20).

 

As I said, some extra values somewhere are messing up the parser, so it is possible the file has been mangled. However, I'm seeing the same 14 lines (aside from the 20 values on 34 and 43) in RRCM.txt, which came straight from the Binary Editor.

 

EDIT: Page 2 already?

Link to comment
Share on other sites

Quisoves Potoo

https://dl.dropboxusercontent.com/u/58490278/Other/GDBump-RRCM-files.zip

 

The file shown in the picture is RRCM-edited.txt, run though GDBump 0.9 (y axis, replace all values with 20).

 

As I said, some extra values somewhere are messing up the parser, so it is possible the file has been mangled. However, I'm seeing the same 14 lines (aside from the 20 values on 34 and 43) in RRCM.txt, which came straight from the Binary Editor.

 

EDIT: Page 2 already?

Whatever file is being represented in your RRCM.txt, it isn't RRCM. Nothing, from the scale to the individual values to the number of values, matches with mine. Unless, that is, the 3D files vary between versions. Which version are you using?

Link to comment
Share on other sites

Heeeeey.... QP? Remember when we were trying to figure out why that one 3D model you exported would not load? I think I figured out why. :P

 

So, false alarm. Still, I am keeping the beta label, as it does still extensive testing, and

 

Maybe the alternate GDB files, which have NX, NY and NZ (if I recall correctly) instead of RGB? I never got around to testing those, but I do know that they can be swapped into GDB files using RGB values instead and it'll still work.

 

Jimbob, you should have told me about this before. Now I have to added support for these, which requires another release. :P

Link to comment
Share on other sites

Hey guys, just wanted to say that effective immediately, development of GDBump has been canceled. Instead, you are all to delete whatever downloads you have and immediately start using WillKirkby's >C# version of GDBump, which is much faster and directly reads and writes the .GDB files. No more copy-paste to and from the Binary Editor! Usage is exactly the same as my tool, so nothing much will really change. Source code and all that fun stuff will remain online, but I will not be updating this anymore. Please use Will's version instead. You will be glad you did. :)

Thanks for all your support and help. :)

  • Like 2
Link to comment
Share on other sites

  • ShadowDraikana locked this topic
Guest
This topic is now closed to further replies.
 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.