Project BaseSyncMFD going Open Sourced

[jarmonik]

Here are the source codes for the BaseSyncMFD. I wrote it about 13 years ago and I don't really remember much about it. It should be reasonably simple for anyone to continue the development.

Also, it looks like I am going to write an open source LTMFD 2.0 for the project NASSP. So, I am going to take a some vacation from the D3D9Client for a while, but that shouldn't take long.

 

[Face]

Thank you very much, Jarmonik! Not only is this outstanding work (as usual for you), it is also a brave statement to put your work under GPL now.

 

[kamaz]

Thank you!

 

[boogabooga]

Will there be an open IMFD?

 

[jarmonik]

Will there be an open IMFD?

Possibly, and that would be IMFD 6.0. I hope that one day I would have the time to create it.

Current IMFD(s) are a very horrible because being patched over and over again since IMFD 1.0. It would only serve as an example how not to create an MFD. Also, others have contributed some code to the project as well, so I am not sole copyright holder. So, I would prefer not to open source it. It would take more of my time than it's worth.

 

[Enjo]

Thank you, Jarmo.
I'll get my hands on it on my next iteration of free time, bringing multiple vessels support and other.

 

[blixel]

BaseSyncMFD has always been one of my staples in Orbiter, so it's great to hear that development on this MFD will continue (in some form or another) on into future releases of Orbiter.

If anyone does have a chance to work on the source code (Enjo or someone else), one issue that I've had with BaseSyncMFD for several years is that it will randomly reset the Tgt to "Surface". This is purely cosmetic as the actual Lon and Lat targeting doesn't change. However, it's something that I always wished could be fixed.

Here are some examples where you can see this happen. Just watch the MFD and notice how the Tgt changes, for no apparent reason, to "Surface". (links are set with a timestamp to just before it happens)

http://www.youtube.com/watch?feature=player_detailpage&v=0BfACfr25Z8#t=345s

http://www.youtube.com/watch?feature=player_detailpage&v=aUnnnHovng8#t=170s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=152s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=332s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=692s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=875s

I've never really noticed a pattern.

 

[Ripley]

displayed # of orbits

Well, have a look at these screenshots I took from the same pc (Orbiter 2010-P1):

This is an old one, correctly showing 8 orbits from 1 to 8:

Edit: Oops, it looks I've deleted this image! Sorry.


And this is a screen I just took, where orbit #2 is missing:

(BTW, you can also see blixel's bug where it says "Surface". The behaviour is the same if I retarget Cape Canaveral, or any other base)

I restarted Orbiter session, reloaded "current state" scenario, but the bug is still there.
I cycled cockpits with F8, but nothing changed (I thought it was due to a "too big" MFD size).


If I click on "NUM":
"1" displays one orbit;
"2" still displays only one orbit;
"3" only displays orbits #1 and #3.

Did anyone ever notice this?

---------- Post added at 21:53 ---------- Previous post was at 20:56 ----------

I've launched other scenarios and the misteryous bug is gone, everything's normal again. Doh! (the bugged screen was from the standard "docked to ISS" DGIV scenario).

 

[boogabooga]

I've never seen that.

 

[Ripley]

I've been able to reproduce it just now.
From the same DGIV scenario "Docked to ISS", undock, target Cape Canaveral in BaseSync, and accelerate time wildly.
My last session started to get weird results already at 100x.

Sometimes 1 or 2 random orbits disappear from the list, it's as if it can't keep up with the time accel.
The strange fact is that if you go back to 1x, the missing orbits remain, well, missing.

 

[boogabooga]

The skipped orbits in your screen shots seem occur for the orbit in which you will be furthest from the base. Perhaps there is a threshold. At any rate, the skipped orbit is of least concern.

 

[Ripley]

Good point!
Nontheless, I'd like to hear if the bug is reproducibile, or if it's my pc which cannot compute fast enough under higher time compression.

 

[Cras]

I have seen the orbits disappear when the distances hits zero, but haven't seen the behavior going the other way.

 

[Ripley]

The skipped orbits in your screen shots seem occur for the orbit in which you will be furthest from the base. Perhaps there is a threshold. At any rate, the skipped orbit is of least concern.

Sometimes (under 100x or more) the skipped orbits are clearly 2.
It's just a short flash, and it's extremely difficult to instantly back time compression to 1x to "freeze" that moment and grab a screenshot.
This would rule out your "threshold" theory.

And with this, I think I'm done reporting about this bug.
I can live with that, and I don't want to give the impression of being obsessed with it

It's up to the developers to look into this, and hopefully this is the right thread.



:hmm: Edit - just in case someone was wondering why should I bump time compression that much in that given situation: it was because I was waiting for the base to "fall" in such a night position to grant me a sunlit landing.

And now I'm done

 

[Ripley]

If someone is going to tackle this MFD's development in the future: on Forum Orbiter Italia there are at least 2 other members with the same "disappearing orbit" bug (Diabolos and apollo17).

http://orbiteritalia.forumotion.com/t3002-bug-di-basesync-mfd

:tiphat:

 

[ADSWNJ]

I took a look at the source, which is a few thousand lines of fairly tough calculations with next to zero comments. Pretty similar to Glideslope 1 when I first tried to unpack it.

The code intentionally does not print an orbit if either the time is negative or the distance is negative. Why it would be negative is still a mystery, but at least it's not just a random mutation. Same with the Surface vs Base situation... if the OapiGetBaseByName does not return a base, then it defaults to Surface. Why there's no base ... I need to hook up a debugger to figure it out.

I'm not quite brave enough yet to dive into a beloved MFD like this, but I could be persuaded!

 

[Face]

If anyone does have a chance to work on the source code (Enjo or someone else), one issue that I've had with BaseSyncMFD for several years is that it will randomly reset the Tgt to "Surface". This is purely cosmetic as the actual Lon and Lat targeting doesn't change. However, it's something that I always wished could be fixed.

Here are some examples where you can see this happen. Just watch the MFD and notice how the Tgt changes, for no apparent reason, to "Surface". (links are set with a timestamp to just before it happens)

http://www.youtube.com/watch?feature=player_detailpage&v=0BfACfr25Z8#t=345s

http://www.youtube.com/watch?feature=player_detailpage&v=aUnnnHovng8#t=170s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=152s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=332s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=692s

http://www.youtube.com/watch?feature=player_detailpage&v=21K1pOwjGYM#t=875s

I've never really noticed a pattern.

Could it be that you have some kind of auto-save running in the background, and the switch correlates with the moments the save is done?

One thing I've noticed in the code is that the string variable storing the Target value in the Sync class is manipulated for write-out on save-events (replacing spaces with underscores). This would of course cause oapiGetBaseByName() to return null on base names containing spaces.

This behavior can be easily fixed by the attached patch: View attachment targetfix.txt. Drop me a note if you want to try a binary.

 

[Face]

The code intentionally does not print an orbit if either the time is negative or the distance is negative.

Correction: if either the time or distance is not positive. This means zero is also a reason to skip it. Perhaps all of the various calculation steps fail to calculate the row, so the initialization of zero causes the skipping.

 

[blixel]

Could it be that you have some kind of auto-save running in the background, and the switch correlates with the moments the save is done?

I do run StateSaver Autosave, but I've never thought to observe if it was the case that the BaseSync target was resetting at the same time as StateSaver was saving.

EDIT: I just brought up Orbiter and ran several tests with StateSaver and BaseSync. StateSaver lets you specify a time interval for the saves. I tried 20 seconds, 45 seconds, and 300 seconds. It was quickly apparent that BaseSync resets its Target back to Surface at the exact instant that StateSaver does its autosave. Great catch! I can't imagine I ever would have made that connection.

This behavior can be easily fixed by the attached patch: View attachment 14163. Drop me a note if you want to try a binary.

Yes, I would certainly be interested in a binary patch that fixes this. (Which I assume is just a new dll for BaseSync?)

 

[Face]

Great catch! I can't imagine I ever would have made that connection.

Thanks for the confirmation. Isn't it cool what 10mins of static source analyzing can do? :lol:

BTW: I find jarmonik's code pretty clear and readable. His use of commenting (only where it needs it, rest self-documented) is quite OK IMHO. Nice work, Jarmo. :thumbup:

Yes, I would certainly be interested in a binary patch that fixes this. (Which I assume is just a new dll for BaseSync?)

Yes, it would be just the DLL. Will send you a PM.