Update TransX development

[Enjo]

And right after that:

Auto-MakeMoney
:rofl:

 

[blixel]

And right after that:
Auto-MakeMoney
:rofl:

Careful. We don't want to turn TransX into a "monkey-push-button, Monkey-go-to-mars end-game"

In all seriousness though, I second the notion. I believe it's more realistic to program in what you want to do, and then have the computer carry out the instruction exactly on time.

 

[Enjo]

Careful. We don't want to turn TransX into a "monkey-push-button, Monkey-go-to-mars end-game"

In all seriousness though, I second the notion. I believe it's more realistic to program in what you want to do, and then have the computer carry out the instruction exactly on time.

There, there...
I'm not sure if I really want to implement the Auto-Burn functionality. I'll think about it later. First, in the next iteration, I'd like to create a generic and simple cross-MFD (or rather cross-module) messaging API, so that they can communicate with each other, like TransX with Launch MFD in the Escape Plan, or TransX with BTC MFD in the Target View. From the technique point of view, it will be similar to HUDDrawer SDK.

As for the Auto-Center functionality, since there were no complaints so far, I will prepare the release soon. But before that, on the code level, I'd like to remove one remaining bottleneck, that has to do with gravitational body selection from the list of all bodies in the planetary system. Some clever caching has to be performed there. I've already laid down tracks for this change.

-I had the spacecraft oriented prograde ( with the default Orbiter AP "]" ) and I entered a pure prograde burn of 3000 m/s. When I disabled the AP and pressed "Auto-Center™", the spacecraft changed its orientation to "Horizontal level" and centered the green x in the target view.
It's not that big a deal, it just seems unnecessary.

After thinking bit of about it, most of the TransX' burns are close to Prograde and Retrograde orientation, and as such the user will want to directly skip from the Prograde AP's orientation to Target View's orientation, which therefore should share the same target bank, and that's how it is done now. Looks more natural. Let's just remember that the 0* target bank ("Hold Level") was needed for Launch MFD's AP to get the most of the lift that the wings can give.

 

[dgatsoulis]

After thinking bit of about it, most of the TransX' burns are close to Prograde and Retrograde orientation, and as such the user will want to directly skip from the Prograde AP's orientation to Target View's orientation, which therefore should share the same target bank, and that's how it is done now. Looks more natural. Let's just remember that the 0* target bank ("Hold Level") was needed for Launch MFD's AP to get the most of the lift that the wings can give.

Now that I've tried it for a couple of missions, it is no problem to remember to have the "wings level" before pressing the auto-center. If not, it simply wastes a bit of RCS fuel. Setting the burn ~1 m/s "short" with BTC, disabling the auto-center and finishing with linear translation works like a charm.

 

[Linguofreak]

Careful. We don't want to turn TransX into a "monkey-push-button, Monkey-go-to-mars end-game"

Actually, what would be nice would be "Monkey push button, all the other monkeys go to Mars, then monkey fly own spaceship to Mars" (in other words, the user can fly his own spacecraft while the other vessels in the scenario auto-execute pre-planned maneuvers without user input), which would have "Monkey push button, monkey go to mars" as a prerequisite.

 

[Enjo]

Actually, what would be nice would be "Monkey push button, all the other monkeys go to Mars, then monkey fly own spaceship to Mars" (in other words, the user can fly his own spacecraft while the other vessels in the scenario auto-execute pre-planned maneuvers without user input), which would have "Monkey push button, monkey go to mars" as a prerequisite.

Guys, come on already. Maybe Steve just had a bad day when saying that. Undoubtedly he's put a lot effort and high class math into TransX. What we do now are just hacks compared to that. Let's get constructive here and not pick on words.

 

[Enjo]

TransX-Launch-BTC-Messaging combo!

If y'all ain't tired of me already, I'm sure you'll like the attached combo.

Through a simple ModuleMessaging library, the TransX is able to send data to LaunchMFD and BTC MFD.

Launch MFD:
In TransX, setup a proper Escape Plan, as described in Launch MFD manual, section Target Inclination, then in Launch MFD open the Target input with Shift+T, and enter "tx" or "transx" (case insensitive) to obtain the inclination and LAN values displayed by TransX

BurnTimeCalc MFD:
TransX exposes DV and Time to burn in both views: Escape Plan and Manoeuvre. They can be captured by BTC with Shift+G (as Get). Of course, you need to arm the MFD immediately, as the captured time isn't decremented.
You'll also notice, that I've extended the MFD with MFDButtonPage. It turned out that the MFDButtonPage is missing some functionality, disallowing its button handlers to return false, so some original BTC UI functionalities won't work, but I'll fix it before making a release.

 

[blixel]

BurnTimeCalc MFD:
You'll also notice, that I've extended the MFD with MFDButtonPage. It turned out that the MFDButtonPage is missing some functionality, disallowing its button handlers to return false, so some original BTC UI functionalities won't work, but I'll fix it before making a release.

Can you leave the EXT button on the main page please? I use it all the time. I never use UNT (which just switches units to feet/pounds), and I never use OS or ST. Perhaps take an impromptu poll to see which BTC buttons most Orbinauts use least frequently.

