Joystick persistence

[BorisTheSpider]

Hi,

I am aware of the joystick letter assignment functionality in FSUIPC to ensure persistence of joystick identification across replugs and changes of the windows joystick number.

I have a bit of a feature request, or perhaps a request for help with figuring out how to do something without FSUIPC if it's possible.

I want to try using a saitek trim wheel with fsforce. Fsforce uses the joystick number to identify an axis, if that's how you're going to trim it, and I'm concerned that the joystick number will inevitably end up changing regularly and will be a pain.

What I'm wondering is if it would be possible to add a feature to fsuipc where it maps a joystick to a new, virtual joystick, the number of which does not change. So I could configure the trim wheel, which might really be joystick number 6 at the time of configuring, then it would be identified by GUID and mapped to joystick 206 on a permanent basis.

I could then point fsforce to joystick 206, and not worry about the number changing.

It also occurs to me that if this were possible in fsuipc, it might be necessary to restart fsforce after fsuipc had loaded, since if it loaded before the virtual joystick existed (it loads from exe.xml) it would probably just exit or fail to connect properly once the virtual joystick became available. Perhaps there's some way I could start fsforce later, via fsuipc?

I have contacted the developer of fsforce, but I'm not really expecting he'll be able to help, since it seems to me that asking him to add the ability to identify the trim wheel by GUID is probably more onerous than asking Pete if it's possible to add this to fsuipc where most of the code for GUID->JoyLetter assignments already exists.

Is there some other, existing way to achieve this that I may have overlooked?

[Pete Dowson]

What I'm wondering is if it would be possible to add a feature to fsuipc where it maps a joystick to a new, virtual joystick, the number of which does not change. So I could configure the trim wheel, which might really be joystick number 6 at the time of configuring, then it would be identified by GUID and mapped to joystick 206 on a permanent basis.

What's the difference between a "virtual joystick" called A and one called 206? The code is already there in FSUIPC to handle joystick letters permanently. To handle numbers instead seems pointless when it isn't doing anything differently.

Additionally, pretty much all possible Joystick numbers (to fitr the fields i have for them) are already taken. What with all the Goflight and PFC serial devices being assigned numbers locally, plus each WideFS Client's button connections having 1,000s additions to distinguish them.

I could then point fsforce to joystick 206, and not worry about the number changing.

How would "FSForce" know about 206 and where would it address it thus if it is internal to FSUIPC?

If what you are really referring to is a virtual device, in Windows, then the programming of such things is way outside my area of expertise, and needs something of much greater privilege (driver level) than a mere module running inside an application, as FSUIPC is.

Regards

Pete

[BorisTheSpider]

If what you are really referring to is a virtual device, in Windows, then the programming of such things is way outside my area of expertise, and needs something of much greater privilege (driver level) than a mere module running inside an application, as FSUIPC is.

Pete, thanks for the reply.

I see what you mean. I may contact the author of SPAD and see if they can do something, since that already does the kind of thing I'm referring to (for example, the gear lever on my saitek switch panel is seen as two buttons on joystick 64, which I then assign through fsuipc)

.

[Pete Dowson]

I see what you mean. I may contact the author of SPAD and see if they can do something, since that already does the kind of thing I'm referring to (for example, the gear lever on my saitek switch panel is seen as two buttons on joystick 64, which I then assign through fsuipc)

Buttons on joysticks 64 ff are supported via offsets. There are similarly virtual axes on these joysticks, addressed at offsets 3BA8 ff. However, I cannot see how any such provision can solve your problem. FSForce will be accessing the joysticks directly into the Windows or DirectX API, not via an intermediate program accessing FSUIPC offsets. Just see what it says in its description:

"Programmed using the latest in DirectX technology"

To redirect any of its operations you'd need a driver-level program which hooked into DirectX below thw Windows API. As I said before, in fact.

Regards

Pete