Pete Dowson

Sorry, I cannot offer any way. 61 certainly seemed many many more than anyone would need. Regards Pete

The event.timer function, as added in a recent version. Please check the Download Links subforum. I think you must be referring to out of date documentation for the FSUIPC Lua libraries. I tried your own Lua programs and even shortened the "sleep" down to 10 mSecs, and it took me 15 minutes of almost constant throttle movement before I could get even one crash, which I am pretty sure was some sort of Lua memory management problem, where it had run out of memory and was tidying up. I'm afraid the core Lua code is not mine and I cannot fix that. The problem is arising anyway because of the wrong use of the global "set" and "get" functions. The inter-thread operations are not at all suited to hight intensity use. You offer no information for me to assist in diagnosing your "FSUIPC.DLL crashes" in any case, so I really don't know what you expect me to do. Sorry. Well, i don't know much about filters, but yours seems less capable, according to my testing, than the built-in Fliter facilities in FSUIPC's calibration pages. Why did you not use those? Regards Pete

How are you activating reverse thrust -- separate reverser axes, a reverse zone on your throttles, or by buttons or keypresses? It makes a lot of difference. How are you assigning the throttles? Also, please test first on a default aircraft. I can't help with a specific add-on aircraft as I don't use them. If it works with a default and not with an add-on you probably need to talk to the add-on support folks instead. Finally, if you are using FSUIPC (you don't actually say), i always need to know the actual version number. If it is earlier than 3.98 then please update first. Regards Pete

Okay, I can see what is happening. The range for including ground traffic in the tables is 3nm. When an airborne AI lands it should be moved to the ground table, but not if that position is more than 3nm away. Bypassing the entry into the other table also bypasses removal from the airborne table until it times out. I'll fix it in the next incremental update. Regards Pete

The COM port number will normally be different on every PC and every connection. It;s an arbitrary assignment by Windows or sometimes the BIOS on your PC. some USB/Serial drivers allow you to configure it in their 'Properties' dialogue. GPSout will certainly not be able to access the port if it is owned by the sync program. If you cannot turn it off you'd have to terminate it, ruthlessly if necessary (i.e. via the Task Manager process list). Regards Pete

The GUIDs are only used to distinguish between two or more devices with exactly the same names. And the whole JoyName section is only relevant if you are using letters to identify joysticks, instead of the Windows-assigned ID numbers. This is because Windows assigns those IDs arbitrarily and they can change is you reinstall windows, or unplug and replug USB devices, or move PCs. The Joy Letters facility in FSUIPC allows it to keep track of the IDs as they change. I'm not sure why FSUIPC can't find the GUIDs on your PC though. That's a bit strange. They should be easily found in the Registry. I'll do some more checking here. [LATER] Okay. I found some odd Registry differences when using FS9 in different compatibility modes. I've changed FSUIPC3 so it can find the GUIDs now in any of two or three places. It' should be okay on the next Interim Update (3.989v). Regards Pete

Really? Even though you are writing them both at the same time? Yes. Your thread will get no time at all until the sleep period expires. It would be daft to put your thread to sleep for 8 seconds -- how will it update the throttle values? For everything, yes, as I keep advising. All three of your activitiies can be in one Lua driven by a couple of timer events -- one at 50 mSecs for the two throttles and the other at 8 secs for 310A. regards Pete

There is no WideServer.INI file for FSX. WideServer is part of FSUIPC4. Do NOT put any WideServer files into the FSX Modules folder! You do not need a WideClient.INI on the Client, only WideClient.EXE, which you run. It will make its own INI file in any case. Note that Vista/Win7 and WinXP use different default "workgroup" names. You should make them match. I always change the name to "Petes" on all my PCs in any case. Provided both PCs are in the same workgroup they should link up fine, given either no firewalls or exceptions made for Wideclient and FSX.EXE. Regards Pete

Hmm. Curiouser and curiouser. That certainly doesn't sound like SimConnect not sending the updates. I'm going to have to try to reproduce it here so I can see what is going on. I saw that, but it was quoting 4 minutes or something silly like that for a download. There was no point at the time, anyway. Okay. in that case I should be able to here, too. Can you EMAIL me a FLT+WX pair of files to put my aircraft at a position where it can be seen to occur? Are you using default AI or an add-on, BTW? You said "it seems to happen only when I am on the ground over 3nm away". If this is indeed the case then it might explain why no one else has seen it or reported it, including me. Being on the ground at a distance from another airport does seem to be an unusual place to worry about traffic clouds at that airport, as presumably you aren't about to take such a sohrt hop over to it .... or are you? I'll try reproducing it here. Regards Pete

1. i'd like to know more about that. I don't see anything there which should crash the sim, though the furious use of Globals (which are stored in a separate Lua thread) is, to put in mildly, very unusual and may be exposing a weakness somewhere in the Lua memory management. 2. Since they both run 'forever', why are you using ipc.set and ipc.get to store global copies anyway? There's no need at all. You could just use variables local to that Lua plug-in. It seems to add unnecessary complexity, and will slow it down somewhat. 3. Why two separate plug-ins? Even without tables or stacks you could put all that into one loop, or probably one loop and one local function, called twice each loop, once for each throttle. 4. Reading and writing offset 310A 40 times a second (20 times each, twice) seems a bit over the top when it only needs refreshing once every few seconds. An ideal candidate for a separate time-event called function. Really? No calibration? So changing thingfs in the calibration tab in FSUIPC makes no difference to the values? Ouch! Can you shown me your FSUIPC INI file please? The values stored should most certainly be post-calibration. There are quite a few applications which depend on that. Maybe you have the NRZ option selected? Folks with Saitek quadrants seem to use that a lot. Maybe that gets you a forward thrust value going from -ve min to +ive max rather than 0 to +ve max ... if so I'll need to fix that. The NRZ option was added much later and this may be an oversight. However, they should still be calibrated, just to the -16k to +16k range used by FS Axis Throttle Set controls for forward thrust, not the 0 - 16k use by the older ThrottleN Set controls for forward thrust. How did you arrive at (nextV / 2) + 8192? That sounds like the input values you see are -16k to +16k, not 0 to 16k, right? What makes them look uncalibrated? Regards Pete

Hmm. Strange. do you have the Traffic Explorer installed, the one which comes with the FSX SDK? If so you could check on the aircraft there, just as a crosscheck. There must be something holding up the updates which SimConnect send on changes in AI. Do ALL the AI appear to freeze in the tables? I can't really understand what could be happening if all the information arrives except for a selected group of AI arircraft hovering in "a cloud of AI Traffic at the arrival end of the runway " (to quote your report). sounds okay. Those links take me to a place which wants money for a reasonable download speed. Would you mind, instead, please sending them to me at petedowson@btconnect.com. but not yet. The FSUIPC log should be short enough to simply paste here, into your messages. Let me see that first. Ah, so they only "freeze" when they get to a certain position, or near? In the order they get there? Can you reproduce this at different airports, or does it only happen there? It really is now not sounding so much like a SimConnect info hold-up but more of a genuine AI traffic hold up. You would need the Traffic Explorer installed to check in a different way from SimConnect -- Traffic Explorer doesn't use SimConnect. Are the apparently frozen aircraft appearing in the Ground table before disappearing from the airborne table? You said " I tried AISmooth and AISeparation". Are they, or any other traffic manipulation programs, running when you get this? Regards Pete

That when you thought you changed the assignment, you didn't in fact do so because it was not confirmed. Because there is absolutely no way that FSUIPC will suddenly decide to remove one assignment and substitute another -- not even a random one, but one still associated with the ailerons and, very coincidentally, the one you had assigned before! There are no mechanisms ANYWHERE in FSUIPC for doing such things except on a change of aircraft (when you have aircraft or profile specific assignments), or via the options dialogues. Regards Pete

If you only elect to register WideFS then the Installer assumes you do not want FSUIPC4 registration. If you want both, check the "both" option. The installer is actually re-creating the KEY file for you, so it needs all the details. Regards Pete

The default is 50 times a second, which is a *lot* faster than the FS default. It is controlled by the PollInterval value in the main [buttons] section of the INI file. You could speed it up, but if it's too fast I doubt that the Lua could execute fast enough to catch every value received. Are you sure that what you observe isn't a result of the 'delta' value which prevents values which are only slightly different being supplied? You also need to make the Lua program as compact as possible -- each statement is executed with a thread yield between, so the fewer executed the faster it executes as it yields less to other threads. Of course that means other threads (like FS) get less time ... When you assign an Axis directly to a Lua program execution the Lua program gets the axis value in ipcPARAM. However, that's not really what you want in this case as you should be using events. I could look at providing an assignable control to set ipcPARAM to a given value (the axis in this case) for a specified Lua plugin, a bit like the LuaSet for Lua flags (LuaValue", perhaps). You could try assigning to the normal axes as usual, but then disconnecting them from FS via offset 310A. you can then read the post-calibration values which WOULD have been sent to FS in offsets 3328 ff., and write the resluts of your computations to the relevant FS-actioning offsets. this is how fly-by-wire can be done, which is a similar control-manipulation process. Regards Pete

No. The event only executes when you exit. The timer just sets a flag. So, no matter how many timer events occur, you only get entered once if they all pile up because you take a while executing. Regards Pete

I was thinking more of an even like on the offset you are changing or possibly a timer event so you can sample as you do now. Ah, you've perhaps read more than me. I've read most of the Lua manual once, but forgot most of it too! ;-0 No, it only works with strings and numbers. Sorry. Maybe another reason to use events? You can do the same as what you've got but with a 50 mSec timer even instead of a 50msec sleep in a loop. Then keep all of your variables in-thread. Regards Pete

Have you considered making it event driven rather than running a never ending loop? It would also then not need to use global variables as the plug-in would be always there and running on demand. Why a stack? Tables are very easy in Lua. You could use a table in stack fashion of course. It's scanning axes the same way no matter what you assign them to. If an axis is assigned to send a control to FS, it sends the control to FS. If it is assigned to update an offset, it updates an offset. Whether any of that is done in the main thread or an axis scanning thread isn't really relevant to anything. Regards Pete

No, only one "ipcready.lua" is read. What you do is have the ipcReady.lua program simply contain lines like this: ipc.runlua("name of first lua") ipc.runlua("name of second lua") ... and so on. Then you save the Lua files uner whatever names you wish and simply add another "ipc.runlua" line to the ipcReady file. The name can include a path, so you cvould also keep all those Lua files somewhere else, e.g. C:\MyLuas: ipc.runlua("c:\MyLuas\speciallua1.lua") Regards Pete

Because the "end" is a syntax error, as you will see reported in the FSUIPC log file. The file is rejected. Pete

No. And it isn't possible because AutoSave doesn't save anything, it merely calls the same routine in FS which you could do manually using the ";" key. If you don't want the .WX files just delete them. Regards Pete

Removed them from the FSX outside view too, or do you mean they remain listed in FSUIPC's tables even after disappearing in FSX? And these aircraft are, or are not, shown by FSX? Sorry, I'm not clear whether you are talking about a problem of FSUIPC not receiving update information from SimConnect or about FSX itself not removing AI aircraft when it should. I did some testing and have found the following: FSUIPC can only update the tables when SimConnect advises it of changes. So it sounds as if either SimConnect is stalling or is simply too busy to bother providing the information. What sort of frame rates are you getting? does the FSUIPC4 log file show any SimConnect problems, like re-connections? SimConnect doesn't exist in FS9, and FSUIPC has direct hooks into all of FS9's important bits. ;-) I've not seen this phenomenon before, but it smacks of slow or missing updates from SimConnect. We could get more information with a SimConnect log, but it would be absolutely huge unless you can generate the condition within a very short time after loading FSX. Regards Pete

