[FSUIPC issue on A2A's C172]

Pete, I'm having an issue with the a2a as well. Hoping someone might have solve it on here would be able to lend a hand. Using Pete's fsuipc i assigned the altimeter increase to the right function of my rotary and down to the left function of my rotary. however on the a2a it docent work. works on all other plaines but not the a2a. Please help me find a way to make this work. 

 

Thanks

Paul

How are you mapping the Kohlsman to the rotary? Direct "SET" will not work as the input needs to be scaled correctly.

You could, of course, employ a Lua script to accomplish this.

The normal FSX controls "Kohlsman INC" and "DEC" work when assigned to a button/switch. One could use the rotary

to send those controls using the "ranges" function, creating a "null" range about the mid-point of the rotary and then

an "UP" and "Down" range on either side with the "control to repeat while in range" option selected.

I use this method for elevator trim as direct mapping results in too 'coarse' a setting.

Also, you did not specify which A2A aircraft you are referring to.I am assuming the C172.

Note also, that there is a separate Kohlsman function in the kap140 autopilot which can be accessed using

the appropriate L:Variables.

Questions regarding the A2A aircraft are best asked in the A2A forums where you might find that others

may have asked the same questions.In any case, that is where to get definitive answers regarding A2A

aircraft since much of the coding in the Accu-Sim aircraft is done 'outside' of FSX.

Paul

[Axis Assignment]

It appears that something is setting nthe "Delta" to 32767. That is the amount that the axis input must change before FSUIPC4

will 'see' a change and act on it. At least that is my understanding.

 

Did you adhear to the assignment procedure and press "Delta" and then move the axis a small amount and press 'Delta"?

 

Also, I would check the calibration of that axis before making the assignment to insure that nthe output moves 'smoothly' with the input.

 

   Paul

[LUA Files are not shown in FSUIPC GUI]

It looks to me like you should consolidate most of those lua functions into

one or two .lua files and use event triggers to activate the various functions.

 

You should read the Lua Library PDF to get an idea of the various ways you can

trigger functions in lua scripts.

 

I usually wind up with one, or two at the most, lua files for each aircraft that needs

special handling via lua scripts.

 

This will save you a whole lot of ini entries to start all those scrips.

 

 Paul

[How to run again a Lua Script called in IPCready.lua]

You can assign a button or switch to run or re-run a lua script. If you look at the FSUIPC4  Buttons + Switches tab

and the drop-down menu for 'FSX command to send' or something like that, there will be entries

for each lua script and the various options...run, kill, etc. The menu entries are listed alphabetically so

scroll down to the 'l's :)

 

  Paul

[Is it possible to limit the of an axis so that in its lowest physical position is above a specific value?]

You should be referring to the Advanced Users Guide PDF as well as the Lua Library PDF.

That is where the information for doing most everything resides :)

 

To do what you want to accomplish sounds like all you need to do is scale the output such

that the instead of a range of say 0 to 100 you wind up with  an output range of 5 to 100.

 

When you assign an axis, in the FSUIPC.ini file the assignment has the min and max values

that were set in the FSUIPC calibration. You edit those values with notepad to have a

higher minimum output for the axis. That would be very easy to accomplish and test.

 

Another approach would be to use a small lua script to read the axis input and scale it

before sending it to the mixture offset.

 

   Paul

[FSX CTD with FSUIPC.DLL (inflight)]

I, too, have been getting FSX crashes since Ver. 4.927a/b with the very same FSUIPC offset:

 

Fault offset: 0x00013691

 

Paul

[Flight Simulator has stopped working]

FWIW, I also have been seeing FSX crashes with the fault module ID'd as FSUIPC.

 

I do not have ASN installed or P3DV2. I first noticed the crashes occuring when I installed 4.927b.

 

I've not been able to reproduce the crashes 'on demand' so haven't been able to devine what may be happening.

The only observation I have been able to make is that these crashes seem to occur when I am using the switches

on my dual Saitek throttle quads which are assigned via FSUIPC and also activate Lua scripts at times.

 

