Strange FS9 Problem

[steku]

quote: Or use FSUIPC, as that appeared to be a workaround for others The problem is that some users report (even on this forum) that FSUIPC is NOT solving this issue.

quote: We must be supportive and wait for the solution, and whilst we have the time, we can all practice our flying skills without the autopilot If elevator trim is affected by this bug it's really hard to practice even traffic pattern...

I understad that solving this problem is not easy but maybe someone from Natural Point can do some research on this and recommend a solution. The most important question is:

Can this issue be solved by FSUIPC (registered?).

If yes - I think we can live with this and developers at Natural Point can work on new features instead.

If not - ...

This product is simply to great to be plagued by such problem without any solution...

[Wayne]

Guys,

We are looking at this issue with reference to the digit acceleration, and we are aware of its existance.

As for FSUIPC, this will solve the the problem, because I use this on my home system. FSUIPC as a utility that can do many things in FS2004, and I personally would not have my FS2004 without it.

This has been a little tricky to resolve, and we are giving this a priority.

[steku]

Fibble wrote

quote: On the other hand, I may need to revise my previous answer. I loaded the most recent version of FSUIPC and reported that the 10-degree jump problem went away. Well it almost did - it is now intermittent. That is, I am turning a knob and it is working properly and suddenly it is jumping by 10-degrees again. Not just cockpit knobs, but the trim control as well. VERY difficult to set up a landing with trim controls jumping by 10 notches instead of 1. sr71_sr71 wrote:

quote: FSUIPC installed without registration does not fix the problem for me , hence I will not use that module, even though its a single DLL. Wayne wrote:

quote: As for FSUIPC, this will solve the problem, because I use this on my home system. FSUIPC as a utility that can do many things in FS2004, and I personally would not have my FS2004 without it. Who is right?
Maybe Wayne's home machine is different?
Maybe some more careful tests are necessary?

Wayne

Could you check in your system if the option solving problem with TrackIR is "Fix control acceleration" (available only in registered FSUIPC). You can do a simple test with this option checked and unchecked and publish results.

After this test we�ll finally know if the solution lies in this option of FSUIPC or elsewhere. Maybe users using registered FSUIPC have this option unchecked and this is why they still have problems with controls acceleration with TrackIR.

Here is description of this option from FSUIPC manual (copyright by Pete Dowson) (mentioned option is now defaulted off - this can be the reason why some versions of FSUIPC seems to solve the problem and some not - maybe it depends on state of this option):

� Fix control acceleration is provided, in FS2002/4 only, to try to
fix the occasional stuck control acceleration-i.e. the problem with
some panels where the increments/decrements to values like heading,
course, and so on, get stuck at 10 (for instance-sometimes, for timing
reasons, you get rather more unpredictability). These "accelerations"
are actually legitimate when a key or mouse is held down long enough,
but it seems some things can make them 'stick'. What happens is that
inside FS there's a timing check: closely arriving controls trigger
the acceleration. The problem appears to be that FS does not care
whether these controls are all the same or all different. The
assumption seems to be that, if they are arriving that close then they
MUST be the same-the user couldn't move the mouse to another spot, or
select another key on the keyboard, so quickly. However, some gauges
or other driver programs can be sending controls very fast indeed,
hence the problem. Whether this explains all the cases reported I
don't know, but it seems likely.
The "fix" for this intercepts all controls, and changes the elapsed
time check in FS before forwarding every different control, so that
the time elapsed looks large enough. If it sees successive identical
controls then it leaves them, so they can be accelerated as normal.
The end effect of this is likely to be the reverse of the original
problem. For normal use of mouse and keyboard there is normally no
difference, but if some gauge or driver starts sending controls very
fast (i.e. at less than 400 mSec intervals) then the controls may not
accelerate even when you expect them to. I tend to think this is
better though. Note that this fix is (now) defaulted off. This is
because, for those exact same panels it is designed to help, the
continuous arrival of those controls causes keyboard use to never
accelerate. Numeric keypad users for throttle, elevator, rudder,
aileron and trim, in particular, will find these controls very
unresponsive as a result. If you use a joystick then I recommend
enabling this facility, but otherwise make sure it is off.

