OHM BurnTimeCalcMFD (BTC) 3.1 for Orbiter 2016

OrbitHangar

Addon Comments
Joined
Apr 9, 2008
Messages
3,832
Reaction score
13
Points
0

Author: enjo

BurnTimeCalcMFD (BTC) is a companion for TransX or any other transfer MFD that gives you your required dV for transfer orbit insertion, and time to periapsis (PeT) but not time to start burning.

Data is feed directly through ModuleMessagingExt from:
Trans X
BaseS yncMFD


Requirements:
Modu l eMessagingExt SDK
Microsoft Visual C++ 2005 Service Pack 1 Redistributable


 

CHANGES IN v3.1
===============

- added sound after adming the MFD

CHANGES IN v3.0

===============

- Module Messaging Ext library now loads dynamically, so it became optional
- added resource files, so the MFD appears in MFD Modes section
- created extensible OOD communication classes



DOWNLOAD
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
In the TransX development thread, we were discussing which buttons should be placed on the second buttons page. Blixel has kindly prepared the following poll, that I'd ask you to take, if you use BTC:

http://strawpoll.me/990809
 

Topper

Addon Developer
Addon Developer
Donator
Joined
Mar 28, 2008
Messages
666
Reaction score
20
Points
33
Hi Enjo,

thanks for updating!

It would be great to have also options for selecting RCS Forward/Backward/Up/Down (Or maybe only forward to don't have so much options?) also as engine type!?

---------- Post added at 01:49 ---------- Previous post was at 00:39 ----------

Enjo, I checked the code and I think it's done fast by replacing
Code:
const THGROUP_TYPE groups[3]={THGROUP_MAIN,THGROUP_HOVER,THGROUP_RETRO};
const char group_names[3][6]={"Main","Hover","Retro"};
by
Code:
const THGROUP_TYPE groups[4]={THGROUP_MAIN,THGROUP_HOVER,THGROUP_RETRO,THGROUP_ATT_FORWARD};
const char group_names[4][6]={"Main","Hover","Retro","RCS FW"};

but I havn't tested.
I could do this but it's better if you do this to keep the changes in one developement branch...

Ah and maybe RCS backward is also usefull, if you want to see your target and brake down your speed...
I think it's a good idea to check if all RCS engine data are equal and in this case, to show only "RCS" for all RCS types ;-) ...
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Hi Topper,

Thanks for the suggestion. However all I wanted to do with BTC was to enable the ModuleMessaging library, and I don't want to have so many addons under my maintenance. Therefore I'd happily pass the mic to you, if you think that you have some ideas to implement. I think that it would be more reasonable for me to focus on TransX right now, if anything.
As an alternative, you could work with me on the same branch, on the same SF project. What do you say?
 

Furet

Active member
Joined
Aug 7, 2011
Messages
199
Reaction score
55
Points
28
Location
France
:)
Great ideas and great updates of TransX, BTC, LMFD.

Thank you Enjo.
:cheers:
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
MFD update:

CHANGES IN v2.6
===============
* Resolved CTDs when switching the MFD on and off
* Simultaneous multiple vessels support (can be pre-programmed!) thanks to MultipleVesselsMFD
* Added RCS Forward, Up, and Retro "engine types"

I had to completely restructure the MFD to get rid of the CTDs. Although I can understand that these bugs slipped in there, because at that time (2005) I was a rookie coder myself, what I don't understand is why nobody has ever complained about the CTDs. Does nobody use the MFD, or are people too lazy to test for and report bugs, or has the stability expectancy of Orbiter addons decreased so much because of general loose coding that a CTD here or there doesn't surprise anybody anymore? If the last is true, then I think that it's very hurting to the Orbiter as a whole.
 
Last edited:

Cras

Spring of Life!
Donator
Joined
Apr 13, 2011
Messages
2,215
Reaction score
0
Points
36
Location
Los Angeles
Website
www.youtube.com
Awesome.

And as for CTDs...I cant say I ever saw any CTDs that I felt were related to BTC, and I use BTC pretty much every flight I do in Orbiter. I am tho sort of....I guess the word is expecting, something to cause my sim to crash at various points, and I have grown so used to it that I know when to save, and constantly am quick saving. There are a few MFDs out there that routinely cause crashes, as well as some vessels that are borderline non-usable because of their funkyness and lack of stability. BTC however never seemed to me to be that, but maybe i was missing it and attributing some of its crashes to other MFDs.

But....I do say the addition to RCS for engine type is a HUGE thing for me, thank you so much for adding this. Enjo once again giving to the community. You are the man Enjo old buddy.
 

Interceptor

