V8 Release Work Thread

Status
Not open for further replies.

jalexb88

Addon Developer
Addon Developer
Joined
Aug 11, 2008
Messages
152
Reaction score
154
Points
43
Location
Canada
Mission control support is now available for Apollo 12. As said before this will not be an officially supported MCC mission for NASSP 8 release but I will try my best to keep it up to date with the latest RTCC state.

Functionally the same as Apollo 11 MCC tracking plus a few extra features:
-PDI recycle (PDI-2 support)
-Abort handling:
Use "Request Abort" in CAPCOM menu to enter abort mode. Supported phases are TLC and lunar orbit. Once an abort is initiated you must burn the next appropriate abort PAD which was previously handed to you during the normal tracking, you will then get MCC support through to splashdown.

Please report any bugs.
 
Last edited:

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
PLEASE READ

After a long process of review and consideration, we have pushed through a small but important update to the way specific heats and temperatures are calculated in the internal systems' simulation state.

Previously, every substance had one specific heat value, and it was invariant with phase changes. This new update adds separate values for liquid vs gas. and will allow us to do some more realistic systems implementations down the road (including resumed work on my long-running fuel cell project).

Old method:
C++:
for (i = 0; i < MAX_SUB; i++)
        AvgC += composition[i].mass * SPECIFICC[composition[i].subst_type];

New method
C++:
for (i = 0; i < MAX_SUB; i++) {
            AvgC += ((composition[i].vapor_mass * SPECIFICC_GAS[composition[i].subst_type]) + ((composition[i].mass - composition[i].vapor_mass) * SPECIFICC_LIQ[composition[i].subst_type]));
    }

The challenge here is that this update will drastically change the temperature of systems in users' scenarios. This isn't usually drastic enough to prevent completing the mission, and we're aware that most users only update between missions and/or watch this thread, however our concern was aimed primarily at the portion of our userbase that does not regularly use or check the forum, and to whom this may seem like we've simply introduced a hoard of bugs rather than a cool new feature. Because fluid temperature is calculated from internal energy and specific heat, older scenarios (excluding the launch scenarios) would have different (and incorrect) new internal temperatures if no measures were taken to correct the energy value. The fix below adjusts the energy level, such that temperature remains the same after the upgrade.

Because of this we now have a simple version checking feature that will tell you to check this page if a "breaking change" has been made by the update.

