[Fix control acceleration P3Dv4]

18 hours ago, Pete Dowson said:

Sorry. It was only possible in 32-bit versions by hacking into the code. There is no way we are going to try doing that in the 64-bit P3D4. If there is still a problem (and maybe L-M didn't understand when I pointed it out before P3D4 was released) you need to address your complaint to L-M.

Pete

 

Ok, I understand. Thanks.

Apparently, L-M did not understand. ☹️

[Fix control acceleration P3Dv4]

Hi,

I am sorely missing the „fix control acceleration“ functionality in P3D v4. I have very misbehaving heading bugs and radio frequencies in certain addons that could well use this FSUIPC functionality.

Any reasons it is no longer around in the FSUIPC versions for P3Dv4? Any other way of getting rid of that (IMHO stupid) control acceleration in P3Dv4?

Thanks

[Writing a watchdog]

Hallo Pete,

 

thanks for your reply. The start_pump_check () function is called as follows:

 

In file NGX.lua

 

if ipcPARAM == 13 then

   start_pump_check ()

end

 

NGX lua with param 13 is assigned to a controller button press.

 

Seems like event.offset() is the way to go.

I knew that there had to be a better way :smile:

 

Based on how the event.offset() works (being active when the plugin loads, thus executing the event handlers right away if events are fired), I'd have to add some logic to only do something when I actually want the watchdog to run, since I don't want to have it start automatically on plugin loading, but only on controller button press.

 

Thanks

[Writing a watchdog]

Hi,

 

I'd like to write a watchdog for the PMDG NGX center fuel tank pumps that turns them off once the "low press" annunciation comes on. The pump check shall start when a certain button on a controller is pressed.

 

I do know all the required offsets and controls I need in order to achieve this and have the function start at a controller's button press, but I am unsure as to how this might be realized best in LUA code.

 

I was thinking about a simple loop that checks for the respective condition every 10 seconds or so, basically:

 

function start_pump_check()

  while (condition not met) do

     -- get data

      if (data meets condition) then

         -- turn pumps off

         break

       end

       ipc.sleep(10000)

  end

end

 

However, I wonder if there is any better alternative or any best practice on how to handle such things.

Any hints?

 

Thank you

 

bpcw001

[FSUIPC crashes]

Okay. Here's 4.909c with the auto-throttle sync cutout when you use a reverser.

 

FSUIPC 4.909c only

 

No need to retest with Lua plug-ins, unless you want to try with that parameter changed -- don't think it'll help much, though.

 

Best Regards

Pete

 

Hi Pete,

 

that's fine. I don't need the LUA's any more since what I wanted is included in FSUIPC by default, so I will settle for what's provided.

Will try 4.909c for checking the reverser problem.

 

Regards

Dave

[FSUIPC crashes]

Hmm. So I hit the correct spot.  But I don't like it being jerky. Of course, the best solution is to use the Event method instead, as already explained. But I'll have a think about how to alleviate the timing problems with the "kill/restart" method.

 

Thanks for the testing. If I do thing of anything to improve it would you still test it for me, please?

 

Pete

sure. Please also have a look at my post #21.

 

Thanks

 

Dave

[FSUIPC crashes]

Hi Pete,

 

I discovered another thing in connection with FSUIPC's own throttle sync, not the lua stuff:

 

When assigning a controller axis to be the reverser axis (FSUIPC -> axis assignment, move axis and choose "send direct to FSUIPC calibration", then "reverser"), this controller axis works ok as long as the throttle sync is not active, i. e. when properly calibrated, the controller axis will move from throttles idle to full reverse.

 

However, then throttle sync is active, the reverser axis just behaves like a normal throttle axis, i. e. it moves all throttles from max power to idle.

 

Can you observe that behavior too?

 

Regards

Dave

[FSUIPC crashes]

Hi Pete,

OK, I haven't had any crashes with the 4.909b version this weekend.

The controls respond a little jerky now which probably is due to the fact that you put in some more critical sections for thread sync. Sometimes, the system seems to "think" for a split second before the throttles react to new input from the controllers. However, like I said, no crashes.

 

Regards

 

Dave

[FSUIPC crashes]

Working a bit in the dark here, without being able to reproduce it, but I suspected it might be related to the thread execution terminating naturally at the same time as it is being killed for the next try. I think there's a small chance of an overlap there where some things are already closed. I've added more critical sections to try to lock those out from each other. It's a bit of a trial and error process with your system being my only way of testing. Sorry, but could you see if you can make FSUIPC4909b crash, using the same Luas?

 

Thanks!

 

Pete

 

I'll try the new version this weekend.

 

Regards

Dave

[FSUIPC crashes]

Hi Pete,

 

I've started trying 4.909a tonight. I even added more lua files in the same way to sync props and mixture axes in order to increase the probability of a crash. 

So far I could yank the axis controls any way I want with no crash. Let's see how this is going after some more stress testing.

 

I also had a quick look into the controls section and found the Throttlesync toggle/on/off assignments. However, I didn't find anything for mixtures and props.

Is that in yet?

 

Regards

Dave

nevermind. I found it.

[FSUIPC crashes]

Hi Pete,

 

I got a crash again. Version 4.909a, although it says 4.909 in the crash log:

 

Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3

Faulting module name: FSUIPC4.dll, version: 4.9.0.9, time stamp: 0x51ee3e7d

Exception code: 0xc0000005

Fault offset: 0x000615ef

Faulting process id: 0xee8

Faulting application start time: 0x01ce8972bfeb5a07

Faulting application path: C:\FS\FSX\fsx.exe

Faulting module path: C:\FS\FSX\Modules\FSUIPC4.dll

Report Id: 90703c92-f566-11e2-906a-f46d040055e1

 

Happened when moving throttles, then pressing button to activate sync on my lua scripts, then moving throttles again.

 

Regards

Dave

[FSUIPC crashes]

Hi Pete,

 

I've started trying 4.909a tonight. I even added more lua files in the same way to sync props and mixture axes in order to increase the probability of a crash. 

So far I could yank the axis controls any way I want with no crash. Let's see how this is going after some more stress testing.

 

I also had a quick look into the controls section and found the Throttlesync toggle/on/off assignments. However, I didn't find anything for mixtures and props.

Is that in yet?

 

Regards

Dave

[FSUIPC crashes]

The existing FSUIPC Throttles Sync facilities can be applied to those too, automatically. It's an option on the Miscellaneous options tab.

 

Regards

Pete

 

Very good. Then no coding required from my side at all.

You make me a happy man :-)

