Gypsy Baron

Thanks for the quick 'fix' Pete. I'll pass along one of the lua scripts I use that make use of the ipc.display routine. For the most part, they all have a section similar to the first function in the file below that displays the 'current control set', or mode assignments for a given aircraft. It is this lua display window that I saw moving between 2 locations. Off the top of my head, when I load a new aircraft that uses an 'aircraft specific' display.lua I have the plugin called, I believe, through the use of the 'Auto.name' functions in the INI file.This should satisfy the criteria you mention above for having a window opened before using the set.display routine, methinks. I often have one of my throttle detent switches programmed to send the 'kill all' and then the 'aircraft-specific-name-display.lua' 101=PD,11,C1084,0 ;//Lua Kill ALL 102=PD,12,CL21:R,0 ;//Run Lua Disp [/CODE] This is the 'auto.aircraft-name' sectiopn of my INI file: [CODE] [Auto.Boeing B-17G] 1=Lua KillAll 2=Lua DispB17CS 3=Lua B17G_Turbo 4=Lua B17G_Gear [Auto.Boeing Stratocruiser] 1=Lua KillAll 2=Lua A2A_B377_icflap [Auto.P-47D] 1=Lua KillAll 2=Lua DispP47CS [Auto.Spitfire Mk I] 1=Lua KillAll 2=Lua DispSPIT [Auto.Curtiss P-40] 1=Lua KillAll 2=Lua DispP40 [Auto.Tomahawk] 1=Lua KillAll 2=Lua DispP40 [Auto.P-51D 'Boomerang ! X] 1=Lua KillAll 2=Lua DispP51CS [Auto.P-51D] 1=Lua KillAll 2=Lua DispP51ASCS [Auto.MAAM-SIM Douglas C-47] 1=Lua KillAll [Auto.R4D] 1=Lua KillAll 2=Lua DispC47CS [/CODE] I believe I see a Lua Display window open when this occurs as I use 'event.offset' routine to call the display functions. Here is one example where I saw the two differt display positions when simply changing the value in 0x66C0 which calls the first function in the file. This is my DispP51ASCS.lus file. [CODE] function dispP51_CS(offs, val) conset=val+1 ipc.setdisplay(650, 200, 500, 100) if val == 0 then ipc.display("MAG INC _ BATTERY _ RECOG _ NAV LIGHTS _ LAND LIGHTS\nMAG DEC _ AV MASTER _ GEN _ APU _ PANEL LIGHTS\nControl Set = "..conset, 10) end if val == 1 then ipc.display("FUSELAGE _ LEFT MAIN _ RIGHT MAIN _ REL L DT _ REL R DT\nFUEL OFF _ LEFT AUX _ RIGHT AUX _ SPARE _ SPARE\nControl Set = "..conset, 10) end if val == 2 then ipc.display("PRIME _ FUEL PUMP _ SPARE _ GUN SIGHT _ GUNS \nSTART _ PITOT HEAT _ SIGHT GYRO _ SIGHT MODE _ SMOKE OFF\nControl Set = "..conset, 10) end if val == 3 then ipc.display("GPS _ AP CHART _ TAGS _ WING LEVEL _ CANOPY\nRADAR _ MAP _ HEADPHONES _ OXYGEN _ CABIN VENT\nControl Set = "..conset, 10) end end function dispFUEL_TANK(offs, dummy) TANK =ipc.readLvar("L:FSelP51State") if TANK == 2 then x = "R MAIN" end if TANK == 1 then x = "L MAIN" end if TANK == 0 then x = "FUSELAGE" end if TANK == 4 then x = "R DROP" end if TANK == 3 then x = "L DROP" end ipc.display("FUEL TANK = "..x, 2) -- ipc.display("L:FSelP51State = "..TANK, 2) end function dispFUEL_VALVE(offs, dummy) STATE =ipc.readLvar("L:Eng1_FuelCutOffSwitch") if STATE == 0 then y = "CUTOFF" end if STATE == 1 then y = "CLOSED" end ipc.display("FUEL VALVE = "..y, 2) end function Vent(offset, val) Vent_Set =ipc.readLvar("L:CabinVent") ipc.display("Vent = "..Vent_Set, 1) end event.offset(0x66C0,"UB","dispP51_CS") event.offset(0x66C6,"UB","dispFUEL_TANK") event.offset(0x66C5,"UB","dispFUEL_VALVE") event.offset(0x66C4,"UB","Vent") [/CODE] I hope this all makes sense. I'll do a bit more testing of the display issue I saw tomorrow, using version 4837. Paul

