Leaderboard

LEGOLAND - State of Modding This topic outlines the progress of LEGOLAND research for modding so that you as a member can get up to speed with the progress on the game and join in! You don’t need to be a programmer to help with this, just a keen eye and some motivation. Many hands make light work, so if you can help please throw in a hand. File Types Extension Progress Tools About RES 100% Yes Resource Volume - The resource archives storing most of the game resources (Legoland.res, Graphics1.res, Graphics2.res) LLS 0% No LegoLand Sprite - These files are compressed image sprites. The format seems to contain multiple images for animations. MAP 0% No MAP file are used for the playable maps in the game. WAV 100% Yes Wave sound file for sound effects. Nothing special needed to play. 3D 0% No Possibly 3D model files that are no longer used. COL 0% No Something to do with colour, possibly not used. CSP 0% No Standardized LL Index File for LLS sprites. Seems to contain a "compilation" of sprites. ILF 0% No See CSP File LOC 0% No Unknown ODF 0% No Possibly "Object Data File". Contains properties of objects. PK 0% No Unknown. There is only one file "pirates song.pk" POS 0% No Unknown but possibly to do with the 3D Model files. RIN 0% No Unknown but possibly to do with the 3D Model files. TXT 100% Yes Standard text document for briefings and level scripts. TSF 0% No Something to do with tile sets. Referrenced by TSM files. TSM 0% No Something to do with tile sets. Referrences TSF files. BMP 100% Yes Standard Bitmap File. SCC 100% N/A Microsoft Visual Source Safe files. Leftover file from development. JBF 100% Yes Jasc Paint Shop Pro files. Leftover from development. STY 100% Yes Microsoft DirectMusic Style. (Thanks LDD Mods) BND 100% Yes Microsoft DirectMusic Band. (Thanks LDD Mods) STR 100% Yes Strings File. BNV 0% No Unknown. Something to do with ride zbuffers. LFM/LMS/LPT/OBJ/LTX 0% No Unknown. Various rollercoaster related files. Current Tools These are the current tools available for dealing with custom LEGOLAND files. RES - LEGOLAND Resource Tool STR - STR Clean Tool Needed Tools We really need tools to deal with the the following files: LLS to BMP, BMP to LLS Edit Index files such as TSM, TSF, CSP, ILF Edit Object Data. For the ODF file format. Map Viewer/Editor for MAP files. Experiments We need members to conduct experiments with altering and swapping files and checking their outcomes. Please post all progress you make on any files. While testing all files is important, the following files are of particular interest: LLS, CSP MAP, TXT (Level Scripts) ODF TSF, TSM Misc Some other pages/topics of interest... LEGOLAND Parameters TCRF Notes Happy modding!

Thanks @legoman99, I've added that information.

Thanks Cyrem. I know that sty and bnd are both DirectMusic Producer files which I've had a small amount of experience of opening them.

Oke i tested the game on my laptop now and i could run the game without a problem. i havent had enhough time to see if the craches still happen but i could run it al fullscreen even tho i tried before to, and then nothing worked. also thank you @aidenpons and @Cyrem for helping, i apriesiate it.

Does your laughably inferior Internet browser have a logo made out of Lego bricks? I didn't think so.

...I may have found my new favourite photographer

