Project Another Apollo Project

[orbitingpluto]

My thoughts on one way this could go without the complex flight model:

No switch throwing, and nothing simulated in complex comes into play. You tap Numpad +, and the engine bangs on and off without any prior interaction. The ship doesn't keep track of anything other than propellent, and will presume that any RCS propellent can be used by all thrusters, so there's no need to crossfeed, or model separate tanks. Reentry and landing could be handled like complex mode though, for the most part, maybe including dying. The reason I think reentry and landing should be similar so that learning how to do something on simple mode won't cause too much of a problem in complex mode. I think being indestructible or having huge margins to fall back on would make the switch to complex harder, but I kinda recognize this might be a bad idea. It's a just a thought.

 

[4throck]

Note that I am specifically talking about when the player leaves "Complex Flight Model" check-box un-checked.

Most users will load a scenario and simply fly with the spacecraft as it comes. They will not change their Orbiter's configuration.
So any features you add should be enabled/disabled by scenario. Otherwise, most people may never even be aware of them.

 

[N_Molson]

You tap Numpad +, and the engine bangs on and off without any prior interaction.

Please, no, no :facepalm: ! A short throttle up / throttle down ignition / cutoff sequence is a minimum. Even better if you have to power on some systems prior to that.

Otherwise, most people may never even be aware of them.

RTFM !!

 

[4throck]

You can cry all you want ....
Sure, people will read the manual if they find the addon interesting enough after the first 10 minutes of use.If not, they will move on to other things.


As an example, look at Apple. I'm not a fan, but they to have a point in focussing on the user first. Sure, their products are dumbed down and do less, BUT they are appealing...

The user will perceive more value from less apparent features. That is a fact!


Nevertheless I'm just saying that a nice "arcade" or "invencible" mode should be selected by a scenario parameter.

That way both audiences can use the same addon, and even have a replay value by repeating mission in "hard mode". Simply offer the scenarios in two flavours.

 

[orbitingpluto]

Please, no, no :facepalm: ! A short throttle up / throttle down ignition / cutoff sequence is a minimum. Even better if you have to power on some systems prior to that.

I'm talking about a simple mode here. Systems to monitor are a good thing, but they add more to deal with. Trying to get a Apollo mission to land on the Moon for the first time, a person might want a simple mode so they can focus on not running of dv or smacking the stack into the Moon. For that kind of first outing, a user is bound to have plenty of unfamiliar things to deal with, so why clutter that up with systems management? If a new guy is trying to make his burn on time, he should be able to worry about that and not about how much helium he'll use or whether the valves are open. That isn't to say it should be just a noob-mode, I appreciate the idea of a mode where I the only thing I need to worry about is my flying.

As a feature request related to this simple/complex flight thing, could there be a scenario line that could trigger an 'safe' mode for docked Apollos? I'm think that when a normally complex CSM with this tag docks, preferably with a space station or something like that, that it won't run it's on it's consumables and act as though it's being cooled and supported by the station. I think something like this would come in handy after complex systems capable of causing negative effects are coded.

 

[Hlynkacg]

Just a note that despite obligations in meat space I'm still working on AAPO.

In fact I just achieved a minor breakthrough on a coding problem that has been holding me up for some time.

As an aside, in case I forget, meson800 deserves a partial coding credit or an acknowledgment at the very for all the help he's afforded me.

 

[kuddel]

In fact I just achieved a minor breakthrough on a coding problem that has been holding me up for some time.

Congrats! I know how frustrating such things can be...and how GREAT the moment of breakthroug feels after that :thumbup:

Any information (of public interest) on the problem? Especially, how you fixed it? Or was it just one of those 'facepalm' things that tend to happen?

Keep goin',
Kuddel


---edit---
Just saw the other thread about the thrusters, so I think there's no need for any further information.

 

[Hlynkacg]

Still working,

I've gone a little struct, and class tree happy and considering the lack of an AAPO manuel i should probably write some of this down.

RCS modes:

• "Linear" as per Orbiter manual
• "Rotation" as per Orbiter manual

toggle using [/]

Attitude Hold:

• "Off" Attitude control inputs are mapped directly to thrusters. Autopilots and FCS are disabled.
• "Hold" In absence of user input, the FCS will attemptto maintain current attitude and velocity. Essentially an auto-killrot
• "Auto" If no autopilots are active attitude control inputs are mapped to linear or angular acceleration. Otherwise attitude inputs will be set by the FCS, note autopilots will be non functional unless attitude mode is in "auto"

toggle using [A], note "Hold Alt" autopilot has been disabled in AAPO vessels.

Vernier:

• "Enabled" RCS authority reduced, FCS will prioritize thrust vectoring in attitude control.
• "Disabled" RCS authority as normal, thrust vectoring limited to CoG balancing.

toggle using [V]

In addition to switches + indicator lights in the VC the status of these items will indicated by hud flags in the same manner as RCS modes and gear status for the DG.

---------- Post added at 11:43 ---------- Previous post was at 11:23 ----------

AAPO inheritance trees

AAPO::Vessel

• LM
  • LM_Ascent
  • LM_Descent
  • LM_Lab
• CSM
  • LES
  • CommandMod
  • ServiceMod
• Chutes
  • CM_Drogues
  • CM_Mains
