PDA

View Full Version : Comparing wobbles and woblanges



AndyJoyhill
02-28-2006, 06:23 AM
I see that huge thread got locked and perhaps for a good reason. There's one more thing I'd like to see discussed since it's puzzling me. A long time ago I mentioned my expectations from real life warbirds' oscillations were somewhat different from what Il-2 had. It was difficult to explain exactly what I thought it should be like, but now I have a video clip from Lock on that pretty much shows what I'd expect from WW2 warbirds. Of course they shouldn't behave exactly like the Su-25, but my gut feeling keeps telling me it's in the ballpark.

I'm not a pilot and one of the reasons I fly simulators is to experience one small part of what it's like to pilot fighter planes. I'd like to know what's realistic and not and that's why I'm looking for other people's opinions on the matter, hopefully some who might have experience.

I suppose few of you have Lock on so I made a video. I don't have any real video processing software so I could only use the slightly problematic Lock on AVI record tool. This video clip is 1:28 long, good quality and, unfortunately, 46MB in size. You need some sort of DivX or perhaps XviD codec to view it. I'll PM the download link to tonyt and Tagert at first, if anyone else is interested send me PM and I'll send you a link if I can without upsetting the download host too much...

msalama
02-28-2006, 11:35 AM
Hmmm... your gut feeling tells you they're in the ballpark etc. and then you admit you're NOT a pilot? Hmmm...

But hey, if someone knowledgeable decides to own up I'm listening too http://forums.ubi.com/groupee_common/emoticons/icon_wink.gif

MG15120
02-28-2006, 09:51 PM
Well,

I'm only an A&P/IA , Student pilot.
I have played online flight sims for more than 10 years now.

The only thing I am wondering about is what hardware the guys experiencing the "wobbles" are using.

I know that using my HOTAS Cougar with evenstrains and hall sensors I have found the "good guy" rides to be much more stable in ALL axes than the "bad guy" rides.

I specifically went online to test this in the War Clouds server last night and verified my thoughts.

I cant help but believe that hardware (controllers) are the main contributor to this perceived difference.

msalama
02-28-2006, 11:07 PM
...or rather how the sim input handler "cooks" and interprets what all those different controllers put out, I'd say. But yes, broadly speaking this is the problem IMO too...

FastDriver74
02-28-2006, 11:28 PM
While hardware can cause input spikes, everyone has the ability to dampen out the spikes using the in-game control setup.

You can use linear interpolation or:

value =v1+interpolant*(v2-v1)

to dampen out the inputs. I'm sure Oleg and company have done this and I'm fairly sure this is what filtering is. If you notice filtering on axes only goes from 0.0f to 1.0f (floating point) which is the same limit for interpolant in that linear interpolation equation.

So if the input value is 50 and the last one was 25 then using that formula with a filter of .5 it would spit out this:

value=25+(.5)*(50-25)

Using order of operations the subtraction is done first, then the multiply then the addition.

value=25+((.5)*50-25))
value=25+((.5)*25)
value=25+(12.50)
value=37.50

This as you see would dampen out inputs. Given this can be set by the user, I believe a correct setting for filter would help a lot.

Check out the control section.
Here is what I've come up with, and implemented in my own game engine as well for input (Sorry Maddox, but the input scheme was brilliant).

The sliders indicate ten separate positions from 0 to max deflection or 100. Essentially each slider represents 10%. The middle slider is 50%. Now if you have the first slider at 10, the following is true.

Using a scale of 0 to 100 for total input values, 10% of 100 is 10. So the first slider can only be worth 0 to 10 input values. If you set the first slider at 10, you now have limited the first 10% to 10% of the total available there. So now you have 10% of 10 input values available.

10 20 30 40 50 60 70 80 90 100

These are the input values or percentages of the total deflection. Now Maddox allows you to set a percentage for each of these positions as well as a global filtering. The filtering determines how fast the controller goes from it's last reading or input to the current one. Think of filtering as the time it takes to go from one stick position to another.

Try this out. Go to your setup and set all sliders to 0 for roll axis. Now set the first one to 100. Move the stick and watch what happens. Now play with the filtering a bit and watch the red box. See how it lags behind the green box? That's filtering. Now move the stick past 10% deflection and you will see that the red box snaps back to dead center. This is because you have set all other ranges to 0, or 0% of that range. I haven't tested this since new patches but it seems to me the ZULL ZONE does not work correctly.

