New Axis Facility (FSUIPC 3.536 Beta) - Support Thread

[jordanal]

Pete,

So far the axis configuration facility in the FSUIPC 3.536 seems to work well. The axis seem more precise and I'm grateful to finally have an axis assigned as a gear lever on my CH Yoke. GOOD JOB! I am surprised how many times I have to hit "Ignore Axis" to start calibratinig another device but it does seem to work. Question about the removal of existing axis in the fs9.cfg file; I have the CH Products USB Yoke, ThrottleQuad, & Pedals along with a Logitech gamepad. As recommended, I deleted the devices.cfg file, removed the existing axis in my fs9.cfg file, and turned off (unchecked) "Enable Joystick." After configuring all three CH devices using "submit to FS," as I was shutting down for the evening last night when I noticed that there were a bunch of axis assignemnts in my fs9.cfg file again. Were these put back by FSUIPC because I was "submitting to FS" or did FS incorreclty pickup the devices again on its own accord? I quickly read the "updated doc" last night so if I missed an important point again as in my previous thread (LOL), just tell me to go back RTFM, LOL :)

BTW, to fix the issue with the devices.cfg file whereby new axis are still picked up by FS, would having only a "GENERIC" section in the file with some eroneous assignments solve the problem?

v/r,

AL

[Pete Dowson]

I am surprised how many times I have to hit "Ignore Axis" to start calibratinig another device but it does seem to work.

This would indicate that the axes you had to "ignore" are providing some noticeable jitter. I only take note of changes which are quite large -- unless you are using RAW mode (you aren't are you? There's no need except for precise numerical setting, as I say in the doc).

Perhaps you could view the input numbers for one such previously "ignored" axis, without touching the lever responsible, and let me know what sort of changes you are seeing it perform all on its own?

The problem really is that if I set the minimum difference I recogise too high, it can be difficult to get an axis noticed at all. This is especially true of those little rotary thumb throttles on some game pad type controls.

Question about the removal of existing axis in the fs9.cfg file; I have the CH Products USB Yoke, ThrottleQuad, & Pedals along with a Logitech gamepad. As recommended, I deleted the devices.cfg file, removed the existing axis in my fs9.cfg file, and turned off (unchecked) "Enable Joystick."

Well, you'd need to do the last thing there first, and the rest with FS not running!

After configuring all three CH devices using "submit to FS," as I was shutting down for the evening last night when I noticed that there were a bunch of axis assignemnts in my fs9.cfg file again. Were these put back by FSUIPC because I was "submitting to FS" or did FS incorrectly pickup the devices again on its own accord?

Unfortunately, whilst I did recommend those steps, I did also say, right before the steps listed:

... I’ve had Fs automatically re-enable joysticks when it thinks it has seen a new device connected. I’ve tried all sorts of things to stop it doing this, and you could try them too. They don’t seem to have any permanent effect, but here is what you can try:

and after the steps listed I added:

I had hoped that these steps, between them, would stop FS reassigning devices, as now it shouldn’t recognise them, but unfortunately it still seems to automatically re-add the [JOYSTICK_ …] sections to the CFG file, even with joysticks disabled! And I’ve still had it re-enabling joysticks if it sees a new one connected. I think all the removal of the DEVICES.CFG files does is force it to use default assignments.

I will continue to try to find a way to stop FS polling joysticks when it has been told not to do so, as I believe that this makes things less efficient than they ought to be. Furthermore, you will get some very odd effects if you do have FS using the same joystick axes as those you’ve directly assigned in FSUIPC!

Perhaps this all explains why some of what we are both trying to do here seems futile?

I quickly read the "updated doc" last night so if I missed an important point again as in my previous thread (LOL), just tell me to go back RTFM

Well, I think you just missed, or misunderstood, the preliminary warning before the list of things to do, and the conclusion afterwards that really says exactly what you've reported to me. You don't need to read the manual again as I've quoted the two parts you missed above! ;-)

BTW, to fix the issue with the devices.cfg file whereby new axis are still picked up by FS, would having only a "GENERIC" section in the file with some eroneous assignments solve the problem?

I'm not sure. It may be worth experimenting. However, you can't use erroneous assignments as these will simply be ignored and default ones entered. I don't know if empty sections would work, but it doesn't seem likely.

