[fsuipc use]

Hi Pete,

If still interested in the behavior of axis events AILERON_TRIM_SET and RUDDER_TRIM_SET, see this post on FS-Developer.

https://www.fsdeveloper.com/forum/threads/using-event-aileron_trim_set-….444147/#post-810988

Best regards, Rob

 

[fsuipc use]

PS:

To exclude the possibility of wrong conversions in XML coding:
I did a flight test with the default 737-800, and writing a value 100 to events AILERON_TRIM_SET or RUDDER_TRIM_SET indeed has a high impact on the flightpath.
Meaning that if the value range of these SET events would be -16K to +16K, writing a value 100 would not be noticeable.

Rob

 

[fsuipc use]

3 hours ago, Pete Dowson said:

Hmm. Something is scalng it when assigned as an axis in FSUIPC then. I have both rudder trim and aileron trims in my 737 cockpit, calibrated through FSUIPC, and with the ProSim 737 they both seem to work quite normally. Of course I've never tried extreme positions away from centre,  but even so, the normal increment on the type of pot in use in my PFC cockpit only gives about 128 unique positions over the -16k to +16k range, so just a slight movement would exceed the 100. Yet the trim works fine.

Next tme I have the cockpit running I'll do some monitoring of the values and see what is going on there.

Pete

 

Hi Pete,

Yes, strange indeed that this works fine in your PFC.