http://strawpoll.me/990809

 

[aldarion]

Wow! Great! I will test it tomorrow.
I have the question. Why the arm button cannot be executed automatically after importing the data into btc?

Wysłane z mojego GT-I9100 przy użyciu Tapatalka

---------- Post added at 20:05 ---------- Previous post was at 19:58 ----------

And what do you think about exporting to btc the DV - 1m/s instead of simple DV?

 

[blixel]

I have the question. Why the arm button cannot be executed automatically after importing the data into btc?

I'm wondering the same thing. And is it really better to have an invisible key press (SHIFT+G) vs. just having another button on Page 2 that imports the data?

 

[Enjo]

Wow! Great! I will test it tomorrow.
I have the question. Why the arm button cannot be executed automatically after importing the data into btc?

I'm wondering the same thing.

And I was wondering if there's anything against it. Done now.

And what do you think about exporting to btc the DV - 1m/s instead of simple DV?

That's what I do in Manoevre mode. Should I also do the same in the Escape Plan, although the Auto-Center isn't used there, hence there's nothing to spoil the view?

Can you leave the EXT button on the main page please? I use it all the time. I never use UNT (which just switches units to feet/pounds), and I never use OS or ST. Perhaps take an impromptu poll to see which BTC buttons most Orbinauts use least frequently.

Sure, and thanks for the poll.

And is it really better to have an invisible key press (SHIFT+G) vs. just having another button on Page 2 that imports the data?

You could say the same about every other button in the MFD. The only difference is, that you're not accustomed to what you see. Plus, I've made the buttons extensible. What if somebody had a good idea but had no chance to add it to the MFD because all of the button placeholders were already taken?
[EDIT]
Also, features which have no buttons access, are completely inaccessible through External MFD windows.

It turned out that the MFDButtonPage is missing some functionality, disallowing its button handlers to return false, so some original BTC UI functionalities won't work, but I'll fix it before making a release.

After re-reading Orbiter SDK docs, I reckon that there's nothing wrong in MFDButtonPage and the BTC's UI should work as before.

 

[Ripley]

Hi Enjo.

In your "TransX-Launch-BTC-Messaging.zip" file (attached in this post) there is a dll called "BurnTimeCalcMFD.dll", while the dll that comes with the latest "BurnTimeMFD 2013.11.28", recently modified by dgatsoulis, is called "BurnTimeMFD.dll".

I thought you were talking about this latest BurnTimeMFD. Did I get it wrong?

 

[Enjo]

Indeed. The .dll is traditionally named BurnTimeMFD.dll, though the addon's traditional name is "BurnTimeCalcMFD (BTC)". I'll update my project settings.
Thanks for catching it.

 

[aldarion]

I have made some tests, and.. awesome work! :thumbup:

I have noticed a few things though:
1. When in target view and pushing var button I see many "strange" variables which should not be visible in this view, I think.
2. Total dv and auto min in manoeuvre mode. Is it possible?
3. Is the alt value properly imported from trnasx into the launchmfd? I think I set 200 km in transx and it was 220 km in launchmfd.
4. Transx losing base information bug - can it be corrected?
5. Launchmfd with huddrawer is not working now.

3 again
The value is not imported at all (it is 220 always I think). I think that the Pe distance from transx could be converted into alt value in launchmfd.

 

[Enjo]

Thanks for testing and feedback!

1. When in target view and pushing var button I see many "strange" variables which should not be visible in this view, I think.

Yeah, I've noticed this too. I'll see what I can do.

2. Total dv and auto min in manoeuvre mode. Is it possible?

It is. I'm experimenting with it. So far I can already tell that it won't work for a lunar transfer, at least not in the current form.

3. Is the alt value properly imported from trnasx into the launchmfd? I think I set 200 km in transx and it was 220 km in launchmfd.
The value is not imported at all (it is 220 always I think). I think that the Pe distance from transx could be converted into alt value in launchmfd.

Could be done.

4. Transx losing base information bug - can it be corrected?

I'll be fixing original bugs later.

5. Launchmfd with huddrawer is not working now.

Ooops...

I have the question. Why the arm button cannot be executed automatically after importing the data into btc?

Actually there was a reason against it: when you obtain values from Manoeuvre mode with negative time, you can't immediately arm the auto burn, because this means immediate start of burn. In the attached version, in case of negative time, the input time is completely ignored and auto burn is not armed.
Note the change of the DLL's filename back to the original, traditional name.

 

[dgatsoulis]

I'll just post my two cents about a couple of aldarion's points.
I'll write about BTC and LaunchMFD connection with TransX later this weekend, when I've had the time to test.

1. When in target view and pushing var button I see many "strange" variables which should not be visible in this view, I think.