The only safe thing to do at present seems to be to check, now and then (and especially if odd things start to happen) that the joystick is still disabled -- i.e. that the Options-Controls entry is still there for you to re-enable and the other joystick entries are suitably grayed.

Regards

Pete

[jordanal]

Well this time I did as you suggested, unassigned axis, disabled joystick and then removed the joysticks from the fs9.cfg file. So far the devices have stayed gone. As for the numerous times I have to hit the "ignore axis" button, this hasn't improved much. No, I'm not using raw mode. In the CH-Products calibartion utility, the raw numbers 0-255 look solid so I think it might be too sensitive in FSUIPC. Maybe something we can adjust ourselvs with an added option to the axis assignemtns tab?

BTW, so far it appears that you can't add comments to the end of axis assignment. I tried to use the same commenting method used in the buttons and keys sections but FSUIPC wipes the axis comments clean after every save. Will this be added?

v/r,

AL

[Pete Dowson]

As for the numerous times I have to hit the "ignore axis" button, this hasn't improved much.

But it won't, as I've not changed anything yet. As I said I need some idea of what sort of changes you see without touching the levers. i.e. how much jitter you are getting. I must say it does sound extraordinarily excessive.

No, I'm not using raw mode. In the CH-Products calibartion utility, the raw numbers 0-255 look solid so I think it might be too sensitive in FSUIPC.

Why should it be? FSUIPC is only asking the Windows joystick interface to supply the fiures it is being given by the joystick driver. FSUIPC cannot do anything to make your joystick or its driver more "sensitive".

Maybe something we can adjust ourselvs with an added option to the axis assignemtns tab?

Well, it's pretty crowded in any case, and what would you add in any case. I've no idea why your joystick input is playing up so. i would ned to understand that before changing or adding anything.

BTW, so far it appears that you can't add comments to the end of axis assignment. I tried to use the same commenting method used in the buttons and keys sections but FSUIPC wipes the axis comments clean after every save. Will this be added?

Well the commenting and line number retaining methods provided in the buttons section (surely not Keys? Dis i do it there too?) was because of the amount of extra programming you can do via INI editing -- multiple entries, conditionals, and so on. There's none of that for the axis assignments. I see no need to ever edit the entries and therefore no need for comments. Why would you want them? It's quite a lot of extra code for no real good reason as far as I can see.

Regards,

Pete

[fog]

Rgd "Devices.cfg":

When you start FS2004, it looks in the devices.cfg to see if your joystick is "known" and predefined here. In addition it takes your modified axis and buttons in the FS9.cfg. If you joystick is unknown, FS still applies a generic assignement to your joystick.

One thing to try out, is to delete all joystick assignements in FS9.cfg, and totally empty the devices.cfg (just leaving a empty document), too see if FS still maps some axis on your devices.

The axis assignement in FSUIPC is great news for those not using CH products. As you easily can add aircraft spesific assignements. If you are using CH products i recommend using the CH manager v4.0 along with CMFS.exe. (read the CMFS documentation to learn what this is about)

Freddy

[Pete Dowson]

One thing to try out, is to delete all joystick assignements in FS9.cfg, and totally empty the devices.cfg (just leaving a empty document), too see if FS still maps some axis on your devices.

Yes, worth trying, but if, as I suspect, FS treats the file as a Windows "Private Profile" file, as it does most all the other CFG files it uses, then I don't think it'll work.

With the Profile API the program doesn't use normal file access in any case, only Section names and Keys. It would be asking Windows to get keys corresponding to each of the DirectInput-reported axes and buttons within the Section with the title relating closest to the device name reported by DirectInput. I think it would get the same negative response back whether there was a file there or not, it only depends on whether the section+key is there.

I have been thinking of ways to try to defeat its default assignments and came up with assorted thoughts about special arrangements in the Devices.CFG file, but I think they are all doomed because of the way the Profile API works.

But it is worth experimenting, still, as you say.

Regards,

Pete

[Whiteox]

I'm not in front of an FS9 computer right now, but perhaps you can change the file attributes of the cfg files to stop FS9 from writing to it (i.e. Read only).?

Also, we've had interesting experiences with FSUIPC 3.537 dll and trying to get the Jet Reverser mapped to a lever on a yoke.

