Project BaseSyncMFD going Open Sourced

[Face]

I've tried to approach the "disappearing row" bug by means of displaying zero or negative row values, if they are within the span of "valid" rows. I.e.: if you have e.g. 4 rows displayed, and strange calculation let row 2 get negative or zero values, it will be displayed anyway.

This way people with the problem can at least report the calculated numbers, so those with more insight into the various calculation steps can take a hint. In addition, it doesn't skew the display regarding position of rows anymore.

Patch: View attachment rowdisplay.txt

 

[Ripley]

...And how do I apply a txt patch?

 

[Face]

...And how do I apply a txt patch?

You have to use a patch tool (most versioning systems do that) on the source code and recompile. I can send you a PM with a download link to the DLL, if you like.

 

[Ripley]

...I can send you a PM with a download link to the DLL, if you like.

I would highly prefer it, thanks.

 

[ADSWNJ]

Looks like you've got this one, Face. I'll defer to your expertise.

P.s. I would just move the underscored Target into a temp variable and leave Target alone so as not to peturb it at all.

 

[Face]

P.s. I would just move the underscored Target into a temp variable and leave Target alone so as not to peturb it at all.

That's what I did in my patch above.

 

[ADSWNJ]

I can confirm that when your orbit runs over the closest point to your base, the closest pass #1 will disappear for 20-30 seconds. The binary chopping search algorithm (which by the way is beautiful) does not like finding a solution right on top of the current position, so it drops it from the list. The number intentionally tries to show something has been dropped, but for regular users it makes it look like a bug.

Face found the other bug - any time you save a target with a space in it, the Target will reset to Surface, despite all being ok.

I have a private copy of the code with both problems fixed (i.e. always contiguous pass numbers, and the save now not causing a reset to Surface). With Jarmonik's permission, I'll upload a complete package to Orbit Hangar, with all credits to him. Jarmo - you ok with this?

 

[Face]

With Jarmonik's permission, I'll upload a complete package to Orbit Hangar, with all credits to him. Jarmo - you ok with this?

By means of consciously putting this software under GPL AFTER the license wars thread's heated discussion, Jarmonik already gave his explicit permission to re-distribute it. I don't really understand what you are asking for.

 

[ADSWNJ]

By means of consciously putting this software under GPL AFTER the license wars thread's heated discussion, Jarmonik already gave his explicit permission to re-distribute it. I don't really understand what you are asking for.

I'm just being polite, that's all. I'll take the current BaseSyncMFD package, merge in the source and the new binary, and then re-release it on OrbitHangar as a patch.

Jarmo - I'll go ahead and do this, and if you disagree, PM me and I'll fix it or pull it down immediately.

---------- Post added at 08:40 PM ---------- Previous post was at 07:05 PM ----------

OK - the new version is now pushed to Orbit Hanger. See this release thread:

http://orbiter-forum.com/showthread.php?t=36589

... and let me know if there are any issues.

 

[blixel]

It didn't occur to me to make this point sooner, but is it possible to see more than 8 orbits out? Like a Page FWD type of thing that would show 9, 10, 11, etc...

I remember a lot of times I would see a passage to the base that had a Dist of like 250km on say orbit 2 or 3, and beyond that they would get larger. Generally if you use time warp to go beyond the last orbit that is displayed, you will eventually find an even closer passage than the one you could see in the 8 rows. So it would be good to see more rows of future orbits beyond 8.

 

[ADSWNJ]

It didn't occur to me to make this point sooner, but is it possible to see more than 8 orbits out? Like a Page FWD type of thing that would show 9, 10, 11, etc...

I remember a lot of times I would see a passage to the base that had a Dist of like 250km on say orbit 2 or 3, and beyond that they would get larger. Generally if you use time warp to go beyond the last orbit that is displayed, you will eventually find an even closer passage than the one you could see in the 8 rows. So it would be good to see more rows of future orbits beyond 8.

Pretty easy actually. It's just a dimensioning thing for the arrays, a new max for the number of solutions, and figuring out where to make space in the buttons. Would you be ok with LAT LON becoming a single button (COO ... coordinate entry), to make space for NXT, and then the same buttons with PRV on the page 2. (If > 16, then it'll just be NXT in a loop for the number of solutions desired. looping back to the start.)

 

[blixel]

Pretty easy actually. It's just a dimensioning thing for the arrays, a new max for the number of solutions, and figuring out where to make space in the buttons. Would you be ok with LAT LON becoming a single button (COO ... coordinate entry), to make space for NXT, and then the same buttons with PRV on the page 2. (If > 16, then it'll just be NXT in a loop for the number of solutions desired. looping back to the start.)