For this update specifically, the procedure to upgrade your scenarios is to run this Python script in a folder containing the scenarios you want to upgrade. (you would only need to run it on your own saves, mission scenarios have already been upgraded using a similar process on our end, so don't "upgrade" those.)
NOTE: This script upgrades ALL of the scenarios that are in the folder with the script.
So please take a minute to read this post, and understand what the script is doing.


If you are even a little bit unsure on how to do the upgrade, please PM me your scenario(s) and I will do it for you.
I realize I didn't provide any instructions for actually using the script so here goes.

  1. Install Python, that can be done by downloading it from this link: https://www.python.org/downloads/ or from the Windows Store. You'll want the latest stable 3.x.(x) version.
  2. Make TWO copy of the folder you want to update. One for updating, and one as a backup
  3. Copy this script into the folder. https://gist.github.com/n7275/8cab7e348507ff4bce4749d09e2c3894 The folder should now contain scenarios and this python script.
  4. Double click on the python script to run. (only do this once on any particular group of scenarios. the script essentially goes through and multiplies all your temperatures by a scaling factor. If you do this twice they will be wrong.)
  5. Copy your scenarios back into the Orbiter directory that you got them from.

If that's hard to follow or you want my help, I will happily run this update for you, all you need to do is put your scenarios in a Zip archive and send them to me (google drive, dropbox, forum attachment, snail mail a floppy, etc. ...)

You should get something like this when you run it.

1666560724118.png



I've added a bit of fool-proofing to try to make sure it can't update scenarios that have already been updated. And the script now updates the NASSPVER lines too.
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
The Apollo 13 mission in NASSP now uses LM131R1, the actually flown LGC version!

The LGC software for Apollo 13 had a complicated development history. But basically, we have been using Luminary 131 in NASSP for a long time, which is an earlier version of the software. Fairly late into the development they decided to implement one new feature into the software, Auto P66. They got rid of the automatic landing program P65 and instead incorporated some parts of it into P66. That made it possible to switch back and forth between fully automatic and manual attitude control. Before this change you could only "downgrade", so go from fully automatic (P65) to semi-automatic (P66) to manual (P67) landing programs, but not back. Some people really wanted this feature to fly on Apollo 13 already, so they made the changes to the software despite already having started development on the Apollo 14 software. That is also the reason why there is no known program listing for the flown version.

Instead, @thewonderidiot build an incredible device called the rope reader, which can read the rope modules that were used in the AGC to store the software. A collector owns the flight spare of the one module (out of 6) that was changed for the Auto P66 revision of the software. And he managed to read the software from the module, assembled the full LM131R1 software and we can now use it in NASSP! This being the one spare module that was manufactured, and the other module being somewhere in an ocean together with LM Aquarius and also the possibility that there is no program listing anymore for this version, the module that was read is possibly the only source for this software that still existed. So we got very lucky that this software was recovered at all!

If anyone is on an active Apollo 13 mission I would advise against updating your NASSP install, as it will update the software being used for Apollo 13 and the landing programs will not work due to padload changes. The padload changes aren't very massive though, just 7 numbers would have to be changed in the erasable memory to make the Auto P66 work. So if anyone is in need of help with that, the change could be made without too much trouble.

Thanks again to @thewonderidiot for this miraculous recovery!
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
The update thread was feeling neglected. Here's a little update:

1675831947290.png


VC fuel cell temp meters now have proper scaling for temperature.

A few other pressure transducers are now wired to the right instrumentation CBs now too.

When you load an old scenario for the first time, your gauge needle may be missing. Don't panic, just a few minute (realtime) and it will come back.
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
NASSP now has support for cue cards in the virtual cockpit:

Np8Bw66.png


Just click around on any velcro spots in the VC of the CSM main panel and you can activate them that way. Clicking repeatedly will cycle through all the cards that are available for one location or make the card disappear again. Scenario saving/loading is supported as well as mission specific cards.

Things still to do:
-Add more cards for many more missions. Right now most of the Apollo 15 CSM cue cards are implemented, because that was the most complete set that is available online in good quality. There is one Apollo 14 specific card as well, but that's it so far. And considering some cards like the TLI procedures and tables are very mission specific this needs a lot of updates to be useful for all missions
-Add LM cue cards
-Add some more CSM card locations that are not on the main panel
-Many smaller tweaks to cue card locations, click spots, meshes and textures
 

Max-Q

99 40
Addon Developer
Joined
Jul 5, 2021
Messages
765
Reaction score
1,181
Points
108
Location
Cislunar Space
Website
www.orbiter-forum.com
The surface EVA features of NASSP received a little upgrade, here's what's new: :cool:

Reflective LEVA visors
visor.png


The LEVA vessel names now use the astronaut's name instead of generic CDR or LMP.
(You can replace the name used with your name, just open the mission file "\Missions\ProjectApollo\Apollo ##.cfg" in notepad)
Also, the astronaut's name is now drawn on the PLCC and RCU textures dynamically, so no more "N. ARMSTRONG" on Apollo 12...
plss_names.png


For those who fly the Apollo J missions, the LRV has had some nice features added.
The big LRV feature: You can board the LRV! No more cheating with scenario editor or driving with empty seats.
The LRV follows the terrain! So if you drive up a slope, no more will half an LRV buried in the dirt...
The wheels kick up dust while driving
I fixed the normals on the LRV mesh. It looks a little better now, at least.
lrv.png
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
A big RTCC update has been merged, changing the coordinate systems it uses to the correct ones used in the real RTCC until Apollo 17, instead of the ecliptic coordinate system that Orbiter is using. This is a big change with no real additional features, but should make a lot of future updates easier. For more details see the description of the pull request: https://github.com/orbiternassp/NASSP/pull/1008

For a typical NASSP user this update is important for two reasons. Do not update your install with this update mid-mission, or the MCC support has a good chance of failing. Missions with the RTCC MFD basically just need their REFSMMATs in the RTCC re-synced to the AGC, but otherwise no big problem.

The other thing is, I have tested this update quite a bit, but a change of coordinate system is probably the most fundamental thing one can do. I can almost guarantee that there are bugs where previously there weren't any. So if you see something weird with any e.g. Maneuver PADs provided by the MCC or if any calculation of it fails, there is a good chance that you haven't done something wrong but that there are new bugs. So feel free to report them! Hopefully this transition goes smoothly, but you never know...
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
This is only a very small update. But everyone likes a post in the update thread :)

