Aircraft ROC Review

[herwin]

ORIGINAL: m10bob

While not every plane can turn on a dime, and not every plane is fast enough to "shoot and skoot", ALL planes must lose altitude to make any turns whatsoever. This is a principal of aerial physics.
The plane that loses altitude less by regaining altitude in quicker climbs has a major advantage, enough so that the over-all combat survivability is affected.
As Sid stated, ROC also affects an interceptors' ability to get up with oncoming enemy bombers.

Not true. Maximum sustained turn rate is defined as the maximum degrees per second you can turn without losing altitude. This is usually at a moderate air speed combined with maximum power output. I spent several months getting this stuff right in my PhD thesis work.

[witpqs]

If the maneuver rating really is the only database value used for aerial combat (other than weapons) then removing the speed component from it would be catastrophically wrong.

[Dili]

If the maneuver rating really is the only database value used for aerial combat (other than weapons) then removing the speed component from it would be catastrophically wrong.

 
I didnt understood it that way.
 

No.
Speed is a separate variable.

 
I understood this as: "Speed already have a field so no need to put it in MVR."

[el cid again]

ORIGINAL: herwin

ORIGINAL: m10bob

While not every plane can turn on a dime, and not every plane is fast enough to "shoot and skoot", ALL planes must lose altitude to make any turns whatsoever. This is a principal of aerial physics.
The plane that loses altitude less by regaining altitude in quicker climbs has a major advantage, enough so that the over-all combat survivability is affected.
As Sid stated, ROC also affects an interceptors' ability to get up with oncoming enemy bombers.

Not true. Maximum sustained turn rate is defined as the maximum degrees per second you can turn without losing altitude. This is usually at a moderate air speed combined with maximum power output. I spent several months getting this stuff right in my PhD thesis work.

I remember getting headaches - and I was just reading routines already written. No need to invent anything - just understand what had been done. It is not entirely obvious - or easy to follow. Lots of things IRL - including that the air itself is virtually never "still air" - sometimes very not so.

Nevertheless, it should be pointed out that the original statement is more true than false for air combat maneuvers. You don't make them at "moderate speed" - and that is the rub.

[el cid again]

ORIGINAL: witpqs

If the maneuver rating really is the only database value used for aerial combat (other than weapons) then removing the speed component from it would be catastrophically wrong.

I regret to say I am forced to agree with this - which is why we have not done so. But it isn't the ideal way to do things.

[el cid again]

ORIGINAL: Dili

If the maneuver rating really is the only database value used for aerial combat (other than weapons) then removing the speed component from it would be catastrophically wrong.

I didnt understood it that way.

No.
Speed is a separate variable.

I understood this as: "Speed already have a field so no need to put it in MVR."

And you should be right. But that isn't how it was done. This is a very simple system.

[Dili]

More noise El Cid. You said arent sure and no one knows,  now you already know. Sorry but that doesnt help confidence building.

[witpqs]

Dili - You wrote:

ORIGINAL: Dili

If the maneuver rating really is the only database value used for aerial combat (other than weapons) then removing the speed component from it would be catastrophically wrong.

I didnt understood it that way.

Would you please tell us how you know how the game engine works internally - what value it expects to find in the database?

[Dili]

Read what i wrote. You will see that is based in The Elf information.

[el cid again]

ORIGINAL: Dili

More noise El Cid. You said arent sure and no one knows,  now you already know. Sorry but that doesnt help confidence building.

Unless we (say you and I) get invited to write our own routine from scratch, it won't be possible to build it as we would like. Nor could we (you and I) know exactly what was intended, what was defined, what was used where? I fail to grasp your intent here? Being honest is ALWAYS a good confidence building measure. Being open about definitions, assumptions, evaluations are also ALWAYS good confidence building measures. I don't see anyone else doing that - officially or otherwise. What more can I do? And how is your comment helpful to any part of the process of getting things better than they are?

[el cid again]

ORIGINAL: Dili

Read what i wrote. You will see that is based in The Elf information.

And when asked how he knew what he said he knew - he didn't tell us. He didn't write the routines. He probably is working on what he was told - just as I am. He may have a sense of things from testing - just as I do. But it isn't information in some greater sense then - say - what the manual says - or what Matrix programmers have posted or written. I think he is substantially correct. But I also think he overstates what he thinks he knows - because those who read this stuff always throw out qualifiers he does not. Things like "the routines I have looked at - there might be others I have not seen". This stuff is not easy to read either - not like rading an essay. You can miss something easily. Particularly you can miss when the routine you THINK will be called is skipped altogether because of some test that passed (or failed) and branched you to an entirely different routine you never heard of. People who read complex, modern, undocumented, sphagetti code always have great respect for the limits of their understanding. And something written long ago by a person not in the discussion cannot be explained to us, in terms of design intent: we must guess. And things various folks have changed along the way may have surprising and unexpected impacts - which no one understands or could explain - even if you knew who to ask and they were free from non-disclusure rules/ethics.