Here's how I make my conclusions.
This is programmed in XML (I can't program in C++), tested with the default Accel B737-800.

50 (>K:AILERON_TRIM_SET)
gives readouts for
(A:AILERON TRIM PCT,percent) : 50
and
(A:AILERON TRIM,degrees) : 5

Likewise:
100 (>K:AILERON_TRIM_SET)
gives readouts for
(A:AILERON TRIM PCT,percent) : 100
and
(A:AILERON TRIM,degrees) : 10

AND
-25 (>K:AILERON_TRIM_SET)
gives readouts for
(A:AILERON TRIM PCT,percent) : -25
and
(A:AILERON TRIM,degrees) : -2.5

But
150 (>K:AILERON_TRIM_SET)
still gives readouts for
(A:AILERON TRIM PCT,percent) : 100
and
(A:AILERON TRIM,degrees) : 10

Hence my conclusion that the value range for the event is only -100 to +100
It's also consistant with the instrument readout for AileronTrim in the VirtualCockpit of the default 737-800.

What you could do: 
Check the event value in the log if you change your dial 1 step, and also observe the AileronTrim instrument in your Prosim 737 VC.
If these are low event values in the log: yes, somewhere the -16K to +16K range appears to be scaled into the -100 to +100 range.

Also check if moving the dial doesn't generate TrimLeft or TrimRight events instead of SET events; because that would explain why it works Ok.
Just saying that, because AILERON_TRIM_SET isn't documented in the FSX-Accel SDK (how about the P3DV4 SDK ??)

Getting curious (never done that upto now) I did the same experiment for the RudderTrim axis.
Result: behaves exactly the same as the AileronTrim.; so the event value range of -100 to + 100 gives max. deflection for rudder trim.

Best regards, Rob

 

 

[fsuipc use]

26 minutes ago, Pete Dowson said:

Strange. Here, with FSX-SE, I could not detect any event when using that sim assignment.

Do you have the same aircraft to test on as the OP?  Originally, till I tested here on a "normal" aircraft, I assumed what was happening on that specific aircraft was that it was somehow capturing the even before FSUIPC could see it, and before whatever is sent by FSUIPC would have been seen. But that wouldn't explain why I couldn't see the axis logged here.

Actually, that's a good spot. It's an error. I only differentiate between the two by checking the control number value -- axes are checked. But that number is missing from that check!

Too late to fix for FSUIPC3 and FSUIPC4, but I'll fix that for FSUIPC5. I'll need to see if I've missed any others!  It's quite a complicated differentiation. There are many "SET" controls. Some are for discrete values (eg Magnetos), even just on/off settings (Slew Set). But there are a number which are continuous, like heading set and altitude set, though those have more specific limits than definble as "Max" and "Min".

I guess what i should be defining as Axes for logging purposes are those I provide calibration for. And that does include the Main control trims. Elevator, Aileron, Rudder.  And I missed those last two. I'll revise the function making the choice to use the same list I use for calibration enabling instead.

Thanks! 

Pete

 

Hi Pete,

I suspected something like that ...LoL

I tested this with another aircraft then the OP (I don't have that either).

As said in a previous post, AILERON_TRIM is a very unique axis function; very peculiar, like the FLAPS axis.
It's not a normal  "axis" (you can't assign a controller lever/wheel to it via the FS menu), and with the event AILERON_TRIM_SET you can only set 201 integer values (-100 to +100) for this "axis".
In FSX (don't know about FS9) upto P3Dv4.3.

In case you wonder: I'm using the AileronTrim axis as "proxy" in a few applications, to control an Lvar with keys/buttons.
The charm of it being, that it has 201 discrete values (either via the SET, LEFT or RIGHT events) and that there's no "control acceleration" for it ..

Glad my input helped pinpointing the problem.

Cheers,

Rob Barendregt

 

 

 

 

[fsuipc use]

6 hours ago, Pete Dowson said:

The Aileron Trim (Centrer) control in FSX-SE (for that is how it is shown) works, but does NOT use any assignable control in FSUIPC. It appears to work internally somehow.

 

Hi Pete,

Maybe my remark below on the FSUIPC.log explains something  ….

This is with FSX-Accel and FSUIPC4 not-registered.

What I did:
In the FSX Controls menu, I assigned a key CTRL+SHIFT+M to the function described in the menu as "Aileron trim (center)".
I also made a small XML test gauge, that generates some axis events; including writing AILERON_TRIM_SET with a value 10

This is what the FSUIPC log shows (with event and axis logging enabled):

// This is the result of me pressing the CTRL-SHIFT-M key:
   150844 *** EVENT: Cntrl= 66731 (0x000104ab), Param= 0 (0x00000000) AILERON_TRIM_SET

// This is the result of the axis event writes in my gauge:
   152516 *** EVENT: Cntrl= 66731 (0x000104ab), Param= 10 (0x0000000a) AILERON_TRIM_SET
   152516 ***  AXIS: Cntrl= 65697 (0x000100a1), Param= 20 (0x00000014) THROTTLE_SET
   152516 ***  AXIS: Cntrl= 65694 (0x0001009e), Param= 30 (0x0000001e) ELEVATOR_SET
   152516 ***  AXIS: Cntrl= 65695 (0x0001009f), Param= 40 (0x00000028) AILERON_SET
   152516 ***  AXIS: Cntrl= 65696 (0x000100a0), Param= 50 (0x00000032) RUDDER_SET
 

All as I expected.
But what strikes me as odd, is that in the log AILERON_TRIM_SET is named  "EVENT" and all other axis writes are named "AXIS".

Best regards, Rob

 

 

[fsuipc use]

Hi Pete, 

Allow me to make some comment here (since I made a few gauge applications using the FSX "aileron trim axis")

The "aileron trim axis" is  a very peculiar "axis" in FSX, and not properly documented in the SDK.
Unlike any other axis in FSX, it doesn't take the usual value range of -16384, 0, to +16384, but a discrete value from -100 to + 100 … So: in percent.

Meaning that writing 50 as value for the event AILERON_TRIM_SET results in the "axis"  being set to 50 percent left-trim.
Likewise, each event AILERON_TRIM_LEFT or AILERON_TRIM_RIGHT, changes the "axis" value with exactly 1 percent between -100 and +100.

Yes, FSX has NO event AILERON_TRIM_CENTER, though suggested by the text "Aileron trim center" in the FSX Controls menu.
If you assign a key/button to the descriptive text  "Aileron trim center" in the FSX Controls menu, it generates an event AILERON_TRIM_SET with value 0.
So sets the Aileron Trim "axis" to zero (== centers it).

This explains why Brian has "aileron trim center" working properly when he assigns a key/button to it via the FSX key/button Controls menu.
I think (but I'm guessing here)  that the problem is that in the FSUIPC userinterface, you cannot assign the "axis" event AILERON_TRIM_SET to a key or button.

Hope this helps ….

Best regards, 

Rob Barendregt

 

 

 

 

 

[RCBco-30 Carrier Ops]

On ‎9‎/‎29‎/‎2018 at 10:08 AM, aeronauta said:

Sorry Pete , I read Doug Dawson ..and then Peter Dawson in the credits and made the assumption..  you are credited for FSUIPC!!! as always , thank you for replying...

 

Jorge

As Pete said (and you allready figured out yourself) , you are mixing up people …..

Pete Dowson and Doug Dawson aren't related (as far as I know ...LoL)

But if you are looking for a solution to use COP3 in P3Dv4 (using 64-bit replacement gauges), please contact me at the EMail address mentioned in the README of my COP3 package.
I may have an alternative solution for you.
 

Cheers, Rob Barendregt

[Logging LVARs?]

Have you tried Doug Dawson's XML_VARS  module (freeware) ?

It displays the Lvars (and their current value) defined in all gauges included in the panel.cfg.

 

See:

http://www.douglassdawson.ca/

 

Rob

 

PS: by the way, not related to FSUIPC.

[fsuipc]

Do the add-on products you are talking about say they need a registered install if FSUIPC? What products are you talking about in any case? What's this "practice area" anyway? You aren't revealing any details at all.

Hi Pete,

If it satisfies your curiosity :) :

It sounds like this guy has installed my (freeware) CarrierOperationPackage, which uses the IPC interface for speed control.

Hasn't contacted me though with his problems.

But I doubt that his problems have anything to do with FSUIPC.

Best regards,

Rob Barendregt

The Netherlands

[why cant I cant contact any one about a problem]

Hi Pete,

You never stop to amaze me on how you react to such non-sence posts like these, in such a polite way :lol:

Why do you even bother to answer it at all ?

Cheers, Rob Barendregt

[FSUIPC 3.71 causes CTD. FSUIPC 3.70 OK.]

Hi Gents,

Although there probably is an "inverse" relation between my replies in this thread, and the amount of Emails/Skype-sessions/testhours with Pete :-), I personally am convinced that V3719c is VERY stable.

Being a developper myself, I (and a testfriend of mine) had very frequent CTDs with V371*, untill Pete found the problem and worked around it in V3719c.

Since then, I have a 100+ FS-hours, and must have done a 1000+ aircraft/flight reloads in it, without a single CTD.

Now, one can never be sure that "your" CTDs are caused by the same problem as "mine", but, as Pete said, an evident problem was solved and it surely solved my CTDs.

Thanks again, Pete.

Cheers, Rob Barendregt

[FSUIPC 3.71 causes CTD. FSUIPC 3.70 OK.]

Hi Pete,

If it helps:

- I have a Nvidia 7900GT card.

- I only change from jet to jet

And in spite of my initial reaction (via Email), that suggested that with V3.7.1.6 (after an hour reloading flights and aircraft) the CTDs were gone, I've seen it three times again since.

But by far not as frequent as with 3.7.1.0.; to the extent that I haven't found a sequence of flight/aircraft selection to force the CTD with V3.7.1.6

Unlike with 3.7.1.0

Best regards, Rob Barendregt

[Strange value from one offset]

Although not related to FSUIPC directly, but if it helps any finding out why:

The XML variables BRAKE LEFT POSITION and BRAKE RIGHT POSITION had the the same problem (= the read values being dependant on eachother).

But that was in FS2002 ONLY (OK in FS9 or FSX), and then ONLY when those two variables were read in the same XML gauge.

Maybe this is a simular problem as yours.

Regards, Rob Barendregt

[The need of FSUIPC]

"He who reads replies, does not read feelings".

Very true indeed; if I read that right:?:

Unfortunately, written communication like in forums or Email can lead to very akward mis-interpretation of what someone is really trying to say with what he writes, or his state-of-mind when he wrote it.

Like the following example, which I wrote this week in the 5th Email to a user that was asking for support on my new FSX gauges that didn't work right for him:

...

""

I truely want to help, but you are (no doubt: undeliberately) misleading me every time :-)

