Pete Dowson

That one would be more efficient like this: function transmitCOM1(offset, value) ipc.writeUW(0x66C0, value) end Silly reading the value again when it is supplied in the call! ;-). Same for your receiving one. function receiveCOM1(offset, value) ipc.writeUW(0x034E, value) end The client Lua will be started automatically by WideClient when it connects to the Server, but the sending Lua needs to be started in FSUIPC, either via ipcReady, or by an [Auto] section, or just by a keypress or button assignment. But that flatly contrdicts what you just said, that 0x66C0 remained zero! It can't be both zero and contain the COM1 value! Maybe you need to Monitor both 66C0 and 034E on both machines, to the normal log, and show me the log! I thought you said it connected okay. does WideClient show connection? Is the WideClient log looking normal? Pete

How can you get an axis value into FS without some analogue to digital conversion circuitry to do it? Surely, if it an Open Cockpits tiller and you are using Open Cockpits cards then everything should work together okay. Don't they provide instructions or support? If you can get an axis value in which looks like an axis input, you can simply assign it. if you are using software which needs to write the value to an offset then certainly 0C08 is fine as also is 3BC4, but note that 3BC4 provides an axis which needs assigning. It isn't automatic unless you are using the PFC driver for PFC hardware for which that area of offsets was designed. 0C08 really needs a pre-calibrated axis, operating -16384 to +16384.. I'm not sure you can do much with a 0-255 value, unlike 3BC4 which normally operates with 0-127 for PFC devices. Pete

So, you worked it out? Above you can see that when you switched 166,1 on, the indication for 166,0 indicates off. In other words, the switch is a "make before break" switch, which is a big problem. The break is causing the "released" assignment to be sent. I don't know anyway around that unless you write a program (eg a Lua plug-in) to somehow work out how to interpret the signals it sends. Well, as you can certainly see, the command sent to FS was "MAGNETO1_LEFT". Don't ask me how it went to "Right" instead. A bug in the aircraft, in FS? Report it to Microsoft. All FSUIPC can do is send the correct controls. Pete

I don't know the C# part of the SDK. It's a user contribution. I think the "dwResult" is the success or failure of the call. I don't know why you are calling that "globweather". You are trying to read a complete area of 4096 bytes from offset 0xB8000, so reading the 2048 byte METAR string and the first 2048 bytes of the binary NWI tables following. Don't you think you need to sort out what you want to read and read it correctly? The format of FSX SimConnect METARs is sort of like real Metars but much extended. Also the read and write formats are different. You will need to look all this up in the SimConnect documentation in the FSX SDK, available on-line at file:///E:/SDK/sdk%20overview.html As for the ICAO id for reading, please refer to offset CC00-CCFF and the NWI package. The control over all these areas is via NWI. The raw FSX Metars are a bonus. Pete

You don't need anything to trigger a Lua plug-in if it is running in the WideClient folder. WideClient will load it initially. Using event.offset it can await a change to offset 0x66c0 then use the value to set the COM frequency. If you need to send keypresses to a client, the built-in KeySend facilities in WideFS will do it. However, there's no need in this case. Pete

No. sorry. you misunderstand, or I wasn't clear. FSUIPC cannot communicate with FSUIPC on the other PC. You would need WideFS. But I thought the alternative of simply pressing a button on the client on which you want the frequency to change would be the easiest option. You only need to frequency change on that PC, right? Pete

Well something you are running wants to connect to FSUIPC and it is either trying to do so too early (before FSUIPC is ready) or, more likely, you are not running this other program at the same privilege level -- i.e "as administrator". Why are you running FS "as adminitstrator" in any case? It should not be necessary. I've never run it "as administrator", but if you do then ALL programs that need to connect must also be run "as administrator"! Until you identify the actual program which is giving you this message I can't help further. It certainly is not FSX nor FSUIPC. Pete

The most likely reason is that you have a corrupted weather file. Try deleting (or moving out) the .WX file associated with the default flight, i.e. C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\FLIGHTS\OTHER\FLTSIM.WX and also delete the wxstationlist.bin file which you'll finf in the same folder as your FSX.CFG file, i.e. in C:\Users\Jarvis He\AppData\Roaming\Microsoft\FSX When either of these binary files get corrupted, it messes up SimConnect's weather reading facilities and as soon as FSUIPC starts reading the weather it causes a crash. Unfortunately SimConnect doesn't check these files, it just assumes they are okay. Pete

