Meadville Space Center
Welcome, Guest. Please login or register.
December 09, 2019, 07:47:36 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP News & Discussion
| | |-+  Support & Bugs (Moderators: movieman, Tschachim, Swatch, lassombra)
| | | |-+  Apollo 7 Beta Testing Bugs
« previous next »
Pages: [1] 2 3 ... 7 Print
Author Topic: Apollo 7 Beta Testing Bugs  (Read 11026 times)
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« on: November 05, 2016, 08:01:42 AM »

I guess I will start it off with what I think is one little audio bug, the audio clip during pre launch of Jack King saying the "crew is at the 320 foot level" etc should only be used for a Saturn V flight, as the Saturn 1B was of course not even 200 feet tall Happy
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #1 on: November 05, 2016, 10:54:40 AM »

Done. This is a non mission specific sound, so I had to add an if condition, so that this is only played for Saturn V vehicles. I don't think we have a Saturn IB equivalent.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #2 on: November 06, 2016, 09:16:15 AM »

Another one for you, the LV IU/CMC switch no longer gives control to the CMC for maneuvering the SIVB.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #3 on: November 06, 2016, 01:20:16 PM »

Another one for you, the LV IU/CMC switch no longer gives control to the CMC for maneuvering the SIVB.

Looks to me like it's an DAP quirk, maybe only happening in Colossus237. Just do a V48 again with a V46 at the end and it suddenly works. No idea why that is required. If you do a V37E00E after the V46E then the takeover doesn't work anymore. I have the feeling I have read something about this in a transcript somewhere, but I don't know which mission...

EDIT: It doesn't seem to happen for Apollo 9 with Colossus249, although the Saturn V LVDC takeover works exactly the same. In Colossus237, the "EnableSIVBTakeover" bit in output channel 12 must have been reset by going to P00. Here the description of the bit for the downlink in GSOP section 2:

Quote
S4B Takeover Enable. Set to 1 following a V46E with bits 14-13 of DAPDATR = 1 (for Saturn attitude control using RHC). Can be reset to 0 by V37E00E, or a restart (since "Saturn DAP" is not restart protected) of bits 15-14 of Flagword 6.

There is no extra version of this page in the GSOP for Colossus IA, so it shouldn't really work much differently in C249. I'll have to look into the C237 and C249 code to see where the difference is.
« Last Edit: November 06, 2016, 01:40:48 PM by indy91 » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #4 on: November 09, 2016, 08:08:30 AM »

I cannot figure out what is causing this, but I am getting an OPR ERR light whenever I load V49 in the A7 mission.  It doesn't effect the V49 itself but should not be lighting up when I call a V49.

EDIT:  Sidenote, I noticed the checklist MFD after the SIVB sep does not open the seq events logic cb's back up, I believe it is supposed to after securing from a seq event/pyro activity.  Additionally, I do not know if it effects anything but shouldn't the dV switch be on CM this mission and in A8 from launch?

« Last Edit: November 09, 2016, 08:11:24 AM by rcflyinghokie » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #5 on: November 09, 2016, 09:26:14 AM »

I cannot figure out what is causing this, but I am getting an OPR ERR light whenever I load V49 in the A7 mission.  It doesn't effect the V49 itself but should not be lighting up when I call a V49.

It's a Colossus 237 bug and very much expected. It's even in the Apollo 8 CMP Checklist, see the discussion here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.msg24545#msg24545

Quote
EDIT:  Sidenote, I noticed the checklist MFD after the SIVB sep does not open the seq events logic cb's back up, I believe it is supposed to after securing from a seq event/pyro activity. 

I'll check it, I probably forgot to add this to the Checklist.

Quote
Additionally, I do not know if it effects anything but shouldn't the dV switch be on CM this mission and in A8 from launch?

For Apollo 7 yes. The AOH section 2 actually states that for a CSM with full propellant tanks the switch should be set to CSM/LM during launch for the suborbital aborts. This affects the TVC gains for a Mode III abort, which makes the CSM more stable (but also less precise). The switch is currently not functional in NASSP, I have found two documents that have the exact values of these gains, but the behavior which these gains is pretty bad, so I'll have to do more research and testing.

I'll go through the Apollo 7 Checklist and look if the switch is set to the wrong setting somewhere.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #6 on: November 10, 2016, 01:32:08 PM »

I have been getting a CTD every time it generates the thread for the 22h25m maneuver pad.  Here is the recent save before it.  But I even started a new mission and am having the same CTD location.  The error is below.

The thread 0x2808 has exited with code 0 (0x0).
Unhandled exception at 0x100ED83C (Saturn1b.dll) in orbiter.exe: 0xC0000005: Access violation writing location 0x67698844.

Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #7 on: November 10, 2016, 01:49:42 PM »

Works fine for me with that scenario. Maybe it's a problem wtih debug mode again? Or have you been building the NASSP solution in Release mode? In that case I have no idea why it would work for me, but not for you...
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #8 on: November 10, 2016, 02:11:37 PM »

The stack backtrace would be helpful if you can get it
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #9 on: November 10, 2016, 02:32:46 PM »

Works fine for me with that scenario. Maybe it's a problem wtih debug mode again? Or have you been building the NASSP solution in Release mode? In that case I have no idea why it would work for me, but not for you...

I have been building in Release mode.

The stack backtrace would be helpful if you can get it

How would I go about this?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #10 on: November 10, 2016, 03:42:40 PM »

I mean, what else than a build problem can it be? I have no uncommited changes to the MCC and RTCC and your scenario is working fine for me, no problem with the NCC1 Maneuver PAD. Can you try and REbuild the solution?
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #11 on: November 10, 2016, 04:53:27 PM »

How would I go about this?

I don't remember off the top of my head. If anywhere it will be around the same place you got the message you posted earlier. There will be something that says "stack trace" or "call trace" or something like that.

I mean, what else than a build problem can it be?

Any of a grocery list of things, most likely of which is an uninitialized variable. On your computer it just happens to work out but in his case there's a difference somewhere that breaks things.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #12 on: November 10, 2016, 09:53:06 PM »

I mean, what else than a build problem can it be? I have no uncommited changes to the MCC and RTCC and your scenario is working fine for me, no problem with the NCC1 Maneuver PAD. Can you try and REbuild the solution?

Just did a rebuild and everything worked.  The last build I did was all successful too so I haven't a clue what happened.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #13 on: November 11, 2016, 06:54:53 AM »

Still might be uninitialized variables. I actually found one already relevant for the NCC1 maneuver, but that particular variable can be in any state and it wouldn't cause harm. I'll search a little bit more, but of course it just might have been a build problem.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #14 on: November 11, 2016, 07:46:22 AM »

Still might be uninitialized variables. I actually found one already relevant for the NCC1 maneuver, but that particular variable can be in any state and it wouldn't cause harm. I'll search a little bit more, but of course it just might have been a build problem.

I just loaded it up this morning for fun and it gave me the same ctd even though it worked yesterday, so hunting for an issue is probably still prudent.

Throws an exception at this line

Code:
oapiAnnotationSetText(NHmessages,msgOutputBuf); // update the annotation

It also happens in the save file after the thread was generated when I try to repeat uplink.
« Last Edit: November 11, 2016, 07:50:49 AM by rcflyinghokie » Logged
Pages: [1] 2 3 ... 7 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!