New 4.312 interim - slow trim response and forgets button...

[wothan]

Hi Peter

Using the 4.312 interim version, I found that trim response has become very slow.

After assigning a button, the setting isn´t saved after next FSX startup

I use the 2 way toggle switches on my Ch-Throttle quadrant for up/don trim and flaps up/down.

I found that trim has become very slow and when I try to assign my flaps up/down to a toggle switch, it isn´t saved (wont work again after next FSX startup)

Finn J

[Pete Dowson]

Using the 4.312 interim version, I found that trim response has become very slow.

Good catch! Actually the button repeat rate in general slowed by a factor of about 3! This happened in a much earlier interim release I think, the first one after 4.30's release. I had changed the "PostMessage" method I used to a "SendMessage" which I thought would give a smoother response (not faster, but more regular), and in most circumstances it seemed better -- I just failed to notice that the repeat rate had plummeted! Ooops!

Please get 4.316 which has this fixed.

After assigning a button, the setting isn´t saved after next FSX startup

Now that I don't understand, and it isn't reproducible here. The only way it might not be saved is if the INI file wasn't accessible for some reason when you "OK'd" out of the Options dialogue. Please check the [buttons] section in your INI. In fact keep a copy of it, then assign the buttons, then compare the after with the before. The button data (in fact all changes) are written back to the file on an OK exit (not an Escape or Cancel exit, which reverts the parameters).

Another possibility is that you set it in an Aircraft Specific mode without realising it, or, on reloading, were using an aircraft with a different aircraft-specific setting for those buttons. Again, checking the INI file will show what is happening.

Finally, there is a remote possibility and that some sort of corruption in your INI file made the read-back fail. If you think that may be the case the best thing is to delete the [buttons] section(s), but by all means let me have a look first.

Regards

Pete

[fjacobsen]

Thanks for Your reply Peter !!

I don´t think that my INI file has become corrupted, since if I revert to 4.30 everything works ok after reassigning the button.

I´m 99% sure that I didn´t use an aircraft specific setting.

I actually had my buttons programmed with 4.30, but upgrading to 4.312 suddently made my "Flaps down" assignment disappear.

I then reassigned it (with 4.312) and things workd fine until I closed down FSX, restarted FSX and was ready to put "Flaps down", then it wasn´t working again.

Reverting to 4.30 and reassigning the "Flaps down" button made it work again even after restarting FSX.

I guess that something with the reading of the button assignments in 4.312 has been goofed, please verify !

BTW: I only found this to be a problem with "Flaps Incr / Decr" so far.

Thanks for fixed "Reverser" :-)

Finn

[Pete Dowson]

I actually had my buttons programmed with 4.30, but upgrading to 4.312 suddently made my "Flaps down" assignment disappear.

I then reassigned it (with 4.312) and things workd fine until I closed down FSX, restarted FSX and was ready to put "Flaps down", then it wasn´t working again.

Reverting to 4.30 and reassigning the "Flaps down" button made it work again even after restarting FSX.

Well I've tried all of that and it all worked fine, 4/30. 4.306, 4.312, 4.316. I don't understand. I'd really need to see your Buttons parameters, as I think I said. There's nothing magic of clever about any of this, it is all very straight-forward, and nothing's been changed at all.

BTW: I only found this to be a problem with "Flaps Incr / Decr" so far.

FSUIPC cannot distinguish one FS control from another. They are simply numbers above 65536, sent to FS, that's all. If it affects one it has to affect all. I need to see what you have that's peculiar in your particular INI.

Regards

Pete

[timcook]

I have a similar problem in that FSUIPC.INI seems to forget my macro key assignment.

The cowls.MCRO file is as follows:

[Macros]

Module="Gauge018.GAU"

1=left_close=RX220a*X5500

I assign this macro to the keyboard X key, and the relevant part of the FSUIPC4.ini file is:

[Keys]

1=88,8,M3:1,0

[MacroFiles]

1=747 OHD

2=APchart

3=cowls

It all works fine when I set it up, but when I close FSX down and restart it no longer works.

Please let me know if you need any more information,

Tim

[Pete Dowson]

It all works fine when I set it up, but when I close FSX down and restart it no longer works.

Please let me know if you need any more information

The main information missing, as usual, is the FSUIPC version number. There was a bug like that fixed a couple of weeks ago, so can you try 4.316 now please?

Pete

[fjacobsen]

I´m working out of town until thursday.

When I get home I will try out 4.316 and report back !

I also said that I was 99% sure that I didn´t use an aircraft specific setting, maybe there is a 1% chance that I actually did :wink:

Finn

[timcook]

Sorry about that - I'm using version 4.316.

Tim

[Pete Dowson]

I have a similar problem in that FSUIPC.INI seems to forget my macro key assignment.

The cowls.MCRO file is as follows:

[Macros]

Module="Gauge018.GAU"

1=left_close=RX220a*X5500

I assign this macro to the keyboard X key, and the relevant part of the FSUIPC4.ini file is:

[Keys]

1=88,8,M3:1,0

[MacroFiles]

1=747 OHD

2=APchart

3=cowls

It all works fine when I set it up, but when I close FSX down and restart it no longer works.