As a result, I have backed out to an earlier version ( 4.924a ) until I can run further test flights. At the moment I

have beta test obligations and online multiplayer mission flight obligations, neither of which can tolerate random crashing of FSX.

 

I've not added any new aircraft/scenery/add-ons since the system was last in a 'stable state' and the onset of the

random crashes.

 

Once I am able to do some further testing with version 4.927b I'll enable the logging and hopefully something will

show up there.

 

My OS is Win7 Pro X64.

 

   Paul

[GUID and autoassignletters]

I use the auto assign letters option having once been 'bitten' by Windows reassigning the device numbers.

 

My understanding and observations is that the GUID will NOT change for a given device even though

it is reconnected to a different port. What WILL change if the number that gets assigned.

 

With the auto assign letters option, the Joy(number) is replaced by Joy(letter) for a given GUID. Since

the GUID will never change, the assignment mappings will remain fixed.

 

   Paul

[How to get Values from a Lvar to FSUIPC Offset or SIOC.]

First off, you should probably have posted this in the main forum below instead of in 'User Contributions". More folks would see it down there.

As a starting point, read the "FSUIPC Lua Library.pdf" to get an idea of what functions are available.
You will most likely want to use Lua scripts to accomplish the software to hardware interface.

For example, you would first read the current state of the L:Var into a variable.

n = ipc.readLvar(“name”)  

"n" would now contain the value of the L:Var called out by "name" ( "L:some_variable" )

Then, depending upon what the output needs to be, you scale/modify "n" and then write it out to the offset that the hardware expects it to be.

value = n

ipc.writeSB(offset, value)

ipc.writeSD(offset, value)

ipc.writeUB(offset, value)

ipc.writeUW(offset, value)

   Paul

[FSUIPC Key assigment]

You would need to pass the current aircraft heading to the proper
OBS or VOR so it would take either a small XML gauge or a Lua script
to do it, I think.

Here is the XML code for setting the various available KEY events:

(A:Plane heading degrees magnetic,degrees) (>K:VOR1_SET)
(A:Plane heading degrees magnetic,degrees) (>K:VOR1_SET)
(A:Plane heading degrees magnetic,degrees) (>K:VOR1_OBI)
(A:Plane heading degrees magnetic,degrees) (>K:VOR2_OBI)
(A:Plane heading degrees magnetic,degrees) (>K:HEADING_BUG_SET)

Here is a sample XML gauge to set the OBS1. Just change the "55"
to the code for the key you would like to use.

<?xml version="1.0" encoding="utf-8"?>
<Gauge Name="B17G Flare Control" Version="1.0">

  <Keys>
    <On Key="55">   <!-- Key 55 is 7 on the main keyboard -->

    (A:Plane heading degrees magnetic,degrees) (>K:VOR1_SET) 
   
    </On>
  </Keys>

</Gauge>

Here are ther FSUIPC4 offsets for the various functions. You could
use a Lua script to read in the aircraft heading and write it out
to the offset you wish to set.


VOR1_OBI_DEC  65662  
VOR1_OBI_INC  65663  
VOR1_SET      65716   <------ Sets OBS 1
VOR2_OBI_DEC  65664  
VOR2_OBI_INC  65665  
VOR2_SET      65717   <------ Sets OBS 2

Using offsets to obtain the Plane heading degrees magnetic,degrees you would need to
read two offsets and subtract the magnetic variation:

0580  4  Heading, *360/(65536*65536) for degrees TRUE.
02A0  2  Magnetic variation (signed,  –ve = West). For degrees
        *360/65536. Convert True headings to Magnetic by  subtracting
        this value, Magnetic headings to True by adding this value.

Using XML is much simpler!

 

  Paul

[Plugin to Convert L:Var to Offset?]

In the past I have used the 'user defined' offsets as the 'output' for an internal L:Var.

 

Read the L:Var and write it to the offset.

 

Those offsets are 0x66C0 to 0x66FF

 

The opposite direction can also be implemented...read a user defined offset and send that value to the appropriate L:var.

 

  Paul

 

