Project Gemini-Titan 2 for Orbiter 2016

[Urwumpe]

I started working on updating the old "Gemini-Titan 2 Version 4.5" add-on towards Orbiter 2016.

The current sources can be found here: https://github.com/Urwumpe/gemini4orbiter

My current work is mostly about the bureaucratic side of starting a new FOSS project. Contrary to my role in SSU, I plan to be your more-or-less friendly dictator about this repository, but you can of course fork your own project there. The expectation is to keep this state at least for the next year.

Next steps is further reorganizing the sources into one solution, integrating some Earth 1962 content to create a "Gemini 1964" context and creating some prototype framework for unit and acceptance testing in Orbiter.

If you want to contribute meshes, scenarios or manuals, feel fine to contribute, as requested by estar some years ago, I kept his project under a BSD license. I would also be glad to see people provide feedback about the current state, test it and could file issues for further improving it.

I don't want to encourage you to provide third-party add-ons for it. If you want to improve it, better contribute to it directly, so it will be part of future releases and part of one quality assurance process. Also this allows for a more flexible release strategy as if I would need to care for compatibility.

I have no big plans yet about adding new features, but feel free to discuss improvements here. Also I have no yet decided about the principles and general priorities of this project. I will provide them as soon as I have some good ideas. Of course, feel free to discuss them here, but for getting things started, I will limit democracy there a bit for the sake of getting off the ground first.


All I can say so far is, that I don't plan to make things less accessible as they are now. There will be no complex procedures or GDC interaction like in NASSP or SSU, unless you really (really!) insist on it. If possible, user interface should be close to the old version.

For the release strategy, I would like to go on towards a more agile process. There will be no next versions, instead the idea is to make a new release every second Tuesday in a month, as long as there are even tiny changes since. If it makes sense, I will try to support continuous integration, like NASSP does, later.

 

[n72.75]

I was just about to message you about starting a thread, but you beat me to it.

 

[Urwumpe]

I was just about to message you about starting a thread, but you beat me to it.

I am sorry for the long delay, I needed to more time to think about the next steps.

 

[n72.75]

Hey, no problem.

One question on the license, and yes I know we have a whole thread on this, but does being BSD make this incompatible with existing GPL addon code?

 

[80mileshigh]