NASSP has had a Skylab mesh since 2005, created by @missleman01 if I'm not mistaken (please correct me if I am). To the best of our knowledge there was a Skylab module that either built with NASSP or was part one of the many NASSP-adjacent addons in the late '00s. We have been using the Skylab1973 (as a required download) addon from @Usonian, but as this is a Spacecraft3 addon, we're severely limited in what we can do, both technically and GPL2-wise.

Thus, NASSP presents: Skylab.

It's little more than a mesh with the right PMI, and rudimentary drag coefficients, so don't get too excited yet.

It's also badly in need of a new mesh, which is unfortunate, because that's one of its only features right now.


1693012323201.png

1693012708308.png
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Since I shared a little bit about Skylab in our last post, I thought I'd fill everyone in on our progress. Sometimes it's nice to take a break from that ol'e Moon for a while and focus on Earth stuff :)

NASSP's Skylab 2 Mission has seen some small updates in the last week:

  • We have had the RTCC targeting in place for Skylab-type rendezvous and launch targeting for a while. Over the past week @indy91 has added preliminary MCC support for Skylab 2 maneuver targeting, which should make flying the mission much easier.
  • We now are officially using the Skylab1973 mesh by @Usonian ; he has generously contributed it to NASSP under GPL, and we thank him immensely for it.
  • I have rigged up some basic animations based on Scott's SC3 animation sequences just for the ATM and solar array deployment:
  • Skylab has an attitude control system and the start of an ATMDC simulator (not an emulator, we need documentation). This has the ability to process commands uplinked from the ground (which at the moment only control attitude mode). Attitude control and also be switched manually by switching focus and pressing 'A'. A message displaying the current attitude control mode is shown on the orbiter HUD.
  • Skylab also now has a VHF ranging system which functions similarly to the one in the LM, also added by @indy91.

We are still using Artemis 72 for this mission so P34 and P35 will not work. However, if you do your burns like the MCC says, are good with your residuals, take marks in P20, the TPI burn will leave you essentially flying down the docking port. Track with P20 COAS and mind your breaking gates, and with minimal visual correction it should be an easy docking. Skylab gets commanded to hold solar inertial just after TPI.

I have included some images below from a recent test flight of the mission. The white CM texture is by @Max-Q from his Pegasus Rendezvous addon.



1694572129071.png

1694572506355.png

1694573085818.png

1694573749707.png
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
A long overlooked an missing feature, the range/rate tapemeter power/signal failure light has been added. You will see this light up as of right now under the following conditions:
  • Tape meter loss of AC power (<85VAC) or DC power (<20VDC)
  • PCMTEA 512KHz timing signal loss
  • Rendezvous radar range or range rate signal loss
  • Landing radar altitude or altitude rate signal loss
  • PGNS altitude or altitude rate signal loss
  • AGS altitude or altitude rate signal loss
In addition, due to the nature of the detection logic, signals less than 5 fps/5ft will also make the indicator light illuminate, this is a feature not a bug and was expected on actual missions as well.

More development of this including drive logic and better/correct signal flow will be added at a later date, this PR focuses on the power/signal fail light logic.
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
Another systems update, we now have added battery outgassing and venting logic as well as heated dump nozzles to the command module.

Batteries will now generate heat and small amounts of H2 and O2 when charging and this gets vented to the battery manifold. This pressure can be read on the system test meter 4A and of course vented overboard.

Waste/h2o, urine, and steam duct heaters have also been added, appropriate power draws and wattages implemented, and the nozzle temperatures can be seen on telemetry.