Pete, That topic title should read "broken when the parameter is 0" I was away in Europe since mid-May and just returned thus the 'late' post relating to a problem. I updated FSUIPC4 from 4.817 to 4.837 yesterday. When I went to start my A2A B-17G, which has all the switches, etc mapped via FSUIPC4 and uses both MCRO file entries and Lua scripts, I noted problems. Any of the switches that had "SET" as the operation in my MCRO file failed when the passed parameter was "0". passing any other number worked OK. Today, I checked two other aircraft and their functioning and found the MCRO file xx=L:Var=SET construct was also failing when a "0" was the parameter. One switch that selects fuel tanks also triggers a Lua display to indicate the selected tank. I noticed that when I selected tanks with select values of 1,2,3 or 4, they worked OK. When I selected the tank "0", the display indicated the previous tank that was selected. I then checked to see what the passed parameter actually was by sending it to the Lua display. As expected, the 1 through 4 selections showed "1" through"4". However, the "0" tank selection displayed a passed parameter of "-2147483648". I then changed the passed parameter to "-1" and that was passed correctly but "0" was not! I reverted back to version 4.827 and everything worked as programmed. next I installed version 4.829 and the "0" problem occured. I then checked the "changes" PDF and noted the 'bug fix' entry for 4.829: 13. Fixed a problem with the LVar macro format "L:<name>=DEC,0", to decrement the named L:Var value down to 0. The "0" was taken as omission and so did not limit the decrementing process. [/CODE] That seems to me to indicate that something that was 'fixed' there also 'broke' something as well. For now I have no option but to stay with 4.827 as any version after that will not work correctly as all of my aircraft assignments are made via FSUIPC4 and rely heavily upon the use of the MCRO files and Lua scripts. I also noted a problem with my Lua scripts that use the "ipc.display" function. I use a change to offset 0x66C0 to trigger a display of my current 'control set', which is defined by the value in that offset. Upon entry to that function I set the position and size of the lua display with: [CODE] ipc.setdisplay(650, 200, 500, 100) [/CODE] What is happening now with 4.829 and above is that the display location seems to randomly change from the position I set and the default position so the window moves to 2 different locations. This apparently is linked to: [CODE] 12 Added new Lua function lua.setowndisplay, which enables the ipc.linedisplay and ipc.display functions to have their own private Window entitled, positioned and sized as needed. Full details are provided in the updated Lua plug-ins documentation published separately. . [/CODE] I have not used this new function "lua.setowndisplay". Paul

Read the "FSUIPC4 for Advanced Users.pdf" in the documents included with FSUIPC4. Pay particular attention to the "shortaircraftnames" and "Profiles" area to have one set of assignments apply to multiple paints, models, etc. You 50% axis problem is most likely a scaling/calbration issue. I have dual Saitek throttle quads and I seem to recall a long time ago seeing that situation. It is an easy 'fix' but it has been so long since I did it I can't remember what was involved, exactly. Paul

I've never had an update of FSUIPC4 mess up my ini file (where the configurations are noted). If you are worried, simply make a copy of your current FSUIPC4.ini file prior to updating. If, for some reason there is something amiss, you can copy you previous configurations to the current ini file. I always keep a backup copy of the ini but have never had to resort to using it as a result of an update. Paul

Not only do they have a support forum but they have some of the best customer support of any 3rd party aircraft developer. The OP should visit the A2A form site to seek solutions to his problems. http://a2asimulations.com/forum/index.php Paul

Hummm...over at FSDeveloper, in the SimConnect forum, I see a good number of threads dealing with communicating to a multiplayer server via sinconnect. Not having an SDK covering the FSX version of multiplayer seems to cause a lot of difficulty, from what I read there, but the threads definitely indicate that simconnect is used to create objects in the multiplayer server as well as remove them. Paul

