Pete Dowson

Very strange. some sort of timing causing pile-ups, like motorway traffic queues perhaps? Are you using a separate Lua plug-in for each device? If not try it, because it might just be too much going on in one thread. Also, to investigate further, uncomment the part logging the number of discards -- see if there's any correlation between those and the delays. The "readlast" function basically uses a loop (inside FSUIPC, in fast C code of course) to keep reading blocks till there are none left, and supplies the last one. If there's a lot of axis activity the button press which occurred a number of discarded blocks ago could be delayed, but half a second seems a little on the high side. You could also see what happens by using "read" instead of "readlast" -- it would probably work better for button presses, but worse for axes where values are changing far too quickly for a humble interpreter to catch all of them. Windows joystick drivers just store values and supply them on poll calls. You could try revising the code to do something similar. Just have one Lua plug-in storing values every n milliseconds to Globals, and one or more separate Lua threads reading values at a normal poll rate (FS's is 6/sec, FSUIPC's default is more like 20/sec). By having them in separate threads you might avoid a pile up in the one reading and storing values. Regards Pete

Interim version FSUIPC 4.706 from this link: FSUIPC 4.706 works okay with your test Lua program. Perhaps you'd like to download it and give it a bit of a work out before i add the library to FSUIPC3 and WideClient? Thanks & Regards Pete

That's just the first 18 seconds. When was a client started? Log fragments aren't of much use I'm afraid, you need to close FS before getting the log, and i'd certainly also need to see the Client log -- every connection has two ends! ;-) BTW the "Not able to serve" message only normally occurs if your copy is not registered. If there's no connection it simply says "waiting for clients". It only checks registration before starting in the first place, so I've no idea exactly what you are seeing, and it isn't being logged, but I assume those details were in the previous log before you disabled and re-enabled it (why do that?). The FSUIPC log would show registration validity. Pete

Sorry, what do you mean? The PFC driver provides a menu for you in FS. select it, find the calibration page with the throttles on and disable them by unchecking them. don't you have the PFC DLL user guide? Pete

That's because LevelD 's autothrottle is not implemented using the FS A/T. The only way around that would be to disable the throttle in the PFC driver and assign in FSUIPC instead, to the normal FS axis controls. The yoke button should work if "Z" works on the keyboard, because basically that's all it does. However, you can reassign it in FSUIPC to suit specific aircraft if you wish. Regards Pete

Okay, thanks. I'll do one then the other. I'll need to add the other functions too. Pete

Do you mean this, for button 4? Why are you using FS-assigned keypresses like 'G' instead of the FS controls they are assigned to in FS? Seems a very inefficient way of doing things, having two assignments, two lookups, just for a simple action? I assume you mean landing lights? FS doesn't implement separate controls for inboard and outboard lights. The easiest way is simply to add another line to switch the landing lights on and off with the same button: 10=P0,4,C65751,0 That'll toggle the lights at the same time as you toggle the gear. You just need to make sure they are both off or both on when you start. Well of course you can You've not read much of the documentation, or the examples in Appendices and so on? With "ShortAircraftNameOk" set to "substring" you can use any part of the full name to identify it. Or, much better usually, you can use the aircraft Profiles facility instead. Having identical sections for the same aircraft with different liveries makes no sense, it just makes the INI file much bigger for no reason! Pete

Certainly this week, by next weekend. I'll release a test version here before Saturday I hope. I've caught up okay with my backlog from holiday but at present I'm busy with a cockpit engineer from the U.S. who is helping me upgrade my 737NG setup. Yes. If you can hold off till the end of the week ... or alternatively release without the library but with a download link for it with a note ... then it should be fine. It would be quicker if you could help test it for me when I've first done it, so which is best for you first: FSUIPC3, FSUIPC3 or WideClient? Or perhaps you have a Lua test script using the LFS functions, which I could use? Regards Pete

Yes, i think so. It seems the WideFS registration wasn't Registered due to Windows security issues. Regards Pete

