Ok, that's checked in. Since I did change a lot of files, let me know if I broke anything in the process!

Note that you no longer need to check vessel class names to ensure it's a Saturn or whatever, as the connector code should automatically figure out whether it's a vessel you can connect to (right now that's the CSM and LEM).

Swatch, I'm not against excel sheets, infact I think it's a good idea, but we should come up with some kind of standard for them NOW before jc gets too far into his...

Secondly... incorporating the eoca into an mfd...

I know this is technically is about the checklist mfd, but we are at a point where we are gearing up for release and there is some real truth to the fact that the eoca as it is is not of much use IN orbiter.

I personally don't even comprehend the math, so I don't think I can pull it off, but maybe someone can?

Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit. Working on new method of calculating TLI.

Swatch, I'm not against excel sheets, infact I think it's a good idea, but we should come up with some kind of standard for them NOW before jc gets too far into his...

I absolutely agree.

Quote

Secondly... incorporating the eoca into an mfd...

I know this is technically is about the checklist mfd, but we are at a point where we are gearing up for release and there is some real truth to the fact that the eoca as it is is not of much use IN orbiter.

I personally don't even comprehend the math, so I don't think I can pull it off, but maybe someone can?

Once we add integration of excel for checklist, then integration from eoca may be very possible as well. I'm in the same boat as you though, I don't understand the math.

Would be so cool... a dream for me By the way, If I knew C++ I would have done an MFD directly. As I already mentionned I'd like EOCA would be part of the virtual MCC.

But guys, no problem for the maths. I'm far from an expert but I learned a lot on space mechanics for 1 year and could help you. By the way the most difficult for me is less math than the logics on how to get the calculator running. Something like:"One table should compute while the other one is in stby and then the computation should starts only if the computation of a third table has stopped..." and so on and so on...Sometime I wonder if it woulndn't be quicker to learn C++...

Would be so cool... a dream for me By the way, If I knew C++ I would have done an MFD directly. As I already mentionned I'd like EOCA would be part of the virtual MCC.

But guys, no problem for the maths. I'm far from an expert but I learned a lot on space mechanics for 1 year and could help you. By the way the most difficult for me is less math than the logics on how to get the calculator running. Something like:"One table should compute while the other one is in stby and then the computation should starts only if the computation of a third table has stopped..." and so on and so on...Sometime I wonder if it woulndn't be quicker to learn C++...

Allthough EOCA is especially designed for vAGC, it should work for any orbiter vessel. The only thing is to convert the deltaV's into the orbiter usual ecliptic frame of reference.in fact, for a standard vessel, so in standard mode, the components of delta V's are useless. but EOCA can give you the total delta V instead, and the proper euler angles for burn orientation. Then any of the orbiter autopilot may perform the burn. Then, with the burn attitude + the time of ignition + the delta V and/or the burn duration, all given by EOCA, you could do the maneuver even with the delta glider for example.

At first I would like to thank all here for picking up this very important feature, keep it up! Since I'm finally resumed the work on the last remaining CSM systems, I only would like to make some small comments about the checklists.

The first thing is the Quickstart Mode. Except some "specials" like the throttleable SPS engine, in Quickstart Mode some currently "hardcoded checklists" are executed automatically at certain events by using the SwitchTo-function of the various switch classes. The original plan was to replace that sometime by easily editable config files like the excel checklists discussed here. This is nothing mandatory, but perhaps we can keep that in mind while working on this checklist MFD. To achieve that there needs to be a possiblity to load and somehow execute checklists independant of a MFD so that the Quickstart Mode isn't broken when the user doesn't activate the MFD, for example by using the always loaded ProjectApolloConfigurator or by doing that in the Saturn/LM itself and using common Checklist, ChecklistStep, ChecklistLoader etc. classes or something like this. Also the checklists would need to be able to be started by certain events like for example tower jettison, earth orbit insertion or changes of the internal systems state (Saturn::systemsState). The "ideal" situation would be that the realism levels are just a setting how checklists are handled, automatically in Quickstart Mode, manually with the MFD in Standard/VAGC Mode or "in between" like every switch is highlighted automatically until the user toggles it and then the next switch is highlighted etc.

I don't want to spoil the work already done, but I wonder if it's a good idea to put the checklists in a new MFD instead of adding one or more additional screens to the existing one. Programming wise 2 MFDs are fine for me, but the user needs to activate 2 MFDs and can mix them up. I can already see posts like this in my mind: "I can't find the checklists..." - "You need to use the Project Apollo Checklist MFD" - "But I already tried Project Apollo MFD" - "No, the other MFD..." etc, I hope you can imagine what I mean...

Again just my , I'm very happy that you guys are working on this important feature!

I don't want to spoil the work already done, but I wonder if it's a good idea to put the checklists in a new MFD instead of adding one or more additional screens to the existing one.

I was wondering that, and can see arguments for both sides. If it does start out in a separate MFD it shouldn't be too hard to bolt onto the Project Apollo MFD later instead, since most of the code would be the same in either case (e.g. reading checklists, displaying them, processing keys).

Yes. Some authors may have specific restrictions on using code in commercial apps, such as providing credit in documentation or sending them an email first, but all code can be used for free.

On the subject of structure:

I agree that the main checklist handling code should be seperate from a specific MFD. But I do feel the interface should be integrated into ProjectApollo MFD. I'm all for making a Swiss-Army Knife MFD for Apollo. It's simpler to use and easier to explain.

I see three main components here...1. Excel API - used to extract information for the Checklist Handling2. Checklist Handling - This handles events and automation, as well as always being accessable.3. MFD Interface - This is just for the display of the checklists, and it communicates with the Checklist Handling program for its information.

Swatch, I'm not against excel sheets, infact I think it's a good idea, but we should come up with some kind of standard for them NOW before jc gets too far into his...

Well, in response to this, I can only say that my ambition for compiling the Ap7 vAGC Flightplan (I wish there was a better name for it now ) was in no way meant to be formatted a specific way for MFD use (if that is what you are referring to), and I didn't expect to have to change the format either. I made it to add a sense of organization and direction to flying the mission historically, (or at least somewhat historically for the time being) and as a one-stop reference for procedures in the mission, instead of having to open multiple docs, consult the forum, or sift through poorly legible 1960/70's documentation.

I totally respect what you guys are doing with the Checklist MFD, and I hope it goes well for those whom are developing it. However, in my preference (as was another reason for my designing the FP) I was hoping to make this flightplan in hopes that, once completed, it could be printed and referred to just as the astronauts had their own paper flightplans, procedures, and manuals they carried aboard on each mission. I know this flies in the face of what you are intending the MFD for, but again, this is just my preference to promote realism and is always going to be how I personally fly each mission.

If you all wish, you may use the FP in any format you wish for the MFD, that is fine by me. Just understand that as I continue to develop it that it will be in much the same format that it is now. I don't want to discredit the fantastic work that Christophe did in adding the procedures in the "docs" folder, (and would actually suggest those, as well) which are even more detailed than the "simplistic" versions of the procedures included in the FP, some of which are based from those docs. I hope I didn't come off to brash with all this, I just hope that it clarifies some things. Thanks.

jc, you misunderstood I think... or somebody did... In no way do I want to replace or modify what you're doing... I like what you're doing. Yours did however present a good example of what we could do with excel, and it would be Christophe's checklists that would be modified in my mind, since his are the more historically accurate checklists and yours are flightplans. So don't worry, you keep doing your thing, we want something someone can print off.