Pete Dowson

FSUIPC does not change settings. If your assignments got crossed between different joysticks it will be only because the joystick ID assigned by Windows changed. That can happen if you unplug USB cables, or update Windows versions. Best to use FSUIPC's joystick lettering facilities so it can keep track -- there's a chapter about this in the User Guide. I see P3D 2.3 was released whilst I was away. I shall be working on an FSUIPC update tomorrow (Monday 18th). Pete

There's no possible cause I could imagine, and there's certainly no difference in this area between FSUIPC or PFCFSX.DLL whatsoever between FSX and P3D. Maybe there's some bug in P3D, but I'd need more information to help narrow it down. First, though, are you using the PFCFSX.DLL assignments for the quadrant, or FSUIPC? There's a significant difference of course! Generally it is all done in PFCFSX's menus. Pete

More information needed I'm afraid. Key assignments themselves can't crash anything because they do nothing unless you actually press the key. First, make sure your FSUIPC4 is up to date -- see the Download Links subforum above. Then show me an FSUIPC log file for a session which crashed, and also your FSUIPC4.INI file. You can paste both here -- use the <> button above the edit area to enclose the text from the files. Pete

There has never been any change to the way the FSUIPC keys are checked. You must be making an error. All three parts -- name, email and key, must be exactly correct, and as originally used. If you have a new email afddress or now spell your name differently, then you are probably making a mistake by using the newer ones. Reinstalling is never a good idea, and especially for something so trivial and which may well be easy to solve. Please refer to the chapter in the User Guide about assigning letters to joysticks when multiple controls are in use so that FSUIPC can keep track. Pete

Not sure FSUIPC does always help with that -- some folks say it does, others don't seem to have those results. There is a User Guide for FSUIPC which has a whole chapter of Joystick Calibration, and does explain the options on the calibration screen including the button marked "REV" (for "reverse"). I would strongly recommend following the staps to best calibration laid down clewarly for you. If you don't want a reverse zone on the lever itself you need to also select "NRZ" or "no reverse zone" too. Again, exaplined in the user gide. Pete

FSUIPC4 is for FSX and P3D and includes GSPout. The GPSout.dll is only for FS9 and before, used with FSUIPC3. You'd need to purchase an FSUIPC registration. Pete

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