It seems Pete types faster than me :)

[How to read a joystick Axis in a LUA script]

Check the Com Library section of the FSUIPC Lua Library.pdf.

 

I think what you will want is this function:

 

n = com.gethidvalue(handle, "axis", str)

 

I've never had the need to use the items in that realm so I can't offer any further insight into

what additional steps you need to take.

 

I suspect you will need to 'open' the device using one of these constructs:

 

handle, rd, rdf, wr, initreport = com.openhid(VID, PID, unit, repno)
Or
handle, rd, rdf, wr, initreport = com.openhid(“vendor”, “product”, unit, repno)

 

I'm sure Pete will be able to give you better direction on this.

 

EDIT: Digging a bit more into the documentation, it may be as simple as using the ipc read facilities, specifically:

 

n = ipc.axis(joynum, "axis")

 

That appears to return the current uncalibrated value of the axis (U for you) of Joynum (1 for you).

 

   Paul
 

[ipcready]

You could assign a spare button/switch temporarily to kill the Lua script when pressed and to

start the Lua script when released. I use this procedure all the time when I am creating

and testing Lua scripts.

 

If you look down the list of assignable commands in the Buttons + Switches drop-down menu

you will see several options listed for each Lua script that is loaded. The kail snd start (or maybe run)

are listed there.

 

  Paul

[Lua script to transfer CRS 1 to CRS 2]

How are you calling that Lua script? Are you using the event.key function?

 

Does your script define this code in a

 

function

..

..

end

 

context?

 

I'm not certain if a space is required in the ("943E",MyData) but you might insert one

in any case. ("943E", MyData)

 

Just curious, I don't see those offsets in the "FSUIPC Offsets Status" pdf file. Where did you get them from.

 

  Paul

[OOM warning]

Since I already use the top window bar to display my 'mode' for my controls (offset 0x66C0 - I have multiple 'modes' for

each aircraft's button/switch assignments)  I needed another way to display the VAS. The log to window is really not a

good solution for me as that red text on grean background is extremely difficult to read! (Damn you Microsoft for not

making the colors and font size user-definable!!)

 

My soulution was to create a small Lua script that periodically reads 0x024C (ipc.readUD) and than sends the

value to the Lua display window (ipc.display).

 

The Lua display window can be positioned wherever you wish on the screen and the text color is white.

 

One can set that display to occur at fixed intervals or when VAS gets below a certain amount or using an

event.button or event.key  function to allow the display to appear when a button/switch of key-combo is pressed.

 

The display window can be set to remain active for a pre-assigned interval...1,2,3 etc seconds.

 

My Lua script below uses the event.offset to execute the function "VAS" each time that value chages.

I assign that value to a local variable, as I use it elsewhere as well, and then output the VAS value to

the lua display when it becomes less than 500000.

 

The display remains active for 2 seconds.

function VAS(control, vas)

    vas_in = ipc.readUD(0x024C)
    ipc.writeLvar("L:VAS", vas_in)

	if
	   vas_in < 500000 then
	   ipc.display("VAS = "..vas_in,2)
	end

end

event.offset(0x024C,"UW","VAS")

I have a 2D window for the RaytheonANR75 radar gauge installed in all my aircraft so it is often 'in view'.

I used the local variable I used in the Lua script,'L:VAS",   to display that value continuously at the top of

the radar gauge window.

 

Here is the xml code I inserted into that radar gauge.

//------------------- VAS Display ----------------------

      <Element id="VASReadout">
        <FloatPosition>410.000,20.000</FloatPosition> 
        <GaugeText id="VAS Readout">
          <BackgroundColor>0x000000</BackgroundColor>
          <Bold>True</Bold>
          <Bright>True</Bright>
          <FontColor>0xffffff</FontColor>
          <FontFace>Arial</FontFace>
          <FontHeight>20</FontHeight>
          <GaugeString>%((L:VAS, enum))%!07d!%</GaugeString>
          <HorizontalAlign>LEFT</HorizontalAlign>
          <Size>70,70</Size>
          <Transparent>True</Transparent>
        </GaugeText>
      </Element>
            
//--------------------------------------------------------------------

So, there are a couple more ways to 'skin a cat', as the saying goes :)

 

   Paul

