Project Another Apollo Project

[Urwumpe]

Well, we have a good project with accurate historic avionics already.

But I still would love to have something in between Apollo, Skylab and the Space Shuttle. maybe even with circular computer displays, like the old military jets of the era.

 

[PhantomCruiser]

There's a whole threads of what-ifs that I wish I had the time and skills to put together.

Anyway, I'm diggin' the forward progress of AAPO! :thumbup:

 

[Hlynkacg]

Well, we have a good project with accurate historic avionics already.

But I still would love to have something in between Apollo, Skylab and the Space Shuttle. maybe even with circular computer displays, like the old military jets of the era.

I'm aware of the old spherical projection SCS and Radar displays that started appearing late in WWII (in truth they were fish-eyes rather than true spheres) but not of anything that mimicked a proper MFD or CRT, can you provide an example?

 

[Urwumpe]

I'm aware of the old spherical projection SCS and Radar displays that started appearing late in WWII (in truth they were fish-eyes rather than true spheres) but not of anything that mimicked a proper MFD or CRT, can you provide an example?

This here is already a pretty modern E or F version of the F-111, but the two round displays on top are actually CRTs in their construction, that had been already in early versions of the F-111.

EDIT: And this display is actually also a Charactron type CRT, used in the SAGE computer system:

In the mid-1970s the same function with then-modern technology looked like that then:

 

[Hlynkacg]

LM MFD now with functional buttons/labels.

 

[Hlynkacg]

What I'm up to and where I'm going...

1st off I'm still job hunting if anyone knows of any openings for a part time math student/and self-taught 3d artist with a US DOD security clearance in southern California drop me a PM.

I can also lift heavy things.

As for AAPO...

90 percent of my effort has been cleaning up and overhauling the LM. My programing knowledge has come a long way since I first started and I needed to bring the code up to code. The major differences visible to the user will be the overhauled RCS code and higher frame rates in the VC. (my old display functions were a nighmare).

On the back end the functions and displays are much more modular, making it easier to plug and play.

---------- Post added 12-03-13 at 13:10 ---------- Previous post was 12-02-13 at 16:44 ----------

AAPO Roadmap:
some further comments on the modularity I mentioned earlier. The next update is going to represent a pretty major overhaul. Aspects of this were already present in the CSM's code as I had appliued numerous "lessons learned" from developing the LM and other projects, but now I am applying them whole-sale.

All vessels in AAPO are now derived from a core "AAPO_Vessel" class.
AAPO_Vessel in turn has two friend sub-classes "AAPO_Cockpit" and "AAPO_Autopilot".

AAPO_Cockpit is a cockpit manager class that contains user interface logic/functions as well as sub classes for common types of displays. Adding a switch or display to a cockpit is now as simple as adding "AAPO_Cockpit::CreateSwitch (blah blah blah)" or "AAPO_Cockpit::CreateDigitalDisplay (blah blah blah)" to the appropriate callback function.

AAPO_Autopilot's name is a bit of a misnomer at the moment as it is only a stub but I have been slowly populating it with math functions used in trajectory planning and RCS optimization.

So where too from here?
All vessels in AAPO are now derived form the AAPO_Vessel class.

Of these I have two "Hero classes" that are being set up for full player control. they are AAPO_CM (Apollo Command Module) and AAPO_LM (the Apollo LM Ascent Module).

Once these two classes are stable, I plan to start adding additional child classes.

in the form of various AAP concepts like the Apollo CRV and LM-derived space tug

 

[Urwumpe]

You could also use namespaces for keeping your classes together and separated from potential name conflicts.

 

[Hlynkacg]

You could also use namespaces for keeping your classes together and separated from potential name conflicts.

I'm already using them a bit in my cockpit code i.e

PANEL1::Switch_01, 02, 03, etc...

vs

PANEL2::Switch_01, 02, 03, etc...

but could you elaborate a bit more on what you had in mind?

 

[BruceJohnJennerLawso]

You could also use namespaces for keeping your classes together and separated from potential name conflicts.

:yes:

One of the least obvious things about programming with mid-level languages is how important structure really is to writing good code. Namespaces sound like a trivial curiosity at first, but wrapping code in them allows for very effective organization of accessible identifiers which help to describe the purpose of that code without even needing to comment it. Its also immensely useful in MSVC++ 2010 due to a nice little interactive feature built into the compiler.

 

[Urwumpe]

but could you elaborate a bit more on what you had in mind?

You could also use "aapo" as namespace for all your classes, instead of prefixing the class name with AAPO.

You can have namespaces nested in namespaces. I don't recommend too much nesting, but its possible.

 

[Hlynkacg]

You could also use "aapo" as namespace for all your classes, instead of prefixing the class name with AAPO.

You can have namespaces nested in namespaces. I don't recommend too much nesting, but its possible.

Ahh...

That is good to know.

 

[4throck]

Imagine I do a repaint for the Skylab CSM (some parts are white).

Would it be possible to select that "skin" per scenario? Of course, overwriting the default texture will work, but since you already have several CMS versions on the add-on, I think it would make sense to have multiple textures :thumbup:

 

[Hlynkacg]

Imagine I do a repaint for the Skylab CSM (some parts are white).

Would it be possible to select that "skin" per scenario? Of course, overwriting the default texture will work, but since you already have several CMS versions on the add-on, I think it would make sense to have multiple textures :thumbup:

PM sent

 

[4throck]

Expect a "Skylab" CSM repaint soon, complete with normal maps and graphic client configs that fix the VC materials, for example. This can be easily back converted into the standard lunar apollo paint scheme (and normal maps used as they are).
As far as I'm concerned, once released, Hlynkacg can use or improve upon them if he wishes

 

[Depth08]

visually impeccable!

 

[4throck]

The repaint is release here:
[ame="http://www.orbithangar.com/searchid.php?ID=6397"]http://www.orbithangar.com/searchid.php?ID=6397[/ame]

It will overwrite the default textures, so take caution there. If you want to retain the standard look, only extract the normalmap and GC configurations.

 

[Hlynkacg]

First screenshot of the year featuring new Command Module mesh now with Texture/UV maping and 20 % fewer vertices.

4thRock we need to talk

 

[Hlynkacg]

the ServiceMod has received similar treatment.

 

[4throck]

Nice!

Indeed, we should talk some more , because of this:

It's working via a phantom sc3 spacecraft docked to the CSM.
Not that elegant but allows for crew and cargo to transfer to Skylab B via attachments.
Tried with UMMU but it lacks simple things such as no RCS for the astronaut (as far as I know...)

PM on the forum works great for me.

 

[Hlynkacg]

Here are three new shots of the CM. I've been learning how to use blender's painting interface to generate new textures.