Addon Maintenance regimen?

[Dutcheeseblend]

- Slightly randomized crew weight, depending on their diet.

 

[Bjoern]

I'd question it, if it wasn't that logical.

 

[JimmyRFR]

One other idea I'm toying with is company funds, i.e. your money being stored in a file that can be accessed by all planes using the gauge. That way, you could haul things in a DC-3 by day and blow the revenue on GA aircraft on the weekends.

That's an excellent idea. Having the option to fly a revenue generating flight if you wish, or just spend money like it's going out of style. It'd be good then, to also have an interactive way to deposit 'funds' in your company account, so one wouldn't need to simply edit the log file you're storing your persistent values in.

When I was coding my asymmetric flap failure system, I spent a long time on a random number generator in xml. Worked fine for randomly failing left vs. right side with even odds, but when it came to random failures, I found it was very much a trial or error type thing to create a believable 'slight chance' type of system.

In my code, I first assigned a random amount of wear, say 1 to 5 points, every time the flaps were actuated. If they were in operation at an airspeed that was too fast, I then also assigned a small random amount of wear per second, increasing that number with higher and higher speeds. This 'wear' value was persistent and was saved with the aircraft. Then, I used a random number generator again in order to compare a random number to the 'wear' value, only at actuation during regular speeds, but also every second during flap overspeed. If the random number drawn was < the 'wear' value, then I'd trigger a flap failure on one side only, using a random number generator yet again to pick a side. The flap failure condition had to keep overwriting the default flap position, because the sim wants to keep the flap at it's desired setting, and you obviously want it at 0. The unexpected and perfect side effect of this, however, was that the slight 'battle' between where the sim wants to put the flap and where the gauge wants to put it, created a visual flutter of the flap... but anyhow...

My point in describing that was that in testing the random number generator, I had difficulty in scaling the values to make something extremely rare under normal circumstances. Even when I was only adding 1 - 5 points of wear to the persistent value, I was having to use a max random number of like 100,000,000 or more, or else in any situation where I was continually checking the value, I'd 'win the lottery' and fail the system far quicker than what should happen. Before I moved on to other things, I was actually playing with different ideas such as having to match or be less than the 'wear' value multiple times in a row.

 

[Bjoern]

One thing I can't fix about flightplan handling is that you have to end the current flight and return to the main menu if you want to unload a flight plan from the GPS. This is standard behaviour in FSX.
Switching from joyride to planned mode by creating or loading a flightplan works well though.

That's an excellent idea. Having the option to fly a revenue generating flight if you wish, or just spend money like it's going out of style. It'd be good then, to also have an interactive way to deposit 'funds' in your company account, so one wouldn't need to simply edit the log file you're storing your persistent values in.

Company mode is going to be optional as it will rely on XMLTools as a module to provide storage and retrievement.

 

[Bjoern]

Working on the engine wear and maintenance logic at the moment. This is tougher than I expected.
Performing maintenance is awfully expensive and actually decreases the engine's condition. Time to failure for an engine wildly varies between 30 and 90 hours.

 

[JimmyRFR]

Working on the engine wear and maintenance logic at the moment. This is tougher than I expected.
Performing maintenance is awfully expensive and actually decreases the engine's condition. Time to failure for an engine wildly varies between 30 and 90 hours.

I'd give you some words of encouragement, but I don't know any.

I'm assuming you're writing it as a gauge in XML; if so, I'll let you know right now that I plan on using whatever you're creating as a base, and tweaking it to my own purposes. That way, I'm not going to even mention any other 'features' I'd like or wouldn't like, and therefore won't bother you with it!

Have fun!

 

[Bjoern]

Fixed the bug, so don't worry.

You can scale the wear accumulation for every system to your liking and once I have a release version up, everyone is invited to post their preferred settings.

Still working on wear and tear, but already thinking about failure modeling.

The first issue is whether to use XMLTools or not.
XMLTools pro/con:
+ Can access default variables better than standard XML key events
+ Can do load/save
+ Would restrict use of external resources to one module instead of one optional module and a gauge
- Doesn't work in FS9 (no Simconnect) or P3D (yet)

The idea is that the odds for any system to fail increase with decreasing system condition.
Once a system is set as failed, another throw of the dice will determine which subsystem will fail.
Depending on whether I'll use XML Tools or not, this could either mean that the flaps will be stuck in a certain position (no XMLTools) or that the flaps on either wing get stuck (XMLTools).
For the gear, it's either brake failure (XMLTools or not) or the gear being stuck. With XMLTools, I can limit this to the left or right or nose gear. (Will obviously not apply to fixed gear aircraft.) Or maybe even just a steering failure. Or a blown tire if I can implement it.
Airframe failures are either the aileron or elevator or rudder going wonky or the whole plane actually disintegrating (using the well tried method of complete control lockup).
Engine failures can either be fiery or simple shutdowns.


- E:

