Meadville Space Center
Welcome, Guest. Please login or register.
August 14, 2020, 06:16:26 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
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
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Re: What code do we start from? NASSP 5 or NCPP?
« previous next »
Poll
Question: What code do we start from? NASSP 5 or NCPP?  (Voting closed: December 04, 2004, 09:39:47 PM)
NASSP 5 Source - 0 (0%)
NCPP Source - 2 (100%)
Total Voters: 2

Pages: [1] Print
Author Topic: Re: What code do we start from? NASSP 5 or NCPP?  (Read 6619 times)
Zachstar
Sr. Member
****
Posts: 317

Is it Star Trek?


View Profile
« on: November 24, 2004, 09:54:12 PM »

http://spacebarjoe.free.fr/NASSP_SOURCE.zip <<--- NASSP 5
Logged


-------------------------------------------
robertsconley65
Administrator
Full Member
*****
Posts: 149


View Profile Email
« Reply #1 on: November 25, 2004, 12:56:54 AM »

My advice is make a new structure and filling in with data and code from both projects.  The only caveat is use the same or a compatible license with the original sources. I highly recommend you go with the GPL for this project as this will allow the use of the Virtual AGC.

I recommend you start out making a list of all the stages in Apollo with the Saturn V and saturn IB being separate lists in the begining.

For example in Mercury the stages for the Atlas are

Atlas Booster + Capsule + Tower
Atlas Substainer only + Capsule + Tower
Atlas Substainer only + Capsule
Capsule + Retro Pack + Antenna
Capsule + Antenna
Capsule

It is a series of "states" that your "stack" is going to be in from launch to recovery.

After the last rocket state is dealt with you are going to have the same list regardless whether you used the Saturn IB or Saturn V.  This will simpilify programming.

As for the project itself I recommend you go with completely manual system at first with no panels, no automatic anything. See my early version of the Mercury and Gemini addons. Get the various states working first.

Then the next thing is to work on the flight controls for the panels. This is because attitude, and thrusters are modeled in the ORbiter API don't require any additional programming.

Then work on the system simulation for electrical, life support, computers, and the rest.

In Project Mercury and Gemini my management code is in the various versions of multi_stageX.h

I generally have my main file, and one set of files for each stage, then I have a ControlPanel set, and a System Set. So for Apollo it would look like this

saturn_ib.cpp   saturn_v.cpp
saturn_ib.h      saturn_v.h
csm.cpp
csm.h
csm_pan.cpp
csm_pan.h
lem_pan.cpp
lem_pan.h
csm_sys.cpp
csm_sys.h
lem_sys.h
lem_sys.h
apollo_sys.cpp
apollo_sys.h
stage_manager.cpp
stage_manager.h

Rob Conley
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #2 on: November 25, 2004, 07:48:25 AM »

NCPP is based on NASSP 5.0 or a later version (AFAIR they were trying to get 5.2 from Jean Luc but I don't know whether they did), so it seems the sane place to start.

As to the re-ordering of the code, there's already a lot shared between the Saturn 1b and Saturn V, so much of that has been done... that said, there are a lot of hardware differences between the Saturn 1b and Saturn V, so it's not as easily shareable as you might like. Equally, the whole thing is driven based on a couple of state variables, so most of that work has been done too. You may want to reorder things, revise the choice of C++ classes and move functions around between files, but you should have a decent base to work from already.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #3 on: November 25, 2004, 09:08:47 AM »

Also, the DSKY code needs revising to make it easier to switch between C++ AGC and Virtual AGC: you should be able to just have two classes with the same interface to the main code so it's invisible to the rest.

Plus we should eliminate pointers wherever possible to minimise the opportunities to accidentally trash Orbiter data structures if the pointer gets corrupted.
Logged
robertsconley65
Administrator
Full Member
*****
Posts: 149


View Profile Email
« Reply #4 on: November 26, 2004, 11:20:57 PM »

Quote from: movieman
NCPP is based on NASSP 5.0 or a later version (AFAIR they were trying to get 5.2 from Jean Luc but I don't know whether they did), so it seems the sane place to start.

As to the re-ordering of the code, there's already a lot shared between the Saturn 1b and Saturn V, so much of that has been done...


I am just suggesting what I would do if I had the time to code for this project. I would re-use a lot of what been written by other apollo project. And there is a reason for this as I have had reports of very annoying bugs in NASSP that seems to be related to the organization of the code rather than bugs in procedures.

The most coherent explanation I found came from SimonPro so I would ask him rather than relying on my second hand information.

I am suggesting is a refactoring rather than a total re-write.
Logged
robertsconley65
Administrator
Full Member
*****
Posts: 149


View Profile Email
« Reply #5 on: November 26, 2004, 11:24:06 PM »

Quote from: movieman

Plus we should eliminate pointers wherever possible to minimise the opportunities to accidentally trash Orbiter data structures if the pointer gets corrupted.


I found if I stayed away from module functions i.e. procedures that are not part of a class. My addon became more stable. The two problem I found are errors in trying to run two or more of the same vessel in the same scenario, and trying to run the same scenario without exiting orbiter.

Personally for Mercury I haven't licked the first, but almost there with the second. I fixed both for Gemini.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #6 on: November 29, 2004, 11:09:10 AM »

The problem with most of the reported NASSP bugs I've seen is that they seem to be things that NASSP has no control over (e.g. corrupt textures on models). Unless NASSP is accidentally trashing Orbiter's data with duff pointers, I don't see any way that it could be causing those things to happen.

To be honest, I suspect they may be Orbiter bugs which other addons don't hit because they don't stress Orbiter as much as NASSP does. But removing as many pointers as possible would be a good idea in case we're failing to initialise one properly.
Logged
Anonymous
Guest
« Reply #7 on: January 18, 2005, 08:58:34 PM »

Let me know if you need help programming wise.

I was thinking of the entry code, but it will have to be hard coded into the AGC, and there is some need for a change in other code.
Logged
joeybigO
Newbie
*
Posts: 1


View Profile
« Reply #8 on: January 18, 2005, 08:59:52 PM »

oops thats me ^ joeybigO
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #9 on: January 19, 2005, 10:54:39 AM »

Sure, a realistic entry autopilot would be good. I think the Delco manual has some info on the algorithms used by the real AGC.

In the short term, someone to do a proper SDK-compliant virtual cockpit implementation would be very good Happy. Doesn't need to implement the control panel, just a better version that the quick hack I did.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #10 on: January 25, 2005, 10:31:36 PM »

I have a feeling it's NASSP5_SOURCE.zip.
Logged
Zachstar
Sr. Member
****
Posts: 317

Is it Star Trek?


View Profile
« Reply #11 on: January 25, 2005, 10:48:32 PM »

Dead link BTW check your inbox often
Logged


-------------------------------------------
Pages: [1] 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!