Help with implimenting UMMU in an addon

[Hlynkacg]

Greetings all.

I already posted this in Orbiter-Forum but I figure it was worth a shot asking the question here as well.

I'm working on incorperating UMMU support into my Lunar Lander. I followed DanSteph's tutorial on how to do so and copy/pasted the pertinent lines from his example. Despite this UMMU crew members are not loading with the scenario file.

I've checked the scn files and have confirmed the they are being recorded, as such I am at a loss .

This is my clbkLoadStateEx

Code: [Select]

// Read vessel status from scenario file
void Spider::clbkLoadStateEx (FILEHANDLE scn, void *status)
{
char *line;
while (oapiReadScenario_nextline (scn, line))
{
if(Crew.LoadAllMembersFromOrbiterScenario(line)==TRUE) continue; // Load UMMUs from scenario
else if(!strnicmp(line, "CONFIGURATION",13)) sscanf(line+13, "%i", &STATUS); // load vessel state
else if(!strnicmp(line, "AUTOPILOT",9)) sscanf(line+9, "%i", &AUTOPILOT); // load autopilot status
else ParseScenarioLineEx (line, status);
}
}
It should also be noted that my "default crew" described in ClbkSetClassCaps are not loading either.

Any assistance would be greatly appreciated.

[DanSteph]

Have you checked that your init is correct in clbksetclasscap ?
Most often it's a bad airlock shape and the init flag stay on false preventing the load function to work.

Dan

[Hlynkacg]

DanSteph wrote:
Have you checked that your init is correct in clbksetclasscap ?
Most often it's a bad airlock shape and the init flag stay on false preventing the load function to work.

Dan

Does the airlock shape have to be defined in clbksetclasscap in order to work?

If so that's probably my problem as I currently have it defined in a seperate function.

[DanSteph]

Hlynkacg a écrit:

DanSteph wrote:
Have you checked that your init is correct in clbksetclasscap ?
Most often it's a bad airlock shape and the init flag stay on false preventing the load function to work.

Dan

Does the airlock shape have to be defined in clbksetclasscap in order to work?

If so that's probably my problem as I currently have it defined in a seperate function.

If the function is called in clbkSetClassCap it should be ok.

Did you read the PDF ?  I think I added a section with the most common error, especially the airlock shape.

Dan

[Hlynkacg]

If the function is called in clbkSetClassCap it should be ok.

It was but I added an airlock definintion to clbkSetClassCap proper and it seems to be working now.

Thank you.

[Hlynkacg]

Another question in regards to the same project.


Reading the documentation and SDK files I know that the folowing lines determine which mesh a UMMU will spawn with.

Code: [Select]

//--------------------------------------------------
// By default UMM 2.0 use the misc id table below to
// choose the UMMU mesh to eva. See PDF doc or README.txt
// in folder config/UMMUIdConfig about those Id/name/meshes table.
// those tables are filled at runtime. You must check if UmmuMiscID
// is empty or look "iNbrOfIdConfigLoaded" below before using them,
// there is 255 ID possible but only a few are filled by default
// at runtime (during init).
#define NUMBER_OF_MMU_TYPE 255
// tables of Id
extern char UmmuMiscID[NUMBER_OF_MMU_TYPE][5];    // example: "Capt" "Sci"
// table of corresponding mesh to use with UmmuMiscID
extern char UmmuMeshUsed[NUMBER_OF_MMU_TYPE][25];    // example: "UMmu/UMmuP" "UMmu/UMmuSci"
// Name corresponding to Misc ID
extern char UmmuFunctionName[NUMBER_OF_MMU_TYPE][25];   // example: "Captain" "Scientific"
extern int iNbrOfIdConfigLoaded; // the number of Id loaded
My question is "Is it possible to use this to find out what mesh a particular UMMU had when it entered the vessel or will spawn with prior to it actually doing so?"


It'd be nice to have the crewmember standing in the window match the crewmember that entered the vessel.



Post Edited ( 05-29-12 04:22 )