Note: I will be adding information on car editing soon. So far this tutorial is best used with just opponent minifigures, and possibly objects, in GAMEDATA. This tutorial will show you how to modify the GDB files in LEGO Racers. These files are used to create the 3D models in the game. This tutorial is listed as 'Advanced' for a reason - 3D modelling in LR is restricted to text-based editing and hence is very tricky and difficult. Until we have a dedicated program for it (if ever), this is the only way to create and edit models. Requirements Decent maths ability >Binary File Editor (Optional) Text editor (Notepad, Notepad++) for jotting down notes (Optional) Advanced image editor (Paint.NET, GIMP, Photoshop) to help visualise models and get coordinates (Optional) >GDBump to make moving objects a lot easier Got all that? Great! Let's get started. Defining Textures The first part of a GDB file lists all the textures that the model uses. This must relate to textures listed in the TDB and MDB files. In CRPELVIS.GDB, it looks like this: k_27 // Materials [1] { "cr_mat" } To add textures to this list, simply add a new line within the curly brackets and enter (in speech marks) your desired texture. This can be a custom one, so long as it is specified in the TDB and MDB files too. For example, if you wanted to add Captain Redbeard’s face texture, you would list it as below. k_27 // Materials [1] { "cr_mat" "cr_dflt" } The number in square brackets tells the game how many textures are listed within the curly brackets. If this is incorrect, the game will crash when entering the race (not the menu, which will load fine). Hence the above code will cause a crash, and must be fixed like this: k_27 // Materials [2] { "cr_mat" "cr_dflt" } Congratulations, you’ve added textures to a model! Note that the game won’t actually use them unless you specify it later on. Scaling This is very easy. All minifigures and parts in the game (both in GAMEDATA and MENUDATA) use the exact same scale: 0.015625. Below is the scale segment of a GDB file. k_33 // Scale (float)0.015625 Modifying this will increase/decrease the size of the minifigure/part. Below is an example where I set the scale to 0.2. Do not set this too large or the game can glitch. When I set it to 2 on Captain Redbeard, he was only visible from a distance at a certain angle. Additionally he glitched out and instantly used a shield and lightning. One last note about scaling: This is the model's scale and not its size. It's like having miniatures at, I don't know, 1:28 scale - they may have different sized models (infantry, vehicles) but they are all the same scale. You should not use this scale to change the size of the model unless you are testing things out. Modelling This is very complicated at first, but once you get your head around the basic concepts then it shouldn’t be too difficult to start drawing 3D objects. LEGO Racers has three lists for drawing elements: Vertices, Indices and Indices Meta. In this tutorial I will be editing the CRPELVIS.GDB file. Vertices A vertices list with just one vertex might look like this: k_2A // Vertices with Colors (X,Y,Z,TU,TV,R,G,B,A) [1] { (float)60 (float)60 (float)60 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 } Notice that this contains one entry (hence the 1 in square brackets), and therefore that a single Vertex entry is nine lines long. It consists of nine attributes: X: x-coordinate of the vertex. Y: y-coordinate of the vertex. Z: z-coordinate of the vertex. TU: where on the specified texture the vertex takes its appearance from. (coming soon) TV: where on the specified texture the vertex takes its appearance from. (coming soon) R, G, B: The colour of the vertex using RGB values. A: Alpha value of the vertex, meaning the transparency of it. Uses values from 0 (0%, clear) to 255 (100%, opaque). Indices An indices list with just one index might look like this: k_2D // Indices [1] { (byte)0 (byte)0 (byte)0 } These specify the Vertices to use when drawing the object. Hence they point to entry locations in the Vertices list, but start from 0 and not 1. So, how do these work? A combination of Indices and Vertexes together creates the 3D object. This is where it can get a little tricky – you’ll need to read this carefully and understand it if you want to create custom models. To help, imagine the object as a mathematical graph with X, Y and Z directions. KEY POINT: The coordinates are a little different here to usual graphs. X moves forward/backward, Y moves left/right, and Z moves up/down. Vertices Each entry in the Vertices list creates a single coordinate in the model. This has no dimensions, it is purely a location. Hence you can have loads of Vertices and not see anything. Indices Indices draw the object using a selection of Vertices. They list three Vertices to draw a single 2D triangle with – one Vertex for each point of the triangle. It is important to note here that Indices create triangles; if you want to create a square then you will need to use two sets of indices. Indices are great because they allow you to use the same Vertex multiple times, saving time and (relevant dimension in) space. Indices Meta This is where both the Vertices and Indices lists are put together to create your 3D model. An example Indices Meta is below: k_2E // Indices Meta [4] { k_27 // Material ID (ushort)0 k_32 // Bone ID (ushort)0 k_31 // Vertices Range (byte)0 (ushort)1 (ushort)4 k_2D // Indices Range (ushort)1 (ushort)4 } The listing system of Indices Meta is a little different. Every k_## section is its own entry, but several of them are grouped together to create one object. Hence the number in square brackets is equal to the number of k_## entries there are. They have four unique sections: k_27: The texture this part of the model uses taken from the Materials list. Starts from 0, not 1. k_32: The part of the model this is. E.g. in a figure, this can be head, chest, legs, etc. Important for animations and hit testing. k_31: The ushort variables specify the Vertex entries this part uses. Not sure about the byte. k_2D: The ushort variables specify the Indices this part uses. Each object requires one k_27, one k_32, and at least one pair of k_31 and k_2D. So, how do you use these in combination? Let’s start by drawing a cube. This is going to be a little tricky, but as it’s among the most basic 3D elements you’ll need to master this before moving on. UPDATE: alan has provided a great image here which visualises the cube you will be creating below. The first step is to create the Vertices list. Remember – the Vertices are the corners of a shape. A square has eight corners, so you will need eight entries. Note that // can be used to create comments which are ignored by the game. k_2A // Vertices with Colors (X,Y,Z,TU,TV,R,G,B,A) [8] { (float)400 (float)400 (float)400 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 (float)200 (float)400 (float)400 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 (float)400 (float)400 (float)200 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 (float)200 (float)400 (float)200 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 (float)400 (float)200 (float)400 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 (float)200 (float)200 (float)400 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 (float)400 (float)200 (float)200 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 (float)200 (float)200 (float)200 (float)0 (float)0 (byte)0 (byte)0 (byte)0 (byte)255 } Here we have defined 8 points, each corner of the cube. This isn’t enough to draw the cube though, as the game doesn’t know how to connect them. Now we’ll use the Indices list to join these dots up. Remember, one index uses three points to create a triangle, and two triangles create a 2D square. Hence a cube, which has six sides, will require twelve triangles (or Indices). KEY POINT: The order you write your three Vertices in a single Index entry is important. Entering them in a clockwise rotation will make that particular triangle visible from the outside only; similarly, entering them anti-clockwise will make that particular triangle visible from the inside only. You will have to choose between clockwise and anti-clockwise dependant on your object’s facing. k_2D // Indices [12] { (byte)1 //Top (byte)5 (byte)4 (byte)4 (byte)0 (byte)1 (byte)3 //Left (byte)7 (byte)5 (byte)5 (byte)1 (byte)3 (byte)4 //Right (byte)6 (byte)2 (byte)2 (byte)0 (byte)4 (byte)6 //Bottom (byte)7 (byte)3 (byte)3 (byte)2 (byte)6 (byte)3 //Front (byte)1 (byte)0 (byte)0 (byte)2 (byte)3 (byte)4 //Back (byte)5 (byte)7 (byte)7 (byte)6 (byte)4 } Each side above has two entries grouped together, or two triangles. Finally we need to merge these two lists together in the Indices Meta. k_2E // Indices Meta [4] { k_27 // Material ID (ushort)0 k_32 // Bone ID (ushort)0 k_31 // Vertices Range (byte)0 (ushort)0 (ushort)8 k_2D // Indices Range (ushort)0 (ushort)12 } The Material ID is set to 0 to use the CR_MAT texture. The Bone ID is set to 0 to use the leg section of the body (which, I'm pretty sure, isn't animated). The Vertices Range starts from (ushort)0 – the first entry – and is set to use the next 7 entries (8 in total) with (ushort)8. Similarly, the Indices Range starts from (ushort)0 – again, the first entry – and is set to use the next 11 entries (12 in total) with (ushort)12. Save this file, launch LEGO Racers, and voila! You should see that Captain Redbeard has disappeared, and is replaced with this: Congratulations, modelling tutorial complete. Texturing Coming soon... And that concludes the 3D Modelling tutorial. Go forth and create custom 3D models in LEGO Racers! You know what? I'm think going to go and make a Small Transport Truck racer mod.