Meadville Space Center
Welcome, Guest. Please login or register.
July 10, 2020, 04:46:02 AM

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 Development
| | |-+  Planning (Moderators: movieman, Swatch, lassombra)
| | | |-+  Project Apollo MFD ideas & concepts
« previous next »
Pages: 1 [2] 3 Print
Author Topic: Project Apollo MFD ideas & concepts  (Read 21204 times)
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #15 on: July 21, 2007, 07:57:48 PM »

Well, here we are, one year later, and I figured I'd resurrect this a bit....not because I'm a necroposter Evil or Very Mad or because I feel bad for the thread Crying or Very sad but instead because with the increased work in dseagrav's Mission Control capabilities, its time we revisit two parts of this.   The Mission Control interface and the Crew Simulation.

I was not aware of this until recently, but DanSteph has a new tool called Universal MMU, and I figured I'd present this as a possible option for the latter of the two subjects.

For the former (mission control interface), I would like to ask if this is where we should implement the simulated CapCom (like M$ FlightSim's ATC) or rather this should be done elsewhere.
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #16 on: July 22, 2007, 06:32:19 PM »

Well, lets see what dseagrav and lassombra think, for my part I'd like to see a "internal MCC interface" rather in the ProjectApolloMFD than as a DebugPrint line, mainly because it looks nicer. An additional voice interface would also be cool, of course.

The crew is simulated in the CSM itself; the crew status can be monitored and the crew count can be changed in the ProjectApolloMFD. For me this is fine for a Apollo 7 release, for proper EVA and LM support this needs to be extended, of course.

Cheers
Tschachim
Logged

dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #17 on: July 23, 2007, 02:04:50 AM »

The UMMU license is not compatible with the GPL, so we cannot use it unless we want to relicense the project. (The UMMU does not allow use unless your project is fully compatible with all of its features, which includes giving the crew jetpacks and parachutes. This restriction is not compatible with the GPL.) It's also not compatible with VS6, so we would have to force everyone working on the project to go buy new versions of VS.

The problem with using an MFD for communication is that you cannot "hear" the ground unless you are looking at the MFD. I wanted to use a text line because it's easiest to convert to text-to-speech later. The only ground voice the crew ever hears is the capcom, so we would only have to deal with one voice. As long as the TTS engine doesn't suck to hard it should work out.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #18 on: July 23, 2007, 10:17:21 AM »

Then in that case, why don't we do this a slightly different and hopefully better way...

  We can create the Virtual CapCom seperate from the MFD so that it can run the TTS stuff at all times.  We can then set up the MFD to access the Virtual CapCom's "buffered conversation" and display it, that way the transcript is easily accessable, but we're not limited to the MFD.  Additionally, we can have an option via one of the many Audio Switches that will turn on or off the seperate text-line display, which also accesses the Virtual CapCom's 'buffer'.  This way we have best of both worlds, both a running transcript via the MFD and a more immediate communication method via the text-line and TTS.  If this sounds acceptable, then I'll start work on that soon while I'm unable to work on the Virtual Cockpit (that computer is down in Cincinnati while I'm up in Cleveland working at NASA).
  In all honesty it shouldn't be too difficult to set up, mostly time consuming creating all the text-based communication lines with tokens to be replaced.  The rest will just be text parsing and writing to a file, followed by TTS/text-line/MFD interfaces that read from that file and 'speaks' to us. I figure that it will be easy to create a basic text file that you write lines from capcom to that way you have a transcript that is also legible to the computer.

Keep in mind though that there were many capcom's that did the mission....so having one voice is not quite accurate, but much easier to implement.
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #19 on: July 23, 2007, 11:18:42 AM »

Then in that case, why don't we do this a slightly different and hopefully better way...

There's a MCC routine in mcc.cpp that gets called once a timestep, and already does parts of AOS determination - That would be where you would put your code. Do it however you want, but make sure it's as event-driven as possible, that way we don't have to store times per-mission and handle failure cases and whatnot. I can clean up whatever you do later.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #20 on: July 23, 2007, 01:03:07 PM »

I was actually going to set up the following way....