• Junk
  • SM_BayCover
  • SLA
  • SLA_Panel
  • CM_NoseCone
  • CM_DockingProbe

AAPO::Cockpit

• CM_VC
• LM_AscentVC
• LM_OrbitVC

AAPO::FCS

• CapsuleFCS
• LanderFCS

AAPO::Saturns

• Booster
  • SaturnC1B
  • SaturnC5A
• Pad
  • LC39
  • LC34
• Stage
  • SatIb
  • SatIc
  • SatIIc
  • SatIVb

 

[Hlynkacg]

Good News everyone!

the feature I just finished implementing is something I can actually take a screenshot of.

Can you spot the differences between these three LMs?

Hint: 4thRock should be pleased.

 

[4throck]

That is attention to detail indeed Don't' forget that the landing stage also had different "versions". The same goes for the CSM.... I think you could do it just by changing textures.

A suggestion: leave room for a post Apollo 17 LEM, it may come handy :thumbup:

 

[Hlynkacg]

That is attention to detail indeed Don't' forget that the landing stage also had different "versions". The same goes for the CSM.... I think you could do it just by changing textures.

A suggestion: leave room for a post Apollo 17 LEM, it may come handy :thumbup:

Don't worry it's easily expandable.

There is now a string variable variable in the LM and CSM's code called "cSkinName" that can be set via scenario file.

cSkinName causes the module to check the new AAPO/Skins directory for a dds called "%module_%cSkinName.dds" if found it will apply it to the mesh.

From left to right in the above screenshot we have

• "AscentStage_Mid.dds" (cSkinName = "Mid") representing Apollos 12 - 14 and the canceled "H missions"
• "AscentStage_Late.dds" representing Apollo 15 and subsequent
• "AscentStage_Early.dds" representing the initial production batch of 5 LMs, Apollos 9 - 11 as well as two test articles

(yes they are out of order)

To add a skin simply create a new dds for the vessel in question and call it CommandMod_x ServiceMod_x or whatever and then in the scenario set the skin name to x.


The bad news is that I've broken my RCS code again

 

[4throck]

Good news!
Please do the same for the descent stage (some minor differences but they do exist) and for the CSM :thumbup:

One thing that I noticed is that your LEM colors are accurate, based on a web reference I saw (http://pfinspace.com/lmdata/) .

Yet the LEM never looks that greenish on photos.... And most of the museum displays are mockups, so you can't use them as reference.

 

[Hlynkacg]

There are actually two complete "flyable" LMs still on Earth. the one in the smithsonian's food-court is a Complete Block II (Mid era) LM than has been modified and repainted to look like a Block I, Specifically Eagle. It would have flown on Apollo 15, but Apollo 15 ended up being upgraded to a Block III LM after their landing site was changed and the spare Block II donated to the Smithsonian.

The second is hanging from the ceiling over KSC's Saturn V. It is the Block III that was being prepped for Apollo 18. No others survive that I am aware of.

As a fun side note. KSC's CSM is actually a 5 man "Rescue CSM" that was built to rescue a marooned Apollo or Skylab Crew. It has since been "restored" to the classic Apollo lunar configuration for display.

PS:
That site was actually one of my primary sources when I was working the LM's mesh.

 

[4throck]

Same here for the ATM B LEM derived observatory :thumbup:

You are right about the real hardware on display. But as you mention most of is was modified, so you can't use is as reference.
They might be acurate displays, but for the level of detail we now use in Orbiter, only real hardware is good enough

So from what you write, only this LEM at KSC is not modified:

Does look close to the Apollo photos of the actual hardware, but still I can't see no hint of greenish tint. Perhaps yellowish...
But the lighting is not 100% natural.

 

[N_Molson]

As a fun side note. KSC's CSM is actually a 5 man "Rescue CSM"

Interesting. I didn't knew it existed.

 

[4throck]

That is part of Skylab hardware.

You have the rescue CSM (never used, 5 seats, crew of 2 goes up) and the long duration CSM (used for Skylab with extra white paint and no High Gain antenna).

That one of the reasons I've asked for multiple textures or meshes. Lot's of replay and future reuse value on having all those versions.

 

[Hlynkacg]

The Rescue CSM actually predates Skylab but the original plan to have it, along with a second Saturn 5, on stand-by for each Lunar mission was nixed for being too expensive.

---------- Post added at 12:11 ---------- Previous post was at 12:00 ----------

The 5 man Apollo CM was actually proposed as a escape pod for the Shuttle/Freedom/ISS but by then the Apollo assembly line had already been re-purposed so the cost savings of from an existing design would have been minimal.

the Apollo CRV would have traded the SM for a simple retro/battery pack and been carried aloft in the shuttle's payload bay.

 

[N_Molson]

the Apollo CRV would have traded the SM for a simple retro/battery pack and been carried aloft in the shuttle's payload bay.

That was a nice idea. :yes:

 

[4throck]

Didn't know about Apollo + Shuttle but always thought that the cargo bay dimensions would make them fit.

Again, lot's of interesting scenario possibilities here...

 

[barrygolden]

Hey Guys

The LM 2 is at the Smithsonian
The LM planned for Apollo 15 is the one at KSC
The LTA 8 LM is at JSC
The LM for Apollo 18 is at the Cradle of Aviation Museum on Long Island
There is a Test article in Philadelphia