Search results

I will also go on record as saying you are one of the few to fly the 13 failure mission, and also find bugs/inaccuracies! So don't sell yourself short!

Adding to this, on some transcript research, it appears missions as early as Apollo 8 also switched to MIN IMP before CM RCS firing. We don't have entry checklists for these missions so this got missed. I plan on adding that step to entry checklists and it should prevent this. Apollo 8...

I am getting the same behavior, configuration looks just fine. @indy91 could this be something to do with the CMRCS changes we made?

It also could be antivirus attacking dll's.

The way the scenario loads/saves the checklist has always been an annoying enigma. So its hard to diagnose why that went ahead without an update or editing the scenario (unless you accidently started a rendezvous checklist in the past then went back to flight plan or something. First P57 after...

Did you by chance update NASSP at all during this flight? Sometimes when checklist updates are pushed, they change the "state" and this sort of thing happens. I am getting the same behavior here in your scn so it wasn't your fault. Seems as the save thinks its in a different spot when finishing...

Was this from a fresh launch or a pre saved scenario? The pre saved ones the checklists can start in weird places a edits are made/pushed. If not, it sounds like you may have skipped something or accidently pushed it to the wrong location. I am happy to take a look/get it back on schedule.

Interesting editors note, the YO-YO was mentioned many times in the Apollo 11 surface checklist so I assumed they had them. The checklist MFD procedures are directly from that document. A YO YO...

You can change the landing site padload in the scenario or you can uplink a new RLS using RTCC with the actual landing site. Either should let the LM land in the actual site versus the planned site.

There is a chart in the launch/TLI checklists with expected yaw values for this, allowed a SIVB takeover flying the ORDEAL ball essentially.

Just saw this thread! Sorry about no response! Get it all sorted? Also, the ORDEAL is used to monitor TLI since the SIVB doesn't burn inertially, it actually moves its burn vector at an expected rate which matches what the ORDEAL can generate, so one ball allows the pitch to remain more or less...

@jarmonik ^ Mind taking a look?

Yeah it is not inconsistent, only Apollo 7 and 9 had SCS use in their burns, and it was strictly for testing.

Missions that use SCS for burns (Apollo 7 and 9 for instance) were to test the SCS. All other mission burns (Apollo 8, and 10-17) were planned to burn with PGNS, with SCS as a followup/backup. Which burns using one or the other are you referring to?

Glad you enjoyed it! Hopefully more changes can be added in the near future to properly simulate all the things you had to work around. Also thanks for finding a few bugs :) They normally wouldnt have been noticed on a routine flight.

Looks like this is a bug, RTCC is throwing a calculation error with masses of propellant. I will let @indy91 take a look. EDIT, I just realized you are in a CM/LM configuration, so the error is thrown because there is no propellant mass in the SM anymore. That is why its crashing. You needed to...

This got a hotfix, with more changes on the way but the meter no longer needs power. Fix is in work here, there was an unnecessary condition check on the auto rcs coils. Hmm looks like another mistake in the simulation! The EL lights should have power from the DC computer cb. I will get a fix...

Yeah that has them just on the main bus tie switches.

Yeah in this case, the LM is still powering MN B and MN A is brought up because both A and B are needed to heat the CM RCS. Unfortunately we dont have the power simulation necessary yet to allow the LM to power the CSM.

Looks like another case of incorrect NASSP code! They should fire in RHC normal and man att accel command without any AC power, but there are checks in the code incorrectly preventing it.