One (or more) text file(s), possibly compiled into the code as a resource, but probably seperate to allow easy editing.  These store different text phrases that will be used in the mission, each defined by an ID of some sort, with provision for multiple, randomized phrases in the cases of common responses.  Within these phrases will be a method of defining tokens that will be replaces by such things as Spacecraft name, numerical values, etc.  Within the MCC code, I'll write a routine that is called to access the file(s) and find a specific phrase, whose ID has been passed in as a variable, along with any additional numerical values to be added to the phrase.  This routine will then print the phrase to the transcript file (a generic text-file that will also serve to record someones mission for later review) along with a sim-tymestamp and a flag character for use by whatever reads the file to tell it what kind of information the line contains.  This routine should be able to be called from anywhere within the Apollo code, so it will be up to you guys to place it at the proper events.  And of course, it will be affected by the audio subsystem panel controls....but maybe not at first.  At some point there will also be code written into the ProjectApolloMFD to provide display of the most recent lines in the transcript file.  Additionally, code will be incorperated to convert this text to speech (which, surprisingly enough, appears to be quite easy through the Windows API) and the text-line interface will be written, along with possible user-input recognition of keywords.

First I'm going to work on setting up a good format for the "phrase database(s)" and then set up some generic phrases.  Once I have a fairly robust identification method, I'll start incorperating the phrase parser and transcript writer into the MCC code.  Then I'll actually set about to working on the user-interface.
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #21 on: July 23, 2007, 03:14:37 PM »

This routine should be able to be called from anywhere within the Apollo code...

Don't do that. Please keep all MCC related things inside mcc.cpp, otherwise we'll have thousands of checks scattered everywhere for whether or not the MCC is active. Keep it in one place.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #22 on: July 23, 2007, 03:55:29 PM »

I may be missing something, but I fail to see what you mean by we need to check if MCC is active.  I figured that once the Capsule Communications code was implemented, it would be active all the time.

Anyway, there are definately ways to keep it all within one location, but it will require the code to be monitoring the simtime and capsule status, and I thought that was what you were trying to avoid when you said....
Quote
Do it however you want, but make sure it's as event-driven as possible, that way we don't have to store times per-mission and handle failure cases and whatnot.

Maybe I missed something here, could you explain what you were thinking?
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #23 on: July 23, 2007, 07:05:10 PM »

I may be missing something, but I fail to see what you mean by we need to check if MCC is active.  I figured that once the Capsule Communications code was implemented, it would be active all the time.
Not necessarily. It can (and should) be turned off when the user wants to do everything themselves - I.E. People who want to use IMFD, or fly non-normal-Apollo missions, or by US when we are debugging and don't want the interference, etc. The internal MCC will also be turned off whenever the external MCC is active.

Quote
Maybe I missed something here, could you explain what you were thinking?

I just meant don't rely entirely on the timer. Make a block of code for each MCC station, with a script of what that person would be doing at that phase of the mission. For each step of the script, watch for the event that person would be waiting for, then announce it and/or react appropriately. For example, during boost, the booster crew watches for S1C CECO. Instead of waiting for the "expected" time and blindly making an announcement, monitor the engine thrust level and make your announcement when it drops to zero. This keeps you from having to re-code your MCC if we change mission parameters,implement random failures, implement non-Apollo missions (Skylab, ASTP), implement distance-based voice lag, or something like that.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #24 on: July 23, 2007, 07:52:17 PM »


Not necessarily. It can (and should) be turned off when the user wants to do everything themselves - I.E. People who want to use IMFD, or fly non-normal-Apollo missions, or by US when we are debugging and don't want the interference, etc. The internal MCC will also be turned off whenever the external MCC is active.

I just meant don't rely entirely on the timer. Make a block of code for each MCC station, with a script of what that person would be doing at that phase of the mission. For each step of the script, watch for the event that person would be waiting for, then announce it and/or react appropriately. For example, during boost, the booster crew watches for S1C CECO. Instead of waiting for the "expected" time and blindly making an announcement, monitor the engine thrust level and make your announcement when it drops to zero. This keeps you from having to re-code your MCC if we change mission parameters,implement random failures, implement non-Apollo missions (Skylab, ASTP), implement distance-based voice lag, or something like that.


