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

[Hlynkacg]

No UMMU support? I would help but Its truly not that hard, particularily for someone as good at coding like you. WRT the comms, maybe you can have a code function that only activates the ATC coms in orbitersound when a Nav receiver is set to a particular channel (not taken up by any nav signals). That way, you can have 2 radio receivers, one needing to be tuned to Mission Control, the other to your landing nav beacon. (If there is one)

I dont suppose theres any way to simulate climbing up the ladder, but at least make sure the UMMU spawn point is on a Landing pad, so theres a chance for all us Orbinauts to use a quote when taking... that giant leap.

Nice work :thumbup:

By the way, dont get rid of the dummy switches. Even if they dont do anything significant, its still nice to be able to do it just to add some atmosphere to the cockpit

no UMMU support yet...

I was doing my best to keep my Addon free of external depandancies but, at a certain point you have to call it in.

the plan for UMMU is to have a simple boolean. In psuedo code it'd look something like this...

if (ground contact = true) place UMMU spawn-point/airlock at base of ladder
else if (ground contact = false) place UMMU spawn-point/airlock at EVA hatch

As for the rest, I'm still thinking about it.

I'm also thinking that I should replace the historical T/W meter with a VACC display.

---------- Post added at 07:32 PM ---------- Previous post was at 07:28 PM ----------

Also the issue isn't so much removing unused dummy switches as replacing historical panels/functions with new Orbiter specific ones.

 

[BruceJohnJennerLawso]

no UMMU support yet...

I was doing my best to keep my Addon free of external depandancies but, at a certain point you have to call it in.

the plan for UMMU is to have a simple boolean. In psuedo code it'd look something like this...

if (ground contact = true) place UMMU spawn-point/airlock at base of ladder
else if (ground contact = false) place UMMU spawn-point/airlock at EVA hatch

As for the rest, I'm still thinking about it.

I'm also thinking that I should replace the historical T/W meter with a VACC display.

---------- Post added at 07:32 PM ---------- Previous post was at 07:28 PM ----------

Also the issue isn't so much removing unused dummy switches as replacing historical panels/functions with new Orbiter specific ones.

Are you going to go with the apollo style surface speed indicator (the moving crosshairs), or go with something else? A digital version of that would look pretty cool IMO. In all seriousness, though, is there any way to climb the ladder?

And, one final thought, assuming its not adding too big of a time consumer/FPS drag, make sure to include the storage bays with the surface experiments/tools, along with the TV camera.

 

[Hlynkacg]

Are you going to go with the apollo style surface speed indicator (the moving crosshairs), or go with something else? A digital version of that would look pretty cool IMO.

The X-Pointer?

Haven't decided yet and haven't gone beyond Idle sketches. I've actually PMed the NASSP guys about stealing thier design but haven't hear back yet.

In all seriousness, though, is there any way to climb the ladder?

In theory yes. but it'll be a big PITA for minimal payout so no.

 

[BruceJohnJennerLawso]

The X-Pointer?

Haven't decided yet and haven't gone beyond Idle sketches. I've actually PMed the NASSP guys about stealing thier design but haven't hear back yet.



In theory yes. but it'll be a big PITA for minimal payout so no.

Ive seen a MFD example somewhere on OHM lists Orbiter version as 2006, might have source if you want me to find the link for you.

didnt think the ladder idea would fly, but stranger things have happened. the airlock can probably strech all the way from the hatch down to the surface as its only defining where the E key will cause an ingress, but when you program the setposrotonEVA call, make sure to have the UMMU appear either right in front of the hatch or about halfway down the ladder. Even if you put the UMMU create point above the lander, it should be able to survive the landing, and the quick fall to the surface looks cool.

Another future idea that might be cool would be asteroid landers (less fuel, maybe some sort of a harpoon in order to stay stuck to the surface?), permanent habitat landers (very useful if we can ever get an OF lunar base project going), a NTR lander, probably other things too, if I can think of them

 

[Hlynkacg]

Ive seen a MFD example somewhere on OHM lists Orbiter version as 2006, might have source if you want me to find the link for you.

