[MODEL UPDATE]
AS JON HAS MODIFIED THE QJBR MESH AND SOME MORE CHANGES ARE ON THE WAY, I WILL POST A LINK FOR YOU IN THIS TUTORIAL SO YOU CAN DOWNLOAD THE ORIGINAL MODEL AND TEXTURES TO USE WITH THIS TUTORIAL. I WILL EXPLAINE HOW TO CHANGE THE TEXTURE DIRECTORY AT THE END SO ORBITER DOES NOT CONFUSE THE TWO SHIPS !
Hello folks. TGEP here. Today, I'm going to tell you how to write a basic vessel config for Orbiter 2006P1.
STUFF YOU WILL NEED:
A blank .cfg file
A model to work with
Orbiter Mesh Wizard
Thrust Control MFD
Why write a full vessel config you ask ?
Because a well written vessel config can be used as a base file for writting other files you will need to make better add ons for Orbiter. All the info you find in this file the way I write them up, can be used to write .ini files, particle files, and basic .CPP and .h files to build modules. It's an extra step that will save you a lot of searching out later because you will already have the data you need at your fingertips.
Now, the first thing is to get a model. We'll use Jons QJBR model because if you've been following his module tutorial like I have, you already have it.
Next, you need a blank .cfg file. If you haven't already downloaded my collection of tutorials and blank developer files, go do that now.
Okey dokey then. The next thing you will need is to have the very latest version of OrbiterMeshWizard installed and located in you main Orbiter Utilities folder. ( You can get it at the OrbitHangar ) I keep it there because I also have Anim8or, SurfaceBaseWizard, and all my other handy dandy developers tools ( except MSVE ) located there as well.
Last of all, I want you to download the ThrustControl MFD made by ComputerX. You'll need to start up Orbiter and activate it in the modules tab of the Launchpad Dialog box before you flight test your ship.
All set ? Ok, here we go.
The first thing I want you to do is send a copy of a blank .cfg and Jons QJBR mesh to your documents folder.
Now I want you to rename the mesh QJTV and rename the config file QJTV.cfg.
Why ? Because this will prevent you from confusing it with the Jester Training vessel being used in Jons Module tutorials.
Now place the QJTV mesh in Orbiter Mesh Wizard ( hereafter refered to as OMW ). Start up OMW and load up the QJTV mesh. Now minimize the window and open the QJTV.cfg file.
STEP ONE~Naming Names
At the very top of your .cfg file, I want you to write this in for the name.
; === Configuration file for QJTV Training Vessel ===
That will prevent you from confusing it with other files at a glance. Now for the other names.
ClassName = QJTV
MeshName = QJTV
note ~ when you run a scenario or add this vessel to a scenario already running in Orbiter, you can name the ship anything you like but the QJTV name MUST be used for the ClassName because it tells Orbiter which file to read the needed data from. Ditto for the MeshName.
STEP TWO ~ Running the Numbers
The next values can be found in OMW, and you're going to have to do a bit of math. Go back to OMW and press the yellow i box. Look in the top right under the size column and write these numbers down. We'll be using them in a moment. Our ship is 392.8074 meters long ( Z-Axis ). Round up to the nearest tenth ( 392.8 ) and divide by 2 and you get 196.4
This is the radius of our ship and the number we use for size in a config file so,
Size = 196.4
Mass.
Here's how I determine the mass of a vessl. Round up the X, Y, and Z axis numbers from the size column ( I told you to write them down ) to the nearest tenth.
Now multiply the X by Y and multiply that total by the Z. Devide your total by three and you get your number for the vessels mass. ( note ~ this is actualy the cubic volume of the mesh box but since all ships in Orbiter are just spheres with textures, it works well for our purpose. ) In our case,
Mass = 1020600.5
MaxFuel.
Without some superduper go go juice, we aint going nowhere in a hurry. But how do you decide how much fuel you want to carry ? Well folks, that all depends on what type of ship you're trying to build. For a real rocket, your fuel mass would be 80 to 90 percent of your vessels mass so we will take our mass number ( 1020600 ) and subtract 90% to find our maximum fuel mass. That gives us 918540 Kg of fuel, so lets round that off to ....
MaxFuel = 920000
ISP
This is just another way of saying engine efficeincy. It tells Orbiter how much fuel to use for a given thrust level. There are two ways to find this number. You can get it by trial and error or you can use the Thrust Control MFD made by ComputerX. I prefer using the MFD during flight testing as it's far faster to find the values we will use here. But, since we need a number to start from, lets use the value of 6e9. The QJTV is a big ship so this will put us in range. If your building a Trek type ship with a "GeeWhiz" drive, you can set this value at 6e10 or higher and never have to worry about running out of fuel.
Isp = 6e9
STEP THREE ~ "Scotty, I need full power now ! "
MaxMainThrust
to start with, we can use an arbitrary number because these numbers will change when we flight test our vessel. We do need something to start with so lets use the value of 6e6. With practice, you will be able to choose a number that will get you closer to your actual figure for a given vessel mass range and minimize the time spent fine tuning your engines.
MaxMainThrust = 6e6
MaxRetroThrust
Does your vessel have braking thrusters ? As a SciFi ship, ours does but depending on the design of your model, it may not. A regular rocket would not and would use RCS thrusters to do this or wouldn't have any at all. If that's the case, the value here would be Zero. Since our vessel DOES have them, we don't need to turn the ship retrograde and use the main engines for braking.
But how do we determine how powerfull they are ? For myself, I like mine to be 60 to 80 percent as powerfull as the mains but the exact value is really up to you based on your personal preferance. for now we'll use the same value as the Mains and tweak the performance during flight testing, so ..........
MaxRetroThrust = 5e6
MaxHoverThrust
Does your vessel have hover engines ? Ours does so we will use a smaller number to start with. The way I write vessel files, I like my hover thrusters just strong enough to lift a ship verticaly in Earth Gravity. That means you will need to remember to use caution when using these enginges on other planets with a diffrent gravity level or you'll go zooming up far faster than you intended and probably spill your coffee in the process. Power should always be applied slowly to hover thrusters for a smooth take off.
Again we will use a test figure and fine tune things during flight testing.
MaxHoverThrust = 4e6
MaxAttitudeThrust
This value will tell Orbiter how powerfull to make your RCS ( Reaction Control System ) thrusters . It's an important number for us because if we make them too strong, we go spinning out of control and inadvertantly paint the cockpit in bright vomit colors before we die. I think it's always better to start out underpowered and then build them up to the right thrust level during testing because RCS thrusters are used for almost every aspect of spaceflight manuvering. With that in mind, we start with a very low number of 2e4.
MaxAttitudeThrust = 2e4
STEP FOUR ~ "Stoke me a klipper, I'll be back for Brunch "
Kuddos to anyone out there who got the RedDwarf referance. LOL
The next set of figures we will determine are not all used by basic vessel files but I include them because they are helpfull to have on hand when you write other types of files. It doesn't matter that they are present in a configuration file because if it's not needed, Orbiter simply won't use them. Now you begin to see the value of a fully fleshed out .cfg file.
COG
This is your Center of Gravity Overground. Not only does this number tell Orbiter WHERE your center of mass is on the Y axis, it also tells Orbiter how high above ground your ship will appear when it's landed dirtside. If your ship is not meant to land on a planet ( as ours clearly wasn't ) you can use the Orbiter default value or something close to it.
COG_OverGround = 2.54
If your ship IS meant to take off and land on a planet, this value becomes very important because if you don't get it right ( as I did with my Hawk variation of the Eagle series ) you will get that annoying powerfull bounce when you apply hover thrusters ( if you have them ) for a Vertical lift-off. So how do we find it ? Lets go look at our mesh in OMW.
Look at the lowest point of your mesh. As your mesh is centred at ( 0 0 0 ) you want to make sure that your COG value is high enough above your landing points to prevent your ship from bouncing up when you apply hover thrust. On the other side of the coin, you want to make sure you don't get a significant "drop" to the ground when hover engines are started.The only way I know of doing this is by tweaking the numbers up or down during flight test. If you can take off like an aircraft, this problem becomes less apparent.
CW
CW is an atmospheric parameter that tells Orbiter what the Drag Co-Efficient is for a given vessel. All vessels will have this and it's an important number for any vessel that will opperate in or near an atmosphere as it ties into the ammount of thrust needed to move a vessel a given distance through a volume of air at a given dencity. To be honest, I use a standard set of numbers for all my vessels, so this section will look like this.
CW = 0.09 -0.09 2.0 1.4
CROSS SECTION
Remember those three numbers I told you to write down earlier, well, were going to use them again. These numbers are the size of your meshbox and represent the actual cross section of the vessel as it's displayed in Orbiter. For our ship, it will look like this.
CrossSections = 101.058 77.12199 392.8074
ROTATION RESISTANCE
This value determines how sluggish your vessel is when opperating in an atmosphere. You can do the math to find the numbers you need; a(w)x,y,z = -v(w)x,y,z r rx,y,z with angular velocity v(w) and atmospheric density r.
or you can do like I do and just wing it and tweak the numbers to your liking during flight testing.
RotResistance = 0.5 1.0 1.0
INERTIA
To find these numbers, we need to use the shipedit.exe located in your Orbiter SDK utilities folder. Send a copy of the mesh there and load it into shipedit.exe. Use the Calc function with a setting of 10 ( even though our mesh only uses 8 grid boxes, the function requires a minimum of 10 ) We will use the numbers found in the inertia tenscer and devide them by 3. In an .ini file, these numbers are used for the PMI values.
Inertia = 3460 4441 167
TRIM
To be honest, I'm not sure what this does but Orbiter seems to like it and it's used in the .ini file so I use a default number of 0.3 for all vessels.
Trim = 0.3
LANDING POINTS.
Now even though our ship was never meant to go dirtside, there's always going to be some knucklehead that wants to do it. My advice is this. IT'S YOUR CREATION. BUILD IT THE WAY YOU WANT. If someone wants to modify it and add landing points to it, I say let'em go for it. If they don't know how, they can learn how. For demonstration purposes, we will put some on our ship so everyone knows how. Since we have no landing gear to rest on, we'll say our ship uses some sort of forcefields to rest on.
Look at the mesh in OMW. Idealy, our landing points would be located on the bottoms of our landing gear but since we have none, we will place our points approxametly 5m below the lowest point on our mesh. I'll give you the numbers to start with then tell you how I got them.
LandingPoints = 0 -43.6 157.6 -34 -43.6 -162 34 -43.6 -162
Ok, we now have three sets of three numbers. They are your foreward, left, and right side landing points.
For the first set, your X value will always be zero so that the point is centred on the X axis. We get -43.6 for the Y location because we want our point 5m below the lowest point on our mesh. We will use this number on ALL three sets. We get 157.6 for our Z location because we have placed our point dead centre of the foreward hull.
Get the idea now ? Your Left and Right side numbers should be mirrored. Look at the numbers above to see what I mean.
CAMERAOFFSET
This is your vessels default camera position and you will use this value for all you future files. It also represents your "home" position for camera placement when you build a module so be careful where you put it. In our case, our camera location is....
CameraOffset = 0 -10.37 191
I got these numbers by zooming in on the cockpit area of the mesh in OMW and placing the point where I thought the captains head would be while commanding the ship. In reality, you can put it anywhere you want.
NOTE ~ THE NEXT 4 ITEMS ARE ALL EXPLAINED IN MY DOWNLOADABLE.CFG SO THERE'S NO NEED TO GO OVER THEM HERE. ALLYOU REALLY NEED TO KNOW IS THAT YOU SHOULD MAKE IT LOOK LIKE THIS.
EnableCockpit = true ; show internal mesh
EnableFocus = true ; can you jump (F3) and pilot this ship? True or false
EnableXPDR = true ; Does it have a homing beacon? True or false
XPDR = 108.0 ; What is the default transponder/XPDR frequency if it is true?
WE'LL MOVE ON TO ATTACHMENT POINTS AND DOCKING POINTS NOW.
STEP FIVE ~ " Load the cargo and begin undocking procedures "
Attachment points can be tricky. It took me a while to get me head around them and they sometimes still give me troubles. With practice, you'll get the hang of them too. Now we want our ship to be fleet compatible, so we'll give it one attach point so a Battlestar Whisker can grab on to it. You must first determine if it's a PARENT OR CHILD POINT. Because of the way Jon has coded the Battlestars, ours will be a PARENT POINT and we begin writing in our file like this.
BEGIN_ATTACHMENT
P
Next, we need to find it's location so by following Jons guidlines, ours will be ...
BEGIN_ATTACHMENT
P 0 -28 0
Now we write in the default vectors for RTF attachments and we have ...
BEGIN_ATTACHMENT
P 0 -28 0 0 0 -1 0 1 0
Finaly, we want to give our point a call out designation so that a battlestar will recognize it as a whisker point.
BEGIN_ATTACHMENT
P 0 -28 0 0 0 -1 0 1 0 APW
If your vessel has any other attachment points, write them in below the whisker point in the same manner. Once you have put all you points in the file you can close it out so that it looks like this.
BEGIN_ATTACHMENT
P 0 -28 0 0 0 -1 0 1 0 APW
END_ATTACHMENT
Note ~ For any vessel I would follow the guidelines set out in Vinka's SC3 tutorial and limit the total number of attachment points to less than 16.
DOCKINGPORTS
Even if you don't have any docking ports drawn on your mesh, it's a good idea to include one in your .cfg so that your ship can be used with other vessels and space stations. First, we determine it's location on the mesh by looking at our mesh in OMW. This will be our X Y Z location.
BEGIN_DOCKLIST
0 -6.938 195.519
Now we determine from which direction another ship will approach our docking point. In our case it will be from the front so our approach vector will be 0 0 1. If our docking point were on the back of our ship it would be 0 0 -1
Get the idea now ?
BEGIN_DOCKLIST
0 -6.938 195.519 0 0 1
Now we determine our docking alignment vector. A better way of thinking of this is as the direction of the top of our docking hatch. In our case, it's 0 1 0. If our docking port were on the top or bottom of our ship, this number would be either 0 0 1 or 0 0 -1 depending on which way you want the ship to point when it's docked to something else.
BEGIN_DOCKLIST
0 -6.938 195.519 0 0 1 0 1 0
Now we need to give our docking point a radio frequency. This will allow the docking MFD to lock onto our port when in another ship and guide us in for a proper alignment and make docking to our point a lot easier. We'll use a radio frequency of 107.50 and then we'll give our point a name so that we know which one it is if we decide to add more docking points later and close out our Docking list.
BEGIN_DOCKLIST
0 -6.938 195.519 0 0 1 0 1 0 107.50 ; Main
END_DOCKLIST
The next part of this tutorial will cover ALL aspects of Engine thruster placement and flight testing our vessel.
It's a bit long and there is some detailed stuff to cover so ..........
Stay tuned folks !