Additionally, the nozzles can now freeze, preventing a waste dump or battery venting. This also allows the crew to cross check the nozzle by verifying the battery vent manifold pressure drops when vented (as it vents though the waste dump nozzle.)
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Another big update! Our S-IVB now simulates propulsive venting. All the time during Earth parking orbit Saturn V S-IVBs vent a little bit of their H2 to keep the tank pressure down while it is heating up. While there are non-propulsive (NPV) venting valves as well, during Earth orbit coast this vent is directed to the continuous venting system (CVS) to cause a small acceleration which keeps the propellants settled.

All types of propellant vents and dumps the S-IVB can do are now simulated, as well as visual effects for them. Also simulated are S-IVB tank pressures (both LOX and LH2) during coasting phases. The previous behavior of our tank pressure gauges in the CSM was to actually show the percentage of propellant remaining. That is not how it really worked, instead it is now pressures and fairly realistic.

I say fairly, at its core there is a simple ideal gas equation and no temperature changes are simulated. And no simulated behavior of the liquid propellants either, except that some LH2 is being boiled. Everything around this simple behavior was already complicated enough, with all the logic and relays involved in controlling the tanks. At some point in the future the thermodynamics calculation are probably going to get upgraded. There are a few slightly unrealistic things, like, the H2 tank pressure (when there is no venting) increases too fast on its own and a little bit of non-propulsive venting is required. But this is only gas venting and overall no problematic behavior. Also, during S-IVB burns the tank pressures are kept at a fixed value because this would have required a bunch of simulated helium otherwise.

The main reason for this update is trajectory. The venting does increase the orbit by quite a lot. The step to go from a 100 NM parking orbit to 90 NM for the later Apollo missions would probably not have been taken if they didn't know that the venting still easily overcomes the drag at the lower altitude. That is one reason why I didn't give all our spacecraft realistic drag coefficients yet. Without venting that would have made the orbits less realistic instead of more, at least for these 90 NM parking orbits it would be noticable. Here is a graph of the typical behavior we had before and will have now:

96vywif.png


There is a tiny bit of venting after TLI, but, the relevance of the propulsive venting mostly stops there. One mission where the venting will have a bigger effect is Apollo 9. The S-IVB on that mission did a second (and third) burn on its own, but in the almost 3 hours before the CSM and LM got away from the S-IVB the orbit kept increasing all the time. And after the CSM+LM are away, they didn't completely adjust their orbit to an specific apogee/perigee combination until days later. So in NASSP the perigee altitude has always been several nautical miles too low during the first few days of the Apollo 9 mission, basically until SPS-5. They also did not turn off the propulsive venting while the CSM performed transposition and docking. That will make this procedure a little bit more challenging in NASSP, the S-IVB is gaining nearly 1 ft/s during the nominal duration of the T&D.

There are also some RTCC changes associated with this update. The AGC doesn't take the venting into account, so for a standard Apollo mission with TLI they uplinked a state vector that is valid shortly before TLI, with the RTCC having simulated the venting. More astute users of the RTCC MFD know about a feature called the Mission Plan Table (MPT), which is very much optional to use, even on missions that aren't supported by the MCC mission support feature. But what now has to be done (on these non-MCC supported mission) is to use the MPT initialization page to select the current vehicle configuration. If the configuration contains an S-IVB then the venting is simulated for state vector uplinks. Otherwise it is not. In the future the use of this MFD page will be even more relevant when full drag is simulated. Then vehicle weights and areas have to be managed here as well. It will still be a while until everything in the RTCC MFD takes these settings into account, but eventually they will be.

The LVDC also has a simple venting model which is now implemented. It is realistic behavior, but the propulsive venting always has the biggest contributor to LVDC state vector inaccuracies and we will get that now, too. On most missions they overestimated how much venting the S-IVB will do. Here a comparison of the venting model in the LVDC on several missions:

g7fbieo.png


The obvious outlier is Apollo 9. For some reason they used a really high venting acceleration in the LVDC. That causes a huge state vector error by the time it restarts the J-2, nearly 100km! From everything I have found this might be realistic behavior, but potentially I will change my mind and make it a bit better in NASSP. Here are some downrange error comparisons:

0Wpq6Ky.png


Even ignoring Apollo 9 there is a fairly large spread. That's why I said our TLIs will become a bit less accurate. But overall it shouldn't be that bad, maybe a few more feet per second of midcourse corrections at worst. I might still tweak our default LVDC venting model to agree a bit better than the actual behavior in NASSP.

