06-03-2010 06:38 AM
Now this does get interesting. You are the first user to comment at length about FSX. As I have said before in other threads, there is a splendid FFB upgrade for FSX in the form of "FS Force" from Dirks Software. A double plus, is that they are aware of the G940. It makes a World of difference and explained my reticence to load 5.09 until there were user reports here on the FSX situation. I think I am going to drop a line to Dirks and ask them if the new Logitech firmware might bugger things up, but I doubt tht it will.
Thank you to the guys with real sticktime, (as opposed to just virtual game time) who unless being Airbus drivers, will appreciate just how the stick should feel and how much feedback it gives to the pilot. This, is what a stick is all about, full stop.
06-03-2010 07:09 AM
Thanks Magic99. In addition, I would like to point out that I felt FSX's forces both with the 5.08 and the 5.09 firmware installed. I'm very certain it's a thing the sim's developers have coded themselves, and not a new feature introduced by Logitech's most recent driver. I'll look into that Dirks package too. I'm wondering what extra effects it might add.
06-03-2010 10:55 AM
It will add quite a few effects, but it is at it's best in letting you feel those last few knots bleed off or things getting happier as they add in. The A/C will just talk to you and that is how it should be. The old slop around the centre was a bit excessive with just the FSX drivers but FS force overides this. If only that stupid throttle issue was fixed, the stick might then be able to begin to live up to the hype - at least with FSX anyway.
06-03-2010 06:19 PM
With the old, I had the "gravel-iness" when I would plug the stick in, my simulation not running. When I would start the sim, the force curve would change and the "gravel-iness" would go away.
With the new, "gravel-iness" is there when I plug in the stick, and now DOES NOT go away when the simulation runs.
Whatever my sim was doing to define the stick's forces no longer works. The feeling does not change when the sim starts, when it use to drastically change.
The sim has not changed or been patched.
Thirdwire doesn't have a demo version you can download. Their sims are inexpensive compared to others on the market. Check out combatace.com if you want to find out more about the sim, and free addons available. I'm JSF_Aggie on their forums if you have any questions.
06-04-2010 07:17 AM
Could it be due to the dampening feature of the profiler? I've removed all dampening from all profiles (mainly because I don't know what it means). There has to be some explanation for the opposing experiences with indentical hardware.
06-04-2010 08:32 AM
I've tried with everything default, except both dampening sliders to 0 (profile & global).
I think the explanation is different simulations. The feel that I'm now missing didn't show up until I started StrikeFighters, and the sim started talking to the stick.
Now when I start StrikeFighters, the stick forces don't change. Whatever the sim was sending the stick seems to have no effect in regards to stick force. Descrete effects still work, stall buffets, wpn releases, etc.
It's just the mechanical, graveliness, feeling of the stick that's driving me nuts. Like I said, it use to feel like that until I started the sim, then it would change to a much smoother feeling stick. With the firmware/software upgrade, it no longer changes.
06-04-2010 09:26 PM - edited 06-04-2010 09:56 PM
As it is in 5.08 at least and probably 5.09. I think I might know what the thinking was and how the reversal bug was born, and maybe why it hasn't (from what I hear) squashed yet.
Word from Logitech has been that it is just part of making sure the thing is less nervous, so that is what the intentions were and what part of the code the reversal bug belongs to. But the behavior we see is (enormously) detrimental to the stated intention - the exact opposite of what it was supposed to do.
They probably intended to put in a 'numb' area of physical movement required of axis movement in the opposite direction until it actually registered, and the output sent would accurately never make any jumps but only start to move from the last position slowly in the other direction once the axis has physically moved enough in this direction. This would make perfect sense to put in. The jump as we see it (4%) would be a logical size of this numb zone (for the rudders and trims especially) and make the device very well behaved and accurate. The rudder would be gentle, smooth and easy to use even when doing smaller movements. The throttles would stick together much more when moved together, moving small increments and finding the exact spot would be an easy affair. TRIM wheels would be smooth and relaxed. The stick doesn't need this as the hall sensors are pretty damned accurate to begin with (but the added reversal bug jumps takes away the precision currently).
Current (5.08, maybe 5.09) Behavior: Gently start to move in the opposite direction = output quickly makes a large jump of 3-4% in the correct direction (far disproportionate to the physical movement). Same happens again when trying to reverse back again to get to the intended position. Over and over.
Analogy: Imagine putting your finger into a glass on top of a slippery table. Your finger is the physical position of the axis. The glass position on the table is the 'output' that is sent to our games etc. When you start moving the finger in the opposite direction, the glass makes a jump the size of its diameter into that direction before your finger even gets to the other side (yeah, it would 'move through' your finger as your finger was already at the edge, but it should help to get some idea).
Intended Behavior: Gently start moving in the opposite direction = at first, no change to output. After moving 3-4% of PHYSICAL travel, the output starts moving gently in the correct direction, from it's last known position.
Analogy: Dragging the glass with your finger in one direction and all is well. When moving the finger into the opposite direction, at first the glass will not move, for the finger has to move from one edge of the glass to the other edge, until it reaches the edge and pushes the glass into the other direction.
To make the intended behavior work for them, they would probably tried to do the following:
1. When axis (input, potentiometer/hall sensor etc) is moving into opposite direction, freeze the output where it was last registered.
2. When axis has moved enough distance (3-4%) into this direction, unfreeze the output.
3. Since the axis (input) has moved a sizable distance (3-4% of travel) the output must be adjusted, else the output will just make a 3-4% jump to catch up with the axis. This done by adding or subtracting 3-4% to the output 'position' in the OPPOSITE direction of how the axis is moving. This makes the output just keep going from where it was last positioned without any kind of jitter or jumps.
My theory is that they put in step 1. But step 2 is not working. Step 3 is still employed but not only is it employed right away without delay, but also the adding and subtracting values are reversed (i.e. it ends up boosting the movement in the direction rather than retard it).
Together, they produce this totally bizarre jumpy behavior where it makes constant jumps whenever the direction changes and accuracy is impossible without third party software to apply post processing on the output to compensate for the weird jumps.
The good news in all this is that this should be easily corrected in a firmware upgrade.
06-11-2010 10:40 PM
Thanks for the update logitech team
When i set a game in the profiler- it executes the .exe , but this game has no given windowed option (i run it in windowed) so i have to append +fullscreen 0 onto the shortcut on my desktop.... BUT in order for the changes in the profiler to be made i have to run the .exe that ive stated in the profiler-
grr, great otherwise- TYVM