We eventually got it to work very well, only to find that it inteferred with the graphics and that none of the keyboard controls would work. Upon restart (FS9), the Reverser lever worked once, then did nothing. Re-assigning the lever in FSUIPC made no difference as it had kept the settings anyway.

Some of the responses in forums I've seen tend to confuse the setup neccessary between 3.35n and 3.357.

For example it is neccessary to assign FSmixture in FS9's Control to the same axis as used in FSUIPC 3.350 - BUT in FSUIPC 3.537 it is not clear that the FSMixture control should be assigned in FS9, as it states somewhere that the same axis assignments should be not be mapped by FSUIPC and FS9. -

Does the FSMixture control have to be assigned to the same lever in FSUIPC 3.357?

FS9 saw the lever in question as 'X rotation' while FSUIPC saw it as 'U'.

Does U equate to X rotation?

Also in FSUIPC, if the U Axis was defined first, then set to Reverser, then calibrated on the next tab, by the time you got back to the Axis tab, it would show a completely different axis (like Y). I suppose that by now FSUIPC would have written a new .ini with the selected values of the U axis? Is a restart needed?

In any case none of these worked by trial and error, except once after a restart when the graphics screwed up. I suspect if X rotation is a POV then that may have something to do with that.

With regard to the cfg files, if FS9 is set to disable the yoke, then does that mean that ALL the functions/assignments of the yoke have to go through FSUIPC to make it work?

Thanks :?

[Pete Dowson]

I'm not in front of an FS9 computer right now, but perhaps you can change the file attributes of the cfg files to stop FS9 from writing to it (i.e. Read only).?

Well, not having it in the CFG file doesn't help if FS generates it internally on each load in any case. The CFG file only represents what it was using at the time you closed it down.

Also, we've had interesting experiences with FSUIPC 3.537 dll and trying to get the Jet Reverser mapped to a lever on a yoke.

Trying? This is probably the commonest action FSUIPC is used for, and it has been used in this way now since FS2000 days with no problems. Why did it need "trying"?

We eventually got it to work very well, only to find that it inteferred with the graphics and that none of the keyboard controls would work.

You most definitely had something else entirely going on there then -- there is absolutely no way FSUIPC touches any of that.

Some of the responses in forums I've seen tend to confuse the setup neccessary between 3.35n and 3.357.

There's no difference whatsoever unless you want to use FSUIPC's axis assignments. And no one's asked questions here, until now, so why are they "responding" elsewhere? The Beta versions are provided here for a reason, so I can get testing and feedback. It is no use having that going elsewhere! :-(

For example it is neccessary to assign FSmixture in FS9's Control to the same axis as used in FSUIPC 3.350 - BUT in FSUIPC 3.537 it is not clear that the FSMixture control should be assigned in FS9, as it states somewhere that the same axis assignments should be not be mapped by FSUIPC and FS9.

If you are confused by Axis assignment in FSUIPC, why on Earth use it? Use the assignment in FS. Of course you can assign an axis to the mixture in FS OR in FSUIPC, not both. Either way it would be picked up by the default setting for reverser in FSUIPC's Calibrations.

An easier way without going via "mixture" is to use the "direct to FSUIPC calibration" option to assign it directly to the Reverser!

Surely, isn't it obvious that FSUIPC's Axis Assignment is an alternative to FS's axis assignment, with more facilities. That's what it says. Why any confusion? It is ANOTHER FACILITY! That is all. Would it be clearer if it were in a different program called "AXISASSIGNMENT"? If so, why, exactly? I am vey very puzzled over this reaction.

My general advice is: if you don't understand it you probably don't need it at all, so don't use it. It was added in answer to requests, and I'm sure those who requested it will use it well.

FS9 saw the lever in question as 'X rotation' while FSUIPC saw it as 'U'. Does U equate to X rotation?

Sorry, I've no idea. There's no such thing as "X rotation" in the standard Windows joystick API. It must be a name given to or by DirectInput. However, if the same axis changes the numbers, then, yes, it IS the same axis, by definition! That's how I would find out if I needed to know.

Also in FSUIPC, if the U Axis was defined first, then set to Reverser, then calibrated on the next tab, by the time you got back to the Axis tab, it would show a completely different axis (like Y).