I see the message content coming in from the Server in a particular packet using Ethersnoop.exe so I assumed that SimConnect would be involved in the MultiPlayer Server-Client configuration. I couldn't find anything identifiable in the simconnect.log file however. I'll continue to dig around and let you know if I discover anything of use. Paul

Hello Pete, I am wondering if there are user-readable offsets where FSX places the tsxt for the messages that are displayed to the user...namely the messages in Multiplayer such as "XXX has joined the game", "yyy has left the game", "Aircraft xxx substuted by Aircraft yyyy". These messages are extremely difficult to read unless you happen to be running the display at 1024x768 as they are the red-text-on green-background type. I used the "WhiteMessages=Yes" in the FSUIPC4.ini file and that works fine for the ATIS broadcasts and my Lua display messages but that does not affect the 'comings and goings' messages. I have observed, and written to, offset 0x3380 and these messages come out OK but that is not the buffer used by the messages I wish to access. What I want to do is grab the text in the 'comings and goings' buffer and re-write it to my Lua window, which is very readable. Any clues as to where that buffer might be? I assume the messages are sent via simconnect but I have zero experience in that realm. I find it interesting that the ATIS red-on-green messages are now white-on-green with the ini file line added but the messages I am after are not affected by that fix. Any clues/help would be appreciated. Paul

Read the documentation...The "FSUIPC4 for Advanced Users.pdf"...the techniques for doing this are explained there. One can use the compound button programming approach or even a small Lua script to do whatever you wish. I use a user-definable location to create multiple "modes" for the switches on my dual throttle quadrant. In one aircraft I have 8 "modes", that is to say that each of my 10 switches have 8 unique functions, or 80 functions overall. I would guess that using a simple Lua script should allow you to handle the two different speeds for the encoder with an "if" "els" construct using the button state as the tested variable. Paul

Thanks Pete. I'll be sure to get the latest update and do some testing when I return in a week. Out the door in a few minutes! Paul

Pete, I had a few minutes before having to get ready to leave for the airport and tested v4.812f. No joy I'm afraid, however some new input. Initially it looked like 4.812f was OK...I entered a session and went out, in, out and in again OK. BUT, my system BIAO were set for my "travel" mode, with the system clock set to deliver a 2.0 Ghz CPU speed as opposed to my normal 4.2 Ghz speed. (i5-2500K) My system has been stable at the 4.2Ghz settings for several months.. I went back and re-booted with my normal BIOS settings with the CPU at 4.2Ghz and tried the same session again two times and got the crash both times. So, it would appear like a timing issue of some sort most likely. Problem signature: Problem Event Name: BEX Application Name: fsx_MP1.exe Application Version: 10.0.61637.0 Application Timestamp: 46fadb14 Fault Module Name: unknown Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Offset: 00000000 Exception Code: c0000005 Exception Data: 00000008 OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 1033 ********* FSUIPC4, Version 4.812f by Pete Dowson ********* User Name=xxxxxxxxx User Addr=xxxxxxx FSUIPC4 Key is provided WIDEFS7 not user registered, or expired Running inside FSX on Windows 7 ... FSX has been renamed as "fsx_MP1" Module base=61000000 31 System time = 04/04/2012 08:22:39 31 FLT path = "C:\Users\Gypsy Baron\Documents\Flight Simulator X Files\" 47 Trying to connect to SimConnect Acc/SP2 Oct07 ... 47 FS path = "X:\Microsoft Flight Simulator X\" 639 Run: "C:\TEMP\DAT_BAK.bat" 639 LogOptions=00000000 00000001 639 Wind smoothing fix is fully installed 639 G3D.DLL fix attempt installed ok 639 SimConnect_Open succeeded: waiting to check version okay 639 Trying to use SimConnect Acc/SP2 Oct07 3650 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 3650 Initialising SimConnect data requests now 3650 FSUIPC Menu entry added 3666 C:\Users\Gypsy Baron\Documents\Flight Simulator X Files\WoP2 B17G Fearless Fosdick RTG at Bassingbourn.FLT 3666 Y:\91st_BG_Aircraft\WoP2_b17g 91st BG\B17g_FF.AIR 34554 Weather Mode now = Real World 74724 System time = 04/04/2012 08:23:53, Simulator time = 16:24:29 (15:24Z) 75052 Aircraft="Boeing B-17G "Fearless Fosdick"" 111728 Starting everything now ... 137171 Advanced Weather Interface Enabled 167763 **** SimConnect appears not to be receiving requests! Re-connecting now ... **** 167872 SimConnect_Open succeeded: waiting to check version okay [/CODE] Paul

