Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[WxTech]

Back in 2013 BT~wasted introduced a mod to generate 13 different random failures to the engines, fuel tanks, oil systems and gear, which acts on AI planes as well as the player. It seemed to go no farther than 4.10.


This past day I've been incorporating this into my B.A.T. 4.0 game. It's easy enough, requiring only to add some code to Aircraft.class:
- in the (currently empty) method rareAction(), and
- adding two new methods.

I've been tweaking things, of course. 


For starters, the invoked methods setEngineStops (kills the motor) and setReadyness (damages the 'crank case') were performed only on engine #0, in spite of a random engine between #0 and #3 being selected for other actions. I've elected to do these two actions on any of the actual engines selected, in the way all other actions are.

--------------------

Secondly, no matter the plane's actual engine count a random engine number between 0 and 3 is selected. For planes having fewer than 4 engines this means that the chance of damage/failure is lessened by the ratio (actual engine count / 4). (Except for the two aforementioned actions, which are always operated on engine #0). For example. A single-engined plane has only engine #0. If the randomly selected engine number were 1, 2 or 3, the action will not be performed, and in this case the chance of the action is 1/4 the chance of damage to a 4-engined plane. In other words, a 4-engine plane could potentially have as many as all four engines damaged by the time a single-engined plane has had its engine damaged.

And for planes having more than 4 engines, those numbered beyond #3 will never be harmed. An 8-engined bird will have only the 4 motors on the port side damaged.

Therefore I've taken the actual engine count into consideration, however many they be.

--------------------

Thirdly, damage was done only to fuel tank #0, even though a plane can have up to 4 tanks (numbered 0 through 3). I've elected to randomly select from the 4 possibilities. Of course, this means that when fewer tanks are present there will be a concomitant reduction in the chance of damage, which I think is OK. Most planes have more than a single fuel tank, at least for WW2 and beyond.

--------------------

The code was structured to read the user-set value for the failure rate from the [Mods] section added to a mission file (not conf.ini). I like this approach because it permits flexibility. Instead of a 'universal' failure rate applying at all times, one can decide on the failure rate based on the theater, the date, or any other criterion. For example, a static campaign for the Axis could have the failure rate worsening in the later stages. It does of course require to add the [Mods] section and failure rate value to every mission as desired, which can be a lot of work!

To make things easier and universal, I could have conf.ini queried for the failure rate value as well. Indeed, it would be possible to add also a second conf.ini entry that selects between a 'universal' value or a mission-specific value. Then a query of both conf.ini AND the .mis file would be done, and whichever the player wants to use will be given primacy. This would allow to enjoy the suffering failures for minimal effort. 

In other words, conf.ini could have FailureRate=7 and the .mis file could have FailureRate 15. If conf.ini had an additional entry something like FailRateSource=0 it would use the ('universal') conf.ini entry if present, and if FailRateSource=1 the .mis file entry would be used if present.

--------------------

The mod was set to be in effect only when one enables the Reliability difficulty option. As far as I can discern, this difficulty setting applies to motors only. And so this random failure mod under discussion handles additional systems not affected by the Reliability difficulty setting. I'm wondering if it would be worthwhile to allow to have this random failure mod operate whether one toggles the Reliability difficulty option or not. The main reason I'm thinking this is because of the 'double jeopardy' of damage to engines when both of these schemes are working simultaneously. In other words, the Reliability difficulty setting could be set to OFF so that motor damage is confined to just this random damage mod.

--------------------

I tried some runs with the failure rate set at 100 (the maximum permitted). On winter and desert maps the rate of failure is twice that for all other maps (cold and dust taking their toll), and so I did this on a Pacific map. At roughly 5-6 minute intervals a failure occurred, although this was with the two causes of motor damage working together. This suggests that a failure rate set to 10 should have some damage event occur about every 50-60 minutes (25-30 minutes on a winter or desert map), although likely on a shorter interval for motors due to the two damage schemes operating together.


Thoughts?

[Kopfdorfer]

You go girl !
I love your interminable curiosity to stretch the game to its max.
Another fantastic development from northern Ontario !

Kopfdorfer

[GeraltNotRivia]

I would also like to see this!

As you said, it would be interesting to set some higher failure rates for mission, where you fly plane without proper maintenance, because lack of spare parts or enemy has made attack run on your airport and plane has taken some damage in process.

I would still keep this mod operating with only reliability difficulty option activated. That way I don't have to disable mod or change settings every time I want test something without need to worry about random failures.

Is it possible to make failure rates higher if plane has has seen a lot of abuse? More stress to frame, more heat in engine, wrong supercharger and fuel settings, harsh climate (this already seems to be the case?), and you get higher failure rate than when flying in most optimal way?
Current vanilla reliability difficulty doesn't seem to affect for every wrong decision you make except engine heat and stress to frame.

[Dimlee]

From the user perspective...

Having the extra "switch" for such a mod would be nice, beyond the current Reliability in the Difficulty Settings would be nice.

If the maximum failure rate is 100 and at the rate of just 10 the failure occurs every 50-60 minutes... Isn't this too harsh for those who fly long missions?

Just curious - can those failures be repaired with RRR (rearm-refuel-repair)?

[Whiskey_Sierra_972]

Any chance to verfy if the aircraft.class between BAt 4.0 and 4.3 are the same?

Aircraft.class of BAT 4.3 is dated 10 august 2021 and have 91.595 bytes

[Orge Schwab]

If the maximum failure rate is 100 and at the rate of just 10 the failure occurs every 50-60 minutes... Isn't this too harsh for those who fly long missions?