The null zone in PF is wrong because let's say you set it at 20%. Now if you move the stick to 21% deflection, your actual deflection accounting for the null zone is 1%. The problem in PF seems to be that it has 0% input up to the null zone, but once outside of the null zone, it does not account for the null zone. So if your null zone is 20%, then when you hit 21%, instead of it using 1% deflection, it will use 21%. Not exactly what you want. Control inputs should be relative to null zone boundaries. You are essentially enlarging the 0% input range.

m_iFinalInputPos=(m_iStickPos-m_iNullZone);

Now the code should use m_iFinalInputPos to compute aileron, elevator, or rudder position.

You must understand though that sticks in DirectX and in computers in general usually range from -32767 to +32767 deflection. DirectInput thankfully eases the pain of calibrating the stick - unlike the old DOS days when the programmer had to use a timer to figure out all the values and then compute the center point.

In my opinion and in my experience with both pure assembly input code and C/C++ code (using port 0201h) as well as my experience with DirectInput code, I'm almost positive given IL2/PF's exquisite input system.......the wobbles are much more than just input issues.

Sorry so long, but I had to show I'm not just spouting off at the mouth. Wobbles are most certainly coming from the FM, however these could be agitated by incorrect input values. All of the FM and input (eventually) is done in floating point and is subject to cumulative rounding errors - thus you will always have some sort of issue - and also given that there are about ten thousand controllers out there on the market.

It's a programmer's nightmare. DirectInput and other libs and the use of drivers have eased the pain, but it's still somewhat of a problem.

msalama
03-01-2006, 12:00 AM
Thanks for the info, Cobra. It actually makes some sense to me http://forums.ubi.com/groupee_common/emoticons/icon_eek.gif because I'm an ex-SW developer myself (financial & telco applications only, but hey, you know).

Still, consider these points:

1) Things have gotten tweaked along the way, that much is certain.
2) Some say no wobbles, big bubbles.
3) Some say no bubbles, big wobbles.
4) Everyone says they're flying the same version.

Now what do we make of this? Given that the FM environment is the same for everyone, and yet only a fraction of us suffers from the wobbles, well... is the main culprit Oleg's flight modelling? Or is it how the sim _reacts_ to whatever we're putting into it?

FastDriver74
03-01-2006, 12:23 AM
Well first of all, too many people are talking about wobbles for it to be a non-issue. If even 30% of your users for your software report some type of adverse effect while using it, I'm sure your QA department would not write that off as a non-issue. That means 3 out of 10 people have an issue and you are ignoring those 3.

However I don't feel that Maddox and company have ignored any of it. Hence that is why the input scheme is setup the way it is. From the beginning it is apparent that they knew with so many sticks and controllers out there, they had to give the user fine control over how the inputs are read and interpreted. The control input scheme for this sim is more advanced than many I've seen and tweaking it will help a lot of issues.

But I also read the aft COG issue and I tend to agree. While I've never flown a warbird I'm sure aft COG would have the same effect on them as my little puddle jumper Cessna's, Arrow's, and Piper's. It feels like you are flying with a big hog strapped to your back. The nose always wants to pitch up, aircraft wobbles and weebles, etc. One of my friends used to fly a C130 Hercules for the RAAF, actually he is from Britain so I dunno if was RAAF or what, but he flew the Herc.

One time he was carrying a really heavy motor grader. This lines up perfectly with what I know because my factory builds these things and we sell them to military, etc. We have videos of these things falling out of airplanes and the chute fails to open. Not pretty. But anyways he was carrying this piece of equipment and when they let it out the back he said the pressure on the yoke was so hard that even with slamming the yoke into the dash and nearly crushing his hands, the nose still went sky high. As the grader went aft of the COG and as it went out the back, thus causing all kinds of weight to be where it shouldn't be, the aerodynamics went to **** in a hurry. Thankfully the beast fell out the back and soon the plane returned to normal.

Ok his COG was messed up because of weight. The COG in the sim is not messed up because of a weight issue or because some noob in the military put the load to far aft or forward, it's more like the engineer mis-calculated the COG. Not a fun plane to fly. With a mislocated COG any addition or subtraction of weight or any change in flight path would cause some major stability issues. He also flew a C130 where a poor chap did just that. He loaded something 6ft in front of where it was supposed to be. He said the plane wanted to nose over, barely made it off the runway w/o him sticking the yoke in his stomach and the poor beast didn't want to climb at all. Back on the ground they then found out about the load being 6 foot in front of where it should have been. I realize there are a lot of factors in aerodynamics but a lot of those (like torque, propwash, etc, etc) could be trimmed out by the pilot. A bad COG would be a major issue and would be nearly impossible to completely trim out all of the effects of it.