No. The FS time is not the system time unless you load a flight in the mode set for "Use system time", which you did, and that results in this line just below in the Log you showed: 107375 System time = 04/06/2011 08:50:07, FS2004 time = 08:48:29 (15:48Z) The log shows it took just over 100 seconds to load the flight.6926 mSecs to 107375 mSecs) which seems to account for the difference. The KEY file is fine and it works ok here with FSUIPC version 3.995 (the latest update). Could you download that (from the Download Links subforum) and see if that helps? I suspect that when you registered WideFS you didn't run the Installer "as administrator", which seems to be necessary after some recent Windows security changes which can prevent Registry changes. I amended FSUIPC to take a more lenient view if the Registry isn't updated correctly. Regards Pete

Ah yes, thanks. So obvious there I never noticed! Of course I wouldn't really have looked for it in this Forum as I watch all topics! ;-) Regards Pete

Not much, really. With Win7 the top rating is 7.9 -- I get that with a SATA 3 ("6 Gb/s") solid state drive, but nothing less. As I said, all AutoSave can do is call on FS to save the flight. It doesn't do that itself. It's just an automated way of pressing the ; key and entering a name. Of course if you have a cycle of 10 (say) files being saved, it also has to erase the oldest each time it saves a new one. Maybe that's defeating the caching, though I've never noticed the sort of hesitation you mention (1-3 secs!!!). You could try disabling the regular cycle and use the "alsosave" facility only. Here's the relevant part of the doc: Maybe, because it doesn't then have to erase older files it will work better for you. The disadvantage is that you don't get a series of saves to select from. Regards Pete

Sorry, but I cannot support "vafs" as I know nothing about it. Do they have a support facility? BTW, please do not say "latest one" when talking about my software versions. I need the version number, and "latest one" only means the one you last saw somewhere for download. It doesn't even tell me if it's for FS9 (FSUIPC3) or FSX (FSUIPC4). Regards Pete

Sorry, but TrafficLook can only display data it can get from FS. Gate information is not available. Those programs which know about gates either deduce them from the Latitude/Longitude information by doing an analysis of the airport scenery data files, or possibly (for landing aircraft) hack into the ATC part of FS in some way. TrafficLook is merely a demonstration of the data supplied by FSUIPC from the FS Traffic Info data. Regards Pete

I don't know of any way that a registration can work then not work, unless the file containing the Regisytration details gets changed or corrupted, or the computer system date is changed to one BEFORE the purchase date. I didn't think they came by email these days. Most SimMarket purchases merely put the registration keys in your account for you to retrieve. It certainly sounds like it might be a date problem then. Check the computer system date. I've had occasional odd things happen when a purchase is made from the USA when it is just after midnight in Germany (where the keys are generated) so the date was one day later. If that were the case the keys should work okay by now. Check the account in SimMarket where the data is stored for you. You can have multiple keys with the same name and email, though it is unusual and I don't know if SimMarket is set up to do it. If you send me an email (petedowson@btconnect.com) and attach the FSUIPC.KEY and FSUIPC.LOG files, from the FS Modules folder, I'll check for you. Regards Pete

Wow! 1-3 seconds!? you must have a seriously badly performing disk system! Normal small file writes are cached and hardly ever affect foreground activity. Maybe you need to free up more space on disk? Maybe you need to check disk write settings -- turning off disk caching in order to avoid data loss on a system crash would make it force-write files immediately, which wouldn't be good with a slow or congested disk system. All Autosave is doing is calling the function in Flight Sim which saves a flight, at the interval you ask. There's no other way I know to save a flight. Maybe if you purchased on of those utilities which creates a disk in memory, and moved your "My Documents" folder there it would work, but there's no real way of saving flights other than by ... saving flights, which for FS means writing files. If I were you I'd look at defragmenting your disk, the one holding your flight files, and freeing up space. And check that you have write caching allowed. Not sure where that's specified offhand. Regards Pete

