Print

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

[vonofterdingen]

I can't think of any way to answer part 2 of question without testing some existing missions. Like the others here I have always set formations and rendezvous points through waypoint manipulation.

[SAS~Storebror]

Yes, I think the conclusion is: Don't touch it.

We could put it even simpler.
The main equation of a set waypoint's speed vs. the "VmaxH" value, which is used to form the base throttle setting, is wrong in IL-2's code already:

Code: [Select]

float speedByVmaxH = this.AP.way.curr().Speed / this.VmaxHThe idea is clear: The closer the desired waypoint's speed is to a plane's Vmax, the higher the initial throttle setting shall be.
That much, that good, but:
"this.AP.way.curr().Speed" is IAS.
"this.VmaxH" is TAS.
And to make matters worse, VmaxH is just Vmax at "HofVmax".
On the deck, the maximum speed would simply be "Vmax".

So in order to follow the game's intention, but to do it right, we would have to create the fraction of current altitude vs. "HofVmax", interpolate between "Vmax" and "VmaxH" according to that fraction, then convert the result from TAS to IAS, and then calculate the equation compared to the current waypoint's speed.
Easy fix, but again: It would alter the speed of all flights on a mission.
And that, I'm afraid, kills all existing missions where the mission builder spent hours to counter the wrong ingame calculation manually before.


Mike

[genXgamer]

Mission builders use a method called trial and error.

Here's some of my thoughts when it comes to AI formations.

• AI fly at 5 kph less than what you set them to fly.
• If they fly over hilly or mountainous terrain you have to subtract the terrain height from their set altitude.
• Aircraft flying at higher altitudes need to have their speed reduced.
• If there are turns then the aircraft on the outside of the formation need their speed increased and opposite for those on the inside.

That's all I can think of at 04:30 am.

[Kopfdorfer]

Lots of interesting info and observations in this thread.

Concensus seems to be that most mission builders seem to have resorted to
the tried and true tweak and check and retweak method when manipulating
waypoints for large formations.

Uber Demon's newest UQMG looks interesting.

For whatever it is worth , Storebror , I say if there is something you can fix regarding
this ( setting speeds which work for multi aircraft formations at varying altitudes ) , I would say fix it.
My feeling is the community will adapt to the results.
Yes , it may have some negative effects on some pre-existing campaigns and missions ,
but the other side of the coin is that it may spur some builders to come up with new
missions and campaigns.
Those that really love an old classic campaign will tweak it to work within the new parameters.
It seems to me this is what is already done for good materiel that is made for a certain modpack
to make it function in another anyhow. I don't see the difference.

Looking forward to whatever improvements are implemented.

Kopfdorfer

[vonofterdingen]

I would disagree with you on this one Kopdorfer. I appreciate the sentiment, but we have thousands of missions on this site alone, not to mention those generated by products like DGEN and DCG. Rendering some or all of those missions inoperable would be a serious blow to the community. Sure there are some mission builders left that could make the corrections, but the number of individuals able and willing to do those tasks is dwindling every day, and the number of fixes that would need to be performed is daunting.

[Frankiek]

Maybe the speed fix could be arranged as a JSGME mod so that if you play older material it won't interfere. In fact it would be nice to escape from all those mission tests to synchronize different flights.

[UberDemon]

What's worse, AI uses a power setting code which makes big planes miss the set speed by quite a bit. There's an initial power setting that depends on the ratio between waypoint speed and "VmaxH", the maximum speed at altitude from the flight model. On top of that initial power setting, the game takes the difference between waypoint speed and current IAS, multiplies it by 0.1, and subtracts the current forward acceleration multiplied by 3 from it.

For instance, I've set a flight of B-29 to cruise at 7500m, 525 kph TAS = 350.09 kph IAS (in IL-2's world), and this is the result when speed and altitude have settled:
Altitude: 7586m
Initial power setting: 58%
Adjusting by WP speed vs. IAS and fwd. accel.: +19%
Final power setting: 77%
TAS: 505.39 kph
IAS: 335.31 kph

This in turn causes AI planes to miss the "perfectly" aligned IAS speeds of given waypoints depending on the altitude difference between them, and it makes the planes miss the pre-calculated times on waypoints the further they are.