Regarding random numbers: The RNG I'm using spits out random numbers in a range from 0 to 1. Setting a "valid value" range of, say 0.45 to 0.55 provides you with a 10% chance of failure for any given time interval in which you roll the dice. Narrow down the valid value range and odds will decrease.
I don't know how much numberical precision FSX exactly supports (32bit?), but odds in the 0.01% range are quite possible. If combined with a dice roll every fifteen minutes or so, chances for a system failure should be acceptably low.

 

[Bjoern]

Alrighty, wear and tear modeling is done. Another big chunk of work from the list.

Engines:
Base wear when engine is running plus additional wear due to throttle settings (including reverse thrust, if available) plus a bit randomized wear from flight session to session. Don't know how many hours you'll get out of your engines as the time to failure is mildly randomized and it all depends on how you (ab)use them. Could be 40 to 50 hours or so.
Flaps:
Flaps wear out while transitioning from position to position and, when not retracted, from aerodynamic loads.
Gear:
Landings, extension/retraction, brake use, (weight dependant) taxiing and flying with the gear extended all influence gear wear. Fixed gear aircraft accumulate less wear when airborne.
Airframe:
Hard landings eat away a good chunk of the airframe condition. The dynamic pressure on the aircraft and G loads also influence airframe wear.

I'll probably do the reputation system as this will just be strightforward enough for a change.


The gauge files are at 760 and 420 lines so far.

 

[RyanJZ]

Alrighty, wear and tear modeling is done. Another big chunk of work from the list.

Engines:
Base wear when engine is running plus additional wear due to throttle settings (including reverse thrust, if available) plus a bit randomized wear from flight session to session. Don't know how many hours you'll get out of your engines as the time to failure is mildly randomized and it all depends on how you (ab)use them. Could be 40 to 50 hours or so.
.

will we be able to adjust the TBO for different engines? like 3000 hours for the PT6 or 3500 for the Garrett TPE-331?

 

[JimmyRFR]

I'm partial to XMLTools, simply for the ease of use it brings when coding the gauge. It's what I used. Love it.

Good work on the small size. My flap failure code was quite complex, and also had a bunch of triggered custom sound stuff using Doug Dawson's sound gauge, but it ran to 400+ lines across two gauges (2hz + 18hz) just for the flaps alone. The gauge for the gear was another 100+ lines on top of that.

I was actually thinking of taking my gauge outside of the sim and using Simconnect instead. Would of been much easier. Would also make for a nicer interface for managing repairs, service, etc. Something to keep in mind, perhaps.

 

[Bjoern]

will we be able to adjust the TBO for different engines? like 3000 hours for the PT6 or 3500 for the Garrett TPE-331?

You can adjust the scale factor for general engine wear to get your 1000s hours of life out of it.
But note that this will be TTF and not TBO. An engine at 0% health will be considered as good as dead.

Extremely large factors take away much of the fun though. Might just as well set the scale factor to zero.

I'm partial to XMLTools, simply for the ease of use it brings when coding the gauge. It's what I used. Love it.

XML tools is awesome. I've equipped a MiG-21 with a gauge that assigns actual payload and/or fuel to each station. With a bit of effect work for visual feedback, I could even take this as far as reducing the weight at said pylon with every spent rocket or missile.

Good work on the small size. My flap failure code was quite complex, and also had a bunch of triggered custom sound stuff using Doug Dawson's sound gauge, but it ran to 400+ lines across two gauges (2hz + 18hz) just for the flaps alone. The gauge for the gear was another 100+ lines on top of that.

I just try to keep it simple. You probably took things into account that I deem unnecessary or too specific.

One thing I fortunately ditched a while ago was relying on the gauge refresh rate to provide timed increase/decrease of variables. I use timers now, which are as simple as they are effective - and they stop updating when the sim is paused.
One thing that is, however, a general problem with (2D) gauges in FSX is that they don't update when not in a external view. I can't solve that though.

I was actually thinking of taking my gauge outside of the sim and using Simconnect instead. Would of been much easier. Would also make for a nicer interface for managing repairs, service, etc. Something to keep in mind, perhaps.

XMLTools uses SimConnect, so the bridge would be there.

No external BS for me though; I am all for unintrusive minimalism. If someone donates a background image in form of a clipboard or so, I might just as well put it in and adjust font coloring accordingly. But other than that, I want to contain everything to a single window in the simulator. Thinking about adding a sceond page to the status window for statistics or so. But this is low on the to-do list.

 

[JimmyRFR]

No external BS for me though; I am all for unintrusive minimalism. If someone donates a background image in form of a clipboard or so, I might just as well put it in and adjust font coloring accordingly. But other than that, I want to contain everything to a single window in the simulator. Thinking about adding a sceond page to the status window for statistics or so. But this is low on the to-do list.

I hear you on the minimalism. There's just been times, especially when coding logic routines, where a little voice in the back of my head whispers to me "this would be so much faster to whip up in C#...". I've done a few interfaces between the sim and an outside program using either FSUIPC or else pure Simconnect, that have been far more complex than simple tracking and failures (such as 'adversary' AI routines and the like) and it's so much cleaner in the long run than mucking about in XML. And of course, doesn't require anyone to edit the panel.cfg file either.

