Havoc89

Hey if you guys have a building model prepped, send it my way and I'll make a tutorial series for setting up buildings in renx.

Awesome games today guys! Thanks to all who showed up, and ofcourse the organizers. Large player counts, even teams, and kick ass come backs. Everything I love about ren!

That's very cool

All you need is our sdk to open up the editor. Once you've opened up the editor you will see a windows explorer like file browser called the content browser. Look under the RenX folder, and you will see a number of sub folders for things like weapons, vehicles, characters, and whatever else. Find the model you want to extract. Right click on the thumbnail of the model, and select export to FBX. Then just import the FBX format file into whatever 3d modeling software you prefer.

Beta 5 uses a new way of adding maps which is a lot easier to setup for map makers as it does not require editing existing ini files. In the SDK mappers will notice an example ini file called "CNC-TestMap_MP.ini" which will add the test map in the menu. So all mappers have to do now is add a new ini file for every map they make with all of the settings defined within that one ini. This means they no longer have to get players to edit their ini files to show the maps in the menu. They simply have to include a custom ini file with their map name and settings defined with in it, and include that with their map file.

Wowzers! I'm completely blown away by this, it looks incredible. Are you running the 32bit or 64bit version of the editor? Try running 64bit.

You cannot acquire new targets from the smoke screen. Only targets you have already acquired before they enter the smoke will have the target box.

Yosh you mad genius you... Very curious to give this a try!

I will confirm that the upcoming update will have the titan... and more

The titan is now avaliable for SDK users. I'm sure some one is able to make a mutator that could bring it inside Open Beta 4. viewtopic.php?f=136&t=75257

DOWNLOAD IT NOW! This is the example asset which includes the .uc classes and the .upk package files. This will NOT function inside Open Beta 4 by extracting the files. These are only source files to show modders how to get their mechs up and running directly inside the Renegade X SDK. There is absolutely no custom code used to get them up and running. All .uc files are simple extensions of the Rx_Vehicle_Treaded class and work just like a standard tank vehicle. All of the animations are handled from inside the animation tree. We will probably include this in the upcoming Open Beta 4 patch so that non-modders can get a chance to have some fun with mechs. Have Fun folks!

I've been digging into this a little bit more lately, and it is indeed possible to get mechs working without custom code. I just have one problem left to resolve. But as soon as that is fixed, i'll release the code, max, and UPK files for it. I didn't really need to do any custom coding, but a little bit is required to get a custom animation tree node for changing the animation for backward movements. For the most part I'm at about 90% and all of that 90% was done without any coding, and mostly handled from the animation and the anim tree editor.

Curious to see progress on this. Yes there is a node in the animation tree editor that can speed up / slow down animations based on movement speeds. We use that on our character animation tree for dynamically scaling the animation speeds to auto adjust to character speeds. That node is called "AnimNodeScaleRateBySpeed" inside the animation tree. Not really sure how to setup a mech though. Definitely need someone with programming expertise for this one.

I'll see what I can do to help explain buildings. I'll also try and prepare an example file that was meant to be included in the sdk for the max file. Any who, part 5 which covers programming is now up and running. Last part still need to be recorded which covers fine tweaking all of the parameters to get the vehicle playing the way you want it to.

Chapter 4 is up, and chapter 5 will be up later tonight, it is currently being compressed. One last chapter left to record which will be all about fine tweaking and finishing touches.

I don't think having 6 wheels is a good idea for such a small vehicle. It might make handling very difficult, but if you can make 6 wheels work the way you want them to then it might be worth trying out. As for how to get those 2 wheels to spin, there was a way to do have a "dummy wheel" back in ut3, but that seemed to have been removed in UDK. You might be able to use an orientation constraint to inherit the rotation of the main giant physics wheel onto the 2 small wheels. As for getting them to spin at the correct rate, well you can try using a multiply node after the orientation constraint to have it turn at a slower rate, though that may not work correctly. If that doesn't work, you could always just set up normal physics wheels for them. That isn't an optimal solution, but its one that will work. Though it might make handling tricky as it would cause wheels to be intersecting. I think your best bet is probably to use a SkelControlSingleBone and use a controller name on it that you can call in code, and get that controller to spin the wheel at which ever rate you want by coding it yourself. Though I'm not sure how that would be done.

Cool! You guys are more then welcome to use our SDK as a starting point. I can't wait to see what you guys produce. Good luck fellas!

Part 3 is up folks. I dont know when Part 4 will be up as I have yet to record it. I will keep you all posted. Sorry, I'm not sure I understand what exactly you're asking.

Hey folks, I know it's been a while, but I've been chipping away at the vehicle rigging tutorial. I am still in the middle of recording it, but I wanted to put up the first 2 chapters right away. Chapter 3 is currently being compressed, and will be up tomorrow night hopefully. I have a lot left to record, but at least you guys can start to follow along. Youtube playlist: I will update this post as more chapters have been uploaded. UPDATE: Part 5 is up! I dont know when part 6 will be going up, I still have to record it. I will keep you guys posted.

I'm a bit confused on what you're talking about for side to side. As for the back wheel, yeah you can absolutely setup a similar system to have the back wheel also create an arc effect like the front wheel does. As per getting a driver, have a look at the Apache. There is a bone for where the character mesh will be, and in the code there is an option to make the driver visible, and a variable for which animation to use for the character.

Aw that's so cool! But yeah totally doable, but certainly not an easy one to do. I did something similar on the stealth tank treads. Here is a simple diagram to explain how it can be done. The animation tree is where you will be doing most of your work to add the wheel's translation, and also add the look at constraint. There is a more accurate way of setting this up, but it will involve too many physical wheels which will end up creating nightmares in vehicle handling. The solution I am suggesting is the quickest/easiest one with the most efficient vehicle handling.

Itching to try this map out!

Really cool stuff! Buildings can be a little bit tricky to implement but I'll see if we can get some documentation on them for you guys as soon as possible.

Very interesting. I'd like to see how the hovercraft plays in a MP game. Though the setup for the hover craft have been ported over from black dawn. Originally we wanted the first mission to have a drivable hovercraft, but it proved to have a number of issues we could not solve at the time, so it was switched to an in game cut scene instead. If you've already made a new hovercraft class off of ours, I'd suggest doing the same with it's weapons because they are massively OP for a multiplayer game.

Buildings are one of the cheapest things to render in the game. We've specifically set them up in a way where they are handled exactly the same as any other static world geometry in the map. You have to remember that geometry is the easiest and cheapest things to handle. Our buildings are split up into multiple components so that unnecessary parts are culled away. We usually break them up into Exterior, Interior, Interior Details, and screens. This way most of the interior geometry that isn't visible from the outside will not be processed. Shader complexity is what will be a lot more intensive than a few extra thousand polygons alone could ever be. Granted our buildings are disturbingly outdated, and could use some tlc and be rebuilt from scratch in a more optimal way. But as it stands now, buildings are as graphically intensive as a giant rock is. Characters, Vehicles, and other dynamic objects are far more intensive for the game engine to process. We've had countless discussions internally on redoing buildings, but for the moment they are not a priority.