FSX (Released) M.I.T. - Maintenance and Income Tool

Heretic

Resource contributor
What I ment to ask, would it be possible for another developer to make this program work with another addon. For example if the addon aircraft of that developer indicates a blown tire and you let it be repaired and "pay" for through this program, can the addon aircraft be programmed to indicated the tire as "repaired". Would that perhaps be possible?
AccuSim, huh?
Nope, it wouldn't. It's either MIT or AccuSim for failure modeling, but not both.
 

F747fly

Resource contributor
AccuSim, huh?
Nope, it wouldn't. It's either MIT or AccuSim for failure modeling, but not both.
Sorry I didn't mean Accusim. Say I make an aircraft whoms systems can indicate a failure (blown tire, leak, what have you) could a MIT command of a payed fix be translated into the aircraft to resolve that issue (since you fixed it through MIT?
 

Heretic

Resource contributor
Sorry I didn't mean Accusim. Say I make an aircraft whoms systems can indicate a failure (blown tire, leak, what have you) could a MIT command of a payed fix be translated into the aircraft to resolve that issue (since you fixed it through MIT?
Yup. Just make a model for a blown tire and assign MIT's variable for the tire state to control the visibility of said model. Since MIT is entirely written in XML, you can access every variable it uses (if you can find it in the code).

Now that I caught up on your idea...yeah, it would be kind of cool to see, if only for a blown tire. (The remainder of failures is internal.)
 

F747fly

Resource contributor
Now that I caught up on your idea...yeah, it would be kind of cool to see, if only for a blown tire. (The remainder of failures is internal.)
I know. I might want to try that out some day, I'll see if I'm able to make a blown tire model. I think it would be a nice feauture...
 

Dutcheeseblend

Resource contributor
Now I remember a guy around here, he made something like that. Three visibility modes for tires: new, used and without any profile, if I remember this correctly. I believe it was Willem for this F27...
 

Heretic

Resource contributor
I know. I might want to try that out some day, I'll see if I'm able to make a blown tire model. I think it would be a nice feauture...
In terms of modeling, the rim model with a few bits of rubber hanging about should do.
In terms of controlling visibility: Easy-peasy XML basics.

One problem I can not solve, however, is modifying the contact points from runtime. In FSPax, when you blew a tire, the plane showed an appropriate bank on the ground. I can't do that via XMLTools, as far as I know.
 

Paul Domingue

Resource contributor
In terms of modeling, the rim model with a few bits of rubber hanging about should do.
In terms of controlling visibility: Easy-peasy XML basics.

One problem I can not solve, however, is modifying the contact points from runtime. In FSPax, when you blew a tire, the plane showed an appropriate bank on the ground. I can't do that via XMLTools, as far as I know.
You would need something like TACPACK for that type of aircraft behavior.
 

F747fly

Resource contributor
That would indeed be the problem. I guess it would take some good thinking to do it...
 

Heretic

Resource contributor
I guess it could be done with a C++ gauge and SimConnect. But if you're gonna go down that route, you might as well start yet another attempt at a true FSPax replacement.

After all, the beauty of MIT is that it is confined to the narrow range of stuff that can be done with XML and XMLTools. No worries about missing features. ;)
 

Heretic

Resource contributor
Interesting! Since the beginning of this thread I'm figuring how I might use it. Don't have a clue yet.
For your add-ons? Plug in and go.

The suitability for military missions depends on how well FSX can do round trip flights. Getting rid of your (money making) payload will make that type of flying a bit of an expensive endeavour to boot.
 

Heretic

Resource contributor
Heads up!
Make sure that the last leg of your flight plan (the one to your destination) is activated before or after you've landed!
Otherwise, the GPS and thus MIT will never set your status to "arrived" and you won't be able to record the flight.

In case you refuse to fly with a GPS, you'll have to make sure that you've hit all the waypoints on your flight plan (check the nav log).
Or create your flight plan as "Direct To".

This is a MSFS limitatation that I can't work around.



P.S:
As for TP compatibility, I could freeze the current payload after takeoff and use that for revenue calculation. That way, you'd always get paid after landing, no matter where the payload went.
 

Heretic

Resource contributor
New revision online.

- Payload calculation is frozen after takeoff. You're welcome, TacPack users, firefighters and parachute carriers.
- The vertical speed of the last landing is now displayed in the message window.
- The message window will show a reminder to leave the landing lights on when you are below the minimum height for lights + 500 ft.
- To facilitate flight plan monitoring, the message window now shows the next waypoint.


