Update TransX development

[Enjo]

On the other hand, you could already try the dynamic prograde vel optimisation while modifying the ejection date in this second dll. The task boils down to finding such an intersection, where it coincides with the line of nodes. You can find solutions quite fast.
:goodnight:

 

[Enjo]

I also have another one - we could have a gobal setting - minimize all - which would automatically minimize all three velocities upon any change of the date.

So, in the Eject plan view, that would be an additional variable -not an adjustment setting- that says "Auto-min DV" with "Yes" and "No" as the adjustment settings to choose from.
If it is set to "Yes", TransX will auto-set the Pro, Pl.ch. and Out, to find a minimum dV solution for that particular date of departure.

I'm starting to think that after all for the multidimensional optimisation it would be better if there was an additional, individual adjustment setting for each variable: Ej.Date-min, which only when selected, would passively react on date change and minimize the variable, along with other variables that also have this setting selected. This way you could decide if you want to:
1) Find the solution with least dv needed, hunting for an intersection at the line of nodes - prograde to Ej.Date-Min
2) Find the solution with moderate dv needed, having some date margin - prograde & change plane to Ej.Date-Min
3) Just wanna get there - prograde, change plane & outward vel to Ej.Date-Min

 

[dgatsoulis]

On the other hand, you could already try the dynamic prograde vel optimisation while modifying the ejection date in this second dll. The task boils down to finding such an intersection, where it coincides with the line of nodes. You can find solutions quite fast.
:goodnight:

The Auto-Min setting on the Prograde doesn't "unlock" when you switch back to one of the other adjustment settings.
I setup an Earth-Mars plan, set Prograde to Auto-Min and cycled through the dates with the "Rough" setting.
The Auto-Min on the Prograde quickly found the correct DV for an arrival at a node.
Then I switched the Prograde back to Coarse and tried to change the date and the Prograde behaved as if it was "stuck" in Auto-Min.
It behaved like this even when I hit Reset on the Prograde.

 

[Enjo]

I know. It's hardcoded for now. The feature that I've just described above requires slightly more coding.

 

[dgatsoulis]

I know. It's hardcoded for now. The feature that I've just described above requires slightly more coding.

Oh ok, I thought it was misbehaving.
Next I'll try the Auto-Min on the slingshot angles. Does it take into account the Orbits to Icept setting?

 

[Enjo]

I don't know. It should...

 

[Enjo]

The Auto-Min setting on the Prograde doesn't "unlock" when you switch back to one of the other adjustment settings.
...
Then I switched the Prograde back to Coarse and tried to change the date and the Prograde behaved as if it was "stuck" in Auto-Min.
It behaved like this even when I hit Reset on the Prograde.

After thinking about this more, it turned out that I had no choice but implementing this system the way you described.
So you can make the variables to be passively optimised by the Ej.Date by simply leaving them with Auto-Min adj. setting. However the optimiser still lacks the multidimensional routine as it works on each variable in the list separately. But only now it makes sense to concentrate on this feature, since we have a working system.

I also have to work on the performance a bit, but I have some ideas already.

Other than that, I simplified the mfdvartypes.cpp file greatly, saving 90 lines of code. Be sure to update your local working copy before continuing.

 

[Ripley]

I cannot help you as a programmer, but I'm closely following this development speechless and amazed.

The bug I wrote about showed up once more, but I still had a mess of various TransX dlls.
Must have been that, because after cleaning my Modules\plugin folder up, I never had it once (crossing fingers), using alternatively "the good ol'one", the "buy 1 get 2" version by dgatsoulis, and these development dlls by Enjo.
If I see it again I'll report here.

I made myself this "TransX switcher" cmd to rule problems out:

@echo off

:START
cls
dir D:\orbiter100830\Modules\Plugin\transx*.dll
echo.
echo            ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
echo            ³                                                   ³
echo            ³           Scegli la versione di TransX            ³
echo            ³                                                   ³
echo            ³          1. Originale  (297 Kb)                   ³
echo            ³          2. Dgatsoulis (2 x 317 Kb)               ³
echo            ³          3. Enjo       (152 Kb)                   ³
echo            ³          4. Esci                                  ³
echo            ³                                                   ³
echo            ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
goto CHOOSE