But overall, I am quite happy that this update is finally done. The lack of propulsive venting was one of the worst trajectory inaccuracies we still had!
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
We have merged a fairly significant systems updated, which overhauls both some of the internal physics as well as greatly expands the systems simulation and detail of the fuel cells and LM ECS.



Summary:

  • Overhaul Thermal Engine​
  • Add ASA heat/cooling (@rcflyinghokie)​
  • Overhaul LM cabin/suit loop heat transfer​
  • Improved Model of Hydrogen, Oxygen, and Nitrogen in the liquid phase.​
  • Add Nitrogen pressurization system to fuel cells.​
  • Add fuel cell reactant chambers​
  • Make fuel cell voltage dependent on reactant pressures.​

Overhaul Thermal Engine

This is the oldest part of this update, it started a a simple update of our thermal engine code, intended to improve code readability and structure. Scope-creep happened and here we are 18 months later.

The main points are:

  • Better code readability
  • Functionality for Bond Albedo and IR radiation from: Earth, Moon, Venus, Mars, Mercury, Jupiter, Saturn
  • Solar radiation now depends on distance to the sun.
  • thermal_obj now supports cardioid, subcardioid, and omnidirectional radiation patterns for received heat, this should greatly improve heating of things like: LM ascent stage, SIVb tanks. Previously only directional heating 'cos(theta)' was supported. setting this condition will need to be implemented by individual systems.
  • Allow solar heating when below the mean planet or moon radius (as is often the case on the Moon).
A quick note on thermal Polars. The plot below shows the types of Polars that SPSDK/NASSP now supports. Previously we only supported the “directional” type, but the addition of the other three will allow us to more realistically simulate external and internal thermal objects. The magnitude (relative to 1.0) indicated how much Sun (and planet IR and reflected) heat the objects (tank, antenna, thruster etc.) receive or radiate relative to its orientation vector.

1703945001553.png


Add ASA heat/cooling

@rcflyinghokie has added the ASA stand-by and fast heaters. These operate during TLC before the AGS is powered up to keep the ASA at the correct temperature. Waste heat gets dumped into the glycol and is a contributing factor to the steady-state temperature of the LM during TLC.

Overhaul LM cabin/suit loop heat transfer

The atmosphere portion of the LM ECS is simulated by a large collection of SPSDK tank and pipe objects. The topology of this collection looks something like this:


1703945020318.png


Changes have been made (mostly small adjustments) to improve the O2 flow around the suit loop by approximately a factor of 2, bringing it significantly closer to the actual mass-flow-rate. This has the effect of drastically improving the ability of the glycol to extract heat from the cabin (which allows us to put a more realistic amount of heat in), and allows us to reduce the partial pressure of CO2 closer to actual values.

The temperature behavior of the LM cabin temp should look something like this: (lower graph)

1703945036910.png


So if you’re getting drastically different results, that is probably an indication that something isn’t right. I won’t say we have LM temps perfect, but feedback from users is very helpful here.

This update to the LM systems has also necessitated slightly increase the number of sub-steps that SPSDK does internally for each Orbiter time-step. This has been done to improve systems stability. Below a 1 second time-step all internal LM systems should be updated on a constant 50Hz(relative to Orbiter time, not system) update loop.


1703945050925.png



Improved Model of Hydrogen, Oxygen, and Nitrogen in the liquid phase.



Last September after some discussions with @indy91 I attempted to add a large H2 tank to our SIVb so that we could realistically simulate propulsive venting. At the time I ran into rather significant roadblocks with the current implementation of our fluid simulation, and as often happens I went down a rather deep rabbit hole in an attempt to fix them. As a result I have ended up a long way from where I started (although we did add propulsive vending last year, just using a different method).


The figure below illustrates the root cause of the issues I was having. Shown in read are the current (now, old) densities of H2, O2, and N2 as a function of temperature. By far the most significant improvement is the removal of the local minima present in both the H2 and O2 existing models. Density increase decrease should now be smooth, continuous, and monotonic with decreasing temperature. The model that was in place before, worked fairly well for conditions like the inside of a CSM cryo tank, but quickly broke down at other temperatures, additionally oxygen was significantly colder (by ~100°F) than it should've been.