""

Which I indeed wrote with a smile on my face, but appearantly was perceived as a real insult by this user.

Even intended humor can be easily understood the wrong way.

And then I'm not even talking about English not being the native language of many simmers (including me); which doesn't help either :lol:

And to Joao:

Besides what Pete replied, also don't forget that the amount of installed FSUIPC unregistered modules probably exceeds 100-times the amount of registered versions, because of all those freeware gauges that use FSUIPC and don't expect users to have a registered version.

And I expect that won't change much for FSX.

Although there now is a SimConnect interface, much of this pre-FSX stuff will still work just because Pete is still supporting the old IPC interface (now via SimConnect) in FSUIPC4 in a compatible way. Which allows me to make new versions of my freeware gauges for FSX very fast, without having to invest a lot of time in converting to the SimConnect interface myself.

For which I, and I guess many users, are very gratefull to Pete. Because he doesn't earn a penny on that part of FSUIPC.

Regards, Rob Barendregt

[FPS hit after installing FSUIPC4...]

Hi Pete,

If it helps: I've also done some FPS tests, using V4.02 unregistered but unused by any gauges.

By observing a rather static scenery ( a saved flight with a parked aircraft on a large airport, in Spot view) for a minute after loading.

And repeated the tests several times.

I use: AVG antivirus and ZoneAlarm firewall.