didnt think the ladder idea would fly, but stranger things have happened. the airlock can probably strech all the way from the hatch down to the surface as its only defining where the E key will cause an ingress, but when you program the setposrotonEVA call, make sure to have the UMMU appear either right in front of the hatch or about halfway down the ladder. Even if you put the UMMU create point above the lander, it should be able to survive the landing, and the quick fall to the surface looks cool.

Another future idea that might be cool would be asteroid landers (less fuel, maybe some sort of a harpoon in order to stay stuck to the surface?), permanent habitat landers (very useful if we can ever get an OF lunar base project going), a NTR lander, probably other things too, if I can think of them

Way ahead of you..

see page 9

I'm also assuming you saw my Payload lander

These were actual APP proposals by the way. Basically the plan was to take an autonomous LEM Descent Stage and then bolt either a Cargo rack or space-station module to the top. Ding! Instant moonbase.

Though I'm think that the Hab-cylinder should be better vertical vice horizontal.

 

[4throck]

Nice model!
May I suggest a slightly different gold foil texture?
Something like this:

 

[Hlynkacg]

Nice model!
May I suggest a slightly different gold foil texture?
Something like this:

Thanks.

I'm sticking with the default Orbiter foil texture mostly out of laziness/convienence, though I admit that the UV mapping could use some work.

On the progress front...

I've been studying up on animations so I can write another "Coding .dlls for people who don't know how to code" tutorial, and we are now one small step closer to being able to do a full launch scenario.

---------- Post added at 06:13 AM ---------- Previous post was at 03:26 AM ----------

Ok this is frustrating...

The following lines are part of the thruster management routine that gets called every post step.

does anybody something in the Roll control switch that would cause "case 0" of the pitch control switch to stop functioning?

