V8 Release Work Thread

[n72.75]

is it me or has the agc turned cyan/blue. How can I turn it back to original green ? Is this an option somewhere ? thanks im running v1759
I watched the ealier video and am a child of the late 60's / 70's LEDs are green or red My first red led ti calculator would drain a PP9 in an hour. Luxury managed to retire my log tables.
What a splendid bunch of improvements have come the addons way thanks for all the hard work from the usual suspects

That was me.

Keep in mind that these are electroluminescent displays, not LEDS.

Also, the colors in historical film of DSKY displays, is very dependent on: filmstock, lighting, development, age, method used to scan and edit the film, the monitor you're watching the video on.

The color I corrected the displays to are based on the videos of CuriousMarc, which he color-corrected to best match what he saw. @thewonderidiot has seen these first-hand as well.

The descriptions of the color in documentation refer to them as green, and give a peak wavelength that is definitely green, however this only described the peak, and not the full spectrum (such as, if there were a weaker blue secondary peak, or just a wide wavelength distribution in the blue part of the spectrum as well.)

I am not 100% set on the color as it is. It's probably too blue right now.

 

[4throck]

Being pedantic, at 23:38 on the video, display wavelengths are mentioned:
510nm for early ground testing models; 530nm for flight models.

Running wavelength to RGB converters (https://www.johndcook.com/wavelength_to_RGB.html or https://academo.org/demos/wavelength-to-colour-relationship/) we get:
510 » RGB value: #00ff00
530 » RGB value: #5eff00

As mentioned, this is peak wavelength, so in reality, saturation would be lower.
Measuring over the non-saturated display portions on Curious Droid video, I get around 70% saturation.

So for flight hardware, based on the video information alone, I'd go with:
#8eff4c

Of course, it looks a bit off for anyone that used a similar display (they did look a bit cyan).
I think the explanation is down to sRGB colorspace limitations:

The triangle doesn't extend much into the 500-540nm high saturation area (top left).
The closest possible color (geometrically) is indeed full green, not cyan.
So we are trying to display an out of gamut color.

When we move to HDR BT2020 computer displays (common on 4K TVs), it will be possible to display it perfectly!
But for now we can't!

As I mentioned, this is full pedantic mode.
Just make it green/cyan, it's a good approximation!

 

[n72.75]

I fixed a minor but annoying bug in the CSM telemetry code yesterday. That fix is now in build 1767.

If you ever used our telemetry client, you will have noticed that if you start a scenario with telemetry in HBR (High Bir Rate) mode, the client will display the values appropriately, the same is true in LBR (Low Bit Rate). Where you would previously run into an issue is if you switched from LBR to HBR. About 1 in 5 times, switching back to HBR worked flawlessly, but the other times, you would end up with random values in only certain analog values. Specifically these values were 10A1-10A150, and are all sent on specific, multiplexed words of the HBR format.

Our LBR mode keeps track of where we should be in the HBR frames if we were suddenly to switch back to HBR mode. At least as far back as 2007 is has not properly kept track of this position. This is now correct.

As a bonus, LBR mode was also sending out a whole frame of zeros that the client never processed, and that it shouldn't have been. It no longer does this.

The fix: https://github.com/orbiternassp/NASSP/pull/664/commits/9e846bbc4b822b2cfa0ecf1eaf23894ceec9e8b2

The current method of sending telemetry over network will get re-worked at some point, so I wouldn't build any new applications around it just yet, if anyone is getting that idea. Right now it is just sending messages consisting of 1024, 8-bit words over a TCP socket.

 

[sw34669]

That was me.

Keep in mind that these are electroluminescent displays, not LEDS.

Also, the colors in historical film of DSKY displays, is very dependent on: filmstock, lighting, development, age, method used to scan and edit the film, the monitor you're watching the video on.

The color I corrected the displays to are based on the videos of CuriousMarc, which he color-corrected to best match what he saw. @thewonderidiot has seen these first-hand as well.

The descriptions of the color in documentation refer to them as green, and give a peak wavelength that is definitely green, however this only described the peak, and not the full spectrum (such as, if there were a weaker blue secondary peak, or just a wide wavelength distribution in the blue part of the spectrum as well.)

I am not 100% set on the color as it is. It's probably too blue right now.

My gamma was a bit out (MSFS 2020 setting) so now i've tweaked that back it looks great somewhere between green and blue and ........ VERY HISTORIC
I'm just going through the changes for all the systems that have been accomplished over the last year and it's stunning. Thanks to all for the hard work. I'm playing about with apollo 7 at the moment, quick question a pad comes through for a re-entry at 08:17. I assume this is an abort PAD if needed. How would I act on it, would i use one of the checklists in the MFD from the index as I left the oven on and have to return home.

 

[rcflyinghokie]

My gamma was a bit out (MSFS 2020 setting) so now i've tweaked that back it looks great somewhere between green and blue and ........ VERY HISTORIC
I'm just going through the changes for all the systems that have been accomplished over the last year and it's stunning. Thanks to all for the hard work. I'm playing about with apollo 7 at the moment, quick question a pad comes through for a re-entry at 08:17. I assume this is an abort PAD if needed. How would I act on it, would i use one of the checklists in the MFD from the index as I left the oven on and have to return home.

Lets try to keep questions like this out of the release work thread, please make a new thread for it so its easier to track

 

[Thymo]

This thread has been locked so only development updates can get posted. If you have a question or something other to discuss, please create a new thread.

 

[indy91]

The CSM, the CSM+S-IVB stage and the S-IVB stage now have realistic airfoil models, instead of using the legacy aerodynamics with unrealistic coefficients. Initially the drag is still reduced because the RTCC calculations can't all take the increase in drag into account yet. In this initial release the amount is only 5% of realistic drag, which I have now realized it is a bit low for an average attitude, although still more than the old version at 0° and 180° angle of attack. But it's only temporarily at 5%, it will get fixed soon. Here are the graphs for the CSM:

On the first look the legacy aerodynamics don't look so bad compared to the realistic model, the curves are very similar. But when you actually look at the scale you see how large the difference between 0° and 90° angle of attack is. With realistic aero 90° AOA has a bit more than twice then amount of drag than 0°. But with our old model it's an absurdly high difference, about 40 times larger at 90°. That previously resulted in a bit random behavior of the trajectory. Not a lot of course with just a bit of drag, but it was extremely dependent on the attitude. And if you look closely, even the 5% drag solution is higher at 0° and 180° than the old aerodynamics.

The airfoils model in Orbiter works well for aircraft. However, spacecraft can easily fly at attitudes that would be unrealistic for aircraft, especially at 90° angle of attack or slip angle. With the horizontal and vertical airfoil functions in Orbiter you get a singularity for the slip angle at 90° angle of attack and vice versa. So at these attitudes the behavior could be somewhat random.

I have not found a good solution for this for lift and moment coefficients, but I have found one for drag. Instead of calculating drag in terms of AOA or slip angle I am using the "total" angle of attack (AOA and slip angle combined) and let only one of the two airfoil functions calculate any drag. This works only for symmetrical spacecraft like the CSM. Thanks to the CreateAirfoil3 function you can access vessel API functions, so I am calculating the angle like this:

VECTOR3 vec;
v->GetAirspeedVector(FRAME_LOCAL, vec);
double aoa_T = acos(unit(vec).z);

And the drag coefficient is then a function of this angle. This solution works at all attitudes and is singularity free. It doesn't work for lift and moments because the direction of lift and moments depend on the attitude, where the drag direction is always the same, the velocity vector relative to the atmosphere.

For the CSM I have also implemented moment coefficients, which are at 100% realistic value already. They can be relevant at low perigee altitudes like Apollo 7 had it for long parts of the mission. Here is a page from the mission report, showing what can happen at a 90NM perigee altitude:

What this shows is that if you are at 90° angle of attack, the aerodynamic torquing effects can give you an additional pitch rate of 0.2°/s within 3 minutes. I think the crew reported difficulties performing P52 at perigee and I expect this to happen in NASSP now, too. So be warned when you fly Apollo 7. This effect might be the reason that the increased the perigee altitude to 100NM on Apollo 9.

 

[jalexb88]

CM Virtual Cockpit:

The command module virtual cockpit has been part of NASSP for more then 10 years, the meshes/textures originally created by Swatch, another NASSP developer. Up until recently however, the VC was completely static and dark so I turned on the lights and started work on bringing it to life

The CM virtual cockpit has been useable for almost a year now but I have not made an official post about it. The VC is now fully animated, all controls/switches are clickable and the VC can be used for an entire mission. What is still missing is a 3D version of the optics views, for now the 2D panel optics views (telescope/sextant) must be used. For convenience, when the current VC viewpoint is the LEB, a flag is set so pressing F8 twice will bring you straight to the 2D optics panel.

A few notes:

Viewpoints are controlled with CTRL-Arrow keys, same as the LM. The COAS can be accessed by a click-spot near the CDR's forward window.

Switch/control operation is virtually identical to the 2D panel, with the exception of both mouse buttons used to operate the switches themselves, so left-click and right-click to move the switch. Switch Guards are operated by right-clicking slightly to the outside of the center of the switch's click-spot. Here is a visual representation, the colors showing where to click:

Seat folding: There is a click-spot to the left of the CDR's seat, just aft of the THC handle. Clicking this cycles the seats folded or un-folded for better visibility when maneuvering around the inside of the VC.

There are a few issues remaining such as click-spots getting corrupted when loading a scenario already in the VC, and at every staging event. The work-around for this is simply to shift to a different viewpoint and back (ctrl-arrows). This will hopefully be fixed in the near future.

Edit: Click-spots at staging are now fixed: https://github.com/orbiternassp/NASSP/commit/246c7a1ec930f4af733f56d255a710015306888a

 

[jalexb88]

A few visuals updates for the CSM & LM:

Some new D3D9 configuration files have been defined for the SM & LM. These now use "metalness PBR" which increase the realism for metallic surfaces and things such as foil.
For the effects to be visible, you mush have D3D9ClientBeta30.7-forBETA r90(r1436) or better since 30.1 does not yet support the metalness shader. In the "D3D9Client Advanced Setup" window, I recommend under "Reflections and Custom camera settings" to set Reflection Mode to "Full Scene" and Update Rate to "Heavy" for the best visual effects.

Max-Q has kindly allowed us to include his "NASSP CSM Textures Update" natively within NASSP. From here: https://orbithangar.com/showAddon.php?id=1090a993-03fb-4308-8bf7-8e273d3b9b38 This includes improvements to the HGA textures, a new shiny exterior texture for the CM and some nice post-reentry effects.

 

[indy91]

In the same way that I implemented improved aerodynamics for the CSM I have now implemented new airfoil functions for the CM alone. Previously there was only one airfoil defined, in the vertical axis (pitch). The yaw axis was kept stable by the center of pressure location. Probably way too stable even. The noticable differences to before are:

-There is now an aerodynamically stable attitude with the apex cover forwards. So try not to fly the start of the reentry in this orientation haha. Previously the CM will have eventually orientated itself blunt-end forward.
-As mentioned, the horizontal axis now also has an airfoil. So this should give realistic dynamic behavior in yaw.
-In general the stabilizing moments are a bit less than before. So especially early during reentry there can be some slightly larger rates, with the CM swinging back and forth. I've usually seen 1 to 1.5°/s. The CMC and SCS would start doing rate damping at 2°/s, something that happened a few, rare times during the actual missions. So our rates are still slightly less than the actual missions, so it's no problem.
-In the transonic region our previous CM airfoil lead to a rapidly changing trim angle of attack. The new aerodynamics are based on numbers from the CSM Data Book, the same source that was used for the NAA and MIT simulators of the CM. With those numbers the CM now gets a lot smoother through Mach 1. In reality the CM behaved a bit less nice than the simulators in this Mach region. The truth is probably somewhere in the middle. They never seemed to have bothered to try and improve the reference aerodynamic coefficients for the CM in the CSM Data Book, so I'm not too worried about it. Just something that is difficult to get right. Here a graph of the difference:

-The airfoil functions are valid in any attitude. Normally there is a bit of a singularity at certain attitudes. At an angle of attack (pitch) of +90° or -90° the side slip angle (yaw) becomes ill defined, so any lift or moment calculations in the horizontal airfoil function are not accurate there. Not really a problem for aircraft, and to be fair, also not for the CM which operates mostly near 160° AOA. But with a few additional calculations and ignoring the input AOA and slip angle to the airfoil functions you can make it singularity free. I'll make a separate forum post about how I did this specifically, maybe it's helpful for people wanting to implement airfoils for axis symmetrical spacecraft like the CM and CSM.

 

[Thymo]

Some of you may have been following some activity about new FDAI textures lately. Today these have been added to NASSP by default to replace the ones that have been used for around the last 15 years. Many thanks go out to @chrival for the new textures. Credit also goes out to @Lupus_Vulpes for independently creating his own textures and providing extra input once it was clear Chrival's work would be upstreamed.

The textures are provided from build 1830 and up and you can preview them here: https://www.orbiter-forum.com/threads/new-fdai-tex-1800x900.40338/#post-590570

 

[indy91]

Earth landmark markers are now available again! The new style of labels was a bit of a headache to get working, but the big advantage over the old style markers is elevation data. The old style of markers didn't support elevation of landmarks. A lot of Apollo Earth landmarks were on the coasts, but there are some like Mexico City airport where the old markers appeared a few kilometers below the surface in Orbiter 2016 and Beta. The shape of the Earth in Orbiter is still spherical, so in radius most landmarks are still off, but with something like Mexico City putting the marker at the right elevation helps a bunch:

Apollo 8 Landmark Maps: +1.21 NM
Orbiter 2010/Old Marker: -1.32NM
Orbiter 2016/New Markers -0.11NM

All these numbers relative to the Earth ellipsoid, not mean radius. That Orbiter 2016 uses the correct elevation data (just above a spherical Earth) can be seen from the fact that the elevation of Mexico City is 1.21 NM, just like the landmark map shows it (difference between old and new marker).

The new style of marker files are located in the Textures folder, so if you are using the high res Earth textures from another Orbiter install than your NASSP install you might need to copy over the Textures\Earth\Label folder to your main Orbiter install, or otherwise the markers won't appear. The installation guide will be updated, right now it only mentions copying over the NASSP textures.

 

[Thymo]

@Max-Q has provided us with a new mesh for the LTA for everyone to enjoy. Available with the latest release.

 

[indy91]

The Apollo 7 MCC has been reorganized a bit. Sadly I had to break old scenarios for that. The mission scenarios that come with NASSP have of course been fixed and if you have just launched, scenarios saved before the first state vector uplink at T+56min are also fine. Otherwise I would suggest not updating NASSP if you are currently in the process of flying Apollo 7. In doubt scenarios could also be fixed, so let me know if that is required. This reorganization should be the last time the MCC is responsible for breaking old scenarios. The Apollo 7 MCC was just the oldest and didn't really allow for future expansion of some more MCC updates happening.

Aside from the reorganization two small features have been added, an IU state vector uplink happening after the CSM has already separated from the S-IVB/IU. And a PAD for the retro attitude orientation test. More Apollo 7 updates to come.

 

[CaptainSwag101]

The electroluminescent display digits have been updated to use the digit style from the official NASA design schematics for the DSKY. This is certainly a more accurate representation of how things looked to the astronauts when interacting with the computer, though it should be noted that other EL displays in the cockpit were likely designed by other manufacturers and their numerical digits may not have been designed to the same specs; we simply don't know. If we ever come across other schematics that indicate different displays use differently-shaped digits, they should also be more convenient to update: I have tweaked the various EL display rendering code functions in order to allow for a simpler way to adjust the sizes of their digits rather than using hardcoded magic numbers. These new digits were drawn using vector art so that they can be freely scaled to whatever arbitrary size is desired. Here is an enlarged representation of the new digits:

And here's how they appear in the 2D and 3D cockpits:

As you may be able to tell, I have also adjusted the digit colors, trying to give them a little more of the greenish tint that people seem to be looking for. As has perhaps been mentioned before, thewonderidiot has determined that one of the reasons for the significant variation in interpretation of DSKY/electroluminescent display color, is that EL technology produces a very wide-band spectrum of light. This means that under different lighting conditions and viewing angles, its color varies a surprising amount. Most firsthand descriptions do indicate a relatively bluish, cyan-tinted color, however in dimmer light environments and more amber-colored ambient light, things appear more green. The peak wavelength (just barely) is around 514 nm, however while most "wavelength to RGB" converters represent this as a stark lime green color, this may not be entirely accurate due to the limitations of the sRGB colorspace. Furthermore, because the light is so wideband, there is a significant blueish component that is frequently visible under many common lighting conditions and to most cameras. I have chosen to pick #00FF96, based on this photo of a real DSKY display (again, other photos of this very same display can appear almost completely cyan, it is nearly impossible to quantify the exact color due to the reasons listed above):

Anyhow, I really don't intend or desire to spark further argument on the topic, and at some point with enough code tweaks it may be possible to allow easier configuration of the EL color between several presets without requiring the end user to compile NASSP from source; perhaps a configuration option so that users may pick whichever color they prefer most. However, I hope that the chosen color is a good compromise for both those who prefer the more bluish color and those who prefer a green DSKY, etc.

And more importantly, I hope that people enjoy the new, more accurate numerical digits!

 

[kuddel]

I am for sure enjoying the new, more accurate numerical digits!

 

[n72.75]

New feature!

I have added local light source spotlight and rendezvous lights to the CSM. These are controlled by the appropriate switches on pannel 2, and consume power from the proper busses (and phases).

Here's a quick demo video of the spotlight

I didn't record video of the strobe, but you can check that out for yourselves.

Hopefully this adds some atmosphere and functionality to operations in darkness/shadow. I am planning on adding interior lights too, when we get a few new D3D9Client features.

 

[indy91]

EVAs with both astronauts are now supported!

This one should have been implemented a long time ago, but until now only one astronaut could exit the LM. There are a few smaller limitations. The CDR always exits first and only the CDR can span the flag and the LRV (on the later missions).

There also is no complete backwards compatibility for scenarios where the (old) astronaut is outside the LM. So a tiny bit of scenario is required if you want to get the CDR back into the LM:

In the scenario find the line "EVA 1" and delete it. Then the old CDR LEVA vessel will have to be deleted. This could be done with the scenario edit in-sim, but in the scenario file it is this part that needs to be deleted:

Eagle-LEVA: ProjectApollo/LEVA
STATUS Landed Moon
POS 23.7097411 0.7135743
HEADING 196.84
ALT 0.770
AROT -105.453 -6.785 67.404
NAVFREQ 0 0
STATE 10
MISSIONNO 11
END

Best search for "-LEVA" as the EVA vessel name is based on the name of the LM.

 

[n72.75]

New feature: active ground stations that interact with our s-band radios.

Some of you may remember seeing this video I posed a few weeks ago.

The update has been pushed today.

If you've flown with mission tracking on (as opposed to doing all your calculations through the RTCC MFD) you will know that we keep track of which stations are in AOS, and have seen the station AOS and LOS messages that appear as you fly. This has been in place, at least in part since 2015, although the earliest indication of it in out commit logs go back to 2007.

When we implemented S-band antenna tracking for the CSM and LM back in 2020, we calculated signal strengths based on a vector between the spacecraft and the subspacecraft point on Earth with no consideration for the RF source emanating from the location of a ground station. It the time it was good enough, and antennas tracking the center of the earth was better than tracking nothing.

As an improvement to this we feed a vector to the current, actively transmitting, ground station, into the same equations we already had.

The challenging part was choosing which station should be the active one. At any given point in a mission, somewhere between 0 and 7+ stations will be in AOS at a given time. For reasons involving RF wave interference, only one of these will be radiating and transmitting its carriers and subcarriers at the spacecraft for it to lock onto at a given time. In the real MSFN a "Site Configuration Message" (SCM) was sent to each station before they began tracking. Our RTCC, through the Next Station Contacts display allows you to see upcoming GETs of AOS, so in theory it would have been possible for the NASSP user to manually switch stations, or generate our own semi-automated SCMs, on missions like Apollo 7 and 9, it would have been more like "Nasa Apollo Spreadsheet Simulation Project". And the workload would've been prohibitively high in some phases of the missions.

So instead of this we have a somewhat simplified automated solution, but one that is plausible and works quite well. When a station enters AOS it becomes the active "Transmitting Ground Station", until such a time that a new station enters AOS (or the transmitting station enters LOS).

At the moment this effects three things:

• The signal strength gauge.
• The telemetry word that represents signal strength (telecom page in the telemetry client).
• Where the antennas point when they are tracking.

Things that this update does not implement (yet):

• Uplinking dependency on signal strength.
• Telemetry dependency on signal strength
• ARIA.
• Mission-specific tracking ship locations.
• Anything that depends on signal strength to work properly in the real spacecraft.

Feedback would be awesome, and will let us know if we need to fix anything with the automatic station switching, before we make other features depend on signal strength.

Thanks!

 

[n72.75]

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:

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

New method

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.