The axis calibration facility scans the axes and shows the one with the biggest change at that time. It does this initially and the scan can be repeated by clicking the Rescan button. Please read the documentation about this. It explains at length, with pictures, how to use that tab.

If an axis is shown as soon as you select the tab it usually means that axis is changing. If you aren't touching it this would usually indicate some jitter. You might need to use the Ignore button to see the one you want to program next, or check on another.

I suppose that by now FSUIPC would have written a new .ini with the selected values of the U axis?

No, it writes the INI with ALL the changes you have made on any or all Tabs, only when you press Ok to exit. At any time before you press Ok you can Cancel, or press Escape, and NONE of the changes you made, at all, during this entire entry to FSUIPC options, will be effected, all of the previous values will be retained.

Is a restart needed?

No, never. Only after user Registration, when you are prompted to restart. Why should one be needed at any other time? That would be horrendous!

In any case none of these worked by trial and error, except once after a restart when the graphics screwed up.

I really cannot imagine what you are doing, but the fact that other things got screwed up is certainly an indication that something else is wrong with your FS installation. I would advise reinstalling FS itself.

I suspect if X rotation is a POV then that may have something to do with that.

POVs are not read and cannot be detected by FSUIPC's axis programming. They are only read by the Buutons tab and converted to 8 buttons according to direction.

With regard to the cfg files, if FS9 is set to disable the yoke, then does that mean that ALL the functions/assignments of the yoke have to go through FSUIPC to make it work?

Not just yoke, all and any joystick devices. But you don't have to disable them, I only said you could IF you wanted to do everything through FSUIPC. It might be more efficient, and certainly more flexible that way (what with the aircraft-specific capabilities). But you don't have to. You certainly can mix them. Just take care not to have any specific axes or buttons programmed in two places at the same time.

Regards

Pete

[Whiteox]

Thank you for an incredibly fast reply!

I've only seen and worked with FSUIPC for a few hours before this post. Forgive me for my ignorance.

Quote:

In any case none of these worked by trial and error, except once after a restart when the graphics screwed up.

--------------------

I really cannot imagine what you are doing, but the fact that other things got screwed up is certainly an indication that something else is wrong with your FS installation. I would advise reinstalling FS itself.

Also

Not just yoke, all and any joystick devices. But you don't have to disable them, I only said you could IF you wanted to do everything through FSUIPC. It might be more efficient, and certainly more flexible that way (what with the aircraft-specific capabilities). But you don't have to. You certainly can mix them. Just take care not to have any specific axes or buttons programmed in two places at the same time.

If a re-install of FS9 would fix the problem then so be it. However I would like to examine other possibilities as an FS9 install would be a real pain.

Perhaps there is a conflict somewhere. When it worked, the graphics were flashing as if the views were being changed rapidly - possibly by a misconfigured button or axis in FS9.

If I can't find the misconfiguration or conflict, would you advise a reinstall of FSUIPC before I go the FS9 reinstall?

Thanks again.

[Pete Dowson]

Perhaps there is a conflict somewhere. When it worked, the graphics were flashing as if the views were being changed rapidly - possibly by a misconfigured button or axis in FS9.

Zip up the FSUPIC.INI file and send it to me at petedowson@btconnect.com. I can check that easily. There are some powerful axis assignments you can make, you certainly don't want to assign things willy-nilly! ;-)

If I can't find the misconfiguration or conflict, would you advise a reinstall of FSUIPC before I go the FS9 reinstall?

If the graphics "problem" was actually only a continual change of view then the most likely thing is that you've assigned a jittering axis to one of the view controls. If that's the case you should be able to find it simply by reviewing all the assignments, one by one, in FSUIPC. i.e. go through the process looking at each axis in turn. If you send me the INI file I can check here too, to see what's been assigned.

Either way, "reinstalling" FSUIPC isn't realy necessary as the only data file controlling what FSUIPC does is the INI file. You can either simply delete that before loading FS again, or, if you have set lots of options up the way you like them, edit it in Notepad, find the [Axes] section and delete just that one section (or more if you've made them aircraft-specific -- each of those will be [Axes.]).

But please don't delete it until you've sent the file to me.

Please let me know either way, and also, if you do encounter folks discussing problems with FSUIPC elsewhere, please see if you can encourage them to come here.

Regards,

Pete