Sounds like a bug in FSX, though I think there's a limit in any case on zooming out. Are you sure 0.3 is not the limit? No, but I would never advise using key presses in any case. Why not use the FS controls instead? There are several: Zoom in Zoom in file Zoom out Zoom out fine Zoom plus Zoom minus Zoom 1x Pete

It's caused by a bug in SimConnect's trust checking methods. Have you updated your FSX with the SP1 and SP2 (or Acceleration) updates? The bug is less severe in the later ones. You could also try using the latest FSUIPC4 incremental update, 4.651, from the Download Links subforum. If none of these things help I would need to see your FSUIPC4 install log, from the FSX Modules folder. Regards Pete

Why are you assigning in FSUIPC and how are you assigning them? You supplied a long log which unfortunately tells me nothing because you don't say what it is supposed to represent. More important is your FSUIPC4.INI file which would show me what you've done. It sounds a bit like you've not really calibrated anything. Why are you pressing "Rescan" and where are you seeing Throttle2 then Flaps? For the same axis or different axes? If different axes it will because you are moving the ones assigned to "Throttle2" and "Flaps" respectively, or they are jittering. But I can't tell because you don't describe what you actually see. If for the same axis on the same display it will be because you have assigned both to the same axis -- as you see, you can assign up to 4 things to each axis. If you have no good reason to assign in FSUIPC, like wanting to switch controls completely for different aircraft types, I would suggest you try FSX assignment instead, or at least first. Get things working correctly the normal way before venturing into more advanced areas. Regards Pete

No, but it might be that you are looking in the wrong folder, in the Aliassed copy of the FS9 folders. Try running Windows Explorer by right-clicking and selecting "Run as administrator" and then looking at the file. Pete