Er .. you said "I have my landing gear set to my button 2", but you don't seem to have that listed here? Is it assigned in FS, not FSUIPC? FS provides separate "AUTOPILOT OFF" and "AUTOPILOT ON" controls, so you should be okay. You'd need to find out what does it for each individual add-on aircraft. FSUIPC can only present what it knows from FS itself. Those add-ons which do their own thing should be providing keyboard shortcuts or controls to operate them. Sometimes it can be done with mouse macros (PMDG typically), sometimes with local gauge variables (L:Vars), sometimes with assigned keystrokes. Check the "User Contributions" subforum. You might find useful hints there. Regards Pete

There might be a way of "subscribing" to threads here, but I don't know (I've not looked, sorry). I don't think any Forums automatically send emails -- with most, unless it is automatic, no one even knows your email address in any case. Regards Pete

FS provides Flap1,2,3,incr,decr,up,down and set controls. These are sufficient. For example a 737 has 9 flaps positions yet cockpits are built which can successfully select any one of them. There's no other way FSUIPC can select flap positions than those methods actually provided by FS. If you don't want to use inc and dec methods, use Flaps Set. You can either have an axis with calibrated detentes, or simply assign Flaps Set to 6 buttons, each with a different parameter which selects the appropriate position (0 - 16384 divided equally). Pete

As Ian points out, this is most likely due to an error on inputting the data. All three fields must be exactly as when you first got the Key. Use cut and paste to avoid errors. There's most certainly no difference between the process between XP and Win7, although you might need to run the Installer by right-clicking and selecting "Run as ... administrator", depending on your version of Windows 7 and its security settings. But even if that was affecting things it wouldn't cause rejection of the inputs. Regards Pete

Thanks for the info. There's one other thought I had -- it may be that the calibrated values were only done for the 4 individual throttles -- I suspect this is what would be used by 99.9% of those needing this facility. So, you could try assigning to Throttle 1 instead of just "throttle" and mapping to the others using the facilities there. Or assigning to throttle as now but mapping to all 4. To get the same non-reverse option you'd need to set the "NRZ" option too. Let me know please. Regards Pete

Are you setting the bit in 310A? Which version of FSUIPC? I'm a bit confused by this, as the intention for those offsets was for use by "Fly-by-Wire" software applications to read the disconnected calibrated value and either pass them directly to the main throttle offsets and manipulate them (fly-by-wire-like) and then do so. They've been used like that for years. But I suspect you have to use the disconnection feature for them to work like that. I still need information from you, as I asked, before I can check. There's no rush -- I can't do any programming or debugging for a few days (re-building at present). Maybe next Wednesday or later. Regards Pete

Correct. Sorry, I see I rather misread you as wanting the throttle value -- the one in use by the A/T. If you want the FSUIPC calibrated throttle axis input you use the values at 332E etc. Hmm. I'm pretty sure the documentation is correct. FSUIPC will be calibrating whatever range your axis gives to the proper FSUIPC value -16k to +16k, as you are seeing. Er, that seems to contradict what you just said about the offset ranging from -16k to +16k? It'll never be 0-1. If it's a -16k to +16k range you'd need to add 16k and divide by 32k. If you want me to check anything further for you you'll need to give some more information, like: 1. Version of FS, version of FSUIPC 2. How are you assigning the axis 3. Whether you are setting the 310A bit to prevent the axis being sent to FS and interfering with the A/T. That last is important. I've a feeling the operation is different depending on that setting -- those offsets never used to be updated at all unless the axis was disconnected. Regards Pete

There's a working version in the Download Links subforum here. Pete

That's very odd because radio operation is pretty much standard across all aircraft, add-ons as well as default. I can't imagine what Justflight have done to mess that up. Yes, and there's really nothing easy for the radios because they always work, as I say. i think you need to seek help in the JustFlight forum, because the radios should be completely standard. You might also check in the VRInsight forum where others may have already solved the problem. Regards Pete