[Assigning offsets and some questions]

You will need to edit the FSUIPC4.ini file to do that I believe.

 

In most of my aircraft-specific setions I have multiple functions assigned to the same

button or switch. As many as 4 in some cases.

 

If you are unsure of the coding needed. just assign each function separately in the Buttons + Switches menu, open the

ini file and copy that entry to a temporary text file. Do the same for the other assignments, assigning the same button/switch

and noting the ini entry.

 

Then just copy and paste those assignments back into the ini file, changing the entry number, and you should be good to go.

 

Here is a section of my assignments for the A2A B-17G. Note the entries for switches 14, 16 18 and 0  Those switches

each have 3 functions when pressed. Button 2 also has multiple assignments as well.

!2=//SET 2 STARTERS ENG 1 - 4 CLEAR START & MESH SET 4 PRIMER & PUMP - ALL MACROS
20=B66C0=1 PD,14,CM6:5,0 ;//STARTER ENG 1 - SET PRIMER TO ENG 1 MACRO
21=B66C0=1 PD,16,CM6:5,2 ;//STARTER ENG 2 - SET PRIMER TO ENG 2 MACRO
22=B66C0=1 PD,18,CM6:6,2 ;//STARTER ENG 3 - SET PRIMER TO ENG 3 MACRO
23=B66C0=1 PA,0,CM6:6,0 ;//STARTER ENG 4 - SET PRIMER TO ENG 4 MACRO
24=B66C0=1 PD,15,CM6:7,0 ;//MESH ENG 1
25=B66C0=1 PD,17,CM6:7,2 ;//MESH ENG 2
26=B66C0=1 PD,19,CM6:8,2 ;//MESH ENG 3
27=B66C0=1 PA,1,CM6:8,0 ;//MESH ENG 4
28=B66C0=1 PA,2,CM6:5,1 ;//CLEAR STARTER 1/2
29=B66C0=1 PA,2,CM6:6,1 ;//CLEAR STARTER 3/4
30=B66C0=1 PA,2,CM6:7,1 ;//CLEAR MESH 1/2
31=B66C0=1 PA,2,CM6:8,1 ;//CLEAR MESH 3/4
32=B66C0=1 PA,2,CM6:30,0 ;//SET PRIMER SELCT TO OFF
33=B66C0=1 PA,3,CM6:31,1 ;//ACTIVATE PRIMER
34=B66C0=1 PD,14,CM6:30,1 ;//SET PRIMER SELCT TO ENG 1
35=B66C0=1 PD,16,CM6:30,2 ;//SET PRIMER SELCT TO ENG 2
36=B66C0=1 PD,18,CM6:30,3 ;//SET PRIMER SELCT TO ENG 3
37=B66C0=1 PA,0,CM6:30,4 ;//SET PRIMER SELCT TO ENG 4
38=B66C0=1 PD,14,CM6:37,1 ;//SET FIRE EXT. SWITCH TO ENG 1
39=B66C0=1 PD,16,CM6:37,2 ;//SET FIRE EXT. SWITCH TO ENG 2
40=B66C0=1 PD,18,CM6:37,3 ;//SET FIRE EXT. SWITCH TO ENG 3
41=B66C0=1 PA,0,CM6:37,4 ;//SET FIRE EXT. SWITCH TO ENG 4
42=B66C0=1 PA,2,CM6:37,0 ;//SET FIRE EXT. SWITCH TO OFF

Note that I alsom use a 'qualifier' arrangement for my assignments as I have multiple 'control sets'

that re-define the functions of all the switches based upon the value in offset 0x66C0. That is

my 'mode' number. That is one of the 'compound nutton' assignment methods.

 

I suggest you have a good read of the "FSUIPC4 for Advanced Users.pdf" for the other possibilities. I reffer to that

document dfrequently when setting up assignments for a new aircraft or 'enhancing' my current assignments.

 