because that's whats happening.

	// RCS control modes (based on stock Dragonfly's thruster controls)
	double tlevel; // thruster setting
	double tlevel_r; // reciprical of 'tlevel'
	static int lin_x,lin_y,lin_z;
	static int rot_x,rot_y,rot_z;
	//dlevel=(VERN_handle>0?1:0.1); //vernier or not!
	double dlevel = 1; // **no vern handle so I'm leaving this as 1**

	switch (SWITCH_PITCH_CONT)
	{
	case 2: // Mode Cont. (orbiter normal)
		// don't do anything
		break;
	case 1: // Pulse Mode
		if (pinput != 0)
		{
			DelThrusterGroup(THGROUP_ATT_PITCHUP);
			DelThrusterGroup(THGROUP_ATT_PITCHDOWN);

			if ((tlevel = GetManualControlLevel(THGROUP_ATT_PITCHUP, MANCTRL_ANYDEVICE, MANCTRL_ROTMODE)) && (!rot_x++)) SetThrusterGroupLevel(th_rot_pup, tlevel*dlevel); 
			if ((tlevel_r = GetManualControlLevel(THGROUP_ATT_PITCHDOWN, MANCTRL_ANYDEVICE, MANCTRL_ROTMODE)) && (!rot_x++)) SetThrusterGroupLevel(th_rot_pdown, tlevel_r*dlevel);
			if (tlevel + tlevel_r==0) rot_x=0;
			//sprintf(oapiDebugString(), "tlevel %f, tlevel_r %f, rot_X %f", tlevel, tlevel_r, rot_x);
		}
		break;
	case 0: // Direct Mode (Manual inputs only)
		if (oapiGetFocusInterface() == this) // Otherwise Spider will be detecting your control inputs even when focus is on a different vessel
		{
			DelThrusterGroup(THGROUP_ATT_PITCHUP);
			DelThrusterGroup(THGROUP_ATT_PITCHDOWN);

			SetThrusterGroupLevel(th_rot_pup,-pinput*dlevel);
			SetThrusterGroupLevel(th_rot_pdown, pinput*dlevel);
		}
		break;
	} // end pitch control switch

	switch (SWITCH_ROLL_CONT)
	{		
	case 2: // Mode Cont. (orbiter normal)
		// don't do anything
		break;
	case 1: // Pulse Mode
		if	(rinput != 0)
		{
			DelThrusterGroup(THGROUP_ATT_BANKRIGHT);
			DelThrusterGroup(THGROUP_ATT_BANKLEFT);

			if ((tlevel = GetManualControlLevel(THGROUP_ATT_BANKRIGHT, MANCTRL_ANYDEVICE, MANCTRL_ROTMODE)) && (!rot_y++)) SetThrusterGroupLevel(th_rot_rright, tlevel*dlevel);
			if ((tlevel_r = GetManualControlLevel(THGROUP_ATT_BANKLEFT, MANCTRL_ANYDEVICE, MANCTRL_ROTMODE)) && (!rot_y++)) SetThrusterGroupLevel(th_rot_rleft, tlevel_r*dlevel);
			if ( tlevel+tlevel_r == 0) rot_y=0;
			//sprintf(oapiDebugString(), "tlevel %f, tlevel_r %f, rot_X %f", tlevel, tlevel_r, rot_y);
		}
		break;
	case 0: // Direct Mode (Manual inputs only)
		if (oapiGetFocusInterface() == this)
		{
			DelThrusterGroup(THGROUP_ATT_BANKRIGHT);
			DelThrusterGroup(THGROUP_ATT_BANKLEFT);

			SetThrusterGroupLevel(th_rot_rright, rinput*dlevel);
			SetThrusterGroupLevel(th_rot_rleft,-rinput*dlevel);
		}
		break;
	}// end roll control switch

	switch (SWITCH_YAW_CONT)
	{		
	case 2:  // Mode Cont. (orbiter normal)
		// don't do anything
		break;
	case 1: // Pulse Mode
		if (yinput != 0)
		{
			DelThrusterGroup(THGROUP_ATT_YAWRIGHT);
			DelThrusterGroup(THGROUP_ATT_YAWLEFT);

			if ((tlevel = GetManualControlLevel(THGROUP_ATT_YAWRIGHT, MANCTRL_ANYDEVICE, MANCTRL_ROTMODE)) && (!rot_z++)) SetThrusterGroupLevel(th_rot_yright, tlevel*dlevel);
			if ((tlevel_r = GetManualControlLevel(THGROUP_ATT_YAWLEFT, MANCTRL_ANYDEVICE, MANCTRL_ROTMODE)) && (!rot_z++)) SetThrusterGroupLevel(th_rot_yleft, tlevel_r*dlevel);
			if ( tlevel+tlevel_r == 0) rot_z=0;
			//sprintf(oapiDebugString(), "tlevel %f, tlevel_r %f, rot_X %f", tlevel, tlevel_r, rot_z);
		} 
		break;
	case 0: // Direct Mode (Manual inputs only)
		if (oapiGetFocusInterface() == this)
		{
			DelThrusterGroup(THGROUP_ATT_YAWRIGHT);
			DelThrusterGroup(THGROUP_ATT_YAWLEFT);

			SetThrusterGroupLevel(th_rot_yright,-yinput*dlevel);
			SetThrusterGroupLevel(th_rot_yleft, yinput*dlevel);
		}
		break;
	}// Yaw control switch

 

[Hlynkacg]

I posted these in a responce to an SDK thread so I might as include them here as well.

 

[Hlynkacg]

Sourceforge account is up

http://sourceforge.net/projects/spid...urce=directory

 

[Hlynkacg]

Just a quick update to say that this project is still Alive.

I'm just having some issues with animations and thruster control routines. I've got a pair of stubborn bugs that just wont die standing between me and a second release.

I can feel the ADD kicking in and I really want to move on to the next project.

If you know a thing or two about matrix math you can help by checking out one of these threads.

http://www.orbiter-forum.com/showthread.php?t=29085
http://www.orbiter-forum.com/showthread.php?t=28958
http://www.orbiter-forum.com/showthread.php?t=28815

 

[Tycho]

And interest is still alive as well; I'm still checking in periodically! Hang in there--you'll get it (w/out my help unfortunately---matrices were never my strength)! :thumbup:

 

[Hlynkacg]

Quick Update.

I had intended to post a second release today but something I did last night has resulted in a massive code implosion. As such I am currently backtracking my way through the changes I made to find the source of this issue, and will post as soon as I have it isolated.

Things to expect in new version.