The "FSUIPC for Programmers.pdf" does not contain the definitive offsets list for FSX. You should be referring to the Offsets Status list. That is also in the SDK and would also have been already installed in your FSUIPC Documents folder, inside the FSX Modules folder. The offsets you are trying to use date back to FS98 and are generally not really suitable for use in FS9 or FSX unless you are also dealing with the weather stations or setting global weather mode. I suggest you investigate offsets B000 through to CFFF, which whilst being listed in the Offsets list, are best described in the NWI ("New Weather Interface" package included in the FSUIPC SDK. The program WeatherSet2 uses that interface. Sorry, I can't help with C# as I don't know it at all. Maybe someone else can do that. If you are using Paul Henty's .Net client DLL then you'd be better off asking in his subforum, above. Pete

No, only SimMarket, unless you want the Japanese version. Pete

But what functions did you assign them to? They are different in any case between "direct" and "FS" type control assignments. Pete

There are no "max" and "mins" or "sync pos" in the axis assignments tab. Don't mess with things you don't need or want. just follow the steps to successful calibration. Theyare numbered to make it easy! Those are simply modes of assignment. The actual assignment is below, using the drop down selections. Unless you tell FSUIPC what you actually want the axes to do, it can't do anything with them! Pete

Are throttle changes seen in the Axis Assignments tab? If not then there's something wrong with the throttles or whatever Saitek driver or other software you installed. The values shown in the Assignments tab are those received directly from Windows. If the throttle changes are seen there, then the problem is in your calibration. Follow the numbered steps in the FSUIPC User Guide chapter on Joystick Calibration. All changes made during a visit to the FSUIPC options pages are saved to the FSUIPC4.INI file when you press OK to exit. If you use another method, like pressing Cancel or the Escape key, then those changes are discarded in favour of the settings before you entered the options. Pete

What program says "unable to connect to FSUIPC"? Because there's no such message in FSUIPC or in FS itself. Sounds like you are trying to run some FSUIPC application before FSUIPC is actually loaded. Pete

FSX weather is very difficult to control by such simple means. Offset 0F8C is an old FS98 offset, and when you write to it, FSUIPC tries to convert that, along with the rest of the weather at your position, into a full METAR string and send it to SimConnect. The problem is the weather at your location is determined by the nearest three weather stations. In order to get around this you probably first need to clear all weather. You might get away with it -- for a while. FSX develops weather in any case, unstoppably, so it won't stay even then. More relaibly you can use Global Weather mode. This can be set through special FSUIPC facilities. Try using FSUIPC's weather logging (see the logging tab). And investigate weather setting using the provided programs -- WeatherSet uses an old FS2002 compatible weather method (still later than the FS98 interface youare using) and WeatherSet2 uses the current FS9/FSX weather setting facilities. Pete

I would have expected WidevieW to provide cuch facilities, as it is the program coordinating all the PCs running FS. WideClient as it stands won't rtun on a PC which is running FS. However, there is a work-around. You can set the ClassInstance parameter in its INI file to some non-zero value (eg 1). (In fact you can run several each with a different class instance). Such an installation won't run any FSUIPC applications, unless they've been modified to talk to the renamed window Class, but they will run Lua plug-ins. However, if the PCs concerned are running FSUIPC, you don't need WideClient in any case. Just run the plug-ins in FSUIPC. Write a Lua plug-in for the PC on which you are tuning the radio to react to COM radio frequency changes (event.offset), copy said frequency to a user offset (eg 0x66C0), then on the other, client, PC, a plug-in reacting to changes in the user offset and writing the result to the COM radio frequency offset. Simpler, if it is a fixed frequency needed only, why not simply have a plug-in which writes that specific frequency when it sees a button (maybe a virtual one, set in an offset on another PC) pressed. There's no need to actually send frequencies when the ones you need are fixed. Pete

Or slightly more efficiently: function interceptStabTrim(offset, value) if value ~= 16000 then ipc.writeSW(0x0BC0, value) end end No, sorry. Even FSUIPC doesn't decode that now. It used to, because originally each FSUIPC application had to be registered with a Key. But it became too inefficient, and most program makers were pretty honest and if they were making money paid their dues. Pete

First mistake. The button released action should be programmed to Magneto1 Off. As I told you earlier, the left most position is an "OFF" position -- no button connection at all. Therefore you have to program the change from the next position. Second mistake. No need to boot anything. Since FSUIPC can only see the switches when they change, you always need to synchronise switch and aircraft first. You can do that on the screen using a mouse. All the rest of your results seems like either the EFIS device is not working correctly or you have not programmed it as you thought. Just use FSUIPC's logging to see what controls it sends. Don't forget, FSUIPC is not really doing much here, it simply sends the control you use to FS. You could do exactly the same thing in FS assignments. In fact I don't know why you are using FSUIPC? To check what controls are sent, go to FSUIPC's logging tab and enable Event logging (not the axis events). Also log Buttons too as it'll show the relationships better. That's two checkboxes on the left. Also enable the console log, another checkbox. Don't touch anything else, just exit OK. If you (temporarily) put FS into windowed mode you'll be able to see the actual button decodes and the controls being sent to FS, in real time. That should tell you whether the problems are to do with the device, your programming, or FS itself. Pete

Not without comparing the aircraft's location against a database of runways, such as that produced by my MakeRunways utility. BTW you posted in a subforum which is specifically concerned with support for Paul Henty's .Net client DLL programming. General support questions should be directed to the main support forum, please. Pete

I'm still wondering, though. is it a program which is writing to 0BC0 and you want to change what it is doing? It's always more interesting to know what the problem is for which a proposed solution is available, rather than simply the solution. It leaves one trying to guess the problem! ;-) Pete