IF we want to work on this at all - we have no choice but to do so like a doctor working on a human body. That is, we cannot see inside what is going on. There are ways we can test this and that. But there is no way to have absolute and total knowledge to the last decimal point. But we CAN have confidence in basic principles - including that being consistent is better than not - and having standards is better than not.

[witpqs]

ORIGINAL: Dili

Read what i wrote. You will see that is based in The Elf information.

He did not provide information on specifically what ROC the game engine expects to find in the database.

Saying what should be used or what you would use is nice - but only what the game engine actually uses in this case is relevant, because that is what we have to provide in the database.

[akdreemer]

ORIGINAL: el cid again

ORIGINAL: TheElf

ORIGINAL: Dili

The Elf since you seem to know the guts of Air Combat can you tell what data should go to build the elusive MVR(Maneuverality)? Since CLIMB doesnt count for air combat then it should go to build MVR (or power to weight ratio) and what about speed?

No.
Speed is a separate variable.

Try not to combine too many variables into one value. It tends to be too one-dimensional.

In spite of the fact NO ONE is doing this in WITP, I must say I agree with The Elf. About the only excuse I have for not going over completely to this point of view is that we cannot redesign the routines. At least we know that speed (and also cruising speed) are used at different points - even in combat related routines. But the maneuverability field DOES contain speed data. It may be it ONLY contains speed data - and that was the first suggestion I got from a programmer. SOME stock aircraft seem to use max speed/10 as maneuverability. I believe the original system was to combine speed/10 with ROC/500. By changing that to speed / 20 and ROC / 200, we changed the ratio - so I have moved in the direction of reducing the speed factor - if not getting rid of it altogether. Adding loading (wing and power) also diluted speed slightly more.

In an ideal world, we would go the way of The Elf: if we wrote the code we would separate speed and maneuverability entirely - and we would split horizontal and vertical maneuverability - possibly calling them ROC and turn rate. If we had the fields we might do this for (say) three different altitude levels (5000, 15000 and 25000 feet????). But we don't get to do that. [Where 5000 means 1 meter to 2000 meters, 15000 means 2001 to 6000 meters, and 25000 means 6001 meters and above]

Why redesign the wheel? There are plenty of good air combat sims out there? I would guess that at lest some have a following of fanatical 'accuracy' pundits. Why not get some of these on board?

[akdreemer]

Two additional factors that no one seems to be looking at. Dive speed and acceleration. By mid war maneuverability was not as important as the ability to pounce and escape, thus the energy fighters became dominant. Why else did the admittedly poorly maneuverable plane like the P-38 turn out to be such a deadly air-air plane?

[TheElf]

ORIGINAL: AlaskanWarrior

Two additional factors that no one seems to be looking at. Dive speed and acceleration. By mid war maneuverability was not as important as the ability to pounce and escape, thus the energy fighters became dominant. Why else did the admittedly poorly maneuverable plane like the P-38 turn out to be such a deadly air-air plane?

It's looked at.

[el cid again]

ORIGINAL: witpqs

ORIGINAL: Dili

Read what i wrote. You will see that is based in The Elf information.

He did not provide information on specifically what ROC the game engine expects to find in the database.

Saying what should be used or what you would use is nice - but only what the game engine actually uses in this case is relevant, because that is what we have to provide in the database.

Someone wrote above (probably The Elf) that I tried to read things too precisely and narrowly. And in general, that is a fair and germane thing to say. As a general rule, WITP is very simple, and semi-abstract as well. An effort was made to get routines that would yield somewhat plausable outcomes. Much less effort was made to get a good set of data for those routines to work on - although they DID open the data input process to the Forum so WE could work on the data and make it better. The point is - remember that the routines were written to be only ball park type generators of plausable outcomes. There was no formal software plan (as, say, you would write if you were in Russia, or even in Germany), there was no attempt even at written technical definitions, even for internal use, and there was no attempt to create serious user (never mind staff/tech support) documentation. Those choices - all driven by a need to keep costs and development time down - all say this was not the sort of thing that had people thinking about these matters in the kind of detail we now are. Then the produce went on through several generations of evolution - into more than one game system - and got worked on by a number of people who themselves didn't have any documentation or written guidence from the original program designer. It is probable that there is no way to know exactly what was intended by the several routines that may (or might some day) use this data? It probably does not matter that much either: this system is so robust you can often make it do things the designers never dreamed of.

Since this is an evolutionary product - one likely to go through at least one more generation of development - it is even possible we are entering data for routines that do not yet exist. Getting a good set of data that is relatively right for all types may become germane even if it is not entirely so at this point in time.

