Leaderboard

Hello friends, The moment is here. LEGO Racers Online (not finished) and the LEGO Racers API (mostly finished, but needs new functions all the time) are now published on GitHub as an open source project. I don't know how Git exactly works and the source code is published to the development branch. I would love to see if you guys could contribute in this project and create forks so I can merge them into the master project. I will review all submitted code and if the code has a good quality, I will add it to the development branch (which had to be the master branch actually). Don't ask me how to put this project Visual Studio, because I don't know how to. Please contact Grappigegovert for more information about this as he done this before. One important thing to remember The software is not complete yet and does probably not what you expects it to do! It's possible that it's not even running online functionality yet/anymore because of the latest developments. This can be fixed easily, but I didn't have time for this last weeks. I am not going to contribute much on the project too for the coming months due to school. Requirements If you want to contribute to the master code, you will need a free GitHub account. Visual Studio (2013 if you don't want compatibility issues) A fresh brain because developing on this project is sometimes a pain in the ass Credits Me: Client, Server, Library and the API. Grappigegovert: massive, massive research for the API. This guy created most of the API functions. Repository You can find all code on the following page: https://github.com/Hoithebest/legoracersonline/tree/development Remember to select the development branch, NOT the master branch! Please create forks and submit them if you would like to contibute. Information about the Solution Some information about the Solution. All code is written in C#. Client Type: executable This Visual Studio Project contains the Client software which allows players to connect to the Server. It uses the LEGO Racers API to control the game. All game controlling functions should not be developed in this project but in the LEGORacersAPI project as this provides the core for communicating between C# and the LEGO Racers game process. LEGORacersAPI Type: class library (outputs a DLL) This Visual Studio Project is considered as the core of the whole project. In the beginning of this project, all game controlling functions were built into the Client directly, but for flexibility, the LEGO Racers API deserved an own Visual Studio Project so it could be reused in other projects too. The outputted DLL can be loaded into other projects to build mods for LEGO Racers. Library Type: class library (outputs a DLL) The library contains information that both the Client and the Server need to know about. Things like participants are stored here. The outputted DLL is being loaded in the Client and Server software. Server The Server software stores all data that the Clients sends to it. When Clients send data to the Server, it processes the requests and returns a response that the Client will process again. The Server is also capable of starting races (mostly). Communication between Clients and Server There are multiple requests a Client can do to the Server. This can be done using TCP and UDP. The following things are being sent through TCP: Connect to a Server When a player wants to join a Server, a request is sent to the Server, which checks if the entered username is still available. It sends a responsive whether the joining was successful or not. Start a race When the Server hoster starts a race, all participants (racers) receive a TCP packet containing the level information. Using a Power Up When a player uses a Power up, this is sent to the Server through TCP, which sends it to all other players in the game (TCP too). For the requests being sent in a loop, we use the UDP protocol which is not as reliable as TCP is, but for those requests is doesn't care when a packet dies on its way to the Server or Client. The following things are being sent through UDP: Sending and receiving coordinates The current player coordinates are being sent with a very low delay. The Server stores this information and returns the coordinates of all the others players as a response. (Settings are also sent in these packets, but this has to change in the future.) To-do list The following things have a high priority in order to build further on the project: Starting a race from the Server Trigger the Initialized (in the API) correctly I will add more to-do items later, as the list is much longer than mentioned above (can't think about more right now, it's been a while since I have been developing on the project). When coding, please think of the following things: Put as many comments as possible in the code, ESPECIALLY WHEN WORKING ON THE API. CODE WITHOUT COMMENTS ABOVE FUNCTIONS WILL NOT BE ACCEPTED IN THE MASTER CODE! Work with as many classess as possible because this will make it easier for other developers and for extensibility. If you need more information, please comment in this topic and I will add the answers here. Happy coding friends!

This sparked my interest. I began looking at the original method with SoX, and after some trying, I got it to work. It turns out that the format is IMA ADPCM, instead of VOX, and has a sample rate of 22050hz, with 2 channels. The two channels are merged into one file by using one byte from the left channel, and then one byte from the right channel, and so on. Here is how to make proper tun files: 1) Create two separate ima files with SoX using the commands: sox input.mp3 -r 22050 channel1.ima remix 1 sox input.mp3 -r 22050 channel2.ima remix 2 (input.mp3 is the input file, -r 22050 specifies the sample rate, remix 1/2 is to select 1 channel at a time) 2) Merge the two ima files I made a small command line tool to do this: http://oresome.rockraidersunited.com/download/186 Use it like this: ima2tun channel1.ima channel2.ima output.tun This creates a file output.tun from the two channels. (it also adds the header needed for a tun file) 3) Profit! ima2tun can also be used the other way around (to convert a tun file to two (headerless) ima files) with: ima2tun input.tun channel1.ima channel2.ima