Note also, that I make use of MCRO files ( the CM6:xx ) entries above to access the local variables (L:Vars) of

this aircraft for the non-standard controls.

 

Note also that I use the entry in the ini file below to assign letters to my controllers. This insures that my

custom coding will not be 'upset' if Windows reassigns the controller numbers due to a change to your

systems controllers, usb hubs or addition of a new controller. This prevents a LOT of headaches should

a renumbering occur!!

 

[JoyNames]
AutoAssignLetters=Yes

 

  Paul

[FUEL CUTT OFF's choice not found in FSUIPC to control it by toggle switch]

The code most likely uses "L:Variables" to activate that function and requires a parameter of 0, 1 or 2 to

be passed to put the switch in the up, middle or down position.

 

I never use mouse macros when I assign my buttons+switches but instead declare the L:Vars in a MCRO file and then

pass the correct parameters.

 

It may be possible to pass parameters in your case. You would have to probably use 2 switches unless you have

a 3-possition switch. the 'off' (middle) position is probably set with a parameter of "1" if the code uses 0,1 and 2.

It is also possible that the code uses 1,2 and 3. In which case a parameter of "2" would set the missdle position.

 

Experiment with each parameter and observe the results.

 

  Paul

[Modifier button?]

Let me offer an approach to your modifier quaetion,

 

I use a 'modifier' on all my aircraft to assign multiple controls
to the switches on my Saitel Pro dual throttle quads. In some cases
I have up to 9 assignments per switch. Think of them as 'modes'.

It is simple and allows easy modification and addition of more 'modes'
by editing the ini file and using 'cut & paste' actions.

The technique uses one of the user-defined offsets to hold the 'mode'
number. One switch is assigned to increment the mode number. Each
press of the switch increments that number until it reaches the
maximum mode number. It then goes back to mode '0'. You COULD
have as many as 256 'modes' using this approach.  :)

The modifier is the "=B66C0=0" part of the assignment statement.
The mode switch is defined once per aircraft and below is my
top-right-most switch on my quadrants, A,4. I use the assign letters
to the joysticks name option so mine are ID'ed as "A", "B", "C" etc.
 

[JoyNames]
AutoAssignLetters=Yes

Here are the aissignmenys for the same switches on my
2 left-most switches on my quadrants, D,14, 15,16 and 17.

[Buttons.Curtiss P-40]
1!==//------- Control Set 1 -----------------
0=PA,4,Cx510066C0,x00030001 ;//CONTROL SET INC Max = 3 Step = 1
1=B66C0=0 PD,14,C66400,0 ;//Magneto - OFF
2=B66C0=0 PD,15,C66400,2 ;//Magneto - Left
3=B66C0=0 PD,16,C66400,3 ;//Magneto - Both
4=B66C0=0 PD,17,C66400,1 ;//Magneto - Right

2!==//------- Control Set 2 -----------------
60=B66C0=1 PD,14,C66506,225 ;//Toggle GPS
61=B66C0=1 PD,15,C66506,440 ;//Toggle ANR-75 radar
62=B66C0=1 PD,16,C66506,14992 ;//Toggle AP Chart
63=B66C0=1 PD,17,C65910,0 ;//MAP - TOGGLE (Panel 5)

3!==//--------- Control Set 3 -----------------
40=B66C0=2 PD,14,C66389,0 ;//Toggle Canopy
41=B66C0=2 PD,15,CM9:1,0 ;//Toggle Gunsight
42=B66C0=2 PD,16,CM9:8,0 ;//Klaxton Test Toggle
43=B66C0=2 PD,17,CM9:10,0 ;//Prestone Test Toggle

4!==//------- Control Set 4 -----------------
60=B66C0=3 PD,14,C66506,225 ;//Toggle GPS
61=B66C0=3 PD,15,C66506,440 ;//Toggle ANR-75 radar
62=B66C0=3 PD,16,C66506,14992 ;//Toggle AP Chart
63=B66C0=3 PD,17,C65910,0 ;//MAP - TOGGLE (Panel 5)