OK, I just checked the forum again before dinner and saw your reply above. I just re-enabled V4.812 mand went online to a multiplayer server. Entered flight OK. Exited the session and then re-entered. This went OK. The key here is I was the ONLY person in the session. I then changed to a different server that had 3 other people in the session. I spawned fine the first time and then left the session and re-entered, or rather tried to. I got the app crash. Here is the app crash message content: Problem Event Name: BEX Application Name: fsx_MP.exe Application Version: 10.0.61637.0 Application Timestamp: 46fadb14 Fault Module Name: unknown Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Offset: 00000000 Exception Code: c0000005 Exception Data: 00000008 OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 1033 [/CODE] And here is the FSUIPC log after the crash. It seems to indicate that simconnect was stalled during the re-entry process: [CODE] Running inside FSX on Windows 7 ... FSX has been renamed as "fsx_MP" Module base=61000000 281 System time = 03/04/2012 19:00:31 281 FLT path = "C:\Users\Gypsy Baron\Documents\Flight Simulator X Files\" 717 Trying to connect to SimConnect Acc/SP2 Oct07 ... 733 FS path = "X:\Microsoft Flight Simulator X\" 1419 Run: "C:\TEMP\DAT_BAK.bat" 1419 LogOptions=00000000 00000001 1435 Wind smoothing fix is fully installed 1435 G3D.DLL fix attempt installed ok 1435 SimConnect_Open succeeded: waiting to check version okay 1435 Trying to use SimConnect Acc/SP2 Oct07 11591 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 11591 Initialising SimConnect data requests now 11591 FSUIPC Menu entry added 11637 C:\Users\Gypsy Baron\Documents\Flight Simulator X Files\WoP2 B17G Fearless Fosdick RTG at Bassingbourn.FLT 11637 Y:\91st_BG_Aircraft\WoP2_b17g 91st BG\B17g_FF.AIR 40139 Weather Mode now = Theme 67127 Aircraft="Boeing B-17G "Fearless Fosdick"" 67143 System time = 03/04/2012 19:01:37, Simulator time = 19:00:53 (18:00Z) 127125 Starting everything now ... 133006 Advanced Weather Interface Enabled 162709 Sim stopped: average frame rate for last 37 secs = 55.2 fps 293640 Weather Mode now = Real World 395759 **** SimConnect appears not to be receiving requests! Re-connecting now ... **** 395883 Trying to connect to SimConnect Acc/SP2 Oct07 ... 395883 Now running with SimConnect Acc/SP2 Oct07 395883 SimConnect_Open succeeded: waiting to check version okay [/CODE] So, emty arena, no problems. An arena with other aircraft, a crash on the SECOND time going back into the same session. The reason I had not noticed this before was that is not something I usually have to do. once I get into a session I stay until I leave for the night. The reason I happened upon this issue was in the past couple of weeks a couple of the pilots I fly with regularly were having "connect issues" which turned out to be this very same app crash. We thought it had something to do with various persons in the session not having the "paint" that someone entering the session was using. This turned out to not be the case/ Today we were investigating another issue which involved 3 of us spawning to various parking spaces. In some instances the MP server would place us at a parking spot we did not spawn to. We usied the in-game menu to "Go to airport" and re-spwn and that put us where we intended to go. At that point it was suggested that perhaps the issue only occured when spawning from outsdide the session. When going back out and re-entering, I suffered the crash. This being repeatable we tested on the normal FSX Gamespy server with the same results. It was at that point that I recalled reading this thread and decided to see if the app crash was possibly related to FSUIPC. Disabling 4.812 "solved: the app crash. Reverting to 4.805 I still experienced the app crash. That is when I went to 4.801 with a positive result. Another related incident happened a couple of days ago when I tried to enter a MP session in an aircraft no one else had...a beta aircraft, for the very first time. I could not even get in the 1st time with that plane. later that night I tried again when the arena was empty and was able to enter and fly with the beta aircraft. In hindsight this would seem to suggest something related to the data being exchanged in a MP session and the impact it has upon the simconnect environment. This boggles my logical mind, I must say. In any case, I hope the information in this post is of use to tackling the issue. Regards, Paul