1703945064802.png


The liquid-density update was previously the subject the subject of several prior (closed without merging) PRs. This update adds an improved model of the density-temperature relationship and bulk modulus for H2, N2, and O2 based on curve-fitting NIST data, and is critical to accurate CSM cryo-tank behavior. Temperatures should much more closely match AOH plots and mission documentation. Tank heater duty cycles and pressure decay rates have also been improved as a result. The Apollo 7 tank stratification tests should produce results that are significantly more well aligned with the mission documentation.

This curve-fit is still not a 100% accurate simulation of real-works substances, but they are representative of real-world data and are within a few degrees/psi over a wide range of temperatures and pressures, and give plausible simulation results. Further improvements to the fluid simulation are probably best accomplished by the replacement of this system with something like Cantera (but I will leave that to people with more ambition and time).

Because of how this changes the compressability of O2, it should be noted that it will now take much longer (which is correct), to fill the surge tank and re-press package from empty.


1703945094727.png


1703945727599.png


Add Nitrogen pressurization system to fuel cells

A long-term goal of mine has been a more complete simulation of the fuel cells. Some of the work being merged now, goes back as far as fall of 2020, at least as far as lessons learned on what is possible to simulate.

The Apollo CSM fuel cells are surrounded by a Nitrogen atmosphere that maintains pressure on the cell stack, as well as serving as a pressure reference for the H2 and O2 regulators. This nitrogen system (shown below in green) is now [mostly] simulated.

1703945106773.png


Those of you familiar with our CSM Telemetry Client will be happy to know that telemetry words for the Nitrogen pressure have been added to the telemetry data and can be viewed on the EPS page in HBR, (Along with proper FC reactant pressures, see next section).

1703945131011.png


Add fuel cell reactant chambers & Make fuel cell voltage dependant on reactant pressures.

Previous iterations of our fuel cells have not included any internal volume for the reactant space. This means that fuel cell flow-rate is always equal to the instantaneous demand for reactant of the cell. A much more realistic approach has now been modeled where each cell has a respective H2 and O2 "Tank" that serves as reactant chamber. The H2 and O2 regulators feed reactants into the chamber, and the fuel cell consumes them. Thus results in a significant improvement in the realism of the reactant flow behaviour and make the cells much more dynamic. A great illustration of this can be seen by closing the reactant valves and watching how the cells behave.


1703945171906.png






Final notes and cautions.

As with all major updates we can never guarantee that anything is 100% bug free, although we take great pains to ensure it is. This update has been extensively tested but it always possible there is an edge case that we missed.

If you are currently flying a mission, as always it is highly recommended that you wait until you finish the mission before you do any updates to NASSP. If you would really like to update your mission we do have a python script that can update your scenarios for you (and as always I am happy to do this for you if you PM me, make a post, or ask on discord.)



Enjoy!
 

thewonderidiot

Active member
Joined
Sep 26, 2017
Messages
14
Reaction score
27
Points
28
Back in August/September, @n72.75 posted about some significant improvements to our Skylab support. As some of you might have guessed or heard, these changes did not come out of nowhere. It was around that time that we learned there was a PGNCS system on display in the New Mexico Museum of Space History in Alamogordo, NM.
1706131568794.png


Installed in this PGNCS system is the CMC that flew to the moon on Apollo 15. And installed in that are all six rope memory modules that flew on Skylab-2 -- containing the long-lost Skylark 48 software. This software flew on all three Skylab missions as well as ASTP, making it the most-flown version of AGC software.

1706131731127.png


Ever since then, I've been working with the museum in the background to get access to this computer, remove the rope modules, and read them. This week, everything finally came together, and I'm extremely pleased to announce that all six rope modules read perfectly, after sitting around for nearly 50 years. We have officially recovered the Skylark 48 software in binary form -- which means it has become possible for us to fly the Skylab and ASTP missions in NASSP using the real CMC software!

1706132075175.png


Meanwhile, @indy91 has been preparing our padload generator and mission files for Skylark compatibility. That has all been merged in, and there is now a Skylab-2 mission scenario available and ready to fly! Skylab-3, Skylab-4, and ASTP scenarios have not yet been created, although I imagine they will be in the coming days.