In your current case, simply define one button/switch to change 
the 'mode' and then just insert "=B66C0=0" in the top assignments
and "=B66C0=1" in the bottom assignments. 

0=P3,1,Cx510066C0,x00030001 ;//CONTROL SET INC Max = 1 Step = 1 Joy 3, button 1
1!==//------- first 4 of first set -------
1=B66C0=0 R2,32,C65607,0
2=B66C0=0 R2,36,C65615,0
3=B66C0=0 R2,34,C66277,0
4=B66C0=0 R2,38,C66276,0

2!==//--- first 4 of second set ----------
71=B66C0=1 R2,32,C65607,0   // NOTE: I see you have duplicated these commands in your  
72=B66C0=1 R2,36,C65615,0   // second set. There is no need to do that.
73=B66C0=1 R2,34,C66277,0   //only add the 'modifier' to those switch assignments that are 
74=B66C0=1=R2,38,C66276,0   //unique between 'modes'. The others you leave 'as 'is' buy only once.

I ususally add my 'global' assignmentsd, those that remain the same in all modes,
at the end of the 'Buttons.<plane name> section. Looking at your list again, I see vary few 
'different' assignments so your implementation should be quite simple.

This method lests you easily add  more 'modes' by simply changing the

0=P3,1,Cx510066C0,x00010001 ;//CONTROL SET INC Max = 1 Step = 1 Joy 3, button 1

entry to:

0=P3,1,Cx510066C0,x00020001 ;//CONTROL SET INC Max = 2Step = 1 Joy 3, button 1

and then add the new lines, taking care to adjust the line numbers.

3!==//--- first 4 of third set ----------
121=B66C0=2 R2,32,<new command>
122=B66C0=2 R2,36,<new command>
123=B66C0=2 R2,34<new command>
124=B66C0=2=R2,38,<new command>

Good luck,

 Paul
 

[The order of radio events]

Hummm, now this is very strange. That value is staying set now. I have no explanation as to

why it was reverting before but it definitely was. I would open FSUIPC and got to the

Buttons + Switched tab and simply hit the 'Reload all buttons' option, then 'OK'.

The tuning function stopped working and when I opened the ini file again, the entry

had changed. I did this several times.

It appears to be working just fine now.

EDIT: OK, I can reproduce the behavior. It seems that the first time I changed the parameter was

after I was already in FSX. I opened the INI file, changed the entry, saved the file and

then hit the 'Reload all buttons' option, then 'OK'. This is what I do when changing

button/switch assignments when testing or creating my 'aircraft specific' settings.

For those operations, the new data is entered and retained in the appropriate section.

I don't recall having had the need to change an entry in the "General" section while

running FSX before so I never encountered this behavior.

It would seem that when the ini file is re-written when FSX is running, the "General" section

is retained as it existed at the start of FSX. I just closed FSX, changed the parameter,

started FSX and then checked that the 'fix' worked. I reverted the value back to '4' while in

FSX, reloaded Buttons + Switches and saw that the previous value of '0' was retained.

So, it all comes down to when the value in the ini is actually changed. It must be prior to

starting FSX.

So, all is well and I learned something. :)

Paul

[The order of radio events]

Hello, Pete,

I just installed 4921g and changed the entry in the ini file:

//TimeForSelect=4

TimeForSelect=0

But, as soon as I do a 'Reload all buttons' operation the ini file reverts back to the default value.

//TimeForSelect=4

TimeForSelect=4

On further investigation I find:

If I make the ini change and then start FSX the change does work as intended. I can tune the

A2A C172 Nav radio Primary channel when that mode is selected. But, as soon as I reload the ini file,

say whenmaking a change to asdsignments, etc during testing, the ini file entry reverts to the

default value of '4'. This is undesirable. None of the other options that I have changed from

default in the ini file are reverting to default. Only this new option.

Paul

[A2A Spitfire Radiator assigned to Axis?]

oh, yes...

 

copy and paste error from myself!

sorry!!!!!

:oops: 

 