Just for information purposes, I had noticed a worrisome FSXA crash (BEX) occuring in FSX Multiplayer that seemed to have started occuring recently. The repeatable crash occured if I entered a MP session, then went back out and re-entered again. The 2nd time I entered, as soon as the "loading..." reached 100%, I saw the disk access that is associated with FSX crashing and a few seconds later I received the "fatal error" message. The first line in the info read "BEX" and the fault module was unknown. After several tests on both the Digital Themepark server and also a FSX Gamespy session, using a default aircraft as well as my usual A2A rides, I discovered that disabling FSUIPC4 v4.812 stopped the app crash from happening. I then reverted to V4.805 and the app crash also happened with that version. I then reverted to V4.801 and no longer had the app crash. A look at the FSUIPC4 log showed nothing beyond the "normal" entry listings up to the connection to simconnect. At least one other person that I usually fly with in MP was also seeing this app crash nand he was running v4.812 as well. I'm about to go traveling so won't be able to do any further testing or add to this information. Paul

Carl, The Saitek mode selector is a "special switch" as set by the Saitek driver and can not be seen by FSUIPC normally. As a result if you do not use the Saitek software you are limited initially to 1 mode. That's where the FSUIPC programming features come into use. Somewhere in this forum someone posted a workaround to cause the Saitek mode switch to be seen in FSUIPC. I've not tried it since my approach gives me the extended flexibility that I need for my application. Try using the search feature in this forum to find that posting. I know I had some replies in that thread as well. Paul

I run FSX but I would think that the same capabilities would be available with the registered version of FSUIPC for FS9 with regards to button programming. I use the "user-defined" offset, 66C0, as a "mode" selector by assigning a button to increment the contents of that location cyclically. The number in that location is used to selectively enable one command from several for the same switch/button using the programming features described in the Advanced Users Guide. I have a Saitek Pro yoke and dual throttle quadrants and have set up the switches onn the throttle quads for various aircraft. Mainly the A2A B-17G, B-377, P-47 and Spitfire. For the B-17G I have 8 "modes" selected by the two switches "closest to me" on my left side. These increment and decrement location 66C0. Below is the layout of the switches and the controls they operate in each mode. The code to facilitate this is entered by editing the FSUIPX ini file in a text editor. Here is a sample from my INI for the B-17G showing the coding for the 6 switches on the left quadrant and 3 on the right for the first 4 "modes: [Buttons.Boeing B-17G] !1=//SET 1 GENERATORS, FUEL PUMPS, FUEL VALVES, CONTROLS LOCK 0=B66C0=0 PD,14,CM6:39,0 ;//TOGGLE ENG1 FUEL VALVE 1=B66C0=0 PD,16,CM6:40,0 ;//TOGGLE ENG2 FUEL VALVE 2=B66C0=0 PD,18,CM6:41,0 ;//TOGGLE ENG3 FUEL VALVE 3=B66C0=0 PA,0,CM6:42,0 ;//TOGGLE ENG4 FUEL VALVE 4=B66C0=0 PD,15,C66340,0 ;//TOGGLE FUEL PUMP 1 5=B66C0=0 PD,17,C66341,0 ;//TOGGLE FUEL PUMP 2 6=B66C0=0 PD,19,C66342,0 ;//TOGGLE FUEL PUMP 3 7=B66C0=0 PA,1,C66343,0 ;//TOGGLE FUEL PUMP 4 ------------------------ !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 ---------------------------- !3=//SET 3 MAGNETOS, INVERTERS 50=B66C0=2 RD,14,Cx11000892,x00030001 ;//MAG1 INC 51=B66C0=2 RD,15,Cx21000892,x00000001 ;//MAG1 DEC 52=B66C0=2 RD,16,Cx1100092A,x00030001 ;//MAG2 INC 53=B66C0=2 RD,17,Cx2100092A,x00000001 ;//MAG2 DEC 54=B66C0=2 RD,18,Cx110009C2,x00030001 ;//MAG3 INC 55=B66C0=2 RD,19,Cx210009C2,x00000001 ;//MAG3 DEC 56=B66C0=2 RA,0,Cx11000A5A,x00030001 ;//MAG4 INC 57=B66C0=2 RA,1,Cx21000A5A,x00000001 ;//MAG4 DEC ------------------------------------- !4=//SET 4 GENERATORS, RADIO POWER, PITOT HEAT, MASTER IGN, APU, BATTERIES 70=B66C0=3 PD,14,CM6:13,0 ;//TOGGLE GENERATOR 1 MACRO 71=B66C0=3 PD,15,CM6:64,1 ;//RADIO POWER 72=B66C0=3 PD,16,CM6:14,0 ;//TOGGLE GENERATOR 2 73=B66C0=3 PD,17,C65858,0 ;//PITOT HEAT 74=B66C0=3 PD,18,CM6:15,0 ;//TOGGLE GENERATOR 3 75=B66C0=3 PD,19,C66535,0 ;//MASTER IGNITION TOGGLE 76=B66C0=3 PA,0,CM6:16,0 ;//TOGGLE GENERATOR 4 77=B66C0=3 PA,1,CM6:32,0 ;//APU MACRO ---------------------------------------- There are 4 more "sets after this, plus there is more code for the other switches in the sets above that is not shown, but this should give you an idea of what is possible and how to go about it. [/CODE] Here is the code for the "mode select" switches: [CODE] !10=//CONTROL SET INCREMENT/DECREMENT 161=PA,4,Cx510066C0,x00080001 ;//INCREMENT 0X66C0 VALUE BY 1, MAX 8 THEN 0, CYLCLIC 162=PA,5,Cx610066C0,x00080001 ;//DECREMENT 0X66C0 VALUE BY 1, MIN 0 THEN 8, CYLCLIC [/CODE] Using this setup I can pretty much take this aircraft from cold & dark to takeoff without having to use the mouse or keyboard. :) I also use some Lua scripts to facilitate more complex functions and to display the "current set" assignments in a Lua window for 10 seconds each time I hit the up or down control set switches. Using this approach, one could program 256 "modes" or assignments of each switch :) Hope this answers your question and helps you out. Paul