Well-known member
Joined
Mar 28, 2008
Messages
2,718
Reaction score
76
Points
63
Location
Michigan,Florida
Hi Enjo,and thanks for keeping this great,and useful MFD alive,anyways I can report no CTDs yet,but the last one,I did have a CTD whenever I would use the VOR VTOL mfd after using Burntime calc,but it only hapened once in awhile,but with this new version I haven't had a problem yet.:thumbup:
 

IronRain

The One and Only (AFAIK)
Administrator
Moderator
News Reporter
Donator
Joined
Oct 11, 2009
Messages
3,484
Reaction score
403
Points
123
Location
Utrecht
Website
www.spaceflightnewsapi.net
MFD update:

CHANGES IN v2.6
===============
* Resolved CTDs when switching the MFD on and off
* Simultaneous multiple vessels support (can be pre-programmed!) thanks to MultipleVesselsMFD
* Added RCS Forward, Up, and Retro "engine types"

I had to completely restructure the MFD to get rid of the CTDs. Although I can understand that these bugs slipped in there, because at that time (2005) I was a rookie coder myself, what I don't understand is why nobody has ever complained about the CTDs. Does nobody use the MFD, or are people too lazy to test for and report bugs, or has the stability expectancy of Orbiter addons decreased so much because of general loose coding that a CTD here or there doesn't surprise anybody anymore? If the last is true, then I think that it's very hurting to the Orbiter as a whole.

Awesome.

And as for CTDs...I cant say I ever saw any CTDs that I felt were related to BTC, and I use BTC pretty much every flight I do in Orbiter. I am tho sort of....I guess the word is expecting, something to cause my sim to crash at various points, and I have grown so used to it that I know when to save, and constantly am quick saving. There are a few MFDs out there that routinely cause crashes, as well as some vessels that are borderline non-usable because of their funkyness and lack of stability. BTC however never seemed to me to be that, but maybe i was missing it and attributing some of its crashes to other MFDs.

But....I do say the addition to RCS for engine type is a HUGE thing for me, thank you so much for adding this. Enjo once again giving to the community. You are the man Enjo old buddy.

I'm using BurnTimeCalc MFD a lot and I've never experienced CTD's...
Anyway, thanks for the updates! I (/we) really appreciate it!

:cheers:
 

blixel

Donator
Donator
Joined
Jun 29, 2010
Messages
647
Reaction score
0
Points
16
MFD update:

CHANGES IN v2.6
===============
* Resolved CTDs when switching the MFD on and off
* Simultaneous multiple vessels support (can be pre-programmed!) thanks to MultipleVesselsMFD
* Added RCS Forward, Up, and Retro "engine types"

I had to completely restructure the MFD to get rid of the CTDs. Although I can understand that these bugs slipped in there, because at that time (2005) I was a rookie coder myself, what I don't understand is why nobody has ever complained about the CTDs. Does nobody use the MFD, or are people too lazy to test for and report bugs, or has the stability expectancy of Orbiter addons decreased so much because of general loose coding that a CTD here or there doesn't surprise anybody anymore? If the last is true, then I think that it's very hurting to the Orbiter as a whole.

Regarding the new RCS engine types - awesome. We have forward and backward translation, so is there a special reason to have up but not down? (I realize you can roll the vessel over. But the same could be said for forward/aft - you could just yaw the vessel around. Just curious.)

Anyway, Orbiter is still hanging on my end with BTC 2.6 with that scenario I posted in the TransX thread.

I'm mentioning it here because,
what I don't understand is why nobody has ever complained about the CTDs. Does nobody use the MFD, or are people too lazy to test for and report bugs

[ame="http://www.youtube.com/watch?v=-P_D9uGv6gw"]Orbiter 2010 - Testing BTC 2.6 - YouTube[/ame]

It may just be time for me to make a new Orbiter installation. Perhaps my existing install has become too polluted.
 

aldarion

Member
Joined
Oct 20, 2007
Messages
47
Reaction score
0
Points
6
Location
Gdansk
I think that there is up only because it is the weaker version of hover engines.
Forward is the weaker version of main and backward is a weaker version of retro.

I think that the idea was to have the weaker version of all "big" engines.

Even so, I also think that having other RCS options could be usefull.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
I think that there is up only because it is the weaker version of hover engines.
Forward is the weaker version of main and backward is a weaker version of retro.
I think that the idea was to have the weaker version of all "big" engines.
Yes, that was the idea.
Even so, I also think that having other RCS options could be usefull.
Don't you think that it could become annoying to have to circle through so many engine types?

Anyway, Orbiter is still hanging on my end with BTC 2.6 with that scenario I posted in the TransX thread.

I'm mentioning it here because,