I don't have that gauge so I can't test it exactly, but certainly the "1=88,8,M3:1,0" parameter works fine here.

Is that the only key you've ever programmed, or have you simply removed the others for brevity here? Might there be other [Keys] sections in the file, maybe [Keys....] for aircraft-specific use?

Can you do some logging, just to see what is happening, please?

First, add the lines

Debug=Please

LogExtras=2

to the [General] section of the INI file. Then load FSUIPC, and enable Key/Button logging in FSUIPC's Logging page. This will show whether FSUIPC is actually attempting to action the key. You would either get a line saying:

.. This key is programmed in FSUIPC4 'Keys' options

in which case it is trying to action the macro, or like this:

.. Key not programmed -- passed on to FS

showing it has forgotten it, as you are suggesting.

I suspect that the Gauge you are trying to access is not always loading into FS memory for some reason, so it seems as if the key programming is missing whereas really it just can't call the appropriate routine.

Regards

Pete

[timcook]

Hi Pete

Is that the only key you've ever programmed, or have you simply removed the others for brevity here? Might there be other [Keys] sections in the file, maybe [Keys....] for aircraft-specific use?

This is only key I have programmed.

Can you do some logging, just to see what is happening, please?

First, add the lines

Debug=Please

LogExtras=2

to the [General] section of the INI file. Then load FSUIPC, and enable Key/Button logging in FSUIPC's Logging page. This will show whether FSUIPC is actually attempting to action the key. You would either get a line saying:

.. This key is programmed in FSUIPC4 'Keys' options

in which case it is trying to action the macro, or like this:

.. Key not programmed -- passed on to FS

showing it has forgotten it, as you are suggesting.

I set up the logging as you said, and here is (I hope) the relevant line from the log file:

215453 KEYDOWN: VK=88, Waiting=0, Repeat=N, Shifts=0

215453 .. This key is programmed in FSUIPC4 'Keys' options

Let me know if you need anything more,

Tim

[Pete Dowson]

I set up the logging as you said, and here is (I hope) the relevant line from the log file:

215453 KEYDOWN: VK=88, Waiting=0, Repeat=N, Shifts=0

215453 .. This key is programmed in FSUIPC4 'Keys' options

So, it isn't forgetting the programming, it is only that either the gauge isn't loaded at the time, or, probably more likely, that the table entries which the mouse macro facility needs are generated on-the-fly by the panel coding instead of being defined in static memory. You could probably check that by re-programming it (to make it work), then load a completely different aircraft, then reload that one and test. I suspect it will be pot luck whether it works again or not, depending on how it sets itself up.

If the latter is the case (and I've not actually met one like that as yet, but I can see how it can be programmed) then there's really not much I can do -- the mouse macro facility can only work with standard SDK defined mouse rectangles statically defined using the SDK macros.

I can check this if you like, but I'd need that gauge, assuming it works without the rest of the panel. What aircraft is it from, by the way. It's name (Gauge018) isn't very helpful.

Regards

Pete

[timcook]

Hi Pete

I can check this if you like, but I'd need that gauge, assuming it works without the rest of the panel. What aircraft is it from, by the way. It's name (Gauge018) isn't very helpful.

I can't upload the .gau file, as it's to big (6 MB within a zip file). It's the cowl flaps gauge within this file that I'm trying to get to work, which is from the MAAM DC-3.

Meanwhile, I'll look at whether I can get a "standard" gauge to work - I'll let you know how I get on.

Tim

[timcook]

Hi Pete

I've just tried to make a mouse macro for the standard 747 - it operates the "Both" function of the audio panel.

Same problem, I'm afraid. The macro works fine when I make it, but if I then either swap aeroplanes or switch off and re-start FSX, then the macro no longer works.

I do have most of the previous version of fsuipc.dll, so I could use one of those if it's of any use?

Tim

[Pete Dowson]

I've just tried to make a mouse macro for the standard 747 - it operates the "Both" function of the audio panel.

Same problem, I'm afraid. The macro works fine when I make it, but if I then either swap aeroplanes or switch off and re-start FSX, then the macro no longer works.

Yes, I can reproduce that. I think it confirms what I said.

I'll look at this example under debugging when I get time. It looks exactly as I said. I will look to see if there's a way I can prevent the "TAB" test working in such cases, so that you aren't misled into thinking you've created a working macro. If the tables are reconstructed from scratch each time, there's really nothing i can do -- I can't find them as they are usually on the stack, which will be different every time.

In fact that's a good clue. I'll see if the address i get relates to the stack, and if so refuse to make it work for the test, or even come up with the option.

Thanks for the examples i can use. I'll be looking at that on my return from holiday on the 1st October.

I do have most of the previous version of fsuipc.dll, so I could use one of those if it's of any use?

No, it isn't anything whatsoever to do with versions. It is to do with how the particular mouse-rectangle parameters are being set up. The example you provided should enable me to stop folks trying to make unusable macros. I'm not sure I can do this, but i have a few ideas.

From the user's point of view all i can do is avoid the confusion you got into about FSUIPC appearing to forget things. That isn't happening here. It is just that what you want it to do can't really be done except by using the mouse to teach it every single time. That's not acceptable, so I will try to stop it looking as if it might work.

Regards

Pete