Meadville Space Center
Welcome, Guest. Please login or register.
September 24, 2020, 12:50:32 AM

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)
| | | |-+  Varying Complexity Levels
« previous next »
Pages: [1] 2 Print
Author Topic: Varying Complexity Levels  (Read 6228 times)
F16PilotJumper
Jr. Member
**
Posts: 8


View Profile
« on: February 05, 2005, 07:11:22 PM »

I love NASSP/NCPP to death, so please don't take any offense to any of my comments...

With the old 4.0/5.0 architecture, the user had a choice between a less complex version (NASSP default) and a more complex version (NCPP).  One of the things that I see happening with the development of 6.x is that this choice has been removed, and all new development is being concentrated on the more realistic panels and systems simulation.

I think it's important to have add-ons that are reasonably accessible to newer Orbiter users.   Mercury 5.0 has a complete-through autopilot, which allows the user to choose how much control they want to take.  At the same time, it provides an excellent experience even if you just fly a flight hands off.

I don't expect an autopilot capable of flying a whole Moon mission, but it would be really nice to have a simpler version of Saturn/Apollo for newer users to take advantage of. Something based on the simpler panel, with a limited number of Saturn-specific switches required for operation. Or even a version with no specilized panel at all, operating based on the 'J' key and basic orbiter principles (I guess the CVEL Saturn V stack already fullfills this role, but it's not as well-known as NASSP).

I would envision some kind of a 'complexity switching' setup program, which would switch out the .dlls for the more complicated paneled versions when the user is ready to move up to the more complex simulation.  Something like the DGIII control panel.

With a large number of people 'finding' Orbiter for the first time since 2005 has come out, it's critical to provide a positive user experience. I'll be honest and say that I have gotten frustrated as well when the mispositioning of one switch has messed up an entire mission.  Even with flashing squares around the switches you need to press like in the old Shuttle game, it's tedious for someone trying to learn what is going on to just randomly flip whatever lights up. I think offering one or more intermediate complexity levels would make NASSP an add-on that a variety of users could enjoy and learn from.
Logged
gimp1992
Full Member
***
Posts: 190


View Profile
« Reply #1 on: February 06, 2005, 08:45:38 AM »

Mercury was meat to be a completly automated flight vehicle so it is simpler to use. Apollo is vastly more complex and required the astronauts to preform more flying duties. That said it is not nessecary to flip every switch to fly apollo. Just the RCS and SPS and Launch Vehicles Yaw and Pitch switches need to be fliped. If you don't  want the new complexities you can always stay with NASSP 5.2.  I think if you progress like the real NASA program did by starting out with Mercury then Gemini(especially when the new Gemini is out) when you get to Apollo you will want the most realistic experiance there is.
Logged

Joe Brown
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #2 on: February 14, 2005, 03:11:58 AM »

I agree that there should be a way for the novice user to get a positive experience from using this add-on. The level of realism idea is a good one, as it should encourage the user to try to step up to the next level, and create a challenging experience.

My thinking at this point would be to create as realistic a simulation as we can, but incorporate some kind of "autopilot" that would set all the proper switch states, switch in all the autopilots, etc. for the complete novice at the simplest level, but at the highest level, require the user to closely follow the real flight plan documents, learn how to use the AGC, follow the checklists to the letter, etc.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #3 on: February 14, 2005, 07:39:13 AM »

Well, the 'Realism' variable already exists in the scenario, though it doesn't do much at the moment. It wouldn't be hard to add code that, say, automatically sets the CSM RCS switches once you seperate from the SIVB, if Realism is set to a low value.

One thing that we probably should add is a global config file to set these kind of things in (e.g. Realism, Language, etc) rather than have it vessel-specific in the scenario file.

The downside is that every time you add a configuration option like that, you significantly increase the amount of testing required.
Logged
robertsconley65
Administrator
Full Member
*****
Posts: 149


View Profile Email
« Reply #4 on: February 14, 2005, 09:34:24 AM »

Quote from: chode
I agree that there should be a way for the novice user to get a positive experience from using this add-on. The level of realism idea is a good one, as it should encourage the user to try to step up to the next level, and create a challenging experience.

My thinking at this point would be to create as realistic a simulation as we can, but incorporate some kind of "autopilot" that would set all the proper switch states, switch in all the autopilots, etc. for the complete novice at the simplest level, but at the highest level, require the user to closely follow the real flight plan documents, learn how to use the AGC, follow the checklists to the letter, etc.


I think you have two choices both of which can be pursued

1) Have a ton of scenarios for each phase of the mission with the switch already switch.

2) A simple version with no panel that relies on the standard orbiter MFDs.  Kind of like how Gemini is now compared to when I get done with 5.0.
Rob Conley
Logged
F16PilotJumper
Jr. Member
**
Posts: 8


View Profile
« Reply #5 on: February 21, 2005, 10:27:18 AM »

I think #2 is a pretty good option.  I never really use split scenarios very much to be honest - I usually want to fly the whole mission from start to finish.  

Gemini was how I learned all my on-orbit ops, because the launch autopilot would put me into a nice orbit and then I could play around from there.

I think having a version based on standard orbiter controls/MFDs would be awesome.  I see so many people trying to get to the Moon with TransX and getting all frustrated when you can do it just fine using Transfer MFD.

You could even simply provide a single generic "Apollo to the Moon" scenario with no panel, and a very simplified quickstart/tutorial, and then once the user has completed that mission, they can move on to the one with the full blown panels.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #6 on: February 21, 2005, 10:37:55 AM »