Hint for "round trip" flights: Define any airport as the departure airport and create a "direct to" flightplan to your departure/arrival airport or put as many waypoints as you need in between. MIT will only consider you "arrived" at your destination after you've actually flown.
 

Heretic

Resource contributor
New revision.

Highlights:
- Changed file handling, now with a base module in FSX\Gauges and an aircraft-specific gauge in the "panel" folder
- Automatic installation script for the panel.cfg
- The MIT window will now automatically pop up and sound the "no smoking" chime when a failure occurs. Popup without any sound will occur when a flight is finished. Can be switched off.
- Custom hotkey (default: CTRL+Shift+m) for the MIT window, configurable on a per-aircraft basis.

Read the "Installation" and "Configuration" parts of the documentation, especially if you're lready running MIT!


Upgrade:
- Uninstall the previous version. Keep the save files!
- Install the current version
- Change the save file names in MI_Tool_Aircraft.xml to the ones of your present save files
OR
- Generate new save files with new names by purchasing the aircraft in FSX, then transfer the file names of the new save files to your old ones and reload the aircraft
 

Heretic

Resource contributor
New revision. Save files are compatible. Mind the save file name in MI_Tool_Aircraft.xml when upgrading.


05/01/2016

Improved aircraft value calculation; changed used aircraft value generation; baseline for increased engine wear is now 92.5% throttle (used to be 85%); purged some legacy code from the system file; fixed semi-broken tire damage code; new bought aircraft will now adhere to the time-to-failure value for the engines that is specified in the configuration area

10/12/2015

Fixed display of large amounts of funds in the status window; fixed a bug with reading aircraft-specific component wear rates
 
In terms of modeling, the rim model with a few bits of rubber hanging about should do.
In terms of controlling visibility: Easy-peasy XML basics.

One problem I can not solve, however, is modifying the contact points from runtime. In FSPax, when you blew a tire, the plane showed an appropriate bank on the ground. I can't do that via XMLTools, as far as I know.

http://www.fsdeveloper.com/forum/threads/landing-gear-override.433844/#post-708436
Yes. Download and install XMLTools v2.0

Then you'll be able to set nose gear to any position using XML code.
Aerodynamic effect and viewpoints are going to be altered as well.

If you are the model author, you'll have to use LVars for controlling the nose gear display, as to avoid possible flicker effects.

I suggest you check XMLTools' TableAndSim example

Tom
Presumably individual main gear can be controlled as well.
 

Heretic

Resource contributor
This is controls landing gear extension and retraction and not the contact points for the wheels. (It's already implemented to boot.)
 

Heretic

Resource contributor
Working on a new feature for MIT: An airport finder.

I usually don't have an idea where I'm supposed to fly. Flying real world airline routes is one option, but what if I want to do charter runs?

Finding suitable destinations by trial and error is a bit annoying. Enter destination, check distance, time and runway length, delete destination and start over.
So why not use FSX' airport database to create a list with custom filter criteria?

And this is exactly what MIT's Destination Finder is doing. All you need to do is...

1) Call up the gauge.



2) Enter minimum and maximum search distance and press "Scan".



DF will then scan (in this example, a maximum of 6962 items of) the default airport database. Those items are then processed by the filter algorithm before being displayed in a list.



Once the initial database is built, you can alter each filter parameter and instantly get your results. Only altering the aiport scan limit and minimum and maximum scan range will reset the results.

Increasing the minimal runway length to 5000 feet will yield these results:



Setting the filter to "water runways" turns up four valid airports in this scenario.



And setting the filter to "other" can be used for add-on airport shenanigans; in this case for finding a custom helipad airport which otherwise wouldn't turn up in the regular results.





Cool stuff:
- Search parameters can be entered via keyboard. No awkward scrolling.
- The result list can be scrolled. As you can see in the screenshots, a smart indicator will tell you whether there's more or not.
- Initial values are kind of smart. Your aircraft's available range and runway requirement is estimated. Same goes for the number of airports that need to be scanned in order to get the highest number of valid returns. All of these parameters can be overridden by the user though.

I still need to implement this into MIT proper, but save for that, I'm pretty much done.
Maybe I can turn this gauge into a random mission generator ("fly x kg payload to airport y and receive z funds") at one point.

If there's some interest in this gauge without the rest of MIT*, I could as well upload it as standlalone.



*:(
 

TurboCompound

Resource contributor
I think that what Essex was suggesting was that you use XMLTools to force the damaged landing gear to the retracted position.
 

Heretic

Resource contributor
And what I was saying is that MIT is already capable of doing this. In fact, if you the gear fails during extension or retraction, it will become stuck in the exact position it failed in.
Gravity gear drops would have been a bit too much.
 
Top