Project Lunar Module "Spider" (Updated 11/01/2012)

[orb]

ShuttleD:anel2dtex = oapiLoadTexture (“ShuttleD\\MainPanel.dds”);

For some reason, the compiler is saying that ShuttleD (as in the file directory, where the texture is located) is undefined. That doesnt make sense does it?

Is `panel2dtex` a public static variable of the `ShuttleD` class, which is accessible from the code that is assigning a value to it?

It isn't saying the directory isn't defined, but that ShuttleD symbol (as in code) is undefined.


By the way, there are "\\" in the path, because backspace is treated by compiler as an escape character (to put special characters in code without using their actual representation).

 

[BruceJohnJennerLawso]

Is `panel2dtex` a public static variable of the `ShuttleD` class, which is accessible from the code that is assigning a value to it?

It isn't saying the directory isn't defined, but that ShuttleD symbol (as in code) is undefined.


By the way, there are "\\" in the path, because backspace is treated by compiler as an escape character (to put special characters in code without using their actual representation).

Heres the definition in the Shuttle D class

class ShuttleD :public VESSEL3
{
public:
    ShuttleD (OBJHANDLE hObj, int fmodel);

	~ShuttleD();


	static SURFHANDLE panel2dtex;

	MESHHANDLE hPanelMesh;

looks right to me

---------- Post added at 04:46 PM ---------- Previous post was at 04:41 PM ----------

It would be interesting to have a limit on how long the LM can operate, like running out of consumables(oxygen for the crew, water to cool systems, battery power to run things). You could make use of UCGO for oxygen and water, but you may have to find some other way to deal with power.

I've been watching Spider grow since I spotted a an odd little craft in the screenshot thread. Keep going Hlynkacg! Spider's fore bearers caused their builders many headaches, but they eventually got sorted out into hardworking and reliable machines. Spider will get to the point too.

Yes, if I might add a little bit of inspiration for you

https://www.youtube.com/watch?v=R9p7Smy_6T4

It sounds ridiculous, but I do think a little bit of an addon devs soul does go into something they create. Its sorta a part of you, you know?

 

[marooder86]

Heres the definition in the Shuttle D class

class ShuttleD :public VESSEL3
{
public:
    ShuttleD (OBJHANDLE hObj, int fmodel);

	~ShuttleD();


	static SURFHANDLE panel2dtex;

