Pete Dowson

You made a mistake, then. The notice on that purchase page couldn't be clearer! What link? Do you mean on Schiratti's page? If so, the one for FSUIPC4 and FSX takes you to the FSUIPC4 purchase page. The one below that, for FSUIPC3 and FS2004 takes you to the page you went to. It always has and it still does -- I just tried it. Sorry, I can't do anything, I'm not involved in sales, only support and development. You could try asking SimMarket, perhaps via a problem ticket on your account, but considering their clear statement on the purchase page I don't think you have it guaranteed. Pete

Because you've purchased FSUIPC3, which is for FS9 and before. You need to purchase FSUIPC4 for FSX and P3D. This is very clear on the purchase pages, where,,oneageyou must have used, this is stated in big bold RED lettering! THIS IS THE FS2004 VERSION ONLY -> THE FSX VERSION IS AVAILABLE SEPARATELYHERE. (There will be no refunds, no exchanges!) Pete

NEVER post such things in any case. I would result in a revocation of your registration. I'm off on holiday tomorrow for two weeks and if I hadn't caught it it would be exposed to all and sundry for that long! Did you cut and paste? The first O looks suspiciously like you entered a 0 instead. Also make sure that your computer date is set correctly AND that you are using the currently supported version of FSUIPC (4.934). The whole process is done automatically and there's never been a case of an incorrect registration, only incorrect entries or versions or dates. If you need these things checking just state the order number and email address. Nothing else needed. Don't post any other details! Pete

Yes, press each in turn and assign the action you want in FSUIPC. The button screen merely oerates FSUIPC's "virtual button" set, 288 buttons from joystick #64 to #72 (9 x 32 buttons). The definitions in the WideClient INI file just provide the labels, colours etc. Pete

It isn't really a good idea to have any of the main flight controls on a client Pc because of the added delays. Certainly no software of mine supports such an arrangement, unless you program it using a WideClient Lua plug-in. Also, i doubt whether Saitek's software will run properly over a netwrk, though if they use SimConnect properly, and nothing else, they may do. No, sorry. Saitek panels may work over WideFS using a program called SPAD, but i'm afraid I can't advise about that as I know nothing about it. I don't think any of those things impose any significant extra load on your FSX PC in any case. I really think you are looking at the wrong things to offload from that PC. Pete

It is sounding more like a problem with the 777 then. did you try asking over in the PMDG forum? The log shows nothing wrong except for the inordinate delay here: FSUIPC never actually gets to run properly. Shortly after the above sequence there should be a line "starting everything now". If that never occurs then FSUIPC isn't getting any processor time to even start correctly. What precedes this is all fairly trivial, just registering its interest in each of the SimConnect values it needs. Note that I have seen it stated many times that you should never have FSX starting with a complex aircraft. Always let it start with a simple default aircraft then select yours from the menu. In my case, what i do is let FS go to its initial selection menu. By that time FSUIPC has started and the default flight pre-initialised. then I select the flight i actually want. This always works fine. One other thing you can try is setting a delay for FSUIPC initialisation. This parameter controls that: InitDelay=0 You could try setting that to, say, 120 (seconds, i.e. 2 minutes), and then reduce it if things are better. Pete

First off I cannot support old versions. The earliest supported version at present is 4.934. Why do you think it is FSUIPC which is "causing" these freezes or delays? Where are the logs or other evidence to show this? I've no other reports of such a problem, and have no information to go on. It sounds very much like a SimConnect corruption issue. At minimum I would need to see an FSUIPC4.LOG for such a problem. But with a current version of FSUIPC, not an old one. Pete

Found it. It wasn't about corrupted weather data after all! It looks like you are using an out of date version of Active Sky Next -- FSUIPC is tripping up on a response from its module "as_btstrp.dll". Could you check, please? I'll add some protection for FSUIPC in this area, in the next version. Pete

I haven't checked the code line-by-line in detail, it just looks like a straight conversion for my originals. I'm a bit busy at present -- we off on holiday for two weeks from 0600 on Saturday and I have preparation to do, so the amount of time I can spend is limited I'm afraid. Sorry. Strings are easier for you to see, when logged for instance, and so interpret. Obviously binary data would be more compact but with such a small amount of data so infrequently it is probably best to make it simple for you to recognise. Decoding should work okay with those functions used, but first log what is received to make sure that part is okay. Pete