This brings us to a couple of questions:
1.) Is it worth trying to make AI meet the set IAS from waypoints? I reckon it is. Should be doable.
2.) If we do that, will it mess up existing missions? Possibly, yes, because AI planes will no longer miss the set speed, i.e. they'll travel at different speeds than the ones when the mission author tested the mission.

It's a bit of a pickle... any thoughts?


Mike

You are probably right that changing the FM for the flight engine may end up messing up existing missions quite a bit, and I'd say there are hundreds if not thousands of missions out there.

So a suggestion I have is not the best solution but if there is a way to create general equations, something that can be summarized, I can implement the calculation in UQMG to at least display what the desired or predicted speed and altitude are.

Since you figured out there is a relationship between the altitude and speed, I could at least display that if you have a flight in a section that is at 2500m and flying at 300Km/h, it really means 2595m and 295Km/h (I pulled these numbers out of a hat...).  The calculation would be simple enough to display.  Even if it is not perfect, if it is better than the info in the IL-2 engine, at least the mission designer could have an idea of the relationship between what they enter in UQMG, and what the results will be in the mission.

Just a thought.

[FL2070]

A possible solution to this: you could have a new .mis parameter in the [Mods] section called "UseNewSpeedParams" or something.

By default, when opening a old mission that doesn't specify, this parameter would be set to 0, and if you open a mission and save it again without changing anything, it would be also set to 0. When creating a new mission, it would be set to 1 by default. It could also maybe be changed manually in some menu or something.

It is a more high-workload solution, but it would definitely solve all possible issues created by this change.

[SAS~Storebror]

A possible solution to this: you could have a new .mis parameter in the [Mods] section called "UseNewSpeedParams" or something.

This is exactly what I'm thinking about.
It could become a full-blown FMB checkbox triggering all the fancy stuff under the hood.
Maybe "UseNewSpeedParams" doesn't really cut it as we will also need to touch formation and other AI parameters, so "AI_Mode=2024" might fit better and gives us room for further improvement.

Now that this needs a careful implementation and thorough testing, I will put it on hold for the time being and get back to it on a later Ultrapack patch.

we have thousands of missions on this site alone, not to mention those generated by products like DGEN and DCG. Rendering some or all of those missions inoperable would be a serious blow to the community.

Thinking of the missions we have on our official SAS Gameserver already causes headaches when I think of messing with timings there.
I agree, this is a no-go.

if there is a way to create general equations

I'm afraid it's not that simple.
As lined out before, the amount by which AI misses given speeds depends on parameters from the flight model.
Some parameters that clearly stick out, like "Vmax", "VmaxH" and "HofVmax", but also the whole .emd plays a role here, because in the end there is a gap between the game's assumption of the achievable speed according to the three values stated before, and the speed it would reach ingame for real depending on the power curve from .emd.
There's literally no way to predict the magnitude by which AI misses a waypoint's speed using the current implementation.


Mike

[HaFu1939]

A late contribution to the discussion... (I'm currently building another mission...). As far as I know, in FMB it is necessary to enter IAS (+10km/h [flying German planes I’m used to think in km/h]), depending on flight height and temperature.
BUT! I remember that on some newer aircraft (I can't find an example now) the speed is to enter in TAS.
For many years I've calculated every mission like this and I've always been satisfied with the result... I don't see it as a problem, but as a feature.

[UberDemon]

Copy Mike,

If it is a parameter in the mission I can figure out later how to incorporate it in UQMG.

[SAS~Storebror]

BUT! I remember that on some newer aircraft (I can't find an example now) the speed is to enter in TAS.

I'd really love to get to know an example where the speed works in TAS.
Looking at AI code, nowhere ever they make use of IAS<->TAS conversion.
The only reason for TAS to apply at spawn time is that stupid AI calculates spawn speed before setting the altitude.

Not trying to question your statement, but I'm really curious.
The only thing I could think of at the moment was that maybe you have faced some odd speed behaviour on jets where 4S_Vega put hands on.
These jets fiddle with their flight model in Java, hence kinda "live a life on their own", independently from what AI is actually intending to do.


Mike