On the other hand, I personally find it far more immersive when everything regarding the maintenance or wear and tear on the plane is handled in-sim, aka 4X DA20 or the A2A fleet.

 

[Bjoern]

I hear you on the minimalism. There's just been times, especially when coding logic routines, where a little voice in the back of my head whispers to me "this would be so much faster to whip up in C#...". I've done a few interfaces between the sim and an outside program using either FSUIPC or else pure Simconnect, that have been far more complex than simple tracking and failures (such as 'adversary' AI routines and the like) and it's so much cleaner in the long run than mucking about in XML.

Learning C++ or C# is on my "Tomorrow I'll start" list.
One advantage of C++ gauges is that they're not subject to the 18Hz refresh limits. Great for (b)locking user input for a certain control.

But for this exercise, it would be too much and much too similar to existing solutions.
Besides, if someone knows XML and wants to improve anything about this gauge, they can do so at will.


The adversary AI routines sound interesting. For personal use or under contract?
A small mock dogfight module would be quite something. Take of with an AI aircraft, fly in formation to a designated area, split up and separate 5, 10 or 20 nm, then dogfight until you or him "tag"s the other with an invisible curved lase beam or an invisible missile. After either one is tagged, you can choose to go again or go home.
Would be difficult to scale this to each aircraft's flight dynamics though. And to add some randomness in maneuvers and pilot skill.
Then again, I think even Falcon BMS doesn't support mock dogfighting against AI aircraft, so it's no biggie.

And of course, doesn't require anyone to edit the panel.cfg file either.

That's a beginner level skill which I expect every user of this gauge - or MSFS in general - to possess.

 

[JimmyRFR]

Learning C++ or C# is on my "Tomorrow I'll start" list.

I've never mucked with C++ gauges, although I should give it a try I guess. I don't think you can really do gauge stuff in C#, but applications which interact through SimConnect or FSUIPC (much easier) fit the bill perfectly. This is one of those times to be honest, but it does add a layer of 'outside the sim'.

The adversary AI routines sound interesting. For personal use or under contract?
A small mock dogfight module would be quite something. Take of with an AI aircraft, fly in formation to a designated area, split up and separate 5, 10 or 20 nm, then dogfight until you or him "tag"s the other with an invisible curved lase beam or an invisible missile. After either one is tagged, you can choose to go again or go home.
Would be difficult to scale this to each aircraft's flight dynamics though. And to add some randomness in maneuvers and pilot skill.
Then again, I think even Falcon BMS doesn't support mock dogfighting against AI aircraft, so it's no biggie.

Personal use. My goal was to define a set of engagement profiles for how the AI would interact with you, and have something like control or engine failure be triggered if he managed to get inside a defined envelope. Of course, at the time, my overall goal was to make something interesting to shoot at with TacPack. The basic concept worked well enough, but AI is limited to turns, climbs and banks that suit an airliner well, not a jet. So my next step was to completely take over the AI aircraft, essentially using my own program to 'fly' it. Because all you're doing is moving the object through the air in the sim, it can perform however you want it to perform. Annnnnd that's where stuff got very complex, very fast. Trying to simulate realistic performance had me looking into using JSBSim as an external FDM; I still think it would be the best bet, but to do it properly would likely take more experience and time than I can muster.

Anyhow, testing was fun, even with a non-realistic AI flight model. I recall the first time I set up to have an F/A-18 to line up on my six; I was flying the trike for the heck of it, trying to pan the camera around to see where the heck the AI jet had gone, when all of a sudden it overtook me and passed like 50 ft overhead.... it then would break to one side or another, and circle around to line up for another pass. Was pretty wild.

 

[Bjoern]

Sounds wild!

If the AI can't do proper ACM, it won't probably make much sense to expand upon that.




In other news:
Added the reputation system. Pilot proficiency is now an indirect influence factor on the well-being of your aircraft.
As with just about everything else, the bonuses and penalties can be scaled at will.

The gauge also made the transition from Tom's 727 to Milton's DHC-7 without a hitch.

 

[Bjoern]

Let's see...

- Quadruple engine fire
- Gear stuck in various positions
- Asymmetric flap failure
- Aileron, elevator and rudder controls damaged

Just playing with XMLTool's Simvars, don't worry. A really bad day with the maintenance tool will only be 90% as bad.

 

[RyanJZ]

Let's see...

- Quadruple engine fire
- Gear stuck in various positions
- Asymmetric flap failure
- Aileron, elevator and rudder controls damaged

Just playing with XMLTool's Simvars, don't worry. A really bad day with the maintenance tool will only be 90% as bad.

I don't think the crew is gonna be able to walk that off.......

 

[Bjoern]

I don't think the crew is gonna be able to walk that off.......

It was actually still mildly controllable until I've introduced the asymmetric flap failure.




The failure generation logic is done, now I just need to tie in any kind of failure that is possible for each system. Hence my test.

 

[RyanJZ]

Bjoern this is gonna be a fantastic addon..... it looks like it's coming along great!

 

[Bjoern]

Still a lot to do. The triggering the right failures at the right time is quite complex in itself.