That version number refers to the revision of WideClient, which is the same for both WideFS6 and WideFS7. the WideFS.zip package is the same for both -- you simply do not use the WideServer.DLL module for WideFS7. If you downloaded WideFS.zip as you were instructed to, and looked at the documentation, you would understand all this. I am also a senior citizen, being 71 years old next month. And it isn't a question of "technology", just one of reading what it says and consequently simply downloadng the package as it tells you. That's all. ;-) Pete

Yes, the logs simply show all is well. The reason is that FSUIPC is supposed to work! What remains unexplained isn't these results but what was different before. Pete

0BC0 is elevator trim, not elevator. Isn't that being set by an input axis from a joystick? If so you can just assign that to a Lua plug-in which tests for your 16000 and otherwise sends it on using the appropriate FS control (Axis elev trim set most probably).. Pete

Yes, but you've already got them, so why are you going back? In your first message you say you "keep being directed to SimMarket". Who or what "keeps directing you"? Obviously the website which tells you where to purchase them always tells you where to purchase them, but surely you aren't stuck in a loop reading that web site and hence "keep getting directed"? Why not? You bothered to download FSUIPC4.ZIP but not WideFS.zip. If you wanted WideFS why didn't you download it? The files are nothing to do with SimMarket. They are downloadable from here (in the Download Links subforum) or over on www.schiratti.com/dowson, the site you yourself mentioned. That one isn't mine nor SimMaket's, but Enrico Schiratti's. WideClient is a component of WideFS7. The other part, the server, is built into FSUIPC4. The documentation and client programs are in WideFS.zip. Well if you wanted WideFS you should have downloaded it, just like you did for FSUIPC. In fact it is quite normal to download these things and read about them BEFORE going anywhere near Simmarket to purchase them! BTW, I just looked at the Schiratti page and it quite clearly instructs you to download using the WideFS link, the one just below the FSUIPC link. How could you be so confused by this? I don't understand! :sad: Please re-read the part on that website I've highlighted below: Pete

I've moved your post to the Support Forum -- you posted in Paul Henty's subforum where support for his .Net client DLL is provided. Please take care where you post. Best, then you update to FSX, because that's a facility provided in FSUIPC4. Since most FSUIPC requests from programs route through FS's message procedure, the one for class "FS98MAIN", you'd need to hook into that procedure (subclass it) and process the FSUIPC requests before they get to FSUIPC. You'd probably also need to do that with the class "UIPCMAIN" which is specifically added by FSUIPC and used by some programs too, depending what library they used, if any. I've no idea how you'd "wrap" FSUIPC. Which offset is "STABTRIM" and how is it being written? If this is from an assigned axis why not use a Lua plug-in to intercept it? Pete