You can certainly assign functions to your controller through FSUIPC4. I use it to assign controls to my Saitek Pro throttle quadrant switches and axis. I also have an X-45 stick/throttle attached but for that I still use the "old" Saitek software for assignments as those buttons/switches operate the "general" controls...gear, flaps, panel veiews, etc. I would suggest you start by reading the FSUIPC4 documentation. In particular, the "Advanced Users Guide". I refer to that document on a regular basis when setting up my controls for a new aircraft. It takes more than one reading, however, as the operations contained in that document will give you a very powerful tool and as a result one needs to understand things like compound button programming and other features. My particular applications use FSUIPC4 to assign up to 8 functions to a single switch on some aircraft. That is to say I have 8 "modes" for a given set of controls for an aircraft. This is accomplished with FSUIPC4. So, while Pete is away, start reading the documentation :) Paul

Are the values you read base 10 or base2? Most controls like that have parameters of 0,1,2,3 (00, 01, 10, 11 base 2 ). Try sending 1, 2 or 3 as the parameter. I just noticed... the command format is " ipc.writeLvar( ) " remove the"s" from your statements! Paul

My guess would be that if you listed the L:Vars for that aircraft you MIGHT find one that corresponded to that light. In which case you could read/control it via a Lua script. I don't have that particulat aircraft but on many others I control various functions via the L:Vars for the aircraft. FSUIPC4 has a function to list the L:Vars for an aircraft. That command appears in the list of FS controls available when you open the FSUIPC4 Buttons & Switches tab. Paul

Just a quick note that might help you Bobby. I use those user-defined offsets in my control configuration setup and one thing I find very usefull is the ability to display up to 4 offsets through the FSUIPC4 Logging facility. I use offset ox66C0 to control the "mode" my controls operate in and I have that offset value "permanently" displayed in the title bar so that I can see at a glance what "mode" I am in (I change modes by incrementing/decrementing 0x66Co with 2 of my momentary switches). I also use several other offsets in that range to trigger Lua functions. When debugging/testing any changes using other offsets, I just change the logging settings to display those offset values. Makes it a lot easier to actually "see" what you are doing...or not :) Paul

