Advanced Engine Reliability in TF5.0 - Need of campaign/mission builders

[Thaine]

Hi chaps, thanks for the feedback. Just a suggestion (and that's all it is) but as the thread has been closed on the ATAG forum would it be worth maybe starting a thread in your forums regarding the suggestion about engine failure (away from this one) and therefore let the mission builders explain what they would require/hope for and the explanation for why it would be useful?

I am not trying to limit/stop or diminish the responses to this thread but maybe if someone could put a post together regarding what would ideally be required if this feature was a server side option, then at-least I have a point of reference to explain the community feedback to those who can enable the features?

I do appreciate the points of view put across here (and the disgruntlement) but if there was a thread started voicing clear objectives and reasons for the requests/suggestions then I will at-least have viable evidence to reinforce your opinions and point of view with the team.

I honestly can only try on your behalf but will do my best to give you a voice. (as always I cannot promise but I will put your points forward as best I can).

Cheers, MP

You hear him chaps. Use this thread to discuss and put forward your needs regarding engine failure. Keep it clear so Mystic a chance to make him heard within TF.

[LuftAsher]

IMO the way to do it properly would be:

- Collect data on specific aircraft across multiple sorties. This data would need to include operational time, engine-settings during the flight, use of WEP, etc. It would also need to track the status of each relevant aircraft system at the end of each sortie. This would tell the game how hard that aircraft was pushed over the course of that sortie, and allow it to make the necessary considerations.

- Properly and accurately apply this data to the aircraft in question, and allow wear and tear to accumulate logically over time.

- Compare operational time to historical maintenance schedules, or allow maintenance schedules to be set by the server. Additionally you could allow pilots to put their aircraft in for maintenance manually after X amount of flight hours, or whenever they like.

It sounds like it'd be really complicated to do properly, and would only be truly useful for things like ACG, Storm of War and other persistent campaigns. Air quake servers like ATAG probably wouldn't get much out of it without some serious overhauls to the way they do things. Their missions run for what, four hours or so each? And many people fly their aircraft until it's a smoking hole in the ground, so you'd be tracking a lot of aircraft with 2-3 flight hours on them in more rapidly diminishing numbers as the furballs start up and people start getting killed.

Perhaps Team Fusion should consider this as something to do as a mini-patch AFTER TF 5.0 as it seems like something that will take a good bit of experimentation to get right, and even then, I don't imagine it would be implemented widely.

[Mysticpuma]

Hi LuftAsher, thanks for your reply. Already though the thread goes off track with the first reply

"Air quake servers like ATAG". What has that to do with what Mission Builders require?

"Perhaps Team Fusion should consider this as something to do as a mini-patch AFTER TF 5.0". Perhaps we will.....but what has that to do with what Mission Builders require?

So if possible, rather than speculation and opinion of what is and isn't wrong, could the thread be used for the purpose it was created. Simply put, if there is to be a chance of getting something required to implement and utilise the engine failure possibility, then can we just use this thread as a "this would be useful/required/great addition" than another reason to have a dig? I get that there are gripes but even when I/TFS try and do something constructive it seems there is always a need to chip in and have a pop

Cheers, MP

[Thaine]

Alright, I try my best Mystic.

This is my wishes and needs from a database/pilot-profile/administration-perspective. I think primarily about it's uses in the ACG campaign, maybe even ACG-public server (atlhough that's still in build up). I think about a persistent airframe approach where the status of each airframe can be read out, stored and altered in a database, and reapplied to the airframe, regardless of pilot.

So we would need:
-Functions to read the status from the server.
-Clear documentation of what statuses represent, how they interact in game, etc...
-Functions to apply the status again to any newly created aircraft in game.

Nice would be as well, if feasible:
-Wear does not only result in a higher failure rate, but rather decreases the power output of the engine. That is you do not get a higher chance of total failure, but a worn out engine doesn't produce the full boost, stalls from time to time etc...

My idea of what I would use it to:
Squadron aircraft used in the ACG campaign would get a history. Their status would be stored in our database after each campaign sortie. The status would be displayed on our database webpages, so that Commanders can issue maintenance to fix some or all of the wear or order new aircrafts. Pilots would be assigned aircraft before the next sortie with the corresponding history.

A black-box system that we can't control and don't understand will most likely be switched off.

[LuftAsher]

Hi LuftAsher, thanks for your reply. Already though the thread goes off track with the first reply

"Air quake servers like ATAG". What has that to do with what Mission Builders require?

I wasn't having a dig, MP. I was simply stating that there are servers that simply don't seem like they'd need/want a system like this in their current form. It's not just ATAG either. Danger Dogs and LeadFarm are somewhat popular servers that provide a sandbox within which to dogfight.
I never implied that this was negative, I'm not an elitist that looks down upon everything except persistent, historically accurate campaigns. I'm an avid War Thunder player for fuck sake.

My post was not simply 'another dig' as you put it. I outlined my thoughts on the matter clearly in terms of the kind of data I think would need to be collected for such a system to work properly. I don't know if you disagree with it or not, but please don't dismiss it as nothing but blind hate simply because you object to some of the terminology I used.