That's what I was thinking. One has to remember that for the most part aero engines in service were very well maintained as lives depended on their operation. And there was rigorous quality control of parts, except where dispersed production due to war damage or lack of materials intervened. Merlins, for instance, were renowned for being very reliable. It was not uncommon for Bomber Command aircraft to perform 10-hour flights to Germany and back without any engine problems - night after night. Similarly, even longer flights of 15 hours over the Bay of Biscay were routinely performed without incident.

So it's a nice idea, but it needs to be give a nod to reality and make mechanical failure an unexpected, somewhat rare event. (Yes, late war Axis scenarios, 1941'42 scenarios for Russian aircraft and theatre specific campaigns might show more prevalence of mechanical problems and the .mis file would be the place foir that).   

[WxTech]

I have incorporated a conf.ini option to choose whether to require the Reliability Difficulty setting be enabled or not.

And I have added another conf.ini option to choose which failure rate value to give priority--that in the .mis file or that in conf.ini. And so one could have a small number of missions containing such a value, and another value in conf.ini. The priority could be given to the .mis file value when present, and if not present there the conf.ini value will be used.

As to the failure rate, at the moment one can go as low as 1 out of 100 (and set any integer between). I can bias the scaling toward a smaller chance overall, so that when set to 100 individual events might occur at an interval of, say, 15 minutes. Meaning around 150 minutes (2.5h) for a value of 10, or 1,500 minutes (25h) for a value of 1.

Incorporating this into other game versions would be a snap. Anyone set up to compile the source Java for Aircraft.class can simply copy the code I've made up. I'll provide it shortly, along with the related conf.ini and .mis file entries.

[tomoose]

WxTech;
apologies if I'm going over old ground here but ref the fuel tanks...  As you probably remember me whining before about the multiple fuel tanks being treated as 'one' by the game.  i.e. a fuel tank hit on a B-17 regardless of where on the aircraft meant that you were going to run out of fuel. So a hit on one fuel tank is essentially a hit on ALL fuel tanks (unless the fuel tank sealed itself) because the game simply drains ALL the fuel in the aircraft when any tank is hit.
All that to say that if a random fault is a fuel leak (which won't/doesn't seal) then the pilot has really no choice but to abort as there is no option except carrying on with the knowledge that the plane will definitely run out of fuel.

I guess what I would suggest would be keeping a random fuel fault as a 'standalone' on/off option if you get my meaning.

Not sure if I'm making sense. 

[WxTech]

I was hasty in suggesting success at reading entries from conf.ini. I had just written the code and not tested carefully enough. It turns out that I can't read from conf.ini from this Aircraft.class. Here's a common implementation

Config.cur.ini.get("Mods", "ReliabilityDiffRequired", 0)

Is there any way I can query conf.ini from Aircraft.class?

[WxTech]

I have toned down some of the imparted damage, such as in cases where the damage state was jumped up 2 or 3 levels in one go--that's kind of severe. I've limited to damage increments by no more than one damage level. Furthermore, in some cases the damage is now executed ONLY when there is currently no damage in effect. I've eliminated two (of the 13) systems acted upon, because they were kind of redundant, they being "crank case damaged" and "oil tank leak". For the engine stoppage and gear failure I've added an additional factor by which to reduce the probability of occurrence.

These few measures notably reduce the accumulation of bad damage in a hurry; the impact is of a gentler 'slow burn' instead of a more calamitous shock.


As to fuel leaks. For planes modeled as effectively having self-sealing tanks, there is always a chance of the leak fixing itself. To be sure, by having all tanks susceptible to leaks this can get out of hand. One reason for my inclusion of all tanks present is to keep the leak effect from originating always in the same place.    To be sure, for planes which cannot have leaks seal themselves this is a sure killer.

It's easy to add an additional probability reduction for any of these systems, as I just mentioned having done for engine stoppage and gear failure. Fuel leaks could be further reduced in probability by, say, a factor of four, making the interval of their happening 4X longer than for most of the rest. Furthermore, a test could be randomly undertaken, but with a rather higher probability of occurrence than the leak, to command the leak to stop. In this way any leaks would be of mostly short duration. Anyway, perhaps it's best either ignore leaks or to give them a really small probability.

[Mick]

... this new mod is a very good idea, as usual ...! 

... but I suppose this new mod would only work for the player's AC, and not other friendly or enemy AC ...? 


... maybe guns jamming could also be implemented, as this was quite common ... 

I know for sure that I have this working on my 4.09 Bf-109E-3 (optional nose gun) ...

[WxTech]

I've been reminded of something I discovered a while back.

For planes not having self-sealing fuel tanks, the code in the plane's hit bone method has the undamaged fuel tank undergo a damage increment by at least 2 damage levels. This means that for an undamaged tank the first damage state will be no less than the heavier fuel leak, bypassing the first, lighter leak. In all instances, for all planes, a fuel tank set to the first, lighter leak will have a chance to have the leak sealed, unless the fuel all runs out first.    The time interval is usually not so long, lasting roughly 1/2 to a few minutes.

As you can see, self-sealing fuel tanks are NOT specifically modeled. Rather, those tanks are never set to the lighter leak damage state which can be made to stop, instead being set to the heavier leak state or worse, for which self-sealing is never possible--for any plane.

Here I'm only establishing the lighter leak, and only when the tank is undamaged. Therefore it has a chance to seal itself already, and I have added code (with a higher probability than makes the leak) to stop the leak I've initiated. Additionally, my code seals ALL small tank leaks if two or more are active and one or more of them have been caused by me.


I've not looked into the matter of gun stoppages at all. Aircraft.class might not be the best place to deal with this. Wherever gun jams are already handled would probably be better.