[el cid again]

ORIGINAL: AlaskanWarrior

Why redesign the wheel? There are plenty of good air combat sims out there? I would guess that at lest some have a following of fanatical 'accuracy' pundits. Why not get some of these on board?


[/quote]

From Matrix point of view, the answers likely include

a) They don't own the other routines - and would have to licence them - and pay for them;

b) The existing other routines not designed for WITP won't be written in a way that is compatable with it, in several different technical senses of that term;

c) Using any such routine would not then permit Matrix to claim ownership, and licence in its own right, nor to have non-disclosure agreements in the simple sense they can with propritary code; clearly Matrix likes to own its code - and to keep it secret - and so this would not be compatable with that philosophy of doing business.

d) There are probably a number of different kinds of routines required for WITP involving different functions related to air combat, AA combat, air-ground combat, etc. It is likely many of them have NO equalivent in other software. And whatever exceptions there may be are almost certainly not exactly what WITP needs.

[el cid again]

ORIGINAL: AlaskanWarrior

Two additional factors that no one seems to be looking at. Dive speed and acceleration. By mid war maneuverability was not as important as the ability to pounce and escape, thus the energy fighters became dominant. Why else did the admittedly poorly maneuverable plane like the P-38 turn out to be such a deadly air-air plane?

Actually - some of us (there is a PhD in the crowd, and I not only have worked on this at a USAF SIL, I have collected the dive speeds for all Japanese aircraft - including many we do not use) - are well aware of these - and yet other - factors.
But they are difficult to obtain data for. And we need data on hundreds of different aircraft, some of which never flew at all, more than a few of which do not have complete data records or have contradictory data records.

However, I think this model DOES include acceleration insofar as ROC is directly related to it. But dive speed is very tricky: not only do I have no idea how to calculate it from basic data (like weight), I have no idea how to use it in a simple air combat model like this one? I can use it in a much more complex model - where we figure out when a plane is diving - and then apply measured data to where it goes next. But how to do it here? I have no idea.

[m10bob]

ORIGINAL: el cid again

ORIGINAL: AlaskanWarrior

Why redesign the wheel? There are plenty of good air combat sims out there? I would guess that at lest some have a following of fanatical 'accuracy' pundits. Why not get some of these on board?

From Matrix point of view, the answers likely include

a) They don't own the other routines - and would have to licence them - and pay for them;

b) The existing other routines not designed for WITP won't be written in a way that is compatable with it, in several different technical senses of that term;

c) Using any such routine would not then permit Matrix to claim ownership, and licence in its own right, nor to have non-disclosure agreements in the simple sense they can with propritary code; clearly Matrix likes to own its code - and to keep it secret - and so this would not be compatable with that philosophy of doing business.

d) There are probably a number of different kinds of routines required for WITP involving different functions related to air combat, AA combat, air-ground combat, etc. It is likely many of them have NO equalivent in other software. And whatever exceptions there may be are almost certainly not exactly what WITP needs.

[/quote]
--------------------------------------------------------------------------------------------------------
Since "mods" are not the property of any corporation, and are offered for free, I suspect we could put ANY value in ANY box in the editor and the program would be smart enough to follow whataver we enter.
In the "maneuver" box, I doubt the computer is figuring on which 5 apples the value represents, but is literally comparing the number to the opponent plane, verbatim.
Therefore, it is up to us to determine what values go where.
We have proveable values for ROC, Service ceiling, speed, size, weight, wing area, etc,and I believe Alaskan Warrior has a good point.
Lots of time went into producing other wargames and their rules, and we might look at how THEY compared apples to oranges, and find common ground.

I believe the air module (stock) bears a re-work, if for no other reason than the fact that I found some of the planes using *identical* values as the Gunston book, but then other planes were just in somebody elses playground, not even close to the same point of comparison, (or verifiability with ANY resource I have found,yet.)
This last is a bold statement, but I have given my sources, all readily (and cheaply) available from amazon.com...

BTW, this is the first thought out (and protracted) discussion with different viewpoints I have seen on this forum in a long time, which was able to have such great talent and ideas, without personal vitriolic comments and non-productive agendas entering the discussion.

Hell, it's an educational experience![;)]

[Dili]

He did not provide information on specifically what ROC the game engine expects to find in the database.

 
He said it. That you might dont take his words at face value is another matter, and i agree that an official "real manual" would be better.
 
I'll put in WITM40 MVR:
 
Speed vs power: to calculate drag
power vs weight: to calculate acceleration( the ROC issue made me think of averages in this too)
wing loading
dive speed (drag and weight?)
 
Still not tought of weight this factors will have for all that (power vs weight will be the most important) and i'll have to manage a soup that will expel numbers similar to those in data base.
 
 
Dunno if this would help:
http://avhistory.org/communityserver/default.aspx