If there's anything else you'd like to say about it, you can PM me. But in the interests of not derailing the thread, I'll leave it at that.

[Dickie]

The value lies in tracking aircraft abuse over an extended period, not on quick tight dogfights or single missions. Sure, an abused engine should have a part fail if utterly abused but you must understand that this isn't about single abuse, it's about maintenance. For instance, we know that the pilots notes for the Spitfire and Hurricane using the Merlin II/III refer to only using 5 minutes at 12lbs, and we know that this had to be reported to ground crews post flight. But what does this mean? People think it means that the engine should overheat after 5 minutes use - that is nonsense. The Merlin II and III could literally go ALL DAY with 12lbs boost, but the use caused greater heat and fatigue, and that COULD lead to a failure of some sort. As long as the engine was cooled it would be fine. I say all day literally because the recommended servicing of the Merlin II and III engines were 100 hours without use of the ABC and 10 hours using 12lbs boost. Yes, that's TEN HOURS of full boost, and that doesn't mean it'll fail after that, it means it is due for overhaul. The Merlin XII engine in the Spitfire II doubled this to 20 hours, it was built to handle the higher boost pressures, such as continuous 9lbs. (Source: Spitfire The History. Morgan & Shacklady)

So what do we need? For general servers I don't see a problem with putting in the randomiser as a server option and also allowing pilots to set their own aircraft condition before flight, or forcing it from the server side or randomising the engine condition as a forced option. I also think that engine condition should be a part of a server set up, probably best suited to co-op style missions which help set the scene. This would also need to be available in the FMB for AI or you may be fighting prime AI in a delicate machine. The FMB options need to be fairly easy to set, a bit like the skills are at the moment. Failures will not be popular with players in furball servers though I think!!

For those of us who run longer campaigns or intend to run a server where there is a war of attrition or where there is a pilot career then we presently do this by our own database and tooling which communicates with COD so for us to make use of such a feature (and we'd love to!) then what we need is get and set methods for the aircraft condition or parts which would affect maintenance. We would need COD to know how long boost was used for, or a way to get aircraft data so that we could view it, then we can run a maintenance program and war of attrition.

A group like ours can create such a database and use it, and we're willing to share, but I'd hazard a guess that others don't have that luxury so you may wish to create this as part of the game, an API and basic DB and interface where server owners could use this functionality. This is a suggestion, we will be fine with the API, but if you dont' allow us to get and set data than your whole concept is pretty useless to us tbh, there's no value in us randomising or hoping that individuals make their aircraft crap for their mission.

Oh and we need a decent wiki on the API so we can use it.

Above all, WE WANT TF5 ASAP. We do not want anything that delays deliver of TF5 in any way whatsoever. I would prefer stuff removed in order to release TF5 sooner, then further patches, chargable or not.

Can we have an interim DLC "WTO 1941 pack" after TF4.5 please? Chargeable, £30 or whatever for 109F1/2, Spit Va/b, Hurricane IIa/b and Wellington - all non tropical (therefore do not impact TF5 MTO)

[Donkey]

What Thaine says. If we are going to have this kind of thing modelled, then we need to be able to get/set and understand it in order to make the persistence work for us. Will combat damage also be factored in? Because if so it shoulld also be get/set-able. I.e. if someone takes a couple of rounds to the engine but manage to glide home, that airframe should not be flying again until the engine has had some serious work done on it.

I would say, however, that this could end up with a lot of complex code, both within IL2 and within ancillary tools and databases, for what could, in effect, not be a huge difference to the "feels". And I also suspect you will end up with a mountain of balancing issues and complaints from players if they feel that the RNGod has looked dimly on them. Hic sunt dracones.

D

[Wolverine]

Others have positioned many of the same points I have already. I'll just outline a few reasons to have the failure or wear and tear rates / percentages adjustable by a mission designer:

Weather and conditions. North Africa is being added as a terrain. Perhaps a mission designer wants to simulate the more grinding conditions of keeping aircraft serviceable in the middle of sandstorms and heat waves and the default settings don't represent that well enough.

Missions that follow a narrative and want to ask a player to attempt a mission with a severely over-worked aircraft that needs to be babied.

For a campaign where you want to use real historical temperature/humidity data over, oh I don't know the Battle of Britain, and make small adjustments to the rates of wear for each of those days.

It's possibilities like the above that keep some of us mission designers interested in working with CloD. Taking functions that are available to edit and seeing what interesting things we can do with them. So asking for tools to edit features with GET and SET options really goes across the board for any kind of new feature or option built into the game.

So even in potentially single player situations that take place during one mission, narratives designed by a mission builder, editing the values can have a benefit to us.

I agree that this is a 'nice to have' at this stage, though. I know sometimes a resource (read programmer) is not tied up at every given stage of development so maybe there's some room/time for someone to look at this, but there are lots of other programmer type things that we'd like worked on ahead of this type of thing (AI, unit pathfinding, etc.).