	MESHHANDLE hPanelMesh;

looks right to me

But have you include that definition into the file where you're trying to access panel2dtex member?

 

[BruceJohnJennerLawso]

But have you include that definition into the file where you're trying to access panel2dtex member?

Where would you suggest it be defined in the CPP?

 

[marooder86]

Where would you suggest it be defined in the CPP?

First, sorry for answering with a question on your question but, how many files do you have in you're project ?
Secondly the best place and typical procedure is to put class declarations into header files and then include those with #include where you need them.

I would also suggest if you can't solve your problem, to start another topic because we kind of hijacking this thread and thats kida rude I think.

 

[Hlynkacg]

It would be interesting to have a limit on how long the LM can operate, like running out of consumables(oxygen for the crew, water to cool systems, battery power to run things). You could make use of UCGO for oxygen and water, but you may have to find some other way to deal with power.

I've been watching Spider grow since I spotted a an odd little craft in the screenshot thread. Keep going Hlynkacg! Spider's fore bearers caused their builders many headaches, but they eventually got sorted out into hardworking and reliable machines. Spider will get to the point too.

Thank you,

I was planning to include consumable o2/power but I'm still trying to figure out the best way to impliment them.

Wouldn't it have been simpler to just keep the thrust through the z-axis and instead rotate the viewport, or might that have given other problems?

The thought did occur to me, and I tried for a while to make it work.

But it introdced a bunch of other issues with touch down points and hover stability (attitude-hold freaked out whenever the commanded pitch exceded 90 degrees). In the end because this is a Lunar Lander I decided to accept the issues with orbital controlability in exchange for greater stability and control on approach/landing.

I would also suggest if you can't solve your problem, to start another topic because we kind of hijacking this thread and thats kida rude I think.

It is but I forgive you.

 

[jedidia]

I was planning to include consumable o2/power but I'm still trying to figure out the best way to impliment them.

Most comfortable way: Abuse propellant resources to store O2, food and water. This way they are accessible in the scneario editor, and you don't have to update the mass manually. Plus, you'll be able to exchange consumables with IMS vessels... :shifty: (after all, a lander needs a mothership!)

Power is another matter altogether. A really accurate power simulation of a LEM is no piece of cake, what with different Buses and all.

 

[BruceJohnJennerLawso]

First, sorry for answering with a question on your question but, how many files do you have in you're project ?
Secondly the best place and typical procedure is to put class declarations into header files and then include those with #include where you need them.

I would also suggest if you can't solve your problem, to start another topic because we kind of hijacking this thread and thats kida rude I think.

Yes Im sorry for being a hijacker, but Im under fairly tight time pressure to get it done before september. Is there an experienced coder that could give the project a look over for me, at least to check that none of the code Ive written is buggy or bad?

 

[palebluevoice]

I was planning to include consumable o2/power but I'm still trying to figure out the best way to impliment them.

I don't know very much about programming, but can't you just have a display, and then use a system like the XR vessels where you press a button in the cockpit to refill o2/power? Then just multiply the consumption rate by the number of ummus. I don't know if this is helpful at all, anyways, your project is looking great.

 

[Hlynkacg]

I don't know very much about programming, but can't you just have a display, and then use a system like the XR vessels where you press a button in the cockpit to refill o2/power? Then just multiply the consumption rate by the number of ummus. I don't know if this is helpful at all, anyways, your project is looking great.

This is the general direction I was leaning but the actual programing is a bit more involved.

---------- Post added at 02:47 AM ---------- Previous post was at 01:54 AM ----------

So I've been looking at the panel and thinking about which functions I actually want to include how best to adapt them to orbiter.

I'm going to post all the deviations from the historical panel I've made so far in the hopes of clearing my head and getting some feed-back.

Panel 1: By far the biggest change is the removal the Commander's X-pointer and ADI to make room for an Orbiter standard MFD. this has left me with 3 "orphaned" switches along the left side of the Panel, I'm not sure what to do with them. With the exception of Manual Control Authority (Pilot or Cmd) all other switches on Panel 1 map directly to things I can do in orbiter.

One change I have been considering is to replace the round "Abort" button in the bottom right of the panel with an "Undock" button. The Historical LEM had no such capability (the CMP would release the docking latch the CSM side). On the other hand, having the stage Seperation and undock buttons right next to each might be an issue so I should probably add a safety catch or something.

Panel 2: The only change I've made is move the "ADI mode select" from Panel 3 to the right side of panel 2 and Move the "ECS mode select" to "ADI mode select" switch's old spot. Why the ADI mode select wasn't next to the ADI from the get go is a mystery. The rest of the switches on panel 2 have to do with propellant management and display scales and can be implemented as is.

Panel 3: is a mess.

External Lighting and Stability Control, are fine but I'm going to either A: Model a full thermal control system and docking radar, or B: find alternate uses for a lot of those buttons and toggles.

Panel 4: I'm not going to bother modeling the full AGC and DSKY as such the plan is use Panel 4 for Autopilot inputs.

Panels 5 and 6: No changes.

 

[BruceJohnJennerLawso]

I just had a brainstorm for a feature request. A-like the original LEM, itll probably need the legs to, umm cantilever?, bend?, inwards, so as to fit into a fairing, and B, sizewise, is it possible, to break this down into components that can be carried as DGIV/XR2 Cargoes, and assembled on-orbit? Time permitting, perhaps you could create a simple version of the lem ascent stage that would act as the CM/Service module, flying the stack say, ISS-Lunar Orbit-ISS/LUNA-OB1?

 

[Hlynkacg]

I just had a brainstorm for a feature request. A-like the original LEM, itll probably need the legs to, umm cantilever?, bend?, inwards, so as to fit into a fairing, and B, sizewise, is it possible, to break this down into components that can be carried as DGIV/XR2 Cargoes, and assembled on-orbit? Time permitting, perhaps you could create a simple version of the lem ascent stage that would act as the CM/Service module, flying the stack say, ISS-Lunar Orbit-ISS/LUNA-OB1?

the landing gear have already been designed to fold, I just haven't gotten around to coding the animations.

As for having the whole thing break down for assembly on orbit, coding it would be too much trouble for too little payoff.

 

[BruceJohnJennerLawso]

the landing gear have already been designed to fold, I just haven't gotten around to coding the animations.

As for having the whole thing break down for assembly on orbit, coding it would be too much trouble for too little payoff.

Sorry, just trying to help. I know this sounds crazy, but I think this addon might be the best of all the ones coming this fall. BTW, an interesting site that you might be able to get ideas from

http://www.shovsoft.com/lunarflight/

 

[Hlynkacg]

Been busy cleaning, commenting, and chasing bugs.

I intend include to include the source as an SDK sample with the addon and intend for to be clean, readable, and thoroughly commented.

I had a couple of major show-stopping/CTD issues that needed to be sorted out, one involving a UMMU/HUD conflict and another where variables would "bleed-over" from one instance of the vessel in a scenario to the other and hilarity would ensue. :facepalm:

As you can see below I think i've got them both licked (though I had to abandon my cool custom hud reticle for a boring standard one)



Spider, performs inflight stability/controlability tests as a technician observes. Her sister-ship "Eagle" (a second Spider instance) awaits testing in the background.

And because I haven't posted enough cockpit work-in-progress shots...



I really liked what Moach was able to do with "negative space" in the G42's VC and decided to experiment with something similar.

What's the verdict? Keep it, try something different, or go back?

Careful observers will also note that the switches are now animated. They are all clickable and some of them even have in game effects. :thumbup:

 

[4throck]

Don't what to thread hijack but take a look at what I've done with those LEM panel textures here http://orbiter-forum.com/showthread.php?t=28762 .

On this case I wanted to give the whole thing a retro trainer interior look so I textured the background with a uniform texture. It helps to give the sense of a small space.

But the black VC is much faster to get right :thumbup: and works for me.

 

[Hlynkacg]

After much drama and frustration I've succesfully finished restructuring Spider's code and migrating the autopilot and other subsystems over to thier own dedicated subclasses.

The landing autopilot is still labeled "crashmeintothemoon" for a reason though. :lol:

 

[jedidia]

As you can see below I think i've got them both licked (though I had to abandon my cool custom hud reticle for a boring standard one)

Have you seen my reply in the other thread concerning this?

 

[Hlynkacg]

Have you seen my reply in the other thread concerning this?

I did, but haven't gotten around to putting it back in yet. The HUD was a low priority in comparison to getting the subsystem classes working.

 

[BruceJohnJennerLawso]

After much drama and frustration I've succesfully finished restructuring Spider's code and migrating the autopilot and other subsystems over to thier own dedicated subclasses.

The landing autopilot is still labeled "crashmeintothemoon" for a reason though. :lol:

Reminds me of my first moon landing. I had managed to intuitively figure out how to do a TLI and get into lunar orbit, but I guess I just figured landing on it would be like reentry on earth. I just slammed the DG into the lunar surface and waited until the ship stopped spinning :lol:. How naive

On a more serious note, this landing AP should be just a throttle manager right? A full landing autopilot would ruin all the fun!

 

[Hlynkacg]

It' can actually be both.

As in the original, there is a row of switches on the Center console that will allow you to activate automatic control of pitch, yaw, roll, and throttle.

With these switches in the "AUTO" position the autopilot should be able to fly the complete descent and landing profile with minimal input from the pilot.

If you want to fine tune your landing site, set Roll/Yaw to MAN and Pitch/Throttle to AUTO, in this set-up the autopilot will manage braking/descent-rate while you steer.

Alternatly you can set Pitch Roll and Yaw to AUTO and manage the throttle yourself.

Finally If you're really hard-core you could always just turn the autopilot off (or hit "Cmd Ovrd").