Bad,boy, Günter, bad boy!   :)

 

Dan, glad you are up and running. Last evening I created an addition to my Spitfire Lua script to add the

Radiator Lever axis assignment code just to insure that it was easily done, as I use the Input Configurator

normally to assign that function. The main difference between my code and Günter's is an attempt to

reduce the 'jumping back and forth' when going from one setting to the next due to any 'noise' on the

axis. I also assign the axis to write to one of the user-defined offsets and then use an event.offset  to trigger

the lua function.

 

Here is waht I came up with:

  function Rad_Flap(control, dummy)

	Rad_Lever_in = ipc.readSW(0x66C6)

    Rad_Lever = round(round((Rad_Lever_in+16384)/32768*10)/2)

	ipc.writeLvar("L:Eng1_RadiatorLeverPos", Rad_Lever)

--  ipc.display("Rad Flap = "..Rad_Lever, 1)  -- this line for testing only

  end


-- rounds the integer
  function round(num)
	num = tonumber(num)
	if num == nil then return 0 end
    if num >= 0 then return math.floor(num+.5)
    else return math.ceil(num-.5) end
  end

event.offset(0x66C6,"SW", "Rad_Flap")

The 'double use' of the 'round' function seemed to reduce the 'stuttering' but did not completely eliminate it.

 

Günter and I use slightly different approaches to arrive at the same result :)

 

   Paul

[A2A Spitfire Radiator assigned to Axis?]

There appears to be a missing "end" in the Spifire section.

------------------------------------------------------------- Spitfire


elseif string.find(acftname,"Spitfire",0,true)
then

	var = round(((ipcPARAM+16384)/32768*10)/2)
	--ipc.display(var)
	--ipc.sleep(50)
	ipc.writeLvar("L:Eng1_RadiatorLeverPos", var)


 end   <----------- This is the missing 'end'

[The order of radio events]

I can confirm the above observations vis-a-vis the registered vs unregistered behavior.

 

The radio 'direct tuning' works properly when the FSUIPC4 key file is removed, making it an unregistered version.

 

With the key file present, the radio 'direct tuning' feature does not work. Checking the above situations by logging

confirms the reordering of the KEY events.

 

   Paul

[Using Plan G over wifi with fsuipc4 and widefs7??]

I believe I set mine up to use simconnect. I'm far from my sim computer for the

next several days so can't really check this.

 

I do have a copy of Plan-G on this netbook that I have used in the past to connect

to FSX over my wifi at home.

 

In Plan-G, under Options I have "Simconnect" selected in the General box.

I have the network mode set to IPv4.

The local, internal IP for my FSX computer is set "192.168.0.194"

Server pipe/port is 500

 

Also, I believe there is an xml file required to be present that has to do

with simconnect but I can't find it here at the moment. Ah, here it is...

in the Plan-G manual item 20.3 on page 98. (page 90 by the bottom of the page numbers)

The simconnct.xml is located on the computer that has FSX running on it.

 

That section explains how to create/edit the simconnect.xml file.

 

Good luck,

  Paul

[Wrong controller numbers transmitted]

The reason you need to rescan is probably due to a noisy axis. That is what FSUIPC4 will see. I have an unused

axis on an old joystick that is connected just to allow my old analog rudder pedals to be connected. I have to tell

FSUIPC4 to 'ignore' that axis and then re-scan for the axis I am trying to work with.

The joy names (letters) is an FSUIPC4.ini file entry that automatically assigns letters to your controllers

instead of using the numbers, which are the default method. By using the letters, which are paired with the

GUID of the controller, even if Windows reports a different number for a previously programmed controler

(due to unpluging a controller or reinstalling FSX or Windows) the letters remain the same and all your

programming will continue to work.

In the FSUIPC4.ini file find the "JoyNames" sectionand insert the line below as shown:

[JoyNames]
AutoAssignLetters=Yes
[/CODE]

See page 26 of the FSUIPC4 User Guide.pdf that should be in your Modules\FSUIPC Documents folder. That will explain the

whole operation and the Windows issues it corrects.

Paul