So let's assume for a moment that the input scheme is perhaps 80% right. Let's assume all other aero variables in the sim are 80% right. Now let's assume the COG is incorrect. Since the COG is extremely important and IMO is a critical variable for all equations, you can see how the 20% inaccuracy in all other variables could be multiplied many times over because of one critical variable being even 20% off.

I think COG would make a huge difference in any flight equation and it's the only thing I could see that may possibly throw the entire system off. Other variables would affect it, but not nearly as much.

A bad COG in an aircraft would be like one pointer in C++ pointing to the wrong address in memory. Sure the code might execute for a bit - but when that pointer is used to access memory, everything comes crashing down fast.

That said, this sim is extremely good. FS9 has a more stable FM, but then FS9 suffers from major problems when slow, inverted, or in a stall and spins are not modelled correct at all (still). The equations just fall apart. There are points in the FS9 flight model where you can actually gain altitude while having the airspeed jump from 0 to maxed out and the plane flopping all over. Take the lear up, go inverted and try to do an outside loop. As the plane begins to stall keep forward pressure on the stick and add some rudder. Maintain this until airspeed is just about nil....and watch the effects. You will have to manually restart the flight b/c it goes haywire.

Maddox has a lot of things right. He has patched this time and time again when most companies would have patched once and deemed the development life cycle over. You can see now why companies do this - you can never please everyone and it's better to work on a new game, new engine, etc, etc. than continually try to improve an old one. Money is in new games, not improving old ones. I tip my hat to 1C and Maddox for excellent support and for doing more than any other developer has ever done for a flight sim.

The question is not what we perceive to be wobbles, the question is in what does the data say? Saying we don't perceive any wobbles is like saying this water is hot or cold. One might think it's hot while the other thinks it's cold. A thermometer, however, could measure the amount of heat in the water. This is what we need. We need to be like engineers and only trust the numbers. The other thread had hard data in it and I'd like to see more.
Hearsay or perception is not going to get anywhere.

Remember the days before profilers? I 'think' the slow section of my code is here. So you spend all day optimizing it, only to find out later....it didn't do anything. Programmers are really bad at determining where their code is slow at and where it's fast. The same holds true for flight sims. We are horrible at explaining what we perceive as wobbles, instability, etc. We need data.

In my opinion fixing 10% of the FM at the risk of breaking 90% of it is not worth the trouble.
Concentrate on BOB before the technology gets ahead of the game engine (DX10 and new OpenGL coming out very soon as well as Windows Vista) and leave this engine alone.

Also that said I'm sure this sim is using known volumes to approximate mass moment of inertia or MOI. In other words everything is an approximation. To compute every variable and function of aerodynamics, update the terrain which in itself is a hog no matter what algo you use, aircraft, mission variables, input variables and input data (either buffered or polled), billboards for explosions and smoke, etc, etc.......the game would run at like 1 FPS.
So things have to be approximated. There is a lot going on in this sim and getting 80 to 120 FPS on newer cards is a testament to the dev team.

Te_Vigo
03-01-2006, 05:41 AM
ok....
Going from an early release X52 that was sensitive, I experienced a lot of wobble. Basically I couldn't hit a bull in the bum with a bucket of weed with it the wobbling was so bad.
Now with a replacement (later release) and the same in game stick settings and running the same version game update....the wobbles have almost disappeared.

If this helps.

LEXX_Luthor
03-01-2006, 05:47 AM
It may not be center of gravity but something else like not calculating fuselage and wing/tail areas exposed to airflow (kinda sorta like center of pressure cp). Like in a wobbly model rocket, you can add weight to the nose (move cg forward) or add total fin area (move cp aft), or a combination of these, or use longer fuselage which is a combination of cg+cp movement (essentially, a new design).

That's IF the wobbles are not realistic for these WW2 heavy fighters, and they could be, and I agree with mslama there may be control issues. I mean, with my puny little Racing Pedals, there is little to no fine rudder control -- its lots of deflection or nothing.

AndyJoyhill
03-01-2006, 05:50 AM
I suppose pretty much everyone here has some sort of a feeling of how the planes should feel like, even if they have no experience at all. Many of us are aviation enthusiasts who tend to collect all sorts of stuff related to flying. I personally want my sims as close as possible to the experience of flying real planes and thus I also want to know what it's like to fly a real plane. And the only thing I can compare to is the simulators I fly so I'm always interested when anyone who knows what real planes feel like wants to make the comparison.

AFAIK there has been at least two kinds of wobble around and that's confusing people. The worse wobble was affectionately named "Oingo-boingo" on SimHQ and that's probably caused by controller problems. It makes the game pretty much unplayable, but luckily only relatively few people suffer from it.