Orbiter 2010 - Testing BTC 2.6 - YouTube
I hope you didn't feel personally attacked. You, dgat, Ripley, aldarion, and others in the TransX dev thread have been extremely helpful, as well as others who do report bugs. I'll get this hang bug solved. I promise. It just seems that some on-line coordination is needed for this task, but so far I wasn't able to provide it. It all depends on a given week's workload.
To be honest I got a bit mad after, you could say, having to fix somebody else's awful mistake in BTC, that you’ve pointed out in that thread. Of course you had no chance of knowing whether it was my fault or not, and I’ve discovered it in the same time as you, which got me thinking whether nobody else had this problem before in 9 years. However, it seems that our use case (debugging with new TransX) was specific enough to cause this bug, unlike normal user handling.
What added to my frustration, was that on Sunday I wanted just to fly around in Orbiter, using my new addon modifications and I got annoyed even more by Orbiter’s general instability, like crashing when leaving Earth’s SOI, or when entering Mars’ SOI. Hence I decided to write this small, maybe too emotional-laden, survey. I guess that the correct approach is to do exactly what Cras said: grow up to this fact, and save the sim’s state regularly. You’ll probably agree though that you cannot show Orbiter to somebody else (like on a presentation), when it frequently crashes, no matter if you’re a good pilot or not.

This "laziness" argument got me thinking a bit more. Let’s think what happens when somebody reports a CTD. The person is instructed to perform a time consuming test that consists of unloading modules and responding with the minimal setup which still reproduces this bug. So he spends his precious time on finding bugs in something that, as a whole, is somebody else’s intellectual property. No wonder that some people refuse to do it.

On a technical level, the described time-consuming test is required because of the fact, that C++ doesn’t throw any Null Pointer Exceptions, which could be caught by an upper scope, like in Orbiter’s core, and print an error on screen, showing the source of the problem, without crashing the sim. But because of the lack of such feature (and for other reasons), the Fathers of C++ advice not to use pointers at all, only references. A question arises - what should be done in exchange for returning a NULL in the event that a called vessel isn’t available (like GetVessel("GL-01"), which may not be present in the simulation)? The answer is - use a combination of a boolean function and a function that returns a reference on success, and throws an exception on failure, which can be caught by Orbiter’s core. For example:

PHP:
string name = "GL-01";
if (oapiIsVesselExist(name.c_str()))
{
	Vessel & vessel = oapiGetVessel(name.c_str());
	// it's legal to use vessel
} else {
	// Normally this event wouldn’t be handled
	Vessel & vessel = oapiGetVessel(name.c_str()); // this would throw an exception
}

Even without modifications of the Orbiter API, like in the above example, some simpler testing framework could be achieved, if only Orbiter was built with Free compilers, like MinGW, instead of MS-VC. Both MinGW and a full version of MS-VC allow for attaching their debuggers to an external process (Orbiter.exe), which allows you to find out which at least which DLL has caused the crash. The problem is, that you can’t debug code with MinGW which is not compiled by it, and a full version of MS-VC, that allows it, costs 600€. Who wants to waste so much money?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,403
Reaction score
581
Points
153
Location
Vienna
This "laziness" argument got me thinking a bit more. Let’s think what happens when somebody reports a CTD. The person is instructed to perform a time consuming test that consists of unloading modules and responding with the minimal setup which still reproduces this bug. So he spends his precious time on finding bugs in something that, as a whole, is somebody else’s intellectual property. No wonder that some people refuse to do it.

I can sympathize with your feeling regarding time-consuming CTD analysis, but I don't understand your "precious time" argument. After all, developers like yourself have also invested precious time to write an add-on (open-sourced or not) and give it to the community for free. IMHO it is only fair to ask users for precise error reports, even if that requires time on their side.

If people refuse to do that due to some IP worries, they should not use a free add-on (and complain) in first place. Same goes for Orbiter itself: if people are unhappy with the license and/or the stability of the core, why not join a team to create a better one, or change to a different product? It is not like they've shelled out huge amounts of money for Orbiter, so they have to stick to it to save their investment.

Don't get me wrong: users that report CTD with a good reproduction recipe are a blessing for every freeware developer. I'm not pointing the above in their direction. What I mean are users that your argument seems to want to cultivate: the one that write "CTD after 2 mins, this game sux, go fix it now!11!"

Even without modifications of the Orbiter API, like in the above example, some simpler testing framework could be achieved, if only Orbiter was built with Free compilers, like MinGW, instead of MS-VC. Both MinGW and a full version of MS-VC allow for attaching their debuggers to an external process (Orbiter.exe), which allows you to find out which at least which DLL has caused the crash. The problem is, that you can’t debug code with MinGW which is not compiled by it, and a full version of MS-VC, that allows it, costs 600€. Who wants to waste so much money?