:CHOOSE
set choice=
set /p choice=Digita la tua scelta:

rem rimuove tutti i caratteri dalla variabile, tranne il primo. Se la scelta non e' valida, torna all'inizio

IF NOT '%choice%'=='' SET choice=%choice:~0,1%
IF '%choice%'=='1' GOTO CHOICE1
IF '%choice%'=='2' GOTO CHOICE2
IF '%choice%'=='3' GOTO CHOICE3
IF '%choice%'=='4' GOTO END
goto CHOOSE

:CHOICE1
copy D:\ORIG_transx.dll D:\orbiter100830\Modules\Plugin\transx.dll /y
goto CHECK

:CHOICE2
copy D:\Dgats_transx.dll D:\orbiter100830\Modules\Plugin\transx.dll /y
copy D:\Dgats_transx2.dll D:\orbiter100830\Modules\Plugin\transx2.dll /y
goto END

:CHOICE3
copy D:\Enjo_Transx.dll D:\orbiter100830\Modules\Plugin\transx.dll /y

:CHECK
if exist D:\orbiter100830\Modules\Plugin\transx2.dll del D:\orbiter100830\Modules\Plugin\transx2.dll

:END

 

[Enjo]

dgat, I integrated your changes:
1. Total dV of the Eject Plan, and
2. Circ Delta
Turned out to be 5 minutes of work ... :facepalm:

I also worked on the performance of the optimiser and on the multidimensions. Unfortunately I found it to be beyond me a bit for the amount of time that I have. I have everything written on paper, which for my managers who only do "conceptual work" would be their final success, but I know that it's far from it. Maybe I'll return to it another time. For now I left it in a readable form, which you can see here. I think it's a good starting point for the future.

Now I'll work on the automated orientation.

 

[dgatsoulis]

Just downloaded the latest dll. I did a quick test now, but I'll have time to do more extensive testing tomorrow.
The Auto-min seems to be working ok and leaving it on and changing the date is probably the fastest way to get a good eject plan, even for TransX veterans. -Amazing job there Enjo!

The total DV is a very quick way to compare between plans and decide which one to use, thanks for implementing it and for the Circ. Delta; No more setting up maneuvers at arrival, to find the dV for orbit insertion. :thumbup:

The "angle" feature request, has now become redundant. The visual cue of the trajectory and the speed with which the user can test, find and compare solutions are more than enough.

I do have one more feature request. (I'll keep asking for those, until you tell me to shut up... )

How difficult would it be to add a "TOF: % days" line, right below the Enc. MJD, in the Eject plan?

The reason I ask for this, is because other than the DeltaV, the TOF is the next criterion for plan selection.
Yes, know that it's a simple mental subtraction (or with a calculator in most cases), but I think it would be another cue, helping the user to decide between plans.

I tried to implement this myself, in the version I uploaded on OH last week, but I couldn't get it to work.
Normally, it should be simply something like this:

double tof = arrmjd-m_ejdate;

That's in the basefunction.cpp, that's where the "arrmjd" (arrival mjd) is calculated.

Yet it doesn't seem to work. The "arrmjd" is calculated correctly, but the m_ejdate, which should be the date the user chooses in the variables, always stays the same; equal to the "now" mjd of the scenario.

If you think that it is something that you can easily add (another 4-5 mins), I think it would be great. If it's something that takes longer than that, don't bother, all it takes is a quick subtraction by the user.

 

[Enjo]

Just downloaded the latest dll. I did a quick test now, but I'll have time to do more extensive testing tomorrow.
The Auto-min seems to be working ok and leaving it on and changing the date is probably the fastest way to get a good eject plan, even for TransX veterans. -Amazing job there Enjo!

No problem. Thanks for testing!

I've found a solution to the relatively poor quality of Auto-Min, which could have only been resolved by manually switching between Pro and Plane vels and firing their own Auto-Min - now the Ej.Date also has its own Auto-Min, which when selected (and kept pressed) will continuously minimize the registered variables. So the use case is:
1) Finding a rough solution with Date Coarse/Rough. When satisfied:
2) Switching Date's setting to Auto-Min and keeping it pressed for some short period of time