Thanks Pete.

Hello Pete, FSUIPC4 version 4749d appears to have broken a function that previously has been working. I noticed this evening that 4 of my switches on my Saitek throttle quadrants were no longer functioning as programmed but I could confirm that the switches were working. The switches in question use the "Offset Signed Byte Increment" and "Decrement" functions: x3100zzzz Offset SByte Increment (offset = zzzz), hexadecimal * x4100zzzz Offset SByte Decrement (offset = zzzz), hexadecimal * When the user-defined locations 0x66C3 and 0x66C4 are modified by the above controls they invoke a Lua script to handle the functions needed...writing to an L:Var and opening a Lua display indicating the value read from the user-defined locations. Additionally these same 4 switches invoke the FSX "PANEL_ID_OPEN" command which is the 2D panel for the C=1 autopilot. Thus, pressing one switch I should see the panel pop up, a message appear and either the turn or elevator knobs on the C-1 rotate. With 4749d only the "PANEL_ID_OPEN" is functioning. I reverted back to version 4747 and everything worked again. Reinstalled 4749d and the functions fail to work. I also have a pair of switches, non-aircraft specific, that use the "OFFSET BYTE CYCLIC INCREMENT" and "DECREMENT" functions and these are still working. 161=PA,4,Cx510066C0,x00080001 ;//INCREMENT 0X66C0 VALUE BY 1, MAX 8 THEN 0, CYLCLIC 162=PA,5,Cx610066C0,x00080001 ;//DECREMENT 0X66C0 VALUE BY 1, MIN 0 THEN 8, CYLCLIC Here is a section of my FSUIPC4.ini file for the aircraft in question that contains the non-operational functions: !8=//SET 8 C1 CONTROLS 130=B66C0=7 PD,14,CM6:73,1 ;//C1 MASTER ON 131=B66C0=7 PD,15,CM6:73,0 ;//C1 MASTER OFF 132=B66C0=7 PD,15,CM6:74,0 ;//AIL OFF 133=B66C0=7 PD,15,CM6:75,0 ;//RUD OFF 134=B66C0=7 PD,15,CM6:76,0 ;//ELE OFF 135=B66C0=7 PD,16,CM6:74,1 ;//AIL ON 136=B66C0=7 PD,17,CM6:75,1 ;//RUD ON 137=B66C0=7 PD,18,CM6:76,1 ;//ELE ON 138=B66C0=7 PD,19,CM6:77,1 ;//TELLTALE LIGHTS TOGGLE 139=B66C0=7 RA,0,Cx310066C3,x00640001 ;//ELEVATOR UP <-------- Not working in 4749d 140=B66C0=7 RA,1,Cx410066C3,xFF9C0001 ;//ELEVATOR DOWN <-------- Not working in 4749d 141=B66C0=7 RA,2,Cx310066C4,x00640001 ;//TURN RIGHT <-------- Not working in 4749d 142=B66C0=7 RA,3,Cx410066C4,xFF9C0001 ;//TURN LEFT <-------- Not working in 4749d 143=B66C0=7 PD,15,C66507,54 ;//INSURE C1 PANEL IS OPEN WHEN CONTROLS ARE OPERATED 144=B66C0=7 PA,0,C66507,54 <------- Same switch press works 145=B66C0=7 PA,1,C66507,54 <------- Same switch press works 146=B66C0=7 PA,2,C66507,54 <------- Same switch press works 147=B66C0=7 PA,3,C66507,54 <------- Same switch press works 148=B66C0=7 PD,19,C66507,54 149=B66C0=7 PD,14,CM6:88,0 ;//C1 MASTER SELECT Looking at location 0x66C3 and 0x66C4 with the logging function I see them both "stuck" at the maximum value, 100. =============== My Lua Script for the functions ============================ function C1_ELEVATOR(offs, val4) ELEVATOR_in = ipc.readSB(0x66C3) ipc.writeLvar("L:c1CenterElevatorKnob", ELEVATOR_in) ipc.display("Elevator Knob = "..ELEVATOR_in, 1) end function C1_TURN(offs, val6) TURN_in = ipc.readSB(0x66C4) ipc.writeLvar("L:c1TurnControlKnob", TURN_in) ipc.display("Turn Knob = "..TURN_in, 1) end event.offset(0x66C3,"SB","C1_ELEVATOR") event.offset(0x66C4,"SB","C1_TURN") ====================================================== Another group of switch assignments using the functions below work as planned. x1100zzzz Offset UByte Increment (offset = zzzz), hexadecimal * x2100zzzz Offset UByte Decrement (offset = zzzz), hexadecimal * 50=B66C0=2 RD,14,Cx11000892,x00030001 ;//MAG1 INC 51=B66C0=2 RD,15,Cx21000892,x00000001 ;//MAG1 DEC 52=B66C0=2 RD,16,Cx1100092A,x00030001 ;//MAG2 INC 53=B66C0=2 RD,17,Cx2100092A,x00000001 ;//MAG2 DEC 54=B66C0=2 RD,18,Cx110009C2,x00030001 ;//MAG3 INC 55=B66C0=2 RD,19,Cx210009C2,x00000001 ;//MAG3 DEC 56=B66C0=2 RA,0,Cx11000A5A,x00030001 ;//MAG4 INC 57=B66C0=2 RA,1,Cx21000A5A,x00000001 ;//MAG4 DEC It appears that it is the SIGNED BYTE functions that are not working. I substituted the unsigned byte functions in lines 139 to 142 above and the controls began to work again, but only in the positive range. This indicates that the Lua script is intact and the only failure point is the incremen/decrement function using sign bytes. Paul