Functional ADI ball
Functional CWA and Master Caution Lights
Overhauled propellant and thruster management
Commander and LMP's side panels added
Initial Implementation of consumables (O2 and Water)

Known bugs (Not counting the random CTDs caused by the afore mentioned code implosion)
Landing gear animation is glitched
Yaw rate needle on ADI is non functional
HUD pointers don't point in the correct direction
Autopilots still unstable

 

[Zachstar]

That sounds interesting! Good luck with finding that bug!

 

[Hlynkacg]

:woohoo:

Spider is back in action!

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

Orbit Hangar file has been updated

[ame="http://www.orbithangar.com/searchid.php?ID=5846"]Spider Lunar Lander *Beta v2*[/ame]

---------- Post added at 03:29 PM ---------- Previous post was at 02:39 AM ----------

Crap!

Just discovered bug that may cause CTD when the Descent Stage (Spider_DS) vessel is spawned.

Standby, hotfix is inbound.

 

[BruceJohnJennerLawso]

:woohoo:

Spider is back in action!

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

Orbit Hangar file has been updated

Spider Lunar Lander *Beta v2*

---------- Post added at 03:29 PM ---------- Previous post was at 02:39 AM ----------

Crap!

Just discovered bug that may cause CTD when the Descent Stage (Spider_DS) vessel is spawned.

Standby, hotfix is inbound.

Do you know whats causing it?

 

[Hlynkacg]

Fix is in

[ame="http://www.orbithangar.com/searchid.php?ID=5846"]Spider Lunar Lander *Beta v2.1*[/ame]

Broken link was causing CTD on stage seperation (descent stage vessel wasn't loading properly) now fixed.


---------- Post added at 06:03 AM ---------- Previous post was at 12:01 AM ----------


Hotfix 2: In the process of fixing #1 I accidently deleted the LEM's touchdown points :facepalm: it's fixed now.

 

[Hlynkacg]

Code updated:

I've cleaned up "clbkLoadVC" and added switch functionality and animations to panels 12 and 14. If you've downloaded version 2+ of the beta you can grab and compile the code from my repository linked on the front page.

I'm also nearing the point where I'm looking to split this project into two threads.

The first will be the "Spider Lunar Lander" and essentially what you see here. Spider will have no requirements beyond Orbiter 2010 and recieve only minor updates post split.

The second thread is tentatively titled "UMMU_Apollo" (I'm taking suggestions, if anyone has better ideas for a name) and will included not only a UMMU/UCCGO compatable version of Spider but also the development of a UMMU compatable CSM (codename "Gumdrop" ) to go with it.

The objective of UMMU_Apollo will be to produce a combined CSM, SLA, LEM stack that can be placed atop the launcher of your choice. Stock included launch scenarios will use Velcro rockets in the interim but eventually I hope to produce the entire Saturn family of boosters (both historical and proposed) as a seperate package.

Finally I want to get the user's take on something...

I've been thinking about reconfiguring Panel 1, returning it to it's historical ADI + X-pointer configuration. The MFD would inturn be relocated to Panel 4 taking the place of the DSKY.

The launch and landing autopilots along with other DSKY functions currently integrated into the vessel module itself would be deleted and implimented as part of a "UMMU_AGC" (UMMU_Apollo Guidance Computer) MFD mode instead.

 

[Kyle]

Not sure if this is the way it's supposed to be, but when I go to download the Spider Lunar Lander Beta v2.2, there's nothing there to download.
[ame="http://www.orbithangar.com/searchid.php?ID=5846"]http://www.orbithangar.com/searchid.php?ID=5846[/ame]

Download (0.00 KB)

 

[Hlynkacg]

Not sure if this is the way it's supposed to be, but when I go to download the Spider Lunar Lander Beta v2.2, there's nothing there to download.
http://www.orbithangar.com/searchid.php?ID=5846

Download (0.00 KB)

It's not supposed to be like that,

I just re-uploaded the file so try it again now.

 

[Tycho]

It looks fantastic. Visuals look great and the VC with all the switches is outstanding! :thumbup:

By the way, I like the idea of replacing the DSKY with an MFD display with an Apollo Flight Computer mode. You could simulate keyboard inputs with that just fine while still preserving realism and accessibility all at once.