I do have one more feature request. (I'll keep asking for those, until you tell me to shut up... )
How difficult would it be to add a "TOF: % days" line, right below the Enc. MJD, in the Eject plan?

Done.

That's in the basefunction.cpp, that's where the "arrmjd" (arrival mjd) is calculated.
Yet it doesn't seem to work. The "arrmjd" is calculated correctly, but the m_ejdate, which should be the date the user chooses in the variables, always stays the same; equal to the "now" mjd of the scenario.

Tricky, ain't it?
the m_ejdate of the basefunction is I think a leftover from early phases of TransX, where the Major Ejection plan could have been the only plan available (remember that even the Encounter MFD had to be integrated into TransX first!). Therefore the m_ejdate of basefunction appears to have no functionality and its responsibilities are now taken by "majejectplan".

This is how the code looks now. Feel free to move the variables around where you like them:

void majejectplan::wordupdate(oapi::Sketchpad *sketchpad,int width, int height, basefunction *base)
{
    int linespacing=height/24;
    int wspace=width/19;
    int wpos=9*wspace;

    if (ratioorbit>0) //Don't show if View: Sling Direct
    {
        TextShow(sketchpad,"Pe/Pl Rad:",0,15*linespacing,ratioorbit);
    }
    else
    {
        double tti = base->GetTimeIntercept();
        double ejt = m_ejdate;
        double numDays = tti - ejt;
        TextShow(sketchpad,"TOF (days):",wpos,22*linespacing,numDays);
        double totaldv=length(ejectvector);
        if (totaldv>0.1)
        {
            //bottom right, watch both glass cockpit AND panel view for correct placement.
            TextShow(sketchpad,"Total DeltaV:",wpos,23*linespacing,totaldv);
        }
    }
}

double basefunction::GetTimeIntercept()
{
    double intercepttime=primary.gettimeintercept();
	double arrmjd=oapiTime2MJD(intercepttime);
	return arrmjd;
}

 

[Enjo]

dgat: since you increased the size of the manouvre cross, when can I find it in the code?

 

[dgatsoulis]

<Bigger cross in Target view>
-Graph.cpp
line 278

TransXFunction::SelectDefaultPen(sketchpad,TransXFunction::Green);
	const int crossSize = [B]5[/B];
	sketchpad->MoveTo(xpos - crossSize, ypos - crossSize);
	sketchpad->LineTo(xpos + crossSize, ypos + crossSize);
	sketchpad->MoveTo(xpos - crossSize, ypos + crossSize);
	sketchpad->LineTo(xpos + crossSize, ypos - crossSize);
	return length(trtarget);

 

[Enjo]

I'd like to make a small announcement.
I give up with TransX for now. I've been working on it intensively, so I'm a bit tired, the code is hard for me to understand, and my wife is going back from her holiday. I will need (and want) to spend some time with her. I still have one day left before the "deadline", so I'll spend it on documenting my changes in readmes and on preparing the release package.

There's still an unresolved issue of the 2nd TransX instance from dgat, which would have to be solved by conditional compilation, but I can't do it this week anymore. Maybe on Christmas or so.

 

[dgatsoulis]

Thank you very much for all the work you've put into this Enjo. :tiphat:

TransX is now better than ever thanks to your additions. The speed with which the user can find a trajectory solution and the ease with which one can compare solutions has increased dramatically. :thumbup:

There's still an unresolved issue of the 2nd TransX instance from dgat, which would have to be solved by conditional compilation, but I can't do it this week anymore. Maybe on Christmas or so.

If this is about having a second instance of TransX that doesn't interfere with the first one, and saves the plan in the scenario properly, the changes that are needed are very minor.

1.Color change TransXfunction.cpp :

void TransXFunction::initpens(void)								//(rbd+)
{
	if (!pens[Green])	pens[Green]		= oapiCreatePen(1, 1 , RGB(0x00, 0xFF, 0x00));	// Green - stands for craft
	if (!pens[Blue])	pens[Blue]		= oapiCreatePen(1, 1 , RGB([B]0xFF, 0x33, 0x33[/B]));	// Blue - stands for planet //Turn to Red for second instance
	if (!pens[Yellow])	pens[Yellow]	= oapiCreatePen(2,	  1	, RGB(0xCD, 0xCD, 0x00));	// Bright yellow - hypos
	if (!pens[Red])		pens[Red]		= oapiCreatePen(1, 1 , RGB(0xFF, 0x00, 0x00));	// Bright red - unused, but danger
	if (!pens[Grey])	pens[Grey]		= oapiCreatePen(1, 1 , RGB(0xC0, 0xC0, 0xC0));	// Light Grey
	if (!pens[White])	pens[White]		= oapiCreatePen(1, 1 , RGB(0xFF, 0xFF, 0xFF));	// Bright white - unused
	if (!brush[Green])	brush[Green]    = oapiCreateBrush (RGB(0x00, 0xFF, 0x00));
	if (!brush[Blue])	brush[Blue]		= oapiCreateBrush (RGB([B]0xFF, 0x33, 0x33[/B])); //This isn't used, but just in case
	if (!brush[Yellow])	brush[Yellow]	= oapiCreateBrush (RGB(0xCD, 0xCD, 0x00));
	if (!brush[Red])	brush[Red]		= oapiCreateBrush (RGB(0xFF, 0x00, 0x00));
	if (!brush[Grey])	brush[Grey]		= oapiCreateBrush (RGB(0xC0, 0xC0, 0xC0));
	if (!brush[White])	brush[White]	= oapiCreateBrush (RGB(0xFF, 0xFF, 0xFF));
}

Name change in display. TransX.cpp

// Called by Orbiter when a screen update is needed
bool TransxMFD::Update (oapi::Sketchpad *sketchpad)
{
	Title (sketchpad, [B]"TransX(2) MFD"[/B]);

Name change. Affects the way the plan is saved in the scenario. (You can now save TransX(2) independently).

globals.cpp

DLLCLBK void InitModule (HINSTANCE hDLL)
{
	static char name[] = "[B]TransX(2)[/B]";
	MFDMODESPECEX spec;
	spec.name    = name;
	spec.msgproc = TransxMFD::MsgProc;
	spec.context = NULL;
	//Code contributed by Dave Robotham
	ifstream kstream;
	kstream.open("config\\[B]transx2.cfg[/B]",NULL);

 

[Enjo]

OK, thanks very much. It's easy. I'll do it.

 

[Interceptor]

Hey Enjo, in the readme it says the surface base feature is some what broken,so do I need to use the encounter mfd along with it to get the surface base option to work right?

 

[dgatsoulis]

do I need to use the encounter mfd along with it to get the surface base option to work right?

Same as in the previous versions of TransX. You need to open MapMFD, target the base and then select "Draw Base" → "Yes" on the Encounter View of TransX.

You will know that the base has been selected by the orange dotted line on the planet/moon and the "Off plane Dist" and "Pe Distance to Base" lines that will appear on TransX.

 

[Enjo]

I'm happy that somebody reads those readmes

I didn't quite understand this text myself to be honest. Dgat: from your reply I understand that this information is now obsolete, right?

 

[dgatsoulis]

I'd say yes, that info is now obsolete.

The info on the readme that Pete was talking about is this:

Some functionality from the old MFD's Encounter view (surface bases) is presently lost. Use the Encounter MFD for now as a workaround.

I don't know how the old TransX used to work with surface bases, but for the past 8 years that I have been using it, the functionallity is the same; as I described in the previous post.