Some notes about Skylark: it's an extremely interesting AGC version. It has had all of the lunar capabilities stripped from it to make room for much more advanced rendezvous capabilities. It also uses a fixed 1950.0 coordinate system, instead of the ever-changing coordinate systems of the lunar programs that meant they were only valid for a couple of years. Skylark pushes a lot of the support for this into erasable memory, meaning it doesn't really have a limit; it would still be possible to fly Skylark today without needing to re-release the software.

As with any AGC software, there are some bugs. There are two big ones that you should keep in mind when flying a mission with Skylark: SKY-001 and SKY-003. Because of SKY-001, any time R27 is run, there is a 4% chance the computer will fail to calculate the number in R3 of noun 77 -- it will show -00001 instead of the elevation angle Φ. If this occurs, you must recover it by running EMP SL-1 as described in Section 7 of the GSOP.

SKY-003 is somewhat more annoying. When proper motioning star 3 (Navi) for the new coordinate system, they made a mistake. As a result, the position of the star is in error by somewhere around 0.035192°, making it very nearly unusable for marking. Try to avoid using that star!

Getting Skylark and adding support for it into NASSP has been a big team effort -- so thanks to all of my fellow NASSP devs, especially @indy91 and @n72.75. And extra big thanks to the New Mexico Museum of Space History, who were absolutely wonderful to work with, and who made all of this possible. Y'all should drop in and see the PGNCS unit and all of their other stuff if you get a chance. :)
 
Last edited:
Joined
Feb 6, 2022
Messages
19
Reaction score
60
Points
13
Location
Earth
After some serious work (the root of which dates back to 2019), NASSP has transitioned from OrbiterSound 5.0 to XRSound. The installation guide has also been updated to reflect this change. The reasoning for this is twofold:

First, it significantly improves the stability of the simulation. OrbiterSound has a nasty habit of reading keypresses even when the simulator is not in focus, and typing while the simulator is unfocused is... generally something a lot of us NASSP devs and users do. Accidentally keying in OrbiterSound's various hotkeys frequently crashes the sim as the module tries to dump a file containing vessel information, due to some deep-seated error between NASSP and OrbiterSound that we've never been able to pin down. After years of accidentally losing hours of flight progress because of this, we're glad to move on. With this one change in sound engine, users and devs alike have reported vastly better uptime and stability while multitasking.

Second, moving to XRSound lays the groundwork for an eventual transition to Orbiter 2024 (a.k.a. the upcoming stable release of OpenOrbiter). That version comes with XRSound included by default, so it's a natural transition to make with forward-looking intent. As mentioned on my personal thread regarding OpenOrbiter compatibility, we don't plan to leave Orbiter Beta R90 just yet, but having one less major codebase difference between our upstream code and the OpenOrbiter branch means less potential maintenance required on my part.

For the most part, this change should be hopefully invisible to most everyone who uses NASSP. Making the switch should be as simple as updating your NASSP install, then downloading XRSound 2.0 and unzipping it into your Orbiter directory, installing our default vessel sound config files, and finally switching from OrbiterSound to XRSound in Orbiter's "Modules" tab in the launchpad.

You may notice a couple small sound effect differences, as well as the absence of the various random cabin ambiance noises that OrbiterSound left enabled by default (those occasional beeps, whirs and clicks). If you wish to re-enable those, it should be relatively trivial to adjust our vessel-specific config files in the "XRSound" directory to your liking. There is no GUI config tool like with OrbiterSound; the files are plain-text config files. They include detailed documentation within themselves for each configurable option, so hopefully it shouldn't require any serious technical know-how to make modifications. The default NASSP vessel sound configurations will now be included alongside every NASSP release on GitHub as a separate ZIP file, so you don't have to worry about overwriting your custom configs every time you update. Just copy the files in once and tweak them to your heart's content, or leave them untouched. It's possible that future commits may alter these files, but I don't expect them to change rapidly like the codebase itself, so for the most part you won't need to worry about updating them constantly (I hope).

Special thanks to @indy91 for his assistance with the code, and several dedicated NASSP devs and users who've been testing this feature for the past couple months.
 
Status
Not open for further replies.
Top