If FSUIPC realy solves this bug maybe Natural Point could make a deal with Pete Dowson and include special copy of FSUIPC (with apropriate function enabled) with every TrackIR sold?

[ September 13, 2004, 03:55 PM: Message edited by: steku ]

[sr71_sr71]

quote:If elevator trim is affected by this bug it's really hard to practice even traffic pattern...I have all those (and many other) controls assigned to the switches on my CH Yoke, and do not seem to be effected on my system?

In general I try to get away from using mouse and keyboard whilst flying, as of course they are not there in the real world. But hey, its only a simulation, so need to go back to them for a few simulation essentials

This is one of the reasons I purchased TrackIR, to take view panning away from my hands.

To be honest, I could not live without it now. To be able to look in the direction that you are flying (not always the aircraft direction, such as a crabbed approach), is just to cool. Its also good when doing circuits, being able to simply look round and see the runway - mmmmm - nice!

[ September 14, 2004, 02:28 AM: Message edited by: sr71_sr71 ]

[steku]

sr71_sr71

If I remeber you are not using registered FSUIPC. It means you are assigning buttons on your CH yoke directly in assigments menu of FS2004 (without FSUIPC Keys or Buttons functions - by the way - these functions of FSUIPC are really powerfull - you can assign a lot more functions to yoke buttons than are available in FS assigments menu - for example turning heading bug clockwise and counterclockwise, the same for OBS, radio tuning etc. - the only problem is limited number of physical buttons).

Do you mean that the increment bug is only visible when you're using your mouse to set something (like trim) i.e. is not affecting you when your are using buttons? It'll be interesting partial solution.

I too use CH Yoke with two logical functions assigned to every button (via CH Control Manager shift function) and additionally have small homemade panel with four buttons (gear, parking brake, fuel pump and altimeter reset to actual pressure) and four analogue controls (elevator trim, rudder trim, cowl flaps, flaps). This panel is connected to good, old gameport and contains no electronic (only four buttons and four potentiometers).

P.S.
Analogue rudder trim and cowl flaps can be only used with registered FSUIPC. Other controls on my analogue panel can be assigned in FS2004 menu directly.

[ September 14, 2004, 03:57 AM: Message edited by: steku ]

[sr71_sr71]

quote:Originally posted by steku:
sr71_sr71

If I remeber you are not using registered FSUIPC. It means you are assigning buttons on your CH yoke directly in assigments menu of FS2004 (without FSUIPC Keys or Buttons functions - by the way - these functions of FSUIPC are really powerfull - you can assign a lot more functions to yoke buttons than are available in FS assigments menu - for example turning heading bug clockwise and counterclockwise, the same for OBS, radio tuning etc. - the only problem is limited number of physical buttons).

Do you mean that the increment bug is only visible when you're using your mouse to set something (like trim) i.e. is not affecting you when your are using buttons? It'll be interesting partial solution.

I too use CH Yoke with two logical functions assigned to every button (via CH Control Manager shift function) and additionally have small homemade panel with four buttons (gear, parking brake, fuel pump and altimeter reset to actual pressure) and four analogue controls (elevator trim, rudder trim, cowl flaps, flaps). This panel is connected to good, old gameport and contains no electronic (only four buttons and four potentiometers).

P.S.
Analogue rudder trim and cowl flaps can be only used with registered FSUIPC. Other controls on my analogue panel can be assigned in FS2004 menu directly.WOW, erm...................... I did not know that the control manager could assign 2 functions to 1 button. I really need to look into that. Thanks.

Nice idea about the controls via gameport, I would be very interested to learn how you achieved that.

Seems like our chat is straying away from the initial subject of this post

But yes, I dont see any trouble with trim. And yes, it only seems to effect mouse clicks on the autopilot. Although I may have to test that again to really confirm if trim is being effected etc.

I also plan to purchase a license for FSUIPC, would be interesting to see the extra gizmos and if it fixes things for real.