Ahh, now I understand.... but I'm not sure you understood what I meant by capcom code.  The capcom I was going to make is the a chunk of code that essentially creates CapCom's phrases.  It would then store these to a file.  Now within your MCC code you would call this code whenever an event is tripped and you would request the proper phrase.  Your capcom code would then "listen" to that file and when it detects a new phrase, it would handle displaying that to the user however the proper way to do that is.  I guess in proper terms, my code isn't so much CapCom as it is just a phrasebuilder.  In the immediate future, I never intended on doing anything that an in-game user would notice, that would be up to the ProjectApolloMFD and your internal MCC code. 

Perhaps I put too many ideas into my last post.  When I was talking about TTS and text-line stuff, that would go into your MCC code when you have it started.  And when I was talking about the running transcript in ProjectApolloMFD, that would be seperate from my phrasebuilder routines.  Both your MCC and the MFD could be controlled in whatever way they normally are, my routines that I'm working on are more of a background process.  Admittedly, they will probably eventually be merged into your MCC code since that's where the majority of the calls will be coming from, but until you create a project for it and start work on that I was going to write my stuff seperate.
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #25 on: July 25, 2007, 10:47:35 AM »

Admittedly, they will probably eventually be merged into your MCC code since that's where the majority of the calls will be coming from, but until you create a project for it and start work on that I was going to write my stuff seperate.

I'm not sure if I'm right, but reading dseagrav's post and looking at mcc.cpp (http://nassp.cvs.sourceforge.net/nassp/projectApolloSource/mcc.cpp?view=markup) it looks like the work already started and you should use the existing design. I think this is especially fine with your cool idea of a central transcript administration supporting multiple "clients" (MFD, DebugPrint line, etc.), but perhaps dseagrav could enlighten us here a little bit more...  Happy

There's a MCC routine in mcc.cpp that gets called once a timestep, and already does parts of AOS determination - That would be where you would put your code.

Cheers
Tschachim
Logged

Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #26 on: July 25, 2007, 12:37:04 PM »

that's odd...I can't see mcc.cpp

I've done an update and its not there.....hmmmm.....  when was it posted?
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #27 on: July 25, 2007, 12:43:36 PM »

when was it posted?

It exists since February this year, it's in Orbitersdk\samples\ProjectApollo.

Cheers
Tschachim
Logged

Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #28 on: July 25, 2007, 12:53:04 PM »

Yea, I was looking through the capitalized letters....and it's lowercase.  I have it.   Duh!
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #29 on: July 25, 2007, 01:49:30 PM »

I'm not sure if I'm right, but reading dseagrav's post and looking at mcc.cpp (http://nassp.cvs.sourceforge.net/nassp/projectApolloSource/mcc.cpp?view=markup) it looks like the work already started and you should use the existing design. I think this is especially fine with your cool idea of a central transcript administration supporting multiple "clients" (MFD, DebugPrint line, etc.), but perhaps dseagrav could enlighten us here a little bit more...  Happy

Well, it's everyone's project, so whatever happens is fine, as long as it works and isn't too ugly. I'm just trying to offer input, not direct the project.
I haven't hashed out all of the details yet myself, I just have a mental image of where I would like it to be.
That said, the script could be used for the ground as well, provided the ground does not have a person acting as their capcom. In that case, the ground software would be running the show, so it would have its own copy of the text file and send it as the capcom speech.

I totally encourage having a phrase database for the capcom. That would be far less work to localize later. We're going to have to organize a translation effort once the code gets banged out... I know we have at least French and German speakers here, I don't know what else. Of course, if a person is acting as the capcom, it is their responsibility to speak a language their crew can understand. ^_^

The reasoning behind the external MCC capability is simply that, if desired, some external process can turn off the internal MCC and substitute in anything they desire. The internal MCC should never become a limitation. Some people would like to play "what-if" scenarios or things like that, and the external MCC would allow them to make their own custom MCC to accomplish their goal without having to burden us with supporting their activity. The external MCC can be anything - a do-nothing routine that simply generates a debug log of capsule status, a totally automated program doing all of the tasks, a single person manning one (or several) virtual consoles, or even a set of real physical consoles installed in a classroom or museum. Of course, not all of this will be done before release, but that's my goal.


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