[FSUIPC crashes]

Thanks for the update. I'll try my best to get some results by the weekend. Work currently keeps me busy and away from simming.

 

That event mechanism sounds good. I remember reading about events in the documentation but I've never paid any closer attention to them so far.

I may have an incentive to do so now, since I'm thinking about making a sync functionality for prop and mixture controls as well.

 

Regards

Dave

[FSUIPC crashes]

Okay. I've verified this. it is a bug! A VERY long-standing bug that no one has reported before. Had you reported it before venturing into other solutions I would have tried to fix it immediately, and will do so now. Unfortunately it may take me a few days as I have other commitments this week. But watch for updates maybe before, or over, the weekend.

 

I'm looking at the crash report now.

 

Pete

 

Ok. Thanks a lot. Looking forward to an updated fsuipc.dll :-)

If I understand you correctly, fixing the multiple throttle sync will make my LUA scripting obsolete.

 

That would still leave me with the question why the LUA version crashes.

 

Regards

Dave

[FSUIPC crashes]

Hi Pete,

 

thanks for your swift reply. Enjoy dinner now :smile:

 

So, I'll try and be more specific:

 

As for the first part:

 

I first had two axes assigned:

Throttle1: "send direct to FSUIPC Calibration", assigned as "Throttle1"

Throttle2: "send direct to FSUIPC Calibration", assigned as "Throttle2".

 

Calibration is done in "3 of 11: Separate Throttles per engine", and "No reverse Zone" is ticked.

 

Under the "Hot Keys" tab, I assigned a keyboard shortcut for "Multiple throttle synchronization", say Ctrl-W.

 

Now, when moving the assigned throttles without having pressed Ctrl-W, everything is fine. When pressing Ctrl-W, the throttle 1 axis will indeed move both throttles in sync, but travelling through the range *including" reverse. So, pulling the throttle all the way back will not be idle as with the separate throttles, but full reverse.

(The specific addon is the RealAir Turbine Duke, btw, but it also behaves like that in other addons).

 

 

Second (LUA) part:

 

