le717 Posted October 31, 2014 Share Posted October 31, 2014 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 GitHub Binaries ProfessorBrickkeeper, Quisoves Potoo, Fluffy Cupcake and 2 others 5 Link to comment Share on other sites More sharing options...
Cyrem Posted November 1, 2014 Share Posted November 1, 2014 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? Link to comment Share on other sites More sharing options...
le717 Posted November 1, 2014 Author Share Posted November 1, 2014 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 More sharing options...
Fluffy Cupcake Posted November 1, 2014 Share Posted November 1, 2014 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! Link to comment Share on other sites More sharing options...
le717 Posted November 1, 2014 Author Share Posted November 1, 2014 To be technical, I think the term for moving a thing in any direction in 3D is called translate. Blame Jimbob if you want. 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. Jimbob 1 Link to comment Share on other sites More sharing options...
Jimbob Posted November 1, 2014 Share Posted November 1, 2014 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 More sharing options...
le717 Posted November 1, 2014 Author Share Posted November 1, 2014 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 More sharing options...
Jimbob Posted November 1, 2014 Share Posted November 1, 2014 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. le717 1 Link to comment Share on other sites More sharing options...
le717 Posted November 1, 2014 Author Share Posted November 1, 2014 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 More sharing options...
le717 Posted November 18, 2014 Author Share Posted November 18, 2014 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 ), 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. Jimbob 1 Link to comment Share on other sites More sharing options...
le717 Posted November 26, 2014 Author Share Posted November 26, 2014 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! 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 More sharing options...
Quisoves Potoo Posted November 26, 2014 Share Posted November 26, 2014 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 More sharing options...
Jimbob Posted November 26, 2014 Share Posted November 26, 2014 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 More sharing options...
le717 Posted November 26, 2014 Author Share Posted November 26, 2014 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. ) GAMEDATA/COMMON/RRCM.GDB, lines 33-46, there is a 14 structure section instead of the standard 9 structure section. 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 More sharing options...
Quisoves Potoo Posted November 26, 2014 Share Posted November 26, 2014 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 More sharing options...
le717 Posted November 26, 2014 Author Share Posted November 26, 2014 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 More sharing options...
Quisoves Potoo Posted November 26, 2014 Share Posted November 26, 2014 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 More sharing options...
le717 Posted November 27, 2014 Author Share Posted November 27, 2014 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. 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. Link to comment Share on other sites More sharing options...
le717 Posted November 28, 2014 Author Share Posted November 28, 2014 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. Jimbob and Fluffy Cupcake 2 Link to comment Share on other sites More sharing options...
Jimbob Posted November 28, 2014 Share Posted November 28, 2014 Thanks for making this awesome tool in the first place, le, it's been invaluable to my modding. Link to comment Share on other sites More sharing options...
Fluffy Cupcake Posted November 28, 2014 Share Posted November 28, 2014 Thanks for the original creation le717! I will be switching over to WK's version right now! Link to comment Share on other sites More sharing options...
Recommended Posts