The other wobble is different and it's not a controller issue, because the problem manifests itself AFTER you let go of the controls. This is what the tests in the huge thread were about. I wholeheartedly agree that there needs to be a measurement to determine what's actually wobble and what's not. That's why I'd like to hear people who have actually flown airplanes, preferrably as close to real warbirds as possible.

Here are a couple of wobbling examples:

This first one is a "wobble" in my books, it's a graph recorded by TAGERT using Il2SFBAEPPF 4.03 (F4U1D) and was first posted in the huge wobble-thread:

http://www.geocities.com/grantsenn/NACA_RESULTS/403/WOB..._F4U1D_YAWIT_YAW.JPG (http://www.geocities.com/grantsenn/NACA_RESULTS/403/WOBBLE/F4U1D/v403_F4U1D_YAWIT_YAW.JPG)


This one I would consider "oscillation", I recorded it from Lock on using 1.12a (Su-25):

http://tols17.oulu.fi/~ailomaki/lo/woblwobl/lockonwobl.jpg

FastDriver74
03-01-2006, 01:20 PM
I've only flown Cessna's, Piper's and Arrow's so I cannot weigh in on how a real warbird actually flies.

They are quite expensive to even get your hands on and most of them, if not all, tour the country doing shows. I've never seen anything about anyone giving rides either, except maybe at Osh-Kosh.

Tully__
03-01-2006, 08:51 PM
Originally posted by msalama:
Now what do we make of this? Given that the FM environment is the same for everyone, and yet only a fraction of us suffers from the wobbles, well... is the main culprit Oleg's flight modelling? Or is it how the sim _reacts_ to whatever we're putting into it?
Two other options to consider...is it how the pilot applies control inputs or is it how the pilot reacts to the sim's response to his control inputs.

Te_Vigo
03-02-2006, 12:17 AM
SOmething i've noticed in outside views, viewing how the rudder moves.......

It seems to move too quick to deflect and then returns to centre slowly.
Shouldn't this be the other way around, taking into account airflow?

It just seems slow to return to centre

msalama
03-02-2006, 02:51 AM
Two other options to consider...is it how the pilot applies control inputs or is it how the pilot reacts to the sim's response to his control inputs.

Yeah, that too. Good questions - or in other words, is it how _we_ react to whatever the _sim_ is putting into us? http://forums.ubi.com/groupee_common/emoticons/icon_smile.gif

Is there a way to measure ham-fistedness, BTW? http://forums.ubi.com/images/smilies/35.gif

AndyJoyhill
03-02-2006, 05:28 AM
In fact, there's a very good way of measuring ham-fistedness. The sim can record control input (AFAIK, I've never actually tested).

Anyway, to keep the thread a bit more on topic, which of the above graphs would you think WWII warbirds should be like? My guesstimation says somewhere in between, but perhaps closer to the Lock on oscillation.

msalama
03-02-2006, 06:24 AM
But isn't Tagert's graph from the v.4.03? And we're flying v.4.04 with greatly reduced oscillations now, making the comparison bit pointless IMHO...

AndyJoyhill
03-02-2006, 06:33 AM
It would certainly be interesting to see new graphs from the 4.04 version. I haven't had enough sticktime with 4.04 to say much about its wobbliness. The question still remains: which one is more realistic? How should these planes react to control inputs?

msalama
03-02-2006, 06:53 AM
I haven't had enough sticktime with 4.04 to say much about its wobbliness.

Much reduced, at least here. Some are still griping about the (perceived) incorrect CoG thing, manifesting itself in clean hammerheads being impossible to execute, etc.

Well there could be some truth in that, but all in all it's still an improvement IMHO...

GTG, I'm out for a kev√¬§tleski-bisse* with my m8 next http://forums.ubi.com/groupee_common/emoticons/icon_cool.gif

* This is an excerpt from an archaic language spoken here in the Land of the Shamans http://forums.ubi.com/groupee_common/emoticons/icon_smile.gif What it means exactly is for me to know and you to guess, but suffices to say that if me & my mate are somewhat hungoverish tomorrow then everything went as planned http://forums.ubi.com/groupee_common/emoticons/icon_biggrin.gif

AndyJoyhill
03-02-2006, 10:04 AM
Watch out with your springwidow-beers, they're known to make planes and other such objects wobble uncontrollably.

msalama
03-02-2006, 06:13 PM
Watch out with your springwidow-beers, they're known to make planes and other such objects wobble uncontrollably.

Indeed http://forums.ubi.com/groupee_common/emoticons/icon_smile.gif Hauskaa was had by kaikki at any rate, and because of that sp√¬§mm√¬§ys riitt√¬§√¬§ perkele just nyt.

Yep, the hangover's in the f**king post for sure...