V8 Release Work Thread

Status
Not open for further replies.

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,257
Reaction score
783
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
978
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
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:
1637751019919.png

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

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,257
Reaction score
783
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
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.

1637909520039.png


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

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
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

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
397
Reaction score
191
Points
58
Location
Colorado
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 (y)
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,134
Reaction score
418
Points
98
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:

WC6Ma4q.png

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:

X07TgAH.png


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

Addon Developer
Addon Developer
Joined
Aug 11, 2008
Messages
141
Reaction score
125
Points
43
Location
Canada
CM Virtual Cockpit:

Screenshot%202022-01-08%2012.29.22.png


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:

Screenshot%202022-01-08%2013.21.34.png



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.

Screenshot%202022-01-08%2012.23.31.png


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
 
Last edited:

jalexb88

Addon Developer
Addon Developer
Joined
Aug 11, 2008
Messages
141
Reaction score
125
Points
43
Location
Canada
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.

Screenshot%202022-01-08%2014.13.43.png
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,134
Reaction score
418
Points
98
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:

IY8UtMq.png


-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

I like breaking things
Addon Developer
Joined
Jun 26, 2016
Messages
118
Reaction score
145
Points
58
Website
nassp.space
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

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,134
Reaction score
418
Points
98
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.
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,134
Reaction score
418
Points
98
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.
 
Joined
Feb 6, 2022
Messages
15
Reaction score
39
Points
13
Location
Earth
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:
NASSP Digit redesign.png


And here's how they appear in the 2D and 3D cockpits:
orbiter_2022-03-28_17-39-38.png
orbiter_2022-03-31_16-51-47.png


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):
DSKY display greenish.png


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

Donator
Donator
Joined
Apr 1, 2008
Messages
1,832
Reaction score
353
Points
83
I am for sure enjoying the new, more accurate numerical digits! (y)
 

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,257
Reaction score
783
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,134
Reaction score
418
Points
98
EVAs with both astronauts are now supported!

qyoFIqT.png


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.
 
Status
Not open for further replies.
Top