When in Target View all the variables are "open" to you. This is has been in TransX at least since 2006 (I don't recall how it was before).
The necessary variables are only the ones concerning the burn, so in this case you'd need:
"Maneuver mode" (On or Off)
"Base Orbit" (Update)
"Prograde"
"Date"
"Pl.Change"
"Outward"
"Auto-Center™"
Everything else is irrelevant. Not Enjo's doing, but it would be nice if the variables of target view could be restrained to just those.

2. Total dv and auto min in manoeuvre mode. Is it possible?

You can already see the total dv in maneuver mode. You just have to be in Target View. (The "DeltaV" above the "T to Manvre"). You still have access to the burn variables, but you also have access to every other variable. So again, it would be nice if those could be restrained.

For the Auto-Min, I am not sure how it would be useful, even if it could be easily implemented.
Perhaps it could work if the target was in the same stage as the maneuver, but sometimes (a great many of them) you make a maneuver on stage1 to affect your closest approach on a target that may be one , two or even several stages away.
Also, you may not even want to minimize the closest approach, just to hit a certain value of distance and inclination relative to body A, in order to arrive at body B after a sling.

IMO there is absolutely no need to implement Auto-min in maneuver mode.
Of course, this is completely up to Enjo.

 

[aldarion]

After rethinking I agree. The auto min in maneuver mode is not needed.

 

[blixel]

In the attached version, in case of negative time, the input time is completely ignored and auto burn is not armed.

Great update Enjo. Something I have always noticed about BTC is that if you input the time that you get from TransX (Begin Burn), BTC will always start the burn late. I don't know why.

If you look at this screenshot, you'll note that BTC is wanting to start the burn about 1.86 seconds after the Begin Burn time.

This isn't a huge problem when you're targeting a large object like the moon. You can "clean it up" with translation. But if there's a way to fix the timing discrepancy, it would make things more accurate - especially when targeting smaller and faster moving objects.

Here's the scenario I'm using to test this.

BEGIN_DESC
Deltaglider in LEO ready for TLi burn.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 55723.7754137836
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-Earth
END_FOCUS

BEGIN_CAMERA
  TARGET GL-Earth
  MODE Cockpit
  FOV 50.00
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_MFD Left
  TYPE User
  MODE TransX
  Ship  GL-Earth
  FNumber 2
  Int 0
  Orbit True
  Vector  4906556.54733 410766.934575 4332446.81509
  Vector  -5128.00292497 -546.337468282 5858.166644
  Double  3.98600439969e+014
  Double  55723.7753848
  Handle Earth
  Handle NULL
  Handle Moon
Select Target
 0 Moon
Autoplan
0 0
Plan type
0 0
Plan
0 0
Plan
0 0
Plan
0 0
Select Minor
 0 None
Manoeuvre mode
0 1
Auto-Center™
0 0
Base Orbit
0 0
Prograde vel.
 4  3131.78652186
Man. date
 7  55723.7825501
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 0
Scale to view
0 0
Advanced
0 0
Finvars
  Finish BaseFunction
  Int 5
  Orbit True
  Vector  368652624.768 33167042.9406 50389951.7719
  Vector  -898.430697088 -80.6079082106 -135.190316214
  Double  4.90279493298e+012
  Double  55722.7777232
  Handle Moon
  Handle NULL
  Handle NULL
Select Target
 0 None
Autoplan
0 0
Plan type
0 1
Plan
0 0
Plan
0 2
Plan
0 0
Select Minor
 0 None
Manoeuvre mode
0 0
Auto-Center™
0 0
Base Orbit
0 0
Prograde vel.
 1  0
Man. date
 1  55723.7754126
Outward vel.
 1  0
Ch. plane vel.
 1  0
Intercept with
0 0
Orbits to Icept
0 0
Graph projection
0 0
Scale to view
0 0
Advanced
0 0
Draw Base
0 0
Finvars
  Finish BaseFunction
END_MFD

BEGIN_MFD Right
  TYPE User
  MODE TransX
END_MFD

BEGIN_SHIPS
GL-Earth:DeltaGlider
  STATUS Orbiting Earth
  RPOS 4893714.08 409399.17 4347073.96
  RVEL -5145.326 -547.808 5842.815
  AROT -0.79 20.09 -5.06
  RCSMODE 2
  PRPLEVEL 0:0.554057 1:0.993709
  NAVFREQ 166 484 0 0
  XPDR 0
  TRIM 0.033887
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

 

[Enjo]

Let's say that I'll think about the Auto-Min in Manoeuvre mode later then. I only see that it can be done.

Great update Enjo. Something I have always noticed about BTC is that if you input the time that you get from TransX (Begin Burn), BTC will always start the burn late. I don't know why.

That's because I only pass the Time to Manoeuvre, and not the Time to Burn. The latter is calculated by both MFDs independently. The question is which one is right. Some close code inspection is needed here. I flag it as an original bug, hence something to do later.

Now I'll be focusing on releasing the latest changes, regarding ModuleMessaging (including obtaining altitude from TransX), and fixing what I've broken so far. The Launch MFD + HUDDrawer bug is gone. I was linking the MFD against an older version of the library. I have a new PC and haven't prepared a full blown development environment yet.

 

[Zachstar]

Can I haz TransX for KSP plz? :idea:

That aside I am glad to see progress being made. The auto-min function tempts me to install Orbiter again. Send data to Launch MFD makes me want to play with the Velcro rockets again.