I hope others will chime-in on the button layout, but in my situation, I only use BaseSyncMFD to help me with base alignment. I never use its deorbit functions, so the ANG, ANT, ALT and DEO buttons could all be moved to Page 2 and I would never miss them.

But that may be just me, so I certainly wouldn't suggest making that change for the "standard" version without getting a lot more data from others.

But if it's a simple change, I would love to have a dll if only for myself, that would allow for more rows to be displayed. And for myself, the E/D option should default to Direct instead of defaulting to Equator since I never use that MFD with the Equator reference. (I always felt like that kind of thing should be configurable through a .cfg file or something.)

 

[ADSWNJ]

Thanks for the info. I'll do a new version and see what people think. Easier that way than to expect too much feedback in here. (E.g. 26 downloads of the new version so far, 1 vote, and no comments! Downloaders ... a little feedback would be nice y'know!)

 

[turtle91]

I can even switch between different vessels or different screens (i.. DGIV XR-vessel) and the target/base keeps persistent selected/displayed.

A realy nice feature, which makes the difference.
Many thanks for that. :thumbup:

 

[ADSWNJ]

OK - pushed v2.5 to the Orbiter Hangar. This is the Blixel release ... and the scanning of up to 32 solutions is really nice if I say so myself. (32 is arbitrary, so if you really want 256 solutions, it's easy!).

 

[blixel]

OK - pushed v2.5 to the Orbiter Hangar. This is the Blixel release ... and the scanning of up to 32 solutions is really nice if I say so myself. (32 is arbitrary, so if you really want 256 solutions, it's easy!).

Much appreciated! The improvements are fantastic! I suspect 32 is sufficient for most bodies. The moon rotates slowly enough that it might actually be useful to have more than 32 in the case of very slow bodies like the moon, but in any event, 32 is WAY, WAY better than 8.

Also, I speculate that there may be a point where the accuracy of the predictions becomes nearly unusable? (At least if Non-Spherical Gravity sources are enabled.)

I know the predictions drift a few km per orbit. Like if you show that on orbit 15, your Dist is 300km from the base, when you warp time forward at 1000x, you'll see that Dist go up a few km every orbit. (Or depending on the situation, it may go down a few km every orbit.) But in my experience, it has never been off by enough to matter.

One other thing I'll mention as a possible area of interest for Enjo. Now that the source code for BaseSyncMFD is available, would it be possible to automate the Base Alignment burn through Burn Time Calculator? The base alignment burn is done according to the Tn value given in BaseSync. If BTC could read that value from BaseSync, then it could automate the burn in the same way that BTC is able to "GET" the Delta V from TransX's Target View. Just a thought. I've always liked the idea of the computer controlling the start and stop of a burn because humans are too inaccurate.

 

[boogabooga]

One other thing I'll mention as a possible area of interest for Enjo. Now that the source code for BaseSyncMFD is available, would it be possible to automate the Base Alignment burn through Burn Time Calculator? The base alignment burn is done according to the Tn value given in BaseSync. If BTC could read that value from BaseSync, then it could automate the burn in the same way that BTC is able to "GET" the Delta V from TransX's Target View. Just a thought. I've always liked the idea of the computer controlling the start and stop of a burn because humans are too inaccurate.

Also the de-orbit burn. Or at least report the time to de-orbit burn start. (Some of us use BaseSync for the de-orbit burn. )

 

[ADSWNJ]

Also the de-orbit burn. Or at least report the time to de-orbit burn start. (Some of us use BaseSync for the de-orbit burn. )

Check out this v2.5 version. I added a TBn (Time to Burn) variable on the deorbit display exactly for this deorbit burn countdown. (It worked first time I compiled it it too, leveraging one of Jarmo's awesome utility routines.)

I'll add the Module Messaging next, to expose those variables for other tools to hook onto.

 

[boogabooga]

:embarrassed:

I haven't had a chance to check it yet, sorry.

 

[jarmonik]

I have a private copy of the code with both problems fixed (i.e. always contiguous pass numbers, and the save now not causing a reset to Surface). With Jarmonik's permission, I'll upload a complete package to Orbit Hangar, with all credits to him. Jarmo - you ok with this?

Thank you for starting to maintain the project. It was open sourced in a hope that the community could further develop the application and redistribute it. There are no need to ask permissions. You have them already.

I'll update the links from my website to point to OrbitHangar.