- With FSUIPC and Firewall On: avg. 11.5 fps

- With FSUIPC and Firewall disabled: avg. 12.5 fps

- Without FSUIPC and Firewall On OR disabled: avg. 14 fps

Disabling Antivirus didn't have any effect.

Regards, Rob

PS: measuring FSP is quite cumbersome of course, since it varies a bit continuously, so it remains a bit guessing.

But I had the most stable FPS (13.6 - 14.3) with FSUIPC not installed.

With FSUIPC and Firewall On, I had the lowest "peeks" downwards (sometimes less than 10)

[Still Version 4.01??]

Hi Pete,

Yes, the FSUIPC screen says V4.0.2 allright (didn't check that before).

But I always check the Windows File Properties first, to see if I actually installed the new version. :wink:

And it works fine for Pushback now.

Thanks, Rob

[Still Version 4.01??]

Hi Pete,

I downloaded V4.02 via the link in Announcements.

But after install, the .dll is still identified (via properties) as V4.0.1.5.

And has exactly the same size as the testversion you emailed me last Wednesday.

Was that your intention ??

Best regards, Rob

[FSUIPC4/SimConnect and FSX versions ...]

yes, it's available in both versions.

If it weren't the standard version wouldn't work at all, especially the weather and mission system ;)

Thanks Jeroen.

Sounds very logical.... If one knows (which I didn't) that these functions also use SimConnect. ;)

I have a lot of catching-up to do ..*sigh*

Groeten, Rob

[FSUIPC4/SimConnect and FSX versions ...]

Hi Pete,

Maybe not directly related to FSUIPC, but I thought I'd ask it here since FSUIPC is the first "heavy" SimConnect application:

Is the SimConnect interface available in both Standard AND DeLuxe edition of FSX ??

Iow: Does FSUIPC work on FSX Standard ?

Sorry if my question is trivial, or allready answered in your doc's, but I wasn't able to find the answer. So much stuff to read :-)

Regards, Rob

[Pushback-turn problem and FSUIPC]

Thanks Pete, for your (as usual) excellent assistance !!

Best regards, Rob

[Pushback-turn problem and FSUIPC]

Hi Pete,

You just replied when I was composing my answer :lol:

Glad you found the probable cause.

Of course it's up to you if you want to make an interim version or not (I can imagine the extra work).

On the other hand (if you don't mind !) I would appreciate an interim version to test with. This Pushback feature is a very tricky thing in FSX, especially if you want to control the pushback tugs as well.

Example: in my new gauge, there should be a short delay between the end of a pushback and the moving away of the tug in the scenery.

Now, I can accomplish that by, at the end of the normal pushback, issueing a repeated TogglePushback command for a few seconds, which causes the aircraft to remain in place with the tug coupled to it. Not a nice solution, but it works great :-)

And I just want to make sure that intercepting toggle_pushback events in FSUIPC (If I understand you correctly) doesn't interfere with that.

Thanks, Rob

[Pushback-turn problem and FSUIPC]

Hi Pete,

I know of the firewall/virusscanner problems.

I use AVG and ZoneAlarm, and also had that "addon menu" problem.

And FSUIPC (when used by a gauge, see the other post about licence keys) works fine itself as long as I place FSX in the trusted zone of the firewall.

I also have no controller problem (yoke / stick / pedals).