I've been wanting to give this a try for a while, and now I finally have the time and resources. We're playing a LEGO game. But not just any old LEGO game. Continue on, dear poster. https://www.youtube.com/watch?v=zXYENUqEzbk&feature=youtu.be

Yes, but that that brings up the question: why would you go through that much effort for such a (terrible) game as GALIDOR?

I'm going to say the exact same thing I've said 60 times. I'm not in this for the games or to win, and I don't need points at all. I couldn't care less about competition. I'm simply posting because I find it entertaining to imagine what my RRU-persona would be like as a super-villain. I like going into Garry's Mod, taking what I've seen from the already done comics, and turning it into a new segment. Regardless of how this thread continues, I'm going to keep posting my comics in here because this is the most relevant place, and because if you guys want, you can consider me like an obstacle that you all have to get past in one way or another. The Pants Enforcer has finally got himself a temporary base on the surface of Earth, because ships aren't good for hiding. He's also hired a party of bounty hunters to help him. A weakness is discovered! If somebody were to capture HK-47, they could hack him and gain access to the Pant's Enforcers second-in-command. But, looks like an invasion of RRU Tower is planned. Why? What for? And what or who is Subject Zero?

As requested above, I will put the source code of the entire project on GitHub soon. Due to school I just don't have enough time to do this on my own. I will keep you guys updated.

Completed: --> Veronica Voltage <-- --> Basil the Batlord <-- ------------------------------------- In progress: -Rocket Racer- Finished: 2 faces WIP: 4 faces / chest / helmet / legs -Commander Cold- Finished: helmet / chest WIP: 6 heads

Includes versions both with and without pants. Overrides Riegel's original textures in game dataALIENS. The skin does not interfere with the low-poly environment Martians, but the one piloting Riegel's mech still has teal skin. Once I have found the textures for them and the .md2 file for the mech, an updated version will make the pilot green while leaving the others teal. https://ore.rockraidersunited.org/legacy/LR2_Green_Riegel_333955.zip

Tell me, does 44100hz work? Ever other time I've tried where someone says 22050 is the only working hz, the double of it, 44100, usually worked too.

Nobody is perfect. Everyone is unique. You only have one shot at making an impact on the world, don't waste that chance. Do things you want to do, follow your dreams like a bloodhound glued to a GPS... And most importantly, don't stop believin' in yourself. That is all. :P

Well that makes complete and utter sense. By chance, were the game devs writing the plot for this game with their feet too? And were they also programming this with their feet? Because it sure as heck looks like it.

The removal of my Third Group turned into regret. Fund-our-corp (now with their fuel problem solved) is back, but this time with a slightly different goal;

I'm not sure if this belongs here, since Skyboxes are gradients, rather than textures, but they change in-game visuals, so it's sort of fitting, I suppose. Anyway, I created some personal in-game backgrounds (skyboxes), based on the backgrounds from box deisgns and catalogues. Since LR1 skyboxes are defined by a mere three colours, the possibilities are sort of limited, but I chose to share this anyway... NEW DOWNLOAD-LINK: https://ore.rockraidersunited.org/legacy/Skybox_291626.zip SCREENSHOTS:

Hang on. Galidor wasn't originally released on PC back in 2003? I seem to remember there being an article in the LEGO Magazine that I thought showed screenshots and tips about the game, along-side BIONICLE: The Game. I guess that doesn't mean it was actualy released, but I though it was. BTW, a lot of laptops have number-pab input via FN + other keys. It's also possible to script some with autokotkey.

That doesn't look like a question mark to me... it looks more like a cedilla: Ç . So it sounds like you badly screwed something up in the font files. Also, can you put the image as large in the OP? Just go to it in the gallery, click "Options" and then "View all sizes," then go to Large, then click on the image itself so you have the image and the image only on the screen, grab the url, and then use BBCode.