I did already try and copy the value from throttle1 to throttle2 without using the generic throttle control, but it proved equally unreliable.

I wouldn't mind a sudden slight change when switching, but it should not crash.

 

Concerning the LUA assignment of the axes:

In FSUIPC, on the "Axis Assignment" tab, I used "Rescan" and moved the respective control to get the appropriate axis, under "Type of action required" I chose "Send to FS as normal axis" and in the dropdown I selected "Lua TH1" for the Throttle1 axis and "Lua TH2" for the Throttle2 axis (the LUA files were named TH1.lua and TH2.lua respectively).

 

When operating in "sync" mode, I do use both throttle controls. I know it is not necessary, but I want to maintain the feeling of dual-engine controls, hence the "dead" throttle2 control is used along with the throttle1 control.

 

There is some jitter in the throttle controls, but It doesn't occur excessive to me.

 

As for the Delta in the assignments, I didn't (knowingly) do anything there. Delta says 256.

 

In case you need more information, I'm standing by.

Regards

 

Dave

[FSUIPC crashes]

Hi,

 

basically I want to sync throttles in a twin-engine setup so that I can change between individial throttles and throttle1 controlling the power input for both engines on a button press.

 

I know that FSUIPC provides the possibility to define a keyboard shortcut for exactly this problem. However, I do not use a reverse zone on my throttles, so when the throttles are moved individually, everything is fine and pulling back the throttles all the way will result in idle, but when switching to single-throttle control via the FSUIPC functionality the throttles move through the whole range, including reverse. That is not what I want, and I didn't find anything to change this behavior. Maybe someone has a good idea here.

 

So, what I came up with are the following two LUA scripts, assigned to the respective throttle axes:

 

throttle1 LUA:

 

-- read if sync is requested or not

sync = ipc.readUB(0x66C0)

if (sync == 0xFF) then

-- sync requested. Copy throttle1 value to throttle control: AXIS_THROTTLE_SET

  ipc.control(65765, ipcPARAM)

else

-- default behavior: forward to throttle1 control: AXIS_THROTTLE1_SET

  ipc.control(66420, ipcPARAM)

end

 

 

throttle2 LUA:

 

-- read if sync is requested or not

sync = ipc.readUB(0x66C0)

if (sync == 0) then

-- no sync: just forward to throttle2 control: AXIS_THROTTLE2_SET

  ipc.control(66423, ipcPARAM)

end

-- do nothing if sync is requested

 

A controller button is assigned to toggle the offset at 0x66C0 with xFF

 

The whole thing appears to work nicely and does what I want, but I occasionally get nasty crashes of FSX when toggling to single-throttle and moving the axes:

 

Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3

Faulting module name: FSUIPC4.dll, version: 4.9.0.9, time stamp: 0x51dd33be

Exception code: 0xc0000005

Fault offset: 0x00061476

Faulting process id: 0x21cc

Faulting application start time: 0x01ce8651cfedf981

Faulting application path: C:\FS\FSX\fsx.exe

Faulting module path: C:\FS\FSX\Modules\FSUIPC4.dll

Report Id: 7a0a7f53-f245-11e2-ac4f-f46d040055e1

 

When taking away the LUAs from the axis and just running the usual axis assignments (either "send direct to FSUIPC" or 

"send to FS as normal axis"), I don't get any crashes.

 

My system is Windows 7 professional SP1 with all up-to-date patches, FSX SP2.

 

Any idea? What's wrong with my scripting?

 

Thanks 

 

Dave

[event.intercept]

The event.intercept function only does what it is documented as doing -- intercepts any write to the nominated offset by any client application, module or gauge. The write internal to FSUIPC from your assignment is not going to be seen as it is not from an outside agency!

All you need to do to accomplish exactly what you are trying to do there is assign the axis directly to Lua TestScript and have that simply do this:

ipc.control(64104, ipcPARAM)

because the axis value is passed as ipcPARAM.

Of course it would be more efficient to assign it directly to that control in the first place, but I'm assuming here that you are experimenting in order to do something more ambitious?

Also, it isn't clear why you might want to stop 66C8 from receiving the value, it being a free user offset in any case. The normal reason for an intercept is to prevent something doing something, or modifying it first.

To use an event you'd be better off allowing the offset to be written and use event.offset to call your function each time it is changed.

