Meadville Space Center
Welcome, Guest. Please login or register.
October 30, 2020, 08:49:27 PM

Login with username, password and session length
Search:     Advanced search
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 Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  V8 Release Work Thread
« previous next »
Pages: [1] 2 3 ... 16 Print
Author Topic: V8 Release Work Thread  (Read 24425 times)
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« on: December 22, 2016, 01:30:57 AM »

This thread is the "What needs done?" thread for V8. The V8 release branch is Orbiter2015, and despite the name is targeting Orbiter 2016.

I just merged all the changes from the V7 (master) branch to V8 in preparation for transitioning V7 to release candidate status.
All new development work should be done in the V8 branch.

Edit: Orbiter2015 is now officially the V8 release branch. We are go for further work.
« Last Edit: December 22, 2016, 02:07:03 AM by dseagrav » Logged
Puma
Full Member
***
Posts: 61


View Profile Email
« Reply #1 on: December 22, 2016, 07:12:33 PM »

for the NASSP version for Orbiter 2016, release: NASSP-V8.0-Alpha-Orbiter2015-309.zip, I have found that The Saturn 1B pitch at launch, make it impossible to achieve a good Orbit!


* NASSP V8 Saturn 1b Launch problem.jpg (73.38 KB, 1360x768 - viewed 947 times.)
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #2 on: December 22, 2016, 08:43:29 PM »

That's a known issue. Orbiter2015/2016 changed the way vessels interact with the terrain. No launch scenario will work. We're probably going to end up completely rewriting the way the stack stacks and unstacks.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #3 on: December 24, 2016, 12:35:39 AM »

On the face of it, we'll have to split off all the Saturn vehicle stages into individual vehicles, reorganize the code, and create the necessary "umbilicals" to link it all together and properly stage them. Hell, the CSM code is integrated directly into that of the Saturn programming class—that would probably be the first step, IMO.

Actually gives me an idea for proceeding on V8—create launch abort scenarios, so we can figure out how to separate the CM and SM code from the Saturn class, then spilt off the stages afterwards. So, we'd verify bug-less performance in the Mode I abort scenarios (CM-only), then move on to the Mode II abort scenarios (at least SIC/SIB independence and CM/SM), then Mode III/IV scenarios (independent SII and SIVB). Is that too involved, or what?
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #4 on: December 24, 2016, 01:13:35 PM »

No, that's pretty much the way to go. Another nice thing is that each stage would only have to have the bits it actually needs to work, so we don't have multiple instances of CMC/LGC bits and other detrius floating around being skipped over. It should let us slim things down significantly, which should help performance. That's not such a big deal now, but it will be super important when we start trying to make a 3D VC.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #5 on: December 24, 2016, 01:51:09 PM »

What I especially like about it is that we will run systems where they belong: LVDC in the IU, CSM as a separate Visual Studio project etc. It should then be much easier to connect a running LM with a Saturn for Apollo 5 and stuff like that. I don't know much how staging is different in Orbiter 2016, but the three options will be to 1. still have one vehicle on the launch pad (is that possible in Orbiter 2016?), have the stages connected with attachments (SSU has the SRBs and the ET attached to the Shuttle Orbiter) or have the stages docked. This last point seems to still undergo some changes, so it might be different once Orbiter 2016P1 will be released. Having the stages docked (in Orbiter terms) has the advantages that the properties of the whole stack are calculated dynamically. With attachments there is a parent vessel whose parameters are mostly used.

In any case, I really hope @dseagrav or someone else will be working on this. I'd like to focus on implenting new Virtual AGC features like Standby Mode and all the new LGC versions first. Then I want to make the launch scenarios and all the RTCC functions ready for Orbiter 2016. And maybe then I can start working on running the LVDC in the IU and these kind of topics.
« Last Edit: December 24, 2016, 02:04:30 PM by indy91 » Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #6 on: December 24, 2016, 06:49:36 PM »

What I especially like about it is that we will run systems where they belong: LVDC in the IU, CSM as a separate Visual Studio project etc.

It occurred to me, could this be useful as a possible solution to separately simulate the cdu counters from the imu?
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #7 on: December 26, 2016, 12:20:07 AM »

We kinda already do, in a way. We just assume no lag between the CDUs and the gimbals, so theoretically, there's no need at all to P52/P54 for realignment (except for a reference change). At least, when I've seen the code, we don't feature the use of random CDU error, inertially or optically.
Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #8 on: December 26, 2016, 04:26:51 PM »

Sorry I meant as a solution to the V40N20 issue when zeroing the icdu counters.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #9 on: January 18, 2017, 02:10:45 PM »

Wrong thread, Eddie. Tongue

Been trying to check out the Standby function in V8, but apparently the DirectInput 8 header we use is throwing a debug line when Orbiter 2016 is used without a joystick (I didn't enable standalone joystick control). I can't see the Standby lines.

Maybe you have a joystick connected but haven't selected it in the Configuration menu? That might trigger the "DX8JS: Cannot aquire THC [RHC]" message.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #10 on: January 18, 2017, 02:20:52 PM »

No, it just simply says "DX8JS: No joysticks detected". Joysticks disabled in the tabs, Orbiter control scheme enabled in the Project Apollo Configurator, still happens.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #11 on: January 18, 2017, 02:38:40 PM »

Do you mean: ""DX8JS: No joysticks found"?  I need to know the exact phrase to be able to find it in the code.

I'm not getting that one, with everything disabled in the Orbiter Launchpad. Maybe it detects my printer or keyboard as a "device" and therefore doesn't display this? Because actually this line should be displayed whenever there is no device found to be used as a joystick. And this line is only printed when the config file is loaded, so it actually should be overwritten by the standby mode debug line, which should be printed every timestep. And I don't even manage to get any debug line printed during config file loading. But I do remember occasionally getting this debug line, no idea why...
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #12 on: January 19, 2017, 04:04:22 PM »

That's exactly the message.

OOC, did Microsoft update DirectInput with 9.0 and above, or do they use an entirely different API for that now?
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #13 on: January 19, 2017, 08:46:58 PM »

I made one change I thought might help: you have the standby debug line in the CMOptics class, not the CSMComputer class. So I thought while the optics were off, the debug line wouldn't update. So I moved it around, and now it works.

According to the debug line, when the computer is started into idle, the SbyPressed state is permanently 1, and immediately after P06 is selected, Standby is set to 1. Within seconds of P06 running, the DSKY transfers to F 37 XX and Standby is set again to 0.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #14 on: January 20, 2017, 05:18:10 AM »

I made one change I thought might help: you have the standby debug line in the CMOptics class, not the CSMComputer class. So I thought while the optics were off, the debug line wouldn't update. So I moved it around, and now it works.

Oops, I think I just used a debug string I had used for some other testing.

Quote
According to the debug line, when the computer is started into idle, the SbyPressed state is permanently 1, and immediately after P06 is selected, Standby is set to 1. Within seconds of P06 running, the DSKY transfers to F 37 XX and Standby is set again to 0.

That's how it was when I stopped working on it. I'm sure @thewonderidiot has something to say about this. I can't guarantee that there aren't any mistakes in the agc_engine.c file. That's why we should should work on this: https://github.com/virtualagc/virtualagc/issues/622 once all the current Virtual AGC changes have been included in the NASSP files.
« Last Edit: January 20, 2017, 06:04:17 AM by indy91 » Logged
Pages: [1] 2 3 ... 16 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!