Hlynkacg
Aspiring rocket scientist
I normally do this as well but for some reason I just wasn't thinking last night and... :facepalm:
For those of you who have been following along...
Please take a look at the complete Header and Source files I posted above and note the changes.
The first and most obvious change is that I've replaced the SuttlePB's physical parameters with a whole host of new ones that describe the Apollo Lunar Lander.
I then went into clbkSetClassCaps and applied those parameters to the vessel.
I'm not going to do a step-by-step for this because 1) it is really quite simple. 2) it is tedious. and 3) this tutorial here covers the subject far more clearly and in greater detail than I ever could.
That said, I will field questions on the subject so if you have 'em, ask 'em.
NOTE: I have not assigned control groups at this point, I'm actually planning something special in this regard.
Another thing I've added is "dificulty modifiers" at the moment their values are fixed at 1 but the intent is that down the road their values will be read from a config file allowing the end user customise things like exhaust velocity, fuel capacity etc... (stealing a page from the XR fleet :thumbup
we will go over the actual implimentation of this process in detail later but for the moment we need is a couple of place-holders.
Another subtle (but important) change is the inclusion of three additional header files.
These files contain a set of definitions that allow us to call individual groups, materials, and textures within a mesh file by name rather than by index number.
Note how the "participating groups" line of our hatch animation has changed from...
to...
Easier to read yes?
Several mesh export/converter scripts will automatically generate a header file for this purpose. If yours does not you can also use MeshC in the OrbiterSDK\Utils folder to create a header file for any existing *.msh file.
These are my headers...
NOTE: I added the animation coordinates to the end by hand.
Mesh resource files are not really important when you're only dealing with 2 or 3 moving parts at a time but as you can see, our VC will have HUNDREDS of them and at that point using index numbers becomes problematic.
Adding and coding the VC is still a long way away but I want to start planning for it now rather than have to go back and re-code a bunch of stuff later. :thumbup:
Anyway...
The next feature I want to impliment is "Staging". The LM is after all a two-stage "rocket" with the rather odd idea of staging while landed! :lol:
However in order to impliment staging we need to be able to create and apply custom vessel states. An important part of this is making sure that these states are persistant. Afterall you don't want the first stage of your launch vehicle "Respawing" every time you load (Current State).scn.
Or maybe you do but the point is that I don't.
So without further ado...
PART 8: Scenario Files
The Reading and Writing of *.scn files is controlled by two call back functions. "clbkLoadStateEx" and "clbkSaveState", I'm pretty sure you guys will figure out which one does what so let's add them to our class interface...
And overload them in our source file...
Unlike the other call back functions we have used so far "clbkLoadStateEx" and "clbkSaveState" need to be explicitly told what to do when called. If we did not include the calls to Orbiter's default vessel parameters our vessel would not be saved or loaded to/from the scenario file.
This is described in the Orbiter API_Guide, and the code shown above will mimic the default functionality.
Moving on...
Our first step will be to save a custom variable to our scenario. Rather than adding a vew variable to our code let's simply write our hatch's status to the scenario file
Add the following to "clbkSaveState"...
As you can see there are two lines that we are interested in.
The first is a standard sprintf function , what it is doing is taking two numbers, an intiger corisponding to our "HatchStatus" and a Float (decimal) corisponding to "hatch_proc", and write them to the character buffer ("cbuf") declared at the top of clbkSaveState.
The next line is an Orbiter API function that actually writes a line into a scenario file.
In this case we are writing a line to the active scenario file "scn", labeling it "HATCH", and then placing the contents of "cbuf" (our current values for HatchStatus and hatch_proc) inside of it.
Let's compile and test...
Open the scenario, open your hatch, and then quit the scenario...
NOTE: If your orbiter simulation hangs on exit, a syntax error in clbkSaveState is one of the most common culprits.
Now open (Current State).scn with a text editor and find your Lunar Lander. There should be a new line at the bottom of it's entry in the scenario.
Our values for HatchStatus and hatch_proc have been succesfully saved to the scenario. Now we need to load them.
Pop up to clbkLoadStateEx and add the following...
Let's break down what's happening here...
Simply scans every line of the vessel's entry in the scenario.
Checks to see if the first 5 characters of the line being scanned are "HATCH", if not we let Orbiter's default scenario reader handle it. If they are we perform the following action...
the first line is another standard C++ function for parsing values. We are telling it to skip the first 5 characters of the line (the part that says "HATCH") and read the first intiger and float it can find. Those two values are then applied to HatchStatus and hatch_proc via pointer.
The second line should be self explanatory.
Compile the code and test it, your hatch's state should now persist between scenarios.
Adding additional variables is a matter of simply following the same procedure.
Feel free to experiment with it. :tiphat:
Next up I will be talking about creating your own custom functions and vessel states with an eye towards writing a stage seperation routine.
For those of you who have been following along...
Please take a look at the complete Header and Source files I posted above and note the changes.
The first and most obvious change is that I've replaced the SuttlePB's physical parameters with a whole host of new ones that describe the Apollo Lunar Lander.
I then went into clbkSetClassCaps and applied those parameters to the vessel.
I'm not going to do a step-by-step for this because 1) it is really quite simple. 2) it is tedious. and 3) this tutorial here covers the subject far more clearly and in greater detail than I ever could.
That said, I will field questions on the subject so if you have 'em, ask 'em.
NOTE: I have not assigned control groups at this point, I'm actually planning something special in this regard.
Another thing I've added is "dificulty modifiers" at the moment their values are fixed at 1 but the intent is that down the road their values will be read from a config file allowing the end user customise things like exhaust velocity, fuel capacity etc... (stealing a page from the XR fleet :thumbup
we will go over the actual implimentation of this process in detail later but for the moment we need is a couple of place-holders. Another subtle (but important) change is the inclusion of three additional header files.
Code:
// Mesh resource files
#include "_ascentmesh.h"
#include "_descentmesh.h"
#include "_cockpitmesh.h"These files contain a set of definitions that allow us to call individual groups, materials, and textures within a mesh file by name rather than by index number.
Note how the "participating groups" line of our hatch animation has changed from...
Code:
static UINT HatchGrp = 8; // participating groups
static UINT HatchHandleGrp = 14;to...
Code:
static UINT meshgroup_Hatch = AS_GRP_EvaHatch; // participating groups
static UINT meshgroup_Handle = AS_GRP_HatchHandle;Easier to read yes?
Several mesh export/converter scripts will automatically generate a header file for this purpose. If yours does not you can also use MeshC in the OrbiterSDK\Utils folder to create a header file for any existing *.msh file.
These are my headers...
Code:
// ========================================================
// Mesh resource file for LM Ascent Stage
// Generated with meshc on Tue Sep 11 13:59:02 2012
// ========================================================
// Number of mesh groups:
#define AS_NGRP 42
// Number of materials:
#define AS_NMAT 14
// Number of textures:
#define AS_NTEX 5
// Named mesh groups:
#define AS_GRP_AftAvionicsCover 0
#define AS_GRP_Antenna 1
#define AS_GRP_AntennaSpars 2
#define AS_GRP_Antennawires 3
#define AS_GRP_CabinRCSMounts 4
#define AS_GRP_CabinStrut 5
#define AS_GRP_DockingPort 6
#define AS_GRP_EngineBell 7
#define AS_GRP_EvaHatch 8
#define AS_GRP_FoilGreebles 9
#define AS_GRP_FwdAvionicsCover 10
#define AS_GRP_Greebles 11
#define AS_GRP_HandRail 12
#define AS_GRP_HatchFoil 13
#define AS_GRP_HatchHandle 14
#define AS_GRP_HullBack 15
#define AS_GRP_HullBack1 16
#define AS_GRP_HullBottom 17
#define AS_GRP_HullCabin 18
#define AS_GRP_HullFront 19
#define AS_GRP_HullMidSection 20
#define AS_GRP_InteriorCabin 21
#define AS_GRP_InteriorDetails 22
#define AS_GRP_InteriorFloor 23
#define AS_GRP_InteriorMidSection 24
#define AS_GRP_Lights 25
#define AS_GRP_Nameplate 26
#define AS_GRP_RCSNozzles 27
#define AS_GRP_RCSQuads 28
#define AS_GRP_RadarAntenna 29
#define AS_GRP_RadarDish 30
#define AS_GRP_RadarMount 31
#define AS_GRP_RadarPivot 32
#define AS_GRP_Radiator 33
#define AS_GRP_SBandAntenna 34
#define AS_GRP_SBandDish 35
#define AS_GRP_SBandPivot 36
#define AS_GRP_TargetBase 37
#define AS_GRP_TargetShaft 38
#define AS_GRP_ThrustChambers 39
#define AS_GRP_WindowFrames 40
#define AS_GRP_WindowGlass 41
Code:
// ========================================================
// Mesh resource file for LM Descent Stage
// Generated with meshc on Wed Sep 12 10:28:11 2012
// ========================================================
// Number of mesh groups:
#define NGRP 36
// Number of materials:
#define NMAT 8
// Number of textures:
#define NTEX 4
// Named mesh groups:
#define DS_GRP_AscentHardpoints 0
#define DS_GRP_AvionicsCover 1
#define DS_GRP_DeflectorStruts 2
#define DS_GRP_DescentBody 3
#define DS_GRP_DescentBottom 4
#define DS_GRP_Downlock_AFT 5
#define DS_GRP_Downlock_FWD 6
#define DS_GRP_Downlock_PORT 7
#define DS_GRP_Downlock_STBD 8
#define DS_GRP_EngineBell 9
#define DS_GRP_EngineGimbal 10
#define DS_GRP_EngineShroud 11
#define DS_GRP_GearHardpoints 12
#define DS_GRP_GearSupports 13
#define DS_GRP_Handrails 14
#define DS_GRP_Ladder 15
#define DS_GRP_LandingFoot_AFT 16
#define DS_GRP_LandingFoot_FWD 17
#define DS_GRP_LandingFoot_PORT 18
#define DS_GRP_LandingFoot_STBD 19
#define DS_GRP_Outriggers 20
#define DS_GRP_Porch 21
#define DS_GRP_PrimaryStrut_AFT 22
#define DS_GRP_PrimaryStrut_FWD 23
#define DS_GRP_PrimaryStrut_PORT 24
#define DS_GRP_PrimaryStrut_STBD 25
#define DS_GRP_SecondaryStruts_AFT 26
#define DS_GRP_SecondaryStruts_FWD 27
#define DS_GRP_SecondaryStruts_PORT 28
#define DS_GRP_SecondaryStruts_STBD 29
#define DS_GRP_ShockStrut_AFT 30
#define DS_GRP_ShockStrut_FWD 31
#define DS_GRP_ShockStrut_PORT 32
#define DS_GRP_ShockStrut_STBD 33
#define DS_GRP_ThrustChamber 34
#define DS_GRP_ThrustDefelectors 35
// Descent stage animation mesh coordinates
const VECTOR3 LM_LegAxis[4] = { {-1, 0, 0}, { 1, 0, 0}, { 0, 0,-1}, { 0, 0, 1}};
const VECTOR3 LM_LegPivot[4] = { { 0.00, 0.42465, 2.88195}, { 0.00, 0.42465,-2.88195}, {-2.88195, 0.42465, 0.00}, { 2.88195, 0.42465, 0.00}};
const VECTOR3 LM_StrutPivot[4] = { { 0.00,-1.19950, 3.62660}, { 0.00,-1.19950,-3.62660}, {-3.62660,-1.19950, 0.00}, { 3.62660,-1.19950, 0.00}};
const VECTOR3 LM_DownlockPivot[4] = { { 0.00,-1.05769, 2.83017}, { 0.00,-1.05769,-2.83017}, {-2.83017,-1.05769, 0.00}, { 2.83017,-1.05769, 0.00}};NOTE: I added the animation coordinates to the end by hand.
Code:
// ========================================================
// Mesh resource file for LM Virtual Cockpit
// Generated with meshc on Sun Nov 11 14:20:19 2012
// ========================================================
// Number of mesh groups:
#define VC_NGRP 238
// Number of materials:
#define VC_NMAT 14
// Number of textures:
#define VC_NTEX 10
// Named mesh groups:
#define VC_GRP_ADI_Interior 0
#define VC_GRP_Alt_Rate 1
#define VC_GRP_Altitude 2
#define VC_GRP_Button_P5_01 3
#define VC_GRP_CabinRCSMounts 4
#define VC_GRP_Cylinder 5
#define VC_GRP_Cylinder002 6
#define VC_GRP_Cylinder003 7
#define VC_GRP_EvaHatch 8
#define VC_GRP_FwdAvionicsCover 9
#define VC_GRP_HandRail 10
#define VC_GRP_HatchFoil 11
#define VC_GRP_HatchHandle 12
#define VC_GRP_Hull 13
#define VC_GRP_Inst_COAS_Plane 14
#define VC_GRP_Inst_CWA 15
#define VC_GRP_Inst_LCDs 16
#define VC_GRP_Inst_Panel1_Gauges 17
#define VC_GRP_Inst_Panel1_Lights 18
#define VC_GRP_Inst_Xpointer 19
#define VC_GRP_InteriorCabin 20
#define VC_GRP_InteriorFloor 21
#define VC_GRP_InteriorMidSection 22
#define VC_GRP_MFD_Cmd 23
#define VC_GRP_MFD_Frame 24
#define VC_GRP_MFD_buttons 25
#define VC_GRP_OvhdWindow 26
#define VC_GRP_Panel_01 27
#define VC_GRP_Panel_03 28
#define VC_GRP_Panel_04 29
#define VC_GRP_Panel_05 30
#define VC_GRP_Panel_06 31
#define VC_GRP_Panel_08 32
#define VC_GRP_Panel_12 33
#define VC_GRP_Panel_14 34
#define VC_GRP_Panel_ADI_Housing 35
#define VC_GRP_Panel_Needle 36
#define VC_GRP_Panel_Needle001 37
#define VC_GRP_Panel_Needle002 38
#define VC_GRP_Panel_Needle003 39
#define VC_GRP_Panel_Needle004 40
#define VC_GRP_Panel_Needle005 41
#define VC_GRP_Panel_Needle006 42
#define VC_GRP_Panel_Needle007 43
#define VC_GRP_Panel_Needle008 44
#define VC_GRP_Panel_Needle009 45
#define VC_GRP_Panel_Needle010 46
#define VC_GRP_Panel_Needle011 47
#define VC_GRP_Panel_Needle012 48
#define VC_GRP_Panel_Needle013 49
#define VC_GRP_Panel_Needle014 50
#define VC_GRP_Panel_Needle015 51
#define VC_GRP_Panel_Needle016 52
#define VC_GRP_Panel_Needle017 53
#define VC_GRP_Panel_Needle018 54
#define VC_GRP_Panel_NeedlePitch 55
#define VC_GRP_Panel_NeedleRoll 56
#define VC_GRP_Panel_NeedleYaw 57
#define VC_GRP_Panel_Switches 58
#define VC_GRP_RCSNozzles 59
#define VC_GRP_RCSQuads 60
#define VC_GRP_Dial_P12_01 61
#define VC_GRP_Dial_P12_02 62
#define VC_GRP_Dial_P12_03 63
#define VC_GRP_Dial_P12_04 64
#define VC_GRP_Dial_P14_01 65
#define VC_GRP_Dial_P1_01 66
#define VC_GRP_Dial_P2_01 67
#define VC_GRP_Dial_P2_02 68
#define VC_GRP_Dial_P2_03 69
#define VC_GRP_Dial_P2_04 70
#define VC_GRP_Dial_P3_01 71
#define VC_GRP_Dial_P3_02 72
#define VC_GRP_Dial_P3_03 73
#define VC_GRP_Dial_P3_04 74
#define VC_GRP_Dial_P3_05 75
#define VC_GRP_Dial_P3_06 76
#define VC_GRP_Dial_P5_01 77
#define VC_GRP_Dial_P5_02 78
#define VC_GRP_Dial_P5_03 79
#define VC_GRP_Dial_P6_00 80
#define VC_GRP_Dial_P6_01 81
#define VC_GRP_Dial_P6_02 82
#define VC_GRP_Dial_P6_03 83
#define VC_GRP_Switch_P12_01 84
#define VC_GRP_Switch_P12_02 85
#define VC_GRP_Switch_P12_03 86
#define VC_GRP_Switch_P12_04 87
#define VC_GRP_Switch_P12_05 88
#define VC_GRP_Switch_P12_06 89
#define VC_GRP_Switch_P12_07 90
#define VC_GRP_Switch_P12_08 91
#define VC_GRP_Switch_P12_09 92
#define VC_GRP_Switch_P12_10 93
#define VC_GRP_Switch_P12_11 94
#define VC_GRP_Switch_P12_12 95
#define VC_GRP_Switch_P12_13 96
#define VC_GRP_Switch_P12_14 97
#define VC_GRP_Switch_P12_15 98
#define VC_GRP_Switch_P12_16 99
#define VC_GRP_Switch_P12_17 100
#define VC_GRP_Switch_P12_18 101
#define VC_GRP_Switch_P12_19 102
#define VC_GRP_Switch_P12_20 103
#define VC_GRP_Switch_P12_21 104
#define VC_GRP_Switch_P12_22 105
#define VC_GRP_Switch_P14_01 106
#define VC_GRP_Switch_P14_02 107
#define VC_GRP_Switch_P14_03 108
#define VC_GRP_Switch_P14_04 109
#define VC_GRP_Switch_P14_05 110
#define VC_GRP_Switch_P14_06 111
#define VC_GRP_Switch_P14_07 112
#define VC_GRP_Switch_P14_08 113
#define VC_GRP_Switch_P14_09 114
#define VC_GRP_Switch_P14_10 115
#define VC_GRP_Switch_P14_11 116
#define VC_GRP_Switch_P14_12 117
#define VC_GRP_Switch_P14_13 118
#define VC_GRP_Switch_P14_14 119
#define VC_GRP_Switch_P14_15 120
#define VC_GRP_Switch_P14_16 121
#define VC_GRP_Switch_P1_00 122
#define VC_GRP_Switch_P1_01 123
#define VC_GRP_Switch_P1_02 124
#define VC_GRP_Switch_P1_03 125
#define VC_GRP_Switch_P1_04 126
#define VC_GRP_Switch_P1_05 127
#define VC_GRP_Switch_P1_06 128
#define VC_GRP_Switch_P1_07 129
#define VC_GRP_Switch_P1_08 130
#define VC_GRP_Switch_P1_09 131
#define VC_GRP_Switch_P1_10 132
#define VC_GRP_Switch_P1_11 133
#define VC_GRP_Switch_P1_12 134
#define VC_GRP_Switch_P1_13 135
#define VC_GRP_Switch_P1_14 136
#define VC_GRP_Switch_P1_15 137
#define VC_GRP_Switch_P1_16 138
#define VC_GRP_Switch_P1_17 139
#define VC_GRP_Switch_P1_18 140
#define VC_GRP_Switch_P1_19 141
#define VC_GRP_Switch_P2_01 142
#define VC_GRP_Switch_P2_02 143
#define VC_GRP_Switch_P2_03 144
#define VC_GRP_Switch_P2_04 145
#define VC_GRP_Switch_P2_05 146
#define VC_GRP_Switch_P2_06 147
#define VC_GRP_Switch_P2_07 148
#define VC_GRP_Switch_P2_08 149
#define VC_GRP_Switch_P2_09 150
#define VC_GRP_Switch_P2_10 151
#define VC_GRP_Switch_P2_11 152
#define VC_GRP_Switch_P2_12 153
#define VC_GRP_Switch_P2_13 154
#define VC_GRP_Switch_P2_14 155
#define VC_GRP_Switch_P2_15 156
#define VC_GRP_Switch_P2_16 157
#define VC_GRP_Switch_P2_17 158
#define VC_GRP_Switch_P2_18 159
#define VC_GRP_Switch_P3_00 160
#define VC_GRP_Switch_P3_01 161
#define VC_GRP_Switch_P3_02 162
#define VC_GRP_Switch_P3_03 163
#define VC_GRP_Switch_P3_04 164
#define VC_GRP_Switch_P3_05 165
#define VC_GRP_Switch_P3_06 166
#define VC_GRP_Switch_P3_07 167
#define VC_GRP_Switch_P3_09 168
#define VC_GRP_Switch_P3_10 169
#define VC_GRP_Switch_P3_12 170
#define VC_GRP_Switch_P3_13 171
#define VC_GRP_Switch_P3_14 172
#define VC_GRP_Switch_P3_15 173
#define VC_GRP_Switch_P3_16 174
#define VC_GRP_Switch_P3_17 175
#define VC_GRP_Switch_P3_18 176
#define VC_GRP_Switch_P3_19 177
#define VC_GRP_Switch_P3_20 178
#define VC_GRP_Switch_P3_21 179
#define VC_GRP_Switch_P3_22 180
#define VC_GRP_Switch_P3_23 181
#define VC_GRP_Switch_P3_24 182
#define VC_GRP_Switch_P3_25 183
#define VC_GRP_Switch_P4_01 184
#define VC_GRP_Switch_P4_02 185
#define VC_GRP_Switch_P4_03 186
#define VC_GRP_Switch_P4_04 187
#define VC_GRP_Switch_P5_01 188
#define VC_GRP_Switch_P5_02 189
#define VC_GRP_Switch_P5_03 190
#define VC_GRP_Switch_P5_04 191
#define VC_GRP_Switch_P5_05 192
#define VC_GRP_Switch_P5_06 193
#define VC_GRP_Switch_P5_07 194
#define VC_GRP_Switch_P5_08 195
#define VC_GRP_Switch_P6_00 196
#define VC_GRP_Switch_P6_01 197
#define VC_GRP_Switch_P6_02 198
#define VC_GRP_Switch_P6_03 199
#define VC_GRP_Switch_P6_04 200
#define VC_GRP_Switch_P6_05 201
#define VC_GRP_Switch_P6_06 202
#define VC_GRP_Switch_P6_07 203
#define VC_GRP_Switch_P6_08 204
#define VC_GRP_Switch_P6_09 205
#define VC_GRP_Switch_P6_10 206
#define VC_GRP_Switch_P6_11 207
#define VC_GRP_Switch_P8_01 208
#define VC_GRP_Switch_P8_02 209
#define VC_GRP_Switch_P8_03 210
#define VC_GRP_Switch_P8_04 211
#define VC_GRP_Switch_P8_05 212
#define VC_GRP_Switch_P8_06 213
#define VC_GRP_Switch_P8_07 214
#define VC_GRP_Switch_P8_08 215
#define VC_GRP_Switch_P8_09 216
#define VC_GRP_Switch_P8_10 217
#define VC_GRP_Switch_P8_11 218
#define VC_GRP_Switch_P8_12 219
#define VC_GRP_Switch_P8_13 220
#define VC_GRP_Switch_P8_14 221
#define VC_GRP_Switch_P8_15 222
#define VC_GRP_Switch_P8_16 223
#define VC_GRP_Switch_P8_17 224
#define VC_GRP_Switch_P8_18 225
#define VC_GRP_Switch_P8_19 226
#define VC_GRP_Switch_P8_20 227
#define VC_GRP_Switch_P8_21 228
#define VC_GRP_Switch_P8_22 229
#define VC_GRP_TelescopeEyepiece 230
#define VC_GRP_TelescopeGuard 231
#define VC_GRP_TelescopeHousing 232
#define VC_GRP_ThrustChambers 233
#define VC_GRP_WindowFrames 234
#define VC_GRP_WindowGlass 235
#define VC_GRP_Window_ADI 236
#define VC_GRP_Window_COAS 237Mesh resource files are not really important when you're only dealing with 2 or 3 moving parts at a time but as you can see, our VC will have HUNDREDS of them and at that point using index numbers becomes problematic.
Adding and coding the VC is still a long way away but I want to start planning for it now rather than have to go back and re-code a bunch of stuff later. :thumbup:
Anyway...
The next feature I want to impliment is "Staging". The LM is after all a two-stage "rocket" with the rather odd idea of staging while landed! :lol:
However in order to impliment staging we need to be able to create and apply custom vessel states. An important part of this is making sure that these states are persistant. Afterall you don't want the first stage of your launch vehicle "Respawing" every time you load (Current State).scn.
Or maybe you do but the point is that I don't.
So without further ado...
PART 8: Scenario Files
The Reading and Writing of *.scn files is controlled by two call back functions. "clbkLoadStateEx" and "clbkSaveState", I'm pretty sure you guys will figure out which one does what so let's add them to our class interface...
Code:
// Overloaded callback functions
void clbkSetClassCaps (FILEHANDLE cfg); // Set the capabilities of the vessel class
[COLOR="Red"]
void clbkLoadStateEx (FILEHANDLE scn, void *status); // Read status from scenario file
void clbkSaveState (FILEHANDLE scn); // Write status to scenario file[/COLOR]
void clbkPostCreation (); // Finalise vessel creation
void clbkPostStep (double simt, double simdt, double mjd); // Manage Animations and Post-Step processes
int clbkConsumeBufferedKey (DWORD key, bool down, char *kstate); // Process keyboard inputsAnd overload them in our source file...
Code:
// --------------------------------------------------------------
// Read status from scenario file
// --------------------------------------------------------------
void LM::clbkLoadStateEx (FILEHANDLE scn, void *status)
{
int i = 0;
char *cbuf;
while (oapiReadScenario_nextline (scn, cbuf))
{
// Load default parameters
ParseScenarioLineEx (cbuf, status);
} // End "while (oapiReadScenario_nextline (scn, cbuf))"
} // End "LM::clbkLoadStateEx"
// --------------------------------------------------------------
// Write status to scenario file
// --------------------------------------------------------------
void LM::clbkSaveState (FILEHANDLE scn)
{
int i = 0;
char cbuf[256];
// Write default vessel parameters to scenario file
VESSEL3::clbkSaveState (scn);
} // End "LM::clbkSaveState"Unlike the other call back functions we have used so far "clbkLoadStateEx" and "clbkSaveState" need to be explicitly told what to do when called. If we did not include the calls to Orbiter's default vessel parameters our vessel would not be saved or loaded to/from the scenario file.
This is described in the Orbiter API_Guide, and the code shown above will mimic the default functionality.
Moving on...
Our first step will be to save a custom variable to our scenario. Rather than adding a vew variable to our code let's simply write our hatch's status to the scenario file
Add the following to "clbkSaveState"...
Code:
// Write default vessel parameters to scenario file
VESSEL3::clbkSaveState (scn);
[COLOR="red"] // Write custom parameters to scenario file
sprintf (cbuf, "%i %0.4f", HatchStatus, hatch_proc); // EVA Hatch status and animation state
oapiWriteScenario_string (scn, "HATCH", cbuf);[/COLOR]
} // End "LM::clbkSaveState"As you can see there are two lines that we are interested in.
The first is a standard sprintf function , what it is doing is taking two numbers, an intiger corisponding to our "HatchStatus" and a Float (decimal) corisponding to "hatch_proc", and write them to the character buffer ("cbuf") declared at the top of clbkSaveState.
The next line is an Orbiter API function that actually writes a line into a scenario file.
In this case we are writing a line to the active scenario file "scn", labeling it "HATCH", and then placing the contents of "cbuf" (our current values for HatchStatus and hatch_proc) inside of it.
Let's compile and test...
Open the scenario, open your hatch, and then quit the scenario...
NOTE: If your orbiter simulation hangs on exit, a syntax error in clbkSaveState is one of the most common culprits.
Now open (Current State).scn with a text editor and find your Lunar Lander. There should be a new line at the bottom of it's entry in the scenario.
Our values for HatchStatus and hatch_proc have been succesfully saved to the scenario. Now we need to load them.
Pop up to clbkLoadStateEx and add the following...
Code:
while (oapiReadScenario_nextline (scn, cbuf))
{
[COLOR="red"] // Load animation states
if (!_strnicmp (cbuf, "HATCH", 5)) // find line labeled "HATCH" in scn file
{
sscanf (cbuf+5, "%i %lf", &HatchStatus, &hatch_proc); // Read values stored there to HatchStatus and hatch_proc
SetAnimation (anim_Hatch, hatch_proc); // Apply process value to animation.
} [/COLOR]
// Load default parameters
[COLOR="red"]else [/COLOR]ParseScenarioLineEx (cbuf, status);
} // End "while (oapiReadScenario_nextline (scn, cbuf))"Let's break down what's happening here...
Code:
while (oapiReadScenario_nextline (scn, cbuf))
{...Simply scans every line of the vessel's entry in the scenario.
Code:
if (!_strnicmp (cbuf, "HATCH", 5))Checks to see if the first 5 characters of the line being scanned are "HATCH", if not we let Orbiter's default scenario reader handle it. If they are we perform the following action...
Code:
sscanf (cbuf+5, "%i %lf", &HatchStatus, &hatch_proc); // Read values stored there to HatchStatus and hatch_proc
SetAnimation (anim_Hatch, hatch_proc); // Apply process value to animation.the first line is another standard C++ function for parsing values. We are telling it to skip the first 5 characters of the line (the part that says "HATCH") and read the first intiger and float it can find. Those two values are then applied to HatchStatus and hatch_proc via pointer.
The second line should be self explanatory.
Compile the code and test it, your hatch's state should now persist between scenarios.
Adding additional variables is a matter of simply following the same procedure.
Code:
// Load animation states
if (!_strnicmp (cbuf, "HATCH", 5)) // find line labeled "HATCH" in scn file
{
sscanf (cbuf+5, "%i %lf", &HatchStatus, &hatch_proc); // Read values stored there to HatchStatus and hatch_proc
SetAnimation (anim_Hatch, hatch_proc); // Apply process value to animation.
}
[COLOR="red"] else if (!_strnicmp (cbuf, "GEAR", 4)) // find line labeled "GEAR" in scn file
{
sscanf (cbuf+4, "%i %lf", &GearStatus, &gear_proc); // Read values stored there to GearStatus and gear_proc
SetAnimation (anim_Gear, gear_proc); // Apply process value to animation.
}[/COLOR]
// Load default parameters
else ParseScenarioLineEx (cbuf, status);Feel free to experiment with it. :tiphat:
Next up I will be talking about creating your own custom functions and vessel states with an eye towards writing a stage seperation routine.