[steku]

sr71_sr71

Send me a mail (look under my Profile). I'll reply with some links about building gameport interfaces. You can as well make some serach on the internet - you can find a lot of information concerning this topic.

Another source of information is FSUIPC users manual, advanced useres manual and FSUIPC SDK (especially manual for programmers where you can find description of all FSUIPC offsets - using this offsets you can control nearly everything in FS).

And finally CH Control Manager which lets you assign two buttons to physical button and much, much more (nonlinear scaling of axes, programming button logic etc.)

You are right that this thread should be left for original issue. So we are waiting for an answer from Natural Point...

[sr71_sr71]

Hi Folks.

Ok, so I just bought a license for FSUIPC, and got the reg.code through instantly - cool.

Downloaded the latest version, and I ran some more tests with the technical option for fix key acceleration ticked, and all my problems went away.

Just thought that was worth mentioning/confirming.

Thanks.

David.

[steku]

Hi David

Really great news

Any nasty side effects?
FPS drop?
Unability to accelerate control when you need it (for example when you need to turn your heading bug or OBS for 180 degrees and you press and hold the button - in this case the haeading bug should start with 1 degree increments and after a couple of steps should accelerate to bigger steps until you release the button)?

Could you confirm that after unchecking "Fix control acceleration" the problem returns?
If yes - it'll mean that you isolated the problem and we have confirmed workaround

I think that Natural Point should do some more tests to finally confirm this workaround and publish it on their FAQ or Troubleshooting pages and of course in user manual.

[ September 14, 2004, 03:55 PM: Message edited by: steku ]

[sr71_sr71]

quote:Originally posted by steku:
Hi David

Really great news

Any nasty side effects?
FPS drop?
Unability to accelerate control when you need it (for example when you need to turn your heading bug or OBS for 180 degrees and you press and hold the button - in this case the haeading bug should start with 1 degree increments and after a couple of steps should accelerate to bigger steps until you release the button)?

Could you confirm that after unchecking "Fix control acceleration" the problem returns?
If yes - it'll mean that you isolated the problem and we have confirmed workaround

I think that Natural Point should do some more tests to finally confirm this workaround and publish it on their FAQ or Troubleshooting pages and of course in user manual.Morning.

I had already run those tests last night, but did not bother to go into details.

I think this fix was already confirmed by NaturalPoint, but yes, FSUIPC's technical option check box of "Fix control acceleration" does resolve the problem.

To confirm then:

a) Either without FSUIPC or using FSUIPC unregistered, the problem remains.

b) Registering FSUIPC gives access to the technical option check box of "Fix control acceleration". Checking this box solves the problem, no other effects seen (on my system).

c) Turning checkbox (b) on and off shows that FSUIPC controls this problem, with no aparent side effects (on my system).

Details of my system:

Hardware
------------
-19inch monitor.
-AMD based unit.
-512mb RAM.
-80gb HDD
-NVidia Geforce 4 128mb
-CD & CD/RW
-4 onboard USB ports
-8 Port USB HUB
-CH USB Yoke (not connected to USB hub)
-CH USB Rudder pedals (not connected to USB hub)
-TrackIR3 pro (not connected to USB hub)
-8 other USB devices.

Software
-----------
-XP Pro SP2 (yes SP2, works just fine)
-FS2004
-UK VFR Photoscenery (all packs)
-UK British Airports (all packs)
-FS Terrain
-FSNavigator 4.60 (registered, plus all latest updates)
-FSUIPC 3.30 (registered)
-ActiveCamera 2004 (registered)
-MyTraffic 2004 (1.3, registered, plus all latest updates)
-CH USB Control Manager 3.0
-AFCAD 221
-TTools

It is worth noting that I have also reinstalled my entire setup to try and resolve this, and got my system to having only FS2004 and TrackIR software installed, at which point the problem starts. By then adding FSUIPC (as in B above) the problem goes away.

Hope that helps.

David.

[ September 15, 2004, 03:04 AM: Message edited by: sr71_sr71 ]