Meadville Space Center

Project Apollo - NASSP => Programming => Topic started by: lassombra on December 18, 2007, 03:21:07 AM

Title: Minimising or even removing the debug line.
Post by: lassombra on December 18, 2007, 03:21:07 AM
I know it's a useful line and that it can easily be used to give important messages to users.  The catch?  It is often used to slightly... less appealing uses.  One example is in the current telecom code, at high bitrate, it starts spewing out a ton of "measure this" messages, which ultimately are completely useless.  If they are useful, it is only to whoever is currently using them to follow their code.

What I propose is this:  We already have a module that is used to provide output and interface to the user not available through the panel.  We have the facilities, and even some example code now, already in place to easily create a debug string output ON the MFD.

It would be simple:

PAMFD would have a static member which would be a static char array of reasonable length.  It would then have a method that passed the reference to the array, much the same as the current oapiGetDebugString() method does.

The Saturn class would then have a reference to just such a method.  In the constructor function, that reference would be pointed to the MFD if possible.  If that fails, it would be a reference to the oapiGetDebugString() as before.  What it would do is allow debug data to be sent to the MFD instead of the command line, assuming the MFD is available.  If the data being output is important to the user, then output it to the user as we always have.  If it's important to be able to see it when the MFD is unavailable, then go ahead and use oapiGetDebugString();  If it isn't important, use the new pointer so that we can keep the bottom of the screen friendlier.

I will go ahead and code this up, but I'll wait to commit till I get a response as to whether this is something we want/would use.  If we don't, it won't be a waste of my time honestly, as the exercise is going to be used as practice for something else I'm going to do anyways, on another project.  I'm just offering to keep it available.

Title: Re: Minimising or even removing the debug line.
Post by: Tschachim on December 18, 2007, 12:41:57 PM
I second that, in my opinion oapiGetDebugString() should only be used to display severe technical problems (like "Telecom bind failed") or configuration problems (like disabled non-spherical gravity sources in VAGC scenarios), but not as normal user interface. In fact I removed a lot oapiGetDebugString() calls in the past and replaced them with a "proper" user interface, I didn't know that the telecom stuff uses that, perhaps it's just forgotten debug stuff and should be removed.

Using PAMFD to display stuff, which cannot (or wasn't) be displayed on the panel, is my preferred solution, too, in fact I did the PAMFD for that in the first place, namely to display the GET during prelaunch.


Title: Re: Minimising or even removing the debug line.
Post by: lassombra on December 18, 2007, 03:05:36 PM
well, as a test, I've made a member method in the Saturn that externally behaves just the same as oapiDebugString().  The method is called debugString, returns a char pointer to the beginning of an array, and allows reasonable length output.

Internally it is a dual function method (actually, it's not a method at all but a pointer).  If the MFD is activated, it points to a function in the MFD to write a debug line.  The MFD then provides additional functions such as "Freezing" the debug line so you can catch what it's saying if there's a lot of details.  It also allows you to clear the debug line.

When the MFD is not activated, it is set to point to the oapiDebugString() as normal, and prints to the debug string that the MFD wasn't activated.

I will go ahead and commit this, and then debug data should go to the MFD.  I moved all the debug data (not the error messages) from the Telecom to the MFD.  I don't think we have anymore debug strings right now, but if we get anymore, send them to the MFD instead of the bottom of the screen if you can reasonably do so.