Mouse macro dropping functions

[ste531]

Im using the most up to date version of FSUIPC for FS9 with the PMDG MD-11. I created a macro for the 3 IRS knobs to turn to align when I pushed a certain key. It seemed to work just fine and all three turned when I tested the switch, however after shutting down FS9 and restarting, only two of the knobs turn to align when I hit the assigned key.

I remade the macro, naming it something different, just to weed out user error, but had the same effect. What could I be doing wrong?

[Pete Dowson]

Im using the most up to date version of FSUIPC for FS9 with the PMDG MD-11.

And what is the version number of that "latest version", please? I always need version numbers! I've lost count of the number of times falks have said "latest" when they mean the latest they've seen, not the actual current version.

I created a macro for the 3 IRS knobs to turn to align when I pushed a certain key. It seemed to work just fine and all three turned when I tested the switch, however after shutting down FS9 and restarting, only two of the knobs turn to align when I hit the assigned key. I remade the macro, naming it something different, just to weed out user error, but had the same effect. What could I be doing wrong?

Sorry, I've no idea. Did you test the macros when you made them?

Without any specific information, like the INI file (which is where all your settings are saved), I cannot really comment. You could of course use the FSUIPC Logging to see what is happening -- use Button logging.

But do please double check the FSUIPC version number first. It should be 4.60 or later.

Regards

Pete

[ste531]

I am using 3.98a I was under the impression that 4.60 was for Flight Sim X users, I am running FS9 as previously stated.

Yes I tested the macros when I made them, they worked at the time of the test. However, according to the log, one of the functions was not performed "because offset is not valid"

145767 JoystickValues PCnum=1, dwCount=6, data[2]={00000000 00000020}

145767 Button changed: bRef=1, Joy=0, Btn=11, Pressed

145767 [buttons.PMDG MD-11 GE CONTINENTAL] 4=P1000,11,CM6:22,0

145767 Macro: mouse action="PMDG_MD11.GAU":X188bf0*X8b12,31

145767 not executed because offset is not valid

145767 Macro: mouse action="PMDG_MD11.GAU":X188c10*X8b90,31

145767 Macro: mouse action="PMDG_MD11.GAU":X188c30*X8b90,31

This did not show up until after a restart of FS9.

What ini file are you referring to?

[Pete Dowson]

I am using 3.98a I was under the impression that 4.60 was for Flight Sim X users, I am running FS9 as previously stated.

Ah, yes. Sorry, my mistake.

Yes I tested the macros when I made them, they worked at the time of the test. However, according to the log, one of the functions was not performed "because offset is not valid"

Ahthen somehow the Gauge is different each time it is loaded. There's a safety check -- it compares the two bytes at the given offset with those in the macro to make sure the version of the gauge hasn't changed since you made the macro. This check prevents my code jumping into a gauge at some random place and causing havoc, crashes and other nasty events.

145767 Macro: mouse action="PMDG_MD11.GAU":X188bf0*X8b12,31

In this case the two bytes at offset 188bf0 were not equal to 8b12.

But the other two were okay:

145767 Macro: mouse action="PMDG_MD11.GAU":X188c10*X8b90,31

145767 Macro: mouse action="PMDG_MD11.GAU":X188c30*X8b90,31

which is rather strange. I can only think that the code at 188bf0 has an instruction which contains a full, not relative, address starting in the 2nd byte, and the Gauge is loading in a different part of virtual memory.

I've not seen this happen before at all, and I'm not sure how it can be dealt with. Perhaps you could ZIP that gauge (PMDG_MD11/GAU) and send it to me as an attachment. Send to petedowson@btconnect.com. I'll see what the code looks like and try to work out an alternative cross-check which i can include. Otherwise I'm afraid that might be a function which isn't really susceptible to this treatment.

What ini file are you referring to?

There's only one FSUIPC.INI file, it's the one next to FSUIPC in the FS Modules folder. It contains all of your FSUIPC settings. What other INI file is there which is at all likely to do that? I don't think there could be any ambiguity! But it doesn't matter now.