I did the ATDA / Angry Alligator and flotation collar meshes a lifetime ago (it's fast approaching 20 years which seems crazy). Rob never released them but I think these were repackaged by Saturn V and then Replicant for Orbiter 2010. Not sure if they were ever licensed correctly, but obviously I want you to have them if it helps. Probably awfully dated by now!

 

[Urwumpe]

Hey, no problem.

One question on the license, and yes I know we have a whole thread on this, but does being BSD make this incompatible with existing GPL addon code?

3-clause BSD is ok for the FSF, but as you can see, with some headaches:

Various Licenses and Comments about Them - GNU Project - Free Software Foundation

www.gnu.org

 

[Urwumpe]

I did the ATDA / Angry Alligator and flotation collar meshes a lifetime ago (it's fast approaching 20 years which seems crazy). Rob never released them but I think these were repackaged by Saturn V and then Replicant for Orbiter 2010. Not sure if they were ever licensed correctly, but obviously I want you to have them if it helps. Probably awfully dated by now!

Yeah sure I can use them. Awfully dated is no problem, I can change this.

I already looked at those packages, but sadly they all lacked licences and I don't know which original authors are still around to ask. Quite some time passed since.

 

[4throck]

This is great news.

I made new docking target meshes based on the original ones, but with extensive repaints and improvements, including a fully functional panel, lights and retracting docking collar:


Obviously I can only take credit as mesh co-author.

Sharing a link for the addon, along with the (very poor) C++ code for the two adapters:

Gemini 2019.zip and 2 more files

3 files sent via WeTransfer, the simplest way to send your files around the world

we.tl

The code is poor and based on the Spider LEM source code. I'm sure it needs to be redone by a better programmer, but it's a start.
[Alt] + Beacon
[Alt] +[A] Antenna
[Alt] +[C] send command code

There's a HUD with the status codes:


Feel free to use this on the project.
I agree to usage and changes as needed for usage in Orbiter, within the scope of an accurate historical simulation.
Simply credit as '4thRock' where appropriate.

 

[Urwumpe]

That is great, I can take a look at integrating this, but much later. Still working on the basics, as you can see:



I first want to change all Earth 1962 scenarios for Gemini to use "Context Gemini" instead of "Sol_1962". Then I can go on looking at the vessels itself, once there is a set of historic scenarios for testing against historic flight data.

 

[Urwumpe]

Thanks to DaveS for reminding me that it was called BaseGrid Tool by @C3PO ... it looks much better now.



The mesh for LC-19 has some glitches, but its good enough for now. A better launch complex 19 can be done later.

 

[Urwumpe]

Don't worry if the descriptions of the issues are still a tiny bit brief... I just already created those issues as reminder so I don't forget them.

Issues · Urwumpe/gemini4orbiter

Continuation of the old Gemini Titan 2 add-on, Version 4.5 for Orbiter 2016 or later - Issues · Urwumpe/gemini4orbiter

github.com

Feel free to write your own issues there, I have no minimum quality standards there yet, but I will of course prioritize those issues that are so well described that it is easy to finish them.

 

[4throck]

Take a look at the launch situations for those Agenas. You should have the pads on the correct locations.

You can also try to contact @asbjos because he updated the pads and sceneries for Mercury X.
I helped but he did most of the work, including programming the Atlas.

For the pads I recommend landed vessels. You might want to animate the towers so it's better to have vessels there from the start.
Does the "context" parameter support alternate surface tiles ? Thinking about how to remove LC39 for a more accurate early 1960s look.

 

[n72.75]

@Urwumpe, or anyone else, have you given any thought to what the scope of this project should be? I think it would be very tempting to strive toward a NASSP/SSU level of detail, but I worry that much of the information needed for that is not publicly available.

 

[Urwumpe]

@Urwumpe, or anyone else, have you given any thought to what the scope of this project should be? I think it would be very tempting to strive toward a NASSP/SSU level of detail, but I worry that much of the information needed for that is not publicly available.

Well, as said in the beginning, such a level of detail should not be the priority. Maybe we can decide to allow extending things later, as long as the usability remains high. The good thing is, that there is a lot more information around about Gemini than about the Space Shuttle in some aspects, but like in case of the Titan 2 rocket, often a lot less.

I think an AMSO approach from an user's perspective would be better for now. Also, I think its smarter to calculate the scope based on one late-at-night-developer.

So, lets tyrannically limit the scope for the first year (Until Walpurgis Night 2022).

The Don'ts:

• No detailled subsystem simulations (yet). The GDC emulation code I included will be kept for reference, but I will not work on it.
• No big prelaunch campaign. Everything shall start maximal 24 minutes before L-0.
• No switch-flipping simulation. If you need to set switches into one specific configuration for progressing to the next mission phase, a single key or mouse press is also enough.
• No MOL or Gemini B or other further big developments in the first year.
• No rogallo wing.
• No pilot position controls.
• No sandwichs.

The Maybe's:

• Simple implementation of the GDC for driving the IVI and ADI.
• Launch simulations of GATV or ATDA shall be strictly optional and can be done later in the year.
• Recovery fleet and vehicles might be included in a simplified way to end a mission with style.
• The unmanned Gemini 1 and Gemini 2 missions could be included.
• Lunar Gemini can be included, since it is only a minor change compared to the GATV.
• If possible, there shall be virtual Gemini development conference on the 1st of May, 2022 to decide the scope for the next year.
• Include nicer looking animated launch complexes.
• Better looking Titan 2 staging, include the fireball reported by the astronauts.
• A simplified crew simulation, focus on health.
• Pilot side indicators.
• Pilot view only during EVA.
• A plotting board with map.
• Limited support from a virtual mission control.
  • Update time to reentry
  • Control GATV
  • Update launch time and trajectory.
• Show the construction of the Apollo infrastructure during the Gemini era by using multiple configurations of Cape Canaveral, using the PERIOD parameter.

The Do's:

• I like VCs. I want a VC (Even if its just one cockpit configuration and not the accurate ones)
• I want to split the Gemini spacecraft from the GLV. Mostly for preparation for later developments (using different launchers), but also keeping the complexity of the vessel a bit lower.
• The IVI shall be functional, even if only manual input of dVs.
• I want to automatize acceptance testing, so the dev velocity can increase from release to release and I can realize more interesting things.
• All abort sequences should be possible, including using ejection seats.
• I want tools to analyse bugs that happen at the player side beyond log files.
  • Support Orbiter's flight recorder
  • a ring buffer with the final 10 or 30 seconds of telemetry (30s = 192 kB binary file).
• The horizon scanners shall finally be animated and shiny.
• The sequential system logic shall be accurate in its behaviour.
• A simplified electronic timer shall be there to count GET and TR. TX is optional right now.
  • Changing/reading TR during flight shall be possible via a vessel-specific MFD.
• The backend framework shall be ready to support complex subsystem simulations
  • Loading/Saving of important subsystem parameters shall be automatic.
  • Test framework support, asserting subsystem states.

Any complaints? If not, I will include this scope as it is into the readme for the project for reference.

 

[Urwumpe]

Take a look at the launch situations for those Agenas. You should have the pads on the correct locations.

I won't launch them for now. I think its better to keep those scenarios out of scope for now. We can return to this feature later.

You can also try to contact @asbjos because he updated the pads and sceneries for Mercury X.
I helped but he did most of the work, including programming the Atlas.

I'll come back to it.

For the pads I recommend landed vessels. You might want to animate the towers so it's better to have vessels there from the start.

Yes, also that works great in SSU and other add-ons. I think its the more reliable path to go.

Does the "context" parameter support alternate surface tiles ? Thinking about how to remove LC39 for a more accurate early 1960s look.

I don't think so.

 

[n72.75]

I agree with the scope and the timing.

Splitting the vessels from the launcher is probably something we should do early on.

 

[N_Molson]

Yes, even if you don't plan to do MOL or stuff that relies on something else than a Titan 2 (Titan 3, or even Saturn V), it should be possible to mate the spacecraft with such launchers (using docking or attachment systems). That "lets the door open", IMHO the real cool thing with Gemini is that it is suited for a variety of missions, including lunar ones, and as a user I would have fun doing some "homebrewed mission planning".

 

[Urwumpe]

I agree with the scope and the timing.

Splitting the vessels from the launcher is probably something we should do early on.

Yes, its the next thing I planned to do in the code. I want to finish most big architecture work for this scope ASAP, and then keep things relatively constant for a while

 

[Urwumpe]

Yes, even if you don't plan to do MOL or stuff that relies on something else than a Titan 2 (Titan 3, or even Saturn V), it should be possible to mate the spacecraft with such launchers (using docking or attachment systems). That "lets the door open", IMHO the real cool thing with Gemini is that it is suited for a variety of missions, including lunar ones, and as a user I would have fun doing some "homebrewed mission planning".

Yes, that is exactly why I want to separate the launcher from the spacecraft. Also, should we ever get to prelaunch operations one day, doing the Gemini 6a campaign could also be interesting...

 

[4throck]

Yes, the capsule should be independent from the launcher. I suggest you use Multistage Titans with the capsule as a live payload.
There were fuel display gauges for each Titan stage on the cockpit, but I don't think there was any other relation. The Titan was not controlled from the capsule.

About the VC, it's on my list of unfinished things:

The problem here is free time to complete it...
So my suggestion is to implement a simple generic 2D panel like on Mercury X.