But again, for the test with "Shift-P 2" I used 3 setups:

- The standard B737 panel.cfg with NO added gauges and manual input of "Shift-P 2".

- With a small XML test gauge added to the panel.cfg that does nothing more than monitoring the Pushback state variable.

- With the same test gauge, but now I issue the TogglePushback and Select_2 events by clicking that gauge.

(so the last test also proves that the problem is related to the events itself, not the keyboard keys that also generate it).

I even tried it with all controllers Off, and firewall shutdown, and AVG completely de-installed.

But always the same behaviour:

- It works fine with FSUIPC not installed

- It doesn't work with FSUIPC installed.

Thanks, Rob

[Pushback-turn problem and FSUIPC]

Hi Pete,

First of all, I know all about the famous "continous event" problem by ill-designed gauges, that give a lot of users headaches with keysequences like "Shift-P 2" (pushback turnright) and "E 3" (Select Engine3).

In fact, I've made several freeware gauges in XML myself to bypass these problems in FS9.

But this problem in FSX / FSUIPC has got me stumped.

I use:

- Normal retail version of FSX, de Luxe

- FSUIPC 4.01, unregistered, is installed.

- A flight with the default 737, default panel.cfg , no other addons except FSUIPC installed.

Here's what happens:

- Without FSUIPC installed: they sequence "Shift-P 1" to start a pushback with a turn after a full length, works perfect (always)

- WITH FSUIPC installed, this sequence doesnot work (never). FSX simply doesnot connect the "1" key to the "Shift-P" key, so the aircraft doesn't turn.

Even in my Pushback XML gauge (where I bypass the "continuous event" problem by giving a Toggle_pushback and Select_2 event in the same cycle, FSX doesnot respond (with FSUIPC installed) to the Select_2 event; which I can see by monitoring the Pushback State variable.

Could you have any explanation for this ???

Can you reproduce this yourself ??

If it helps: I also made a logfile of FSUIPC, and it amazed me (but that might be normal) that there are so many wheather-related lines in there.

Snapshot:

405141 WX Received in 0 mSecs, WX request type 5, Lat=52.3129, Lon=4.7628, Alt=0.0m

405141 Weather Received (type 4 request, Interpolated): "????&A0 121227Z 00000KT&D609NG 100KM&B-1500&D6072 CLR 15/05 Q1013 "

405141 WX Received in 0 mSecs, WX request type 4, Lat=52.3129, Lon=4.7628, Alt=-0.4m

405563 *** EVENT: Cntrl= 66483 (0x000103b3), Param= 0 (0x00000000) TOGGLE_PUSHBACK

405563 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_2

406156 Weather Read request (At Aircrft) to area 4: ICAO="GLOB", Lat=52.31, Lon=4.76, Alt=-0.4, Req=2

406156 Weather Received (type 4 request, Interpolated): "????&A0 121227Z 00000KT&D609NG 100KM&B-1500&D6072 CLR 15/05 Q1013 "

406156 WX Received in 0 mSecs, WX request type 4, Lat=52.3129, Lon=4.7628, Alt=-0.4m

Which also shows the that my gauge gives the Toggle_pushback and Select_2 event in the same cycle.

And to make it even more weird: keysequences like "E 2" (Select engine 2) and "Shift-E 2" (Select Exit 2) works OK, with or without FSUIPC installed.

Any idea's ???

Regards, Rob Barendregt

[Keys for freeware gauges in FSX / FSUIPC4]

Hi Pete,

Thanks for the clear (and very reasonable) answer.

Cheers, Rob

[Keys for freeware gauges in FSX / FSUIPC4]

Well, that's clear enough :)

And how about the following:

Although we (me and another designer) are strictly freeware-gauge designers, we occasionally get a question if one of our freeware gauges can be included in a payware product; which we usually allow in exchange for a free copy of that product.

Untill now, we've always refused that, when that gauge included FSUIPC access, because of your conditions for the freeware keys.

How's your view on that now ?

Iow: If such a freeware gauge uses FSUIPC, is it allowed to have that (not FSUIPC of course) included in a payware product ?

This might be a "grey" area, but we surely will comply with your wishes for the use of FSUIPC. And I just want to be sure, either way ..

Regards, Rob