Jump to content
The simFlight Network Forums
airernie

SPAD and Saitek BAT Switch

Recommended Posts

It appears that a change introduced in one of the recent versions of FSUIPC4 is affecting SPAD's interface with the BAT switch on the Saitek switch panel.

Using the default 172 for testing, the BAT switch functions normally with FSUIPC 4.964, Saitek FSX plug-ins, or if the BAT switch is using 'keyboard emulation'.

However, with 4.966 and 4.966c in 'FSUIPC offset change' mode (which is the default), SPAD displays switch movement in it's GUI, but nothing happens with the 172.

Thanks,
Ernie

Share this post


Link to post
Share on other sites
20 hours ago, Thomas Richter said:

Hi,

make sure you use latest FSUIPC4966n.zip

Thomas

Thanks for the link.  I just tried it and have the same issue.  

I don't have a copy of 4.965 to see if the issue exists there also, so I don't know when the functionality changed.

Ernie

Share this post


Link to post
Share on other sites
5 hours ago, Thomas Richter said:

Hi,

what version of SPAD are you using anyway?

Thomas

I'm using the freeware v0.5.0 although I've also tried v0.5.1.  

Share this post


Link to post
Share on other sites

Hi,

I picked up a Switch panel (here from Shannon) to check with SPAD v0.5.1. The bug is introduced with 4.966 or just before, but anyway. As a workaround you can paste this Battfiddle.lua into your Modules folder and if you already run any Lua file then add into your ipcReady.lua file the following line to start the fiddle file

ipc.runlua('BatFiddle')

If you don't run any Lua file then just paste also the ipcReady.lua file into your Modules folder.

The fiddle just checks the switch position (Offset 0x3102) and compares with FS Master Battery, if False then it toggles the FS Battery Switch.

Thomas

ipcReady.lua

BatFiddle.lua

  • Upvote 1

Share this post


Link to post
Share on other sites

Hi Pete,

Just a bump, so the offset issue I experienced doesn't get lost in the flood of 64-bit related posts.  

I reverted to 4.964, so I haven't had a try at Thomas' suggestion yet.  Admittedly, I'm hoping that you can resolve the issue in a future version, so I don't need to add the Lua script.

Thanks, 
Ernie

Share this post


Link to post
Share on other sites
1 hour ago, airernie said:

Admittedly, I'm hoping that you can resolve the issue in a future version,

I don't think I understand the "issue" well enough to fix it

On 5/9/2017 at 10:12 PM, airernie said:

It appears that a change introduced in one of the recent versions of FSUIPC4 is affecting SPAD's interface with the BAT switch on the Saitek switch panel.

Using the default 172 for testing, the BAT switch functions normally with FSUIPC 4.964, Saitek FSX plug-ins, or if the BAT switch is using 'keyboard emulation'.

What would FSUIPC have previously seen when you operate the BAT switch? Is it a button numver? A virtual button perhaps? I really don't know what SPAD does -- maybe its author or support can investigate whether it is something I can do.

I see Thomas found the same, but without knowing more I'm not sure what I can do. I was planning on releasing version 4.966n properly next week as 4.967, along with the 64-bit version for P3D4 at the same time. I would rather fix it before then than have to change both soon after.

1 hour ago, airernie said:

I reverted to 4.964, so I haven't had a try at Thomas' suggestion yet.

Well, trying that would probably tell me all I need to know, so it is important. Otherwise it just won't get fixed. Bumping this thread "so it won't get lost" is a bit pointless without doing that first.

Pete

 

Share this post


Link to post
Share on other sites
52 minutes ago, Pete Dowson said:

Well, trying that would probably tell me all I need to know, so it is important. Otherwise it just won't get fixed. Bumping this thread "so it won't get lost" is a bit pointless without doing that first.

Hi Pete,

Just tried Thomas' LUA scripts with 4.966c and the BAT switch works correctly when it is present.  Without the LUA scripts, the BAT switch is inoperative.

Ernie

Share this post


Link to post
Share on other sites
On 5/26/2017 at 4:31 PM, airernie said:

Just tried Thomas' LUA scripts with 4.966c and the BAT switch works correctly when it is present.  Without the LUA scripts, the BAT switch is inoperative.

Okay. Thanks. That sems to imply that offset 3102 isn't working correctly.

I'll take a look.

Pete

 

Share this post


Link to post
Share on other sites

What version of FSX or P3D are you using, please?

Both offsets 3102 and 281C (both master battery switch offsets) should operate the battery switch by direct action in SimConnect, being controlled by a "SimVar".

This worked in all versions of FSX and FSX-SE, and also in P3Dv1, but it was broken in the Simconnect included with P3Dv2. Until it was fixed I implemented temporary action (called "P3Dfiddles" -- there are more than one!), which could be turned on or off by INI file parameter.

The parameter should be defaulted 'on' for P3D2 but off for everything else, where the problems are supposed to be fixed. But it looks like it is now Off by default in any case.

[LATER]

I've just tested with P3D3.4 and it still hasn't been fixed in P3D.  I'd better check P3D4 too!

For now, instead of using that Lua plug in, just add "P3DV2fiddles=Yes" to the [General] section of the INI file.  I'll make the battery option fix default in 4.967.

Pete

 

 

Share this post


Link to post
Share on other sites
14 hours ago, Pete Dowson said:

What version of FSX or P3D are you using, please?

Hi Pete,

FSX SP2, Windows 7 Pro 64-bit, FSUIPC4 4.966c. 

I replaced the Lua plugins with "P3DV2fiddles=Yes", but it didn't resolve the issue.  Perhaps because I'm in FSX?

I have attached the ini and log files in case they might prove useful.

Thanks,
Ernie

 

FSUIPC4.log

FSUIPC4.ini

Share this post


Link to post
Share on other sites
7 hours ago, airernie said:

I replaced the Lua plugins with "P3DV2fiddles=Yes", but it didn't resolve the issue.  Perhaps because I'm in FSX?

Ah, sorry. Should have checked. It's just that the problem you have was a bug in P3D2 and now I find P3D3, but I've now found it is okay in P3D4 so they finally fixed it.

It has never been a problem with FX or FSX-SE, so I'm puzzled. I CAN make the "P3D" fiddles work across the board but I'm rather concerned why it is necessary and why it appears different between 4.964 and 4.966c when there's certainly been no changes which could affect that area.

I've not really got time for a while to investigate this further so I'll just do the "fiddle" for the 4.967 release, by the end of this week.

Pete

 

Share this post


Link to post
Share on other sites

I'm sure the issue is made all the more difficult because I've only seen one mention and he had written it off to Windows 10.

In any case, it's nothing more than a minor annoyance that is easily dealt with through Thomas' Lua script if need be.

Thanks for the help,
Ernie

Share this post


Link to post
Share on other sites

Well, I've found the difference, but it wasn't between 4.964 and 4.966c, but from 4.959. I don't know why it worked for you in 4.964.

It's a entry in a large table which got changed "WROK" to only "WR". And only for 3102. the equivalent 281C was still WROK, even for the same SimVar!

It was a problem that "WROK" wa no good in P3DV2 and later (though its okay in P3D4). i've been concentrating on P3D so much in the last weeks that I didn't notice it was going to be wrong for FSX. Very naughty of me, there's so much to re-test even on minor changes. Sorry.

It'll be okay in 4.967.

Pete

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.