Regards

Pete

OMG - facepalm. Thanks a lot! I was working up something insanely complex while the only solution I needed was assigning a lua directly to the axis.

Anyway, that way I got to toy around a little with the event lib.

[event.intercept]

Hi,

I tried to make a simple test script, TestScript.lua, for FSUIPC in FSX SP2.

Running FSUIPC version 4.904.

function fsuipc_T1(offs, val)

ipc.control(64104, val)

end

event.intercept(0x66C8, "SW", "fsuipc_T1")

in FSUIPC.ini, I have the following:

[Auto]

1 = LUA DynamicFriction

2 = LUA TestScript

Now, in FSUIPC, I assigned an axis to "Offset Word Set" its values to x66C8.

On moving the axis, I'd expect the fsuipc_T1 function to trigger and send the param to control 64104 (FSUIPC calib throttle), which should move the throttle.

However, nothing happens.

I tried the same using a "while 1 do" construct and that works, however I thought using events might be more elegant than a polling loop.

Seems I have not grasped the event stuff yet.

What am I doing wrong here?

[FSX aircraft exits - pulling my hair]

Case closed, everything works again.

During some recent experiments, I lost the FSX control assignments for SELECT ITEM NO (1,2,3,4). Hence it could never work, and the doors didn't work no matter what aircraft I chose.

Sorry for having you bothered.

[FSX aircraft exits - pulling my hair]

Hi,

I've recently acquired Majestic's Q400 addon. Aircraft exits are supposed to be openend/closed via the standard SHIFT-E-([1], 2,3,4) key sequences.

I've never had any problem with other aircraft opening those doors using the respective key sequences, but for some reason it does not work on the Q400, although it is documented to work and apparently works for many people out there.

Opening the main exit using SHIFT-E is fine. Anything that comes after SHIFT-E is apparently ignored, since it is always the main exit that toggles.

Now, I've already tried the built-in FSUIPC fix, playing around with the time setting for the allowed period between SHIFT-E and the subsequent key press.

I've also assigned buttons to TOGGLE_AIRCRAFT_EXIT commands with the respective parameters (2, 3 or 4), hoping that I could prevent any key press timing problems.

All my attemps failed.

Anybody has any idea what could prevent these pesky doors from reacting to the appropriate inputs?

What other FSUIPC trick could I possibly pull on that problem?

Thank you.

[Dynamic axis assignment]

Yes. You'd have to put that logic into a Lua plug-in. The axis would be assigned to that Lua plug-in, which would automatically receive the raw uncalibrated axis input as variable "ipcPARAM". In the plug-in you would test a user offset to see how to forward the axis using ipc.control. The best control values to use are the "direct to FSUIPC calibration" ones, lists at the end of the added controls list in the FSUIPC advanced user's guide.

The user offset (eg 66C0) would be updated by your button using offset byte cyclic inc, so the value there cycles between however many values you want, or if only the two, use offset byte togglebits with a value of 255 so it alternates between 0 and 255,

Regards

Pete

Thanks. You really work through your posts backlog and provide help and answers. I do appreciate that.

[Dynamic axis assignment]

Hi,

I'd like to have a joystick axis reassigned on button press, e. g. if a joystick axis is assigned to the aileron axis, I want to press a button to reassign the same axis to act as steering tiller axis, and pressing the button again (or a different button) should switch back to the aileron axis assignment.

Is such thing possible?

If yes, I'd appreciate any input on how to actually solve this.

Thank you very much

Dave

[Key press assigned to axis range - repeat rate]

Hi Pete,

sorry to bother you again. I'm too dumb to do the Lua solution.

I understand the calculation you posted, and I understand that I need to do something like ipc.control(<axis throttle set code>, newCalculatedValue) in the script.

However, how would I assign this script to the respective axis? I only found that I could assign lua scripts to an axis as actions when travelling through certain ranges?

Thanks

Dave

[Key press assigned to axis range - repeat rate]

Hi Pete,

thanks for your (as always :smile: ) comprehensive answer.

I did have two of my quadrant buttons assigned to separate reversers which worked, but in the heat of a landing it was just too much fumbling, so I decided to go for a solution using a single axis for both reverses (although I do have two separate axes assigned to the throttles).

I like your Lua suggestion; going to try this one.

Thanks a lot!

Regards

Dave