Regards

Pete

[ste531]

Ok Pete, I have zipped up that GAU file and its in the mail.

What other alternatives if any, do I have to map functions to a single button with FSUIPC? There is no key command for those buttons, so Im thinking I am pretty much out of luck.

Thanks for looking into this.

[Pete Dowson]

Ok Pete, I have zipped up that GAU file and its in the mail.

Unfortunately it looks like it is compressed and/or enoded in some way, so I can't get into in using my normal tools. I'll have to try to assign it as a Gauge in an aircraft so it'll get loaded into FS and de-compressed/decoded first. I cannot promise that I will succeed in finding any solution.

What other alternatives if any, do I have to map functions to a single button with FSUIPC? There is no key command for those buttons, so Im thinking I am pretty much out of luck.

Unfortunately this is also the way with many default FS gauges -- it isn't only add-ons which have such problems. Designers don't always think about the needs of those wishing to improve simulation realism with hardware.

You might see if the switch settings are stored in Local gauge variables (L:vars), because, if they are, then writing to those, via a normal macro or a Lua plug-in, may just do the trick. There are some "sticky" threads at the top of this Forum about all this, mostly contributed by 'guenseli'. Check the one entitled "Tutorial: how to get LUA Vars or commands out of FS ". There's also one about the MD11X (the FSX version) which might be partially relevant.

If I get anywhere with the GAU file I'll add to this thread, but it might take a while. And even if I find a solution it might not result in an updated FSUIPC version for a while as I'm in the midst of other stuff at present.

Regards

Pete

[Pete Dowson]

If I get anywhere with the GAU file I'll add to this thread, but it might take a while. And even if I find a solution it might not result in an updated FSUIPC version for a while as I'm in the midst of other stuff at present.

I managed to load it into FS9 and take a look, but that particular routine is a mess. Rather convoluted. Either the table entry pointing to it is constructed dynamically, so the entry actually changes (in which case there's no solution), or it is some result of the relocations or de-compression.

To try to help I've added a facility to make FSUIPC bypass the check and execute the code in any case. I won't publish this generally because it is rather dangerous (possibilities of executing wrong code at random, but more likely a crash). I've added a trap for normal exceptions so it may save anything so drastic (it would log an exception, the same as it now logs the mismatch).

Download this replacement FSUIPC.DLL and put it into your FS Modules folder:

http://fsuipc.simflight.com/beta/FSUIPC3985.zip

Then To make it take this course, edit the macro file. Find the part reading X188bf0*X8b12,31 and change it to X188bf0*????,31. The 4 ?'s tell FSUIPC to bypass that check.

Let me know if this helps. I think it has a 50:50 chance.

Regards

Pete

[ste531]

Thanks Pete, this seems to be working as of now with no ill effects.

I spent a couple hours last night just trapping that one switch, writing down the variable, and then restarting the simulator. After about 100 or so cycles I discovered that the two bytes at offset 188bf0 seem to stay within a set range, 8b10 through 8b18. It also seems that 8b11, 8b13, and 8b15 are excluded as I never saw them used.

Not sure if that is any kind of help to you.

Ill run a couple of flights with this later tonight and check in with you later. Thanks for all the help

[Pete Dowson]

I spent a couple hours last night just trapping that one switch, writing down the variable, and then restarting the simulator. After about 100 or so cycles I discovered that the two bytes at offset 188bf0 seem to stay within a set range, 8b10 through 8b18. It also seems that 8b11, 8b13, and 8b15 are excluded as I never saw them used.

Not sure if that is any kind of help to you.

Not really. There's no way I can generalise a check from that. Thanks anyway. I think you just have to stick to the unchecked method (i.e. ????) for such cases -- but take care to re-generate the macro if you ever update that aircraft. (You'd need to re-generate them all in any case then, but the others wouldn't crash FS, but only log the error and not work).

Regards

Pete