Thanks Pete. When you get to it. No big hurry. Paul

That would be great, Pete, as I previously tried to "run" this script via the Lua EXT library without success. As a matter of fact, that was my first choice. The reason I need to launch that bat file without a command window is that I can't have one pop up while I am in flight, particularly while flying in formation in multi-player. I need to keep the FSX window focused while the periodic file backup takes place. Paul

The scrip runs outside of FSX....it runs fine if I double-click it's icon or type it's name into the "run" command line so Win7 knows how to run it. This script merely launches a batch file that does the auto-backup of my A2A accusim dat files every 10 minutes but the script is needed to start the bat file to run without opening a DOS Command window.

Hello Pete, I wish to run an external program when FSUIPC4 starts and have defined the correct path and program name in my FSUIPC4_MP.ini file, however the program is not being run and the FSUIPC4 log file indicates an error [Error=193] which is meaningless to me. My FSX is named "FSX_MP.exe", thus the reference to "FSUIPC4_MP.ini" above. I am running Win7 x64. All programs are set to "Run as Administrator". UAC has been turned OFF since day 1. Here are the salient sections of my INI file and the log file with the Programs declaration followed by the INI snippet: !4=//----------------- Run Backup Script ------------------------ [Programs] Run1=C:\TEMP\RUN_A2A_BAK.vbs ********* FSUIPC4, Version 4.746 by Pete Dowson ********* User Name="xxxxxxxxxxxxxxx" User Addr="xxxxxxxxxxxxxxxxxxxxx" FSUIPC4 Key is provided WIDEFS7 not user registered, or expired Running inside FSX on Windows 7 ... FSX has been renamed as "fsx_MP" Module base=61000000 Wind smoothing fix is not installed DebugStatus=15 62 System time = 09/11/2011 18:49:28 62 FLT path = "C:\Users\Gypsy Baron\Documents\Flight Simulator X Files\" 109 Trying to connect to SimConnect Acc/SP2 Oct07 ... 109 FS path = "X:\Microsoft Flight Simulator X\" 1281 FSUIPC couldn't run: "C:\TEMP\RUN_A2A_BAK.vbs" [Error=193] 1281 LogOptions=00000000 00000001 1297 SimConnect_Open succeeded: waiting to check version okay My guess is that FSUIPC4 can not launch a .vbs script which would be a shame as I need to run that script to launch a .bat file so that the .bat file does not open a Command Prompt window. EDIT: It does not work in Xp Pro x32 either. Paul