One thing I notice is that the receiver is logging several connections and disconnections, whilst the sender simply logs the connection the once, because the code that does that is only ever executed once. Maybe things are different when only doing periodic transmissions -- the programs you derived this from were constantly sending data, many times per second. Not sure why the disconnect/reconnects are occurring. Maybe there's some timeout. Is anything received? Maybe it times out / disconnects first? Why not add some logging into the receiver, for instance log the string you receive? I really cannot diagnose things remotely. You could also try using the Lua trace option on the Logging page -- but note you need to enable then BEFORE the plug-in is started. Pete

Sorry, I cannot solve PMDG problems. I cannot even read the text in the thumbnail picture you posted. You'll need to actually tell me what it says, if you think it is anything to do with FSUIPC. Why are you posting to this forum anyway? BTW you say you've uninstalled all PMDG add-ons, yet you have all of their DLLs still listed and enabled in your DLL.XML file! Pete

The value of that parameter simply changes how often the weather is being read. A value of 0 stops FSUIPC reading or writing weather altogether. A non-zero value sets the interval at which it is read in half seconds, so the default of 2 is every second. Setting it to 1 makes it read twice as often, which should make it crash faster! I'll check the data you appended. Thanks. Pete

Okay. That information most definitely points to the weather requests, and the only time I've seen this is when there is a corruption somewhere in the weather files. To verify this you can prevent FSUIPC asking for weather completely by setting the "WeatherReadFactor" to 0 in the [General] section of the FSUIPC4.INI. Try that. BTW, was that data when using 4.934 or 4.934a? Do you think you could try again with this version (it's my latest unreleased build), before you change the WeatherReadFactor, please: FSUIPC4935b.zip If it still crashes, please show me that data again. It should allow me to pinpoint exactly what is wrong with the data. Maybe I can then protect FSUIPC against bad weather data. Regards Pete

Conditional button actions can be programmed by editing the FSUIPC4.INI file. There are examples in the Advanced User's guide for FSUIPC. Pete

They don't matter. The local prefix just makes the code more efficient -- it saves the exporting of function names not referenced outside. Only the functions referred to in event functions cannot be local. One observation, and this may well cause the error reported: host = "<SILVERZERO>"; Does your server name really have <> parentheses around it? If not take them off! The symbology "<servername>" simply denotes a place for the server name. The <x> parts are always to show this is a parameter you need to set. this is consistent throughout all my documentation (and many others, I should add). Pete

You didn't need to remove all the "local" prefices, only the one on the single function called by your events! You didn't look through the logs and see this on the Client? 272643 *** LUA Error: ...icrosoft Flight Simulator X\Modules\SlaveServer1.lua:36: Valid name, no data record of requested type Look at your "SlaveServer" line 36. Sorry, I can't count lines reliably in these messages. I normally use an editor which gives line numbers. Pete

how are you identifying FSUIPC as the cause? To get crash information, go to the Windows event viewer and find the crash report. It will give details -- I would need the Module name, the error code and the module offset, as a minimum. But before doing anything more, you need to update to the currently supported version of FSUIPC. You say it's a totally new installation of FSX, yet you are using FSUIPC version 4.929c which dates right back to March! The current version is 4.934 or later. (4.934a is available in the Download Links subforum). Pete

Best way to check is to try them. But first, remove the "local" prefix off the functions which are called by the event library -- the have to be non-local so the call can hook up from the event. Pete

Yes, ipc.display operates on the FS PC. Ah. Of course. You are right. There's no way the WideClient can affect the client offsets. Sorry. It was me being stupid. My only excuse was that I was very busy here with visitors and had a lot on my mind too. Actually, I can't think of any way to do what you need via WideFS without writing the frequency to a file in the Client Lua and have an FSUIPC-based Lua plug-in reading that file. You might be better off using a network connection directly between two Lua plug-ins both running in the respective FSUIPC's -- in other words not using WideFS at all. There's an example of such communication provided in the Lua plug-ins package in your FSUIPC documents folder. Look at "MasterClient" and "SlaveServer". These are designed to make one PC running FS act as a slave, sim-wise, to the other, so they are doing much much more than you need. Just strip everything out and transmit only the COM frequency. No need for 66C0. Note that those examples were written before the event library had been extended enough to make it all event driven. You can replace the infinite loop at the transmitting end with the event of COM1 frequency changing, and have the receiving end operating on an event.timer, not 5 mSecs as the current loop of course, but maybe 500. Sorry for wasting your time leading you down a dead-end! Senior moment. Pete

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