What I don't get is why you think that flying an Apollo mission 'by the seat of the pants' is going to be _easier_ than using the AGC autopilot functions? Before long the AGC will get you into orbit, fly the TLI burn, fly the mid-course corrections, land you on the moon, bring you back into lunar orbit, and fly the re-entry... is that really going to be easier to do by hand?
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #7 on: February 22, 2005, 02:45:15 AM »

Quote from: movieman
What I don't get is why you think that flying an Apollo mission 'by the seat of the pants' is going to be _easier_ than using the AGC autopilot functions? Before long the AGC will get you into orbit, fly the TLI burn, fly the mid-course corrections, land you on the moon, bring you back into lunar orbit, and fly the re-entry... is that really going to be easier to do by hand?


Well, not "easier", but a lot more fun.
Logged
F16PilotJumper
Jr. Member
**
Posts: 8


View Profile
« Reply #8 on: February 22, 2005, 12:12:54 PM »

The AGC doesn't transfer automatically between all those functions though.

All I'm asking is that as you go through and make everything more realistic and add more and more features to NASSP, to keep the accessiblity of it all in mind and not make Apollo something that only the Orbiter elite who are willing to pour over AGC commands and switch checklists can handle.

The moon landings and the Shuttle are the most widely known manned activities of our space program, and I think it's extremely important that there be an easy to use, accessible Apollo mod that someone with a few basic Orbiter skills can pick up and use to get to the Moon.

I enjoy messing around with the AGC and doing things 'by the numbers', but not everyone thinks the same way.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #9 on: February 22, 2005, 12:31:42 PM »

Quote
I think it's extremely important that there be an easy to use, accessible Apollo mod that someone with a few basic Orbiter skills can pick up and use to get to the Moon.


Do you really think people can land on the moon 'by the seat of their pants' more easily than they can click PROG 37 NOUN 63 ENTER PRO?
Logged
Anonymous
Guest
« Reply #10 on: February 22, 2005, 06:14:04 PM »

You could always use the LLMFD version of the landing code and dispense with the AGC entirely.

I'm simply trying to comment on something I've observed during the past year and a half of NASSPs evolution.  No need for hostility.  I appreciate the work you guys are doing. Geez.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #11 on: February 22, 2005, 06:15:55 PM »

I just don't understand the point you're making. If flying to the moon and back by hand was so easy, NASA wouldn't have put a computer on board to do it... learning to use the AGC is trivial compared to learning to fly the whole trip by hand.

As I said, we can easily make a realism setting that automatically sets the cockpit switches to sane default settings (e.g. RCS enabled), I just don't see why you wouldn't want to use the AGC if you want to make flying easier.
Logged
Moofy
Guest
« Reply #12 on: February 22, 2005, 09:49:04 PM »

I have to agree with the original poster on this one.  First of all, don't get offended, everyone appreciates the amount of time and effort put into this project by people nice enough to sacrifice their time.  No one is being rude or unappreciating here, they just want this project to turn out as best possible.

That said, i've observed that the complete panel is a turnoff to a lot of people who don't enjoy that level of complexity.  I believe when it comes to apollo you have people on different ends of the spectrum.  
On one end you have people who want to replicate the missions as best as they can.  They are the type of people who would build a simulator in their basement, play the mission wearing an authentic astronaut suit, not using time compression and so forth.  

On the other end you have people (like me) who enjoyed 5.2 because it was complex and required some reading and figuring out before they could fly.  However they never really warmed to the idea of 2000 switches spread across multiple panels, and tiny little windows, even if that was more realistic.

Obviously making the apollo project "nccp only" kinda excludes those people.  I think an option for people to play with something like the 5.2 panel still using other improvements and advancements that have been made would be a good idea.
Logged
F16PilotJumper
Jr. Member
**
Posts: 8


View Profile
« Reply #13 on: February 22, 2005, 10:55:56 PM »

The AGC is a useful navigational aid, yes, but I don't see what it really does for you that the default MFDs won't do.

Launch vehicle guidiance is a requirement. Once in orbit in a scenario with a launch window, you use the stock transfer MFD to plot a new Earth orbit that goes just past the moon when it is the right spot. Estimate so the burn is on either side of time to burn = 0, hit the '+' key, and away you go.  

MCC to keep the trajectory correct.  Close in to the Moon, pull up Orbit MFD and set ref to the moon.  Lunar injection burn retrograde at PeT = 0.  Wait until lunar orbit passes over desired landing site, drop off the LEM....slow pitch-up until horizontal velocity is gone, watch the vetical, use the VTOL MFD if you're really concerned about that last bit of translational velocity.  

Take off from moon when CSM is overhead, using the Map MFD to estimate the heading.  Minimize RInc on the way up using Orbiter MFD.  Synch and dock with the CSM.  As Earth comes over the lunar horizon, burn towards it to return home.

I'm sure that isn't perfect, but it's pretty close.

A new guy on the forums today did it in the default DG.  

I think that someone who is more interested in getting there could think it through and do it in less time then it takes to figure out all the complexity of the current version.

Think about what the target audience is for the project.......I've been interested in Apollo since I was 7 but when I spend my free time playing Orbiter I want to be doing something other then flipping switches and time accelerating.
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #14 on: February 23, 2005, 12:55:11 AM »

No offense, but if you want to fly to the moon and back, then use the DeltaGlider. It is FAR more capable than any real spacecraft ever developed.

But, if you want to simulate something that ACTUALLY went to the moon, like Apollo, then you have to appreciate the real world technology that existed to get you there, especially circa 1969,  like the AGC.

I still agree there can be levels of complexity, but if we're trying to simulate Apollo, then one goal would be to ACTUAULLY simulate Apollo.
Logged
Pages: [1] 2 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!