" title="External link">don't stop believin' in yourself. I'm not clicking that link. You've betrayed my trust one too many times.

As the one who started all of this, I feel responsible for sorting all of this out. Unfortunately I have absolutely no idea what is even going on right now, so that'll be a bit difficult. Someone feel free to explain it to me. What I can say, in general, is that we have strayed a lot from the original point. I noticed it a long time ago, before any of this controversy began, and I simply left it be thinking that, maybe this is a good change, a natural evolution? Maybe it'll be good for the thread? I wish I had said something back then. See, it all started when people started posting multi-panel comics. This is an art battle, not a comic battle. The idea was to post funny pictures to counter someone else's funny picture. With each person contributing a single panel, a single solitary event. Somewhere along the line though you guys got a little too ambitious, started taking the story a bit too seriously. Now we've got people posting entire chapters, planning out storylines in advance, trying their hardest to make the story go exactly their way, the way they want it to go. That's not what we're supposed to be doing here. It's about improv, people. It's about each player adapting to the actions of their opponents, That's what makes it fun, and interesting. I'm not sure exactly where to go from here, as I'm not really sure where we are at this point. Like I said it'd be nice if someone filled me in on the details. But it''s obvious I have to think of something, just give me some time.

While I'm not going to demand a stop to the story. I do agree with Ben that things have gotten a little sidetracked. Though i think the reason for this is mainly due to the title of the game Art Battle, with a name like that its no wonder people are going to come up with everything that has to do with conflicts and... well... Battle. I believe that Nobody is in reality responsible for this mildly inconvenience, everybody just did what they believed that they should do with the best of their ability. Lets just keep going for now, but once we call this battle over, we should discuss about the future of this game so that we can all get a better idea on how we can keep everybody happy.

Phantom Terror complete. I had originally intended to post him at the same time as Pereki but I got stuck on some details and took longer than expected, so i went ahead and posted Pereki first. And now, together!

It looks like I managed it. This is the test track. The red triangles are the ones with vertices at the end of the previous vertex range. I could handle them also the last time. The blue triangles are the ones that did not work. Now they work. The reference vertices at the beginning or the previous vertex range. I tried to replace the test track with a very huge quad but the game (and the explorer and my pc) crashed. I think I will have to change small things first. Here are exports of two other gdb files of the RACEC0R1 folder: SHIP01: and LINE06:

LEGO Racers: The structure and values of AI path files NOTE: The following information was generally obtained by testing with the .RRB file of one racer on Royal Knights Raceway. I'm not completely sure, but the information about to follow will apply to other .RRB files in the LEGO.JAM too. Values in code tags apply to the boss racer on Royal Knights Raceway. This topic is not (yet) a full documentation of the regarding files. Tools used to gather this information are JMMB's Jam Extractor and origamyguy's Binary File Editor. I know that it is confirmed that .RRB files are the path files for an AI, but I have not found a good documentation of these files yet. I've been working a lot with these files last week, and would be glad to share the information I gained from working with these files. I will discuss the main values/structure of an .RRB file, and explain what value does what wherever I can. Some information that follows is already known by some or many, but I felt that I should include most, if not all, information of these files here. If I missed out information, or if you know more that adds to the understanding of these files, I'd be glad to hear from you then. To start off with, where can these files be found? Each track folder (RACEC*R*) in the LEGO.JAM contains a certain amount of .RRB files, mostly around 15 or so (adding up to about three for each AI). Only the TEST folder doesn't contain these files, because an actual race was never meant to be held on that track. Therefore, there aren't any path files there, or checkpoints and so forth. How are these files named? The .RRB files are named like this: Rx_y_z.RRB, where the red letters are variable for the file name. x is defined as 0, 1, 2, 3, 4 or 5. These numbers represent an AI, with 1 being the boss racer, 2 being Governor Broadside/Islander/Willa the Witch/Black Knight, 3 being Rob-'n-Hood/Royal King/Blackjack Hawkins/Admiral etc. The .RRB file with 0 is not found in all racetrack folders, as this file is the path for the demo, which is King Kahuka by default. y is defined as F, M, S. These letters might represent the speed of an AI's path, perhaps for reference to the designated AI, where F would be fast, S would be slow, and M would be, eh, Medium? These letters however do not have any influence on the speed of the path of an AI. Changing the letter in the file name won't do much to its path speed. Velocity is defined in the .RRB file itself, and I will discuss this later on, when we get to the contents of the .RRB file. z is defined as 0, 1, 2 or 3. These numbers probably represent a path number. Then it would mean that every AI has a minimum of 2 paths, and a maximum of 4 paths (I've seen racers with just two .RRB files, and racers with 4 .RRB files, and ofcourse others with 3 .RRB files). What happens when I delete or replace .RRB files from a track folder? Nothing really happens to an AI's path, when you remove certain .RRB files. Only when the first of all paths, being Rx_y_0.RRB, is deleted, the AI will not move from its startposition. Even pushing the AI won't work, it will be stuck at his startposition. When deleting the other paths for the AI (but leaving Rx_y_0 in the folder), it will move and continue following this remaining path. Thus, removing all .RRB files means that the AI is stuck at his startposition. Adding, or rather replacing the .RRB files with those of another track simply makes the AI follow this replaced path. For example, replacing the boss's Knightmare-Athon path with the one from Magma Moon Marathon makes the boss follow the latter path on Knightmare-Athon. This path obviously isn't aligned with the Knightmare-Athon track, so you would see the red dot on the Knightmare-Athon map 'floating' around the actual track. How is an .RRB file structured? Elements of an .SPB file can be found in the .RRB files as well. These elements are the startpositions and their respective rotation. However, an .RRB file has many more code lines, and only applies to a single racer, an AI. The main structure of an .RRB file is shown below. The code lines are divided in seven groups. I left out the other 681 nodes, for an obvious reason. k_29 (float)356.9742 (float)210.8356 (float)0.199971 k_28 (float)0 (float)0 (float)-0.704013 (float)0.710187 k_2A (float)367.861 (float)210.6208 (float)0.19997 k_2B (float)0 (float)0 (float)-0.765386 (float)0.643571 k_2C 77536 k_2D 464 k_27 // Nodes [682] { (f16)0 (f16)0.02734375 (f8)0 (f8)0 (f8)0 (f8)10.4375 (f8)5.625 (f8)2.5 (f8)2.5 (byte)193 ... } What are the values for in an .RRB file? The values in an .RRB file vary from defining the startposition of an AI, to the waypoints it has to follow in a race. These values are appearing as integers, floating points and bytes. How is a startposition set in an .RRB file? The floats under k_29 and k_28 are the same for all path files of a single racer of a track. For example, the following files share the same floats in the .JAM archive (providing they are located in the same track folder): R2_M_0.RRB, R2_M_1.RRB and R2_M_2.RRB. But the files R3_S_1.RRB and R4_S_1.RRB in that same track folder do not share the same floats for k_29 and k_28, because these two files do not apply to the same racer (different startpositions). The floats under k_29 are relatively simple to understand. These floats define the startposition of an AI, and work the same as for the player (which are defined in an .SPB file). The first float under k_29 is for x-positioning. This means that the horizontal position (left/right) of an AI's vehicle is set with this float. The second float under k_29 is for y-positioning. This means that the horizontal position (up/down) of an AI's vehicle is set with this float. The third and last float under k_29 is for z-positioning. This means that the vertical position of an AI's vehicle is set with this float. If you still like to know more about (editing) the startpositions, >this tutorial explains most of it. How is rotation set in an .RRB file? The floats under k_28 are for the rotation of the AI vehicle IN its startposition. This rotation is not for setting the direction of the path it has to follow, there is no connection between startposition rotation and path direction. That means, setting the rotation for the AI vehicle under k_28 to a different value may change the direction his/her vehicle faces, but at the moment the race starts, the AI will directly face its path direction. This can be clearly observed when setting the AI vehicle in reversed position (i.e. having its facing direction 180 degrees switched). At the moment the race starts, its vehicle will switch back 180 degrees to align instantly with the direction of its path again. All floats under k_28 range from -1 to 1. This rotation is not based on radians, as far as I know, so that means rotation of an AI vehicle works different than that of a player. The first two floats under k_28 are for a 3D rotation of an AI vehicle in startposition, to call it that way. This also explains why the value of this float is always (close to) absolute zero, because in all tracks, the startposition is on a leveled surface. If this float is bigger or smaller than 0, the AI vehicle will align with the surface in an angled (see image) and somewhat twisted way, but not perpendicular at absolute 1 or -1 I believe. The last two floats under k_28 are for horizontal rotation of an AI vehicle in startposition. What are the k_2A, k_2B, k_2C and k_2D groups standing for? The k_2A and k_2B groups share the same structure as the k_29 and k_28 groups, something you may have noticed already. The floatvalues under k_29 and k_28 are the same for all AI path files for a single track, whereas the floatvalues of the k_2A and k_2B groups are different for all AI path files for a single track. For example, the floatvalues under k_29 and k_28 are the same in these two files (from the same track folder): R1_F_0.RRB and R1_F_0.RRB. But the floatvalues under k_2A and k_2B are different in these two files (from the same track folder). The values under k_2A and k_2B denote the finishing position of an AI racer, the point where it crosses the finish line after three laps. The values under k_2C and k_2D are always an integer. But these integers are different for all AI path files for a single track as well. The integer under k_2C denotes the total race time of a racer on a given track in milliseconds. What are the nodes (the k_27 group)? Nodes are waypoints for an AI to follow during a race. Going through all nodes in a single .RRB file means that the AI completed three laps (thus one race). That means, that there are about three different paths for each AI on a track (one .RRB file representing one path). The nodes are the ones that really add up to the amount of code lines in the .RRB file, because one node only represents a small distance to race on the racetrack. Therefore a lot of nodes are used to fill a complete AI path. The amount of nodes can be 682, as seen in the code lines below (directly under k_27) for an AI path on Royal Knights Raceway, but the amount can also be over 1000 (which is for Rocket Racer Run AI paths). Below follows the structure of the nodes again. Each node consists of 10 code lines. I also put additional comments next to the nodes. These comments refer to the explanation given in the text below the code. k_27 // Nodes [682] { (f16)0 //value 1 (f16)0.02734375 //value 2 (f8)0 //value 3 (f8)0 //value 4 (f8)0 //value 5 (f8)10.4375 //value 6 (f8)5.625 //value 7 (f8)2.5 //value 8 (f8)2.5 //value 9 (byte)193 //value 10 ... } What happens if I remove certain nodes? If you remove a few nodes completely, and also define the new amount of nodes in the brackets (e.g. from [682] to [672]), the game won't give any errors when the AI uses this modification to its path file. The AI will simply skip the 'missing' nodes, and will eventually not be aligned with the track anymore because of this modified path. If you remove parts of a node, like only removing the (f16) part, it does affect the AI path. At the moment the AI reaches this node (with the changed structure), it will be stuck at this waypoint. You cannot move it by pushing his/her vehicle, because the node structure is messed up, meaning that the game doesn't know where the AI has to go next in the waypoint list. What are the first three values for? Values 1 and 2 contain the relative coördinates in an AI path. You have to add or subtract these numbers from the former coördinates to get the new coördinates of the racer on its path. Basically you have to calculate the position of each node as following. For the first node of the path: value 1 = (new x-coördinate) - (startposition x-coördinate) value 2 = (new y-coördinate) - (startposition y-coördinate) value 3 = (new z-coördinate) - (startposition z-coördinate) And for all subsequent nodes: value 1 = (new x-coördinate) - (old x-coördinate) value 2 = (new y-coördinate) - (old y-coördinate) value 3 = (new z-coördinate) - (old z-coördinate) However, for the z-position (value 3) it works a little different, since it is not adressed the same amount of space as the former two values. It ranges from 0 up to 16. All values (starting) from 0 up until 8 indicate an increase of z-position and all values (starting) from 8 up until 16 indicate a decrease in z-position. The change in z-position is, like values 1 and 2, also stored relative to the previous height, but since it is limited in adressing, the maximum increase or decrease z between two nodes is: |z| < 8 Also, an increase of respectively z = 1 unit and z = 5.3 units is given by (f8)z = (f8)1 and (f8)z = (f8)5.3, whereas a decrease of respectively z = 1 unit and z = 5.3 units would be stored as (f8)z = (f8)15 and (f8)z = (f8)10.7 (thus 16 - z). No change in height is denoted by 0. The other four values are the rotation stored as quaternions. Quaternions are a number system which are an extension of the complex numbers, which on itself are an extension of the real numbers (the system that generally everyone is familiar with). I have never studied any further than complex numbers, so my knowledge of how this rotation works lacks here. Values 4 and 5 appear as 0 most of the time. When it is set as 0, the AI vehicle is perfectly aligned to the surface. Tweaking or majorly changing the value causes the vehicle to appear 3-dimensionally rotated while using its path. That means you could have the AI make a wheelie for the whole race, when having the right value for these two subnodes. Values 6 and 7 are values to express the direction the AI vehicle has to face. Meaning, that in combination with modified subnodes 1 and 2, you can have the vehicle drive the 'wrong way' AND face the 'wrong way'. Values 8 and 9 are still unknown to me. I've seen that the value for these two subnodes is 2.5 in every .RRB file in LEGO Racers, but do not quite understand what they are for. What is the last value for? At last, value 10. You could say that the speed (or absolute velocity) of an AI is determined by this value. The byte (an 8-bits number) appears as an integer with an absolute value ranging from 0 up until 256. If you open a random .RRB file, the bytes will mostly be integers of around 200. My guess is that the bytes are the times in milliseconds assigned to each node. I could sustain or reject this if I took the time to calculate the sum of all bytes for a path and compare this with the value under k_2C (total race time in milliseconds). The values most commonly seen are around 3, 129 and 200. If my guess is correct, then the value has a great impact on the smoothness of the path. A large distance between two nodes with a relatively small byte value causes a great positive acceleration for the car, whereas the opposite will do a negative acceleration. It is this correlation that shows that you cannot just alter coördinates and expect the racer to run a smooth as it originally was, you'd need a good recorder to get the path right (one that records both coördinates and relative time elapse). If this measuring happens on constant intervals, then the byte value can be regarded as a contstant. The question that arises is the interval time at which to measure. An .RRB file can only hold that much information, thus you cannot create intervals so small that you'd exceed the maximum amount of nodes. Then again, it is easy to surpass the condition for the third value of the node (relative z-position) on some tracks if you measure with intervals too big. It is this issue that has kept grappigegovert from completing his RRB recorder (the GHB recorder does not have to deal with this issue as it only uses rotation and absolute coördinates for each node, with lap times defined at the start of the file). A possible solution to this is to keep record of the potential overflow of this third value and add this to the next node's third value. Does overflow occur again, pass it forward to the next node. Continue this proces until your overflow record is at 0 again (the principle of a ripple-carry adder).

I was going to make these textures after I returned from my trip but instead I made >Stunt Rally Racers. Anyway, I hope you already know where these files goes. If not: PLAYER X FACES goes to: heads/textures. PLAYER X TORSO and PLAYER X LEGS goes to: bodies/textures. PLAYER X.MD2 goes to: heads/models. Col_X, XX_visor and XX_helmet goes to: common/textures. SOLID X SKY goes to: common/skybox. Download Specs Download Shadow Download Digger

Originally I was going to upload only Blacktron Future Generation Astronaut's textures but... Blacktron Future Generation Astronaut overwrites smile face (no need to put PLAYER FOUR FACEs if you already have that smile face), blue cap, police torso and yellow legs. PLAYER FOUR FACEs goes to: characters/heads/textures. PLAYER FOUR LEGS and PLAYER FOUR TORSO goes to: charcters/bodies/textures. SOLID GREEN SKYs goes to: common/skybox. SP_VISOR AND SP_HELMET goes to: common/textures. PLAYER4.MD2 goes to: charcters/heads/models. Do we cheat them Dewey Cheatum overwrites Sam Sinisters face, red racing helmet, grey torso with black arms and black legs. PLAYER TWO FACEs goest to: characters/heads/textures. PLAYER TWO LEGS and PLAYER TWO TORSO goes to characters/bodies/textures. PLAYER2.MD2 goes to: characters/heads/models. Banker overwrites smile head with orange eyebrow, white firefighter helmet, black torso with glasses(?) and grey legs. PLAYER THREE FACEs goes to: characters/heads/textures. PLAYER THREE LEGS and PLAYER THREE TORSO goes to: characters/bodies/textures. PLAYER3.MD2 goes to: characters/heads/models. Rudo Villano overwrites smile face with sunglasses, blue aviator helmet, white torso with shark on it and green legs. PLAYER ONE FACEs goes to: characters/heads/textures. PLAYER ONE LEGS and PLAYER ONE TORSO goes to: characters/bodies/textures. PLAYER1.MD2 goes to: characters/heads/models. Remember to backup your files! Download Blacktron Future Generation Astronaut Download Dewey Cheatum Download Banker Download Rudo Villano