Project Another Apollo Project

[Zachstar]

Very pretty! I cant wait to see what you have in store for the VC of the CM.

 

[4throck]

Looks quite nice.

I personally use both Blender tools and a photo editor to do textures.
I go back and forth between them and the UV editor, depending on the geometry.

The internal paint tools are good for curved and flowing areas, such as cloth, foil, etc. And also to do some cleanup, shadings, etc, etc...

 

[vinny5000]

Hi, guys!

Question for you, what is the difference between the NASSP-project apollo & the AAPO or another apollo project since right now I'm using the NASSP-project apollo? Thanks!

Cheers,
Vincent

 

[Tycho]

Ideally, AAPO aims to simulate aesthetics and some degree of functionality of the Apollo spacecraft (flicking functional switches and such). If you're familiar with AMSO, the aesthetics are stunning and the functionality/ease of use is very accessible to the general orbinaut, while NASSP is geared towards hard-core spaceflight simulation with checklists and so forth. I guess the aim of this project would be to strike somewhat of a balance between aesthetics and functionality, if that makes any sense.

But I'm sure Hlynkacg wouldn't mind me saying that this project is just what the title suggests: another Apollo project. Just try 'em all out and see which you like best (and be advised that AAPO is still a work in progress). That's the beauty of having such a wide array of Orbiter add-ons.

 

[4throck]

AAPO integrates better with other Orbiter add-ons such as UMMU and UCGO. It also allows you to use the default MFDs in cockpit.

So think of it as an Apollo done with Orbiter tech.

 

[4throck]

Could someone please verify the CSM UMMU EVA hatch logic?
It's inversed for me: EVA possible with hatch closed, impossible with hatch open!

I'm getting this result with the CSM as the only vessel in the scenario.

 

[clive bradbury]

I seem to have a problem - when I apply main engine in the CSM it rotate uncontrollably and the only way out is to exit the sim. Can anyone please help?

 

[Hlynkacg]

Could someone please verify the CSM UMMU EVA hatch logic?
It's inversed for me: EVA possible with hatch closed, impossible with hatch open!

I'm getting this result with the CSM as the only vessel in the scenario.

Found bug in the focus checker that is likely culprit.

Will be fixed once LM is put back-together.

I seem to have a problem - when I apply main engine in the CSM it rotate uncontrollably and the only way out is to exit the sim. Can anyone please help?

In what stage of flight are you?

---------- Post added at 14:18 ---------- Previous post was at 14:18 ----------

PS:
Project is not dead, just in pieces.

 

[4throck]

Thanks! Another thing on my wish list is EVA with the CSM docked. :hmm:

As with the CSM repaint, you will find some photo textures+normalmaps on my ATM B add-on that may suit your LEM.
The mapping is not the same, but you can simply copy the necessary parts. Feel free to use them for AAPO.

 

[Hlynkacg]

Thanks! Another thing on my wish list is EVA with the CSM docked. :hmm:

The code that (in theory) was supposed to make that possible is the code that is causing the problem. It's supposed to check the hatch status and current focus object and then assign a "Allow EVA" true/false value, but some wires got crossed somewhere .

 

[N_Molson]

I seem to have a problem - when I apply main engine in the CSM it rotate uncontrollably and the only way out is to exit the sim. Can anyone please help?

Did you try to stir O2 tanks, by any luck ? :hmm:

 

[Hlynkacg]

The Kaboom is only supposed to happen on the second stir and only if you name your CSM "Odyssey"

 

[clive bradbury]

Found bug in the focus checker that is likely culprit.

Will be fixed once LM is put back-together.




In what stage of flight are you?

Gumdrop/spider in lunar orbit scenario. Seoarate the CSM, apply main thrust - spin, spin spin!

 

[Hlynkacg]

Gumdrop/spider in lunar orbit scenario. Seoarate the CSM, apply main thrust - spin, spin spin!

sounds like the TVC (engine gimbal control) is failing to reset after undocking, I will investigate.

---------- Post added at 11:17 ---------- Previous post was at 11:06 ----------

Feedback Needed

I'm making solid progress towards a release and need to ask a question.

Just how simple should the simple flight model (AKA oapiComplexFlightModel == false) be?

I'm already bypassing electrical and thermal management but should I also be bypassing thruster and propellant controls as well? I'm at the point in development where the call has to be made.

Note:
Things like burning up in the atmosphere or killing the UMMUs if you run out of O2 are already being covered under the "Damage and Failure simulation" option in Orbiter's parameter menu.

 

[clive bradbury]

Thank you.

 

[4throck]

.

Just how simple should the simple flight model (AKA oapiComplexFlightModel == false) be?

As simple as possible ("indestructible").
People like Gemini and AMSO because "it works" and "it's fun".

So go for fun, and add realism as an option (for replay value and for advanced users).
Perhaps you can set "invulnerable mode" by scenario, just like AMSO.

Just my :2cents:

 

[Hlynkacg]

As simple as possible ("indestructible").
People like Gemini and AMSO because "it works" and "it's fun".

So go for fun, and add realism as an option (for replay value and for advanced users).
Perhaps you can set "invulnerable mode" by scenario, just like AMSO.

Just my :2cents:

"invulnerable mode" is already in place and controlled by the "Damage and Failure simulation" check-box in orbiter's options menu.

The question is how much of the other stuff should I automate or simply not model?

How much do you guys care about stability control, propellant management etc...

Should thrust vectoring be a "Complex model only" feature?

What about CG balancing?

 

[N_Molson]

As simple as possible ("indestructible")

As complex as possible

The question is how much of the other stuff should I automate or simply not model?

I'd say that depend how much time you have and how confident in your coding abilities you are.

How much do you guys care about stability control, propellant management etc...

Personally, a lot. That kind of stuff makes all the difference. Especially if you link that with failures.

Should thrust vectoring be a "Complex model only" feature?

Why that ? It helps to save RCS fuel.

What about CG balancing?

Currently, and from my personal experience, the CG/CoM related functions are buggy, so I'd understand you don't want to venture into that. But if you manage to find a way, of course, that's a great feature to implement.

 

[Hlynkacg]

As complex as possible

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

Personally, a lot. That kind of stuff makes all the difference. Especially if you link that with failures.

Agreed but see above

Why that ? It helps to save RCS fuel.

Because it involves making calculations, pushing buttons, and monitoring gauges. I've already had complaints about not being able to fly AAPO in a strictly "glass cockpit" environment so the question becomes "is it important enough to be worth coding two interfaces for?" one for simple/glass cockpit mode and another for the VC.

 

[N_Molson]

Because it involves making calculations, pushing buttons, and monitoring gauges. I've already had complaints about not being able to fly AAPO in a strictly "glass cockpit" environment so the question becomes "is it important enough to be worth coding two interfaces for?" one for simple/glass cockpit mode and another for the VC.

Well, it depends at which public you aim. Again personally, I'm all for something that allow more flexibility than AMSO or NASSP in terms of fictionnal scenarios, but that has an equal or better level of realism (meaning that the spacecraft systems are simulated in detail, but that more a-historical scenarios and launch configuration flexibility is allowed).