From my personal experience, it is next to impossible to guarantee a side-effect free environment in any C++-based framework/plugin concept. No matter how good your error reporting is, or how strictly you use certain programming techniques, as long as you use C++ and an open infrastructure like Orbiter, you will always have situations where the best debugger will just show you a access violation somewhere inside the core with a stack-trace getting you nowhere. I have personally witnessed CTDs with the debugger just showing you the render loop, with no clue to what DLL was the culprit. Only after fine-grained variable inspection (lots of Orbiter disassembler knowledge preconditioned) could you trace it back to the (possible) error-source DLL.

Therefore, I doubt that a free debugger situation will really help the current situation much.

However, I agree that the common C++ usage of pointers is almost always the culprit in CTD cases. I think that perhaps a switch to a managed environment (for plugins only) might help in this regards. That's one of the reasons why I've started the Orbiter.NET project.

That said, you did an excellent work here :cheers:. Don't get frustrated by seemingly less frequent feedback, many folks just use it quietly and are happy with it, I'm sure.

regards,
Face
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
If people refuse to do that due to some IP worries, they should not use a free add-on (and complain) in first place. Same goes for Orbiter itself: if people are unhappy with the license and/or the stability of the core, why not join a team to create a better one, or change to a different product? It is not like they've shelled out huge amounts of money for Orbiter, so they have to stick to it to save their investment.
Time is also a valuable investment. I spent a lot on it. In return, Orbiter and its API have taught me a lot, for which I’m grateful, but the API doesn’t move on to become more modern, to suit my, and the job market’s increasing demands. So however your paragraph may sound - yes, it is a logical solution. I keep developing for Orbiter, because I have developed a few working systems here which yield, and it’s still fun for me, but if I ever find enough time to switch to something else, I will do it.

Don't get me wrong: users that report CTD with a good reproduction recipe are a blessing for every freeware developer. I'm not pointing the above in their direction. What I mean are users that your argument seems to want to cultivate: the one that write "CTD after 2 mins, this game sux, go fix it now!11!"
These are users who I simply ignore… at least officially :)

Therefore, I doubt that a free debugger situation will really help the current situation much.
You described an outlier against my point, and this outlier still hadn’t stopped you from fixing the mentioned bug. I’ve had a positive outlier situation, when a real-life tester turtle91 has reported exactly where a bug was in Launch MFD, in connection to Kulch’s addons, because turtle91 owns a full version of MSVC, so he could run Launch MFD through a debugger.
So much about user-based testing. Let’s also add the entire developers community - I’m sure that they would know more about fixing bugs in their own addons, if they developed them with the help of a debugger, which in 80% of cases points you to location of a dereferenced NULL pointer.
… or:

However, I agree that the common C++ usage of pointers is almost always the culprit in CTD cases. I think that perhaps a switch to a managed environment (for plugins only) might help in this regards. That's one of the reasons why I've started the Orbiter.NET project.
Thumbs up. This is also a solution, as C++ is great, but it’s not good for everybody.

That said, you did an excellent work here :cheers:. Don't get frustrated by seemingly less frequent feedback, many folks just use it quietly and are happy with it, I'm sure.
Well, "No feedback is better than bad feedback", but I’m not frustrated by the lack of feedback about my addons - I’m quite happy with it. I was only describing a situation of somebody else’s addon, and as somebody who rarely uses Orbiter itself, I wanted to know what the users think.
 

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
3,133
Reaction score
407
Points
123
Location
Rome
Website
www.tuttovola.org
There's a (useless) 1.6Mb Word file in doc folder (along with the same file in pdf format).
Just a heads-up for future versions.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Do you know what time it is? It's time for an update!

CHANGES IN v2.7
===============
* Resolved sporadic freeze on startup due to displaying of uninitialized variables
* Resolved craft's "orbit freeze" bug when the MFD was closed and Time Acc. >= 10000 was applied
* Added new button - RCS for including RCS fuel in total DV calculations
* Internal: Changed "TBurn" ModuleMessaging variable to "InstantaneousBurnTime". TransX update required for GET button to operate correctly


There's a (useless) 1.6Mb Word file in doc folder (along with the same file in pdf format).
Just a heads-up for future versions.
Not really. If somebody found a typo in the PDF, he/she could fix it only through the .doc.
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
I'm happy to hear that.
The cause of the bug was the short version of VESSEL::GetElements(). You can see my bug report here. The solution was simply to replace the short version of this method with its longer sister. I figured it out by bisecting the code with "returns", until I got to the source of the problem.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Update to v. 2.9.2

Update to v. 2.9.2:
Removed the legacy ModuleMessaging dependency, using only ModuleMessagingExt.


Same goes for Launch MFD and TransX.
Andrew now only needs to update his [ame="http://www.orbithangar.com/searchid.php?ID=6707"]On Station Ops[/ame] and [ame="http://www.orbithangar.com/searchid.php?ID=6221"]RV Orientation[/ame] , and we're officially migrated from ModuleMessaging to ModuleMessagingExt.
 
Top