Pete Dowson

Hm, interesting I didn't now there were supposed to be delays! Most times you see it on gauges it is because of poor coding! 😉 I'm surely you could handle that quite easily in your interface to your gauge. I suspect the gauge would have to use the exact same Gauge SDK functions which FSUIPC does, so I'm not sure how much advantage that would confer. But, yes, except for XML gauges (which aren't strictly programs as such), you can access FSUIPC offsets from a C/C++ DLL or Gauge (which is only a DLL in any case). you have to use the Module Users interface, for which there's a separate little package in the SDK. I use C or C++. C# is a "managed" language, which imposes an overhead. C is about as efficient as you can get without resorting to machine code. I'm on holiday now for a few weeks. John may be able to help with any further questions. Pete

Nor are we. but perhaps John can populate the offsets from that variable and you can then check. I'll have to leave it to him. Pete

FSUIPC will be rescanning controllers on entry/exit to options. You really need to work out what changed, because you said is was okay. Since neither FSUIPC nor P3D will change by themselves, something else changed. Pete

That's with RC, AIseparation, so I'm not surprised. It will only be trying to use the facilities to handle aI in certain curcumstances. We are concentration on trying to reproduce it with AIseparation, which at a busy airport should be doing this stuff much more frequently. We need to be able to get it happen reproducibly. Pete

Sounds like you had some sort of system change then. FSUIPC has nothing to do with TrackIR. Nothing amiss in the files you attached. The odd values seen from your devices in P3D either indicate a conflict (P3D and FSUIPC both reading the devices), or a dogy USB connection or Hub. (In fact, could the Track IR problem be USB connection related too? Pete

First, why are you re-reregistering? Running the installer will merely replace your previous version with a new one, it won't touch your registration details nor settings. Second, there is absolutely no change in the Installer except that it contains the updated module and documentation. So the processing of your data is identical in every way. You must be making an error -- all three fields, Name, Email and Key must be exactly right. Pete

Okay, I see I have to tell AIsmooth to retrieve data for it to do anything. Both John and I have been running in with 5.151b and so far there's no crashes. Maybe we just don't have enough aircraft? I'm at EGCC with around 300, john also at EGLL but with 380. AIseparation seems to be trying to do things but still no crashes, Oddly, monitoring AIseparation's efforts in the relevant offsets, it appears to set a selected aircraft into SLEW mode with SLEW on, then it sends a SLEW AHEAD MINUS (to move it backwards) followed by a SLEW off. BUT it then continues to adjust that same aircraft with more SLEW AHEAD MINUS and SLEW OFF pairs, with no further SLEW ON for that aircraft. So it really isn't doing what it sets out to do -- just one brief adjustment is made. Anyway, we are still concerned as to why it crashes your P3D4 but neither of ours. Could you tell us how many AI you have at the time? It might be useful also for you to monitor the relevant offsets so please do this as follows: FSUIPC Logging Tab Right hand side, enter offset 2900 type U32, 'hex' selected, and 2904 type U32 not hex. Check 'normal log' below. When the crash occurs please sned the FSUIPC5.LOG file. Also the AISmooth settings please (is there an INI file?). Pete

Further to the above, I've installed AIseparation and I am running it connected to FSUIPC5.151 on P3D4.5 under win7. I am at EGCC with over 300 AI about -- about 1/3rd in the air. How do I encourage AISmooth to actually do something? I have left it with "airborne" selected, because I can't make sense of the Ground" option -- how does it separate Ground AI using the parameters -- obvious distances of 7nm or up don't make sense. So far it hasn't done anything at all with AI, nor logged any 'conflicts'. Pete

Hmm. Curiouser and curiouser ... I can't imagine which of the relatively small changes since 5.150 could make any such difference. I would like to assist John with this, but I have precious little time now before going on holiday. As for reproducing it, it may be better (quicker) for John to use FSAIS (AIseparation) instead of RC4, as the latter needs rather more setting up and learning. Is this the right download? Category: Flight Simulator 2004 - Utilities Flight Simulator AI Separation File Description: Flight Simulator A.I. traffic separation. With this tool you will be able to separate the traffic inbound to an airport defining a set of paremeters like minimun separation, desired separation, reduced separation zone, reducing the annoying go arounds that the AI engine of FS2004 can cause. Filename: fsaisv1.1.zip License: Freeware, limited distribution Added: 17th March 2005, 13:41:42 Downloads: 31540 Author: Armando Di Francesco Size: 497kb I'll try it here if I get time over the next two days. Pete

I think John needs more information about exactly what viewpoint it is. I think he asked me about this because there are several alternatives available in the SimConnect interface. What did that offset use to be in the 'old days' when is was an original FS value (FS9 days or before?). Pete

TrafficLook itself has no facility to run in the background. It is probably just off-screen. Just delete the two window size and position parameters in its INI file, which is in the same place as the program. Look in the [Window] section. It will revert to a default position and you can then move and resize it as you wish again. Pete

If writing your interface in C# as in your first message here is too slow, then, no, not via L:Vars. However, surely most of the faster changing values you need for instruments are just standard native FS values, which are supplied at the frame rate or better via offsets already. Heading, speed, altitude, and so on. What are you looking for not already supplied with well supported offsets? The only things for which you need to find alternatives are those few subsystems which are specifically added or implemented in the add-on model and not part of the underlying simulation engine, and of course those controls (switches etc) associated with them. Surely for a C172 there's not many (if any) of either. I have a cockpit originally made by Aerosoft Australia which is for a Piper Arrow III. It has all analogue gauges and I wrote a driver for it which only uses normal FSUIPC offsets and it works beautifully. I've gone through several aircraft models from add-ons over the years -- I think my current one is from Carenado, but it may not be (I'm afraid I've been too busy on my 737NG cockpit recently to have flown VFR for a while). As far other possible aircraft models, sorry, I don't know. I think Carenado and Alabeo do C172 models, but I don't know if they are any more suited to cockpit instrumentation other than via the normal sim values and related offsets. Best to ask on somewhere like the AVSIM forums. Pete

I've moved this thread to the Support Forum proper, where it more reasonably belongs now. I wish there was a quicker way to read a big batch of L:Vars, but I'm afraid there isn't. Or at least not one I know about. Each read involves two separate calls into other code, code which is mainly to do with the add-on creating the LVar. The first call requests the ID number of the named LVar, and the second actually reads it. The overhead of using a Lua plug-in instead of your C# program is huge as well. Lua plug-ins are really no substitute for a proper compiled program. The system was never intended to be such. To start with the plug-ins are interpreted, as a script. then FSUIPC delberately introduces delays ("sleeps") between operations involvng outside agencies, such as the LVar provisions, so that there's no impact upon the mainstream operations of the simulator. I don't really understand why you have so many LVars changing all the time. How is that? Or are you only talking about getting something initialised? If it is initialisation, then the time taken is surely trivial. There is a supplied plug-in called Log lvars.lua which scans the LVars by ID (0 to 65535 max) to get the names then reads them to see if they've changed. That's always worked well, displaying the changes as they occur. Is that also overloaded by your aircraft? Pete Why? What is so important about getting a high rate of changes received? It looks, from the names of the values you are reading, that this is for main aircraft instrumentation. If so then surely the aircraft maker offers a better way than just LVar access? That is really unsuitable for hardware implementation no matter how you program it. There is no queuing for events at all. There is only one flag per registered event. If the value represented changes faster than the Lua plug-in can process them, the program will only get the latest value. That is surely as one would expect. You wouln't want them fed one at a time gradually getting later and later compared to reality! But each LVar you create an event for will have a separate entry, a separate "changed" flag, and a separate entry in the value table. There is no specific limit -- the tables involved are not fixed tables in a defined space but chained allocated memory blocks. allocated as necessary. So you shouldn't be losing any changes at all. However, by using the minimum polling interval for multiple events your Lua thread will be spending most of its time doing nothing else. You either need a larger polling interval or separatre threads (separate plug-ins) for each. Then watch your P3D performance carefully. In the end I think you are trying to use simple Lua scripting in ways not really intended. As a way of testing things they are excellent. They are also good for extending the facilities of FSUIPC to do more things. But they are really no substitute for a properly interfaced compiled program. I certainly wouldn't use Lua to drive my hardware -- I wrote C/C++ programs for my PFC MIP, PFC centre console and flight controls, Cockpitsonic forward overhead, and Sismo aft overhead. I just use small Lua plug-ins for my Flight Illusion clocks and a couple of replacement gauges (replacing single needles for dual needles on pressurization and duct pressure gauges), and to release the 737 magnetic starter latches when the engines start -- the latter work via an Arduino program too. The only use of LVars on my system are for the 8 different doors which can be openedsed and closed on the Prosim 738 I use -- they used LVars for that purpose as the door control facilities in P3D are limited to just 4. Pete

It wouldn't make any difference to this problem. If an earlier version of P3D4 doesn't fix it, the only interim solution for you is not to use AIseparation for the time being. There have not been any changes in FSUIPC5 to accommodate any P3D updates recently. The only "accommodations" have been when P3D4.0 was released and then with 4.1 to take advantageof new facilities (in the PDK). Unlike FSUIPC4, which had to be updated for every release, FSUIPC5 is designed to be free of such hassle. Pete

Well, I'm relieved. You had me worried. I notice you have many other assignments to keypresses which would be better as controls too. "Better" in the sense that they'd be more efficient. Also clearer (via the automated comments added to the INI file), and safe from any changes you might make to the key assignments in FSX-SE. Nevertheless there's no really pressing reason to change them if you are happy. Pete

It only logs changes. Your extract only shows two entries for adfHeadingNeedle: 2025359 LUA: Global: adfHeadingNeedle = 170 2025375 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:56 2025375 LUA: Global: adfHeadingNeedle = 1700 They certainly don't look the same to me! And Paul is correct. It would be much more efficient to use events. Let FSUIPC do the LVar scanning. Pete

It does seem to point to a weakness somewhere in P3d4.5. What about previous P3D4 versions? Currently we don't know of any solution other than the drastic one of stopping FSUIPC applications using the facilities in FSUIPC for controlling/slewing AI aircraft. I don't like that idea, and for AIseparation it destroys its purpose altogether. There are some things which we might try, but it is in John's hands. I am on holiday soon and won't be able to assist till july. If you know it was okay in P3D4.4, or 4.3, say, it would give us a bit more leverage with L-M. Currently to prove it is a P3D problem and not one or more addons is not easy -- in fact they'll want us to demonstrate it with the most simple of tests, possibly not even with FSUIPC (i.e. a small program calling the same functions in P3D as FSUIPC does). Of course they'd also need a decent number of AI too. How many AI aircraft were you getting at the times of the crashes? Is AIseparation going to be really busy at the time? One of the tests we thought we'd do is to try and slow the request rate down, but if it occurs with few AI being controlled that might be doomed. Pete

But they are correct. The C denotes Control, the K denotes Keypress. That's it. Please show me the actual entries in your INI file -- those will be annotated automatically by FSUIPC, so if they are correct there you will see the actual names of the controls (the names you use are not the actual names). Best to show the entire file, then I might have anidea what version of FS and FSUIPC you are using too, as you haven't actually told me such vital information yet. Also, you'd find it much easier to assign the controls first in FSUIPC's Buttons & Switches tab, THEN add the conditional changes afterwards. Just change the button numbers to suit. Pete

Sorry, the same happens in FSX as well? So it isn't just a weakness we've come across in P3D4? Not I. It will be John. And if slowing down the requests sent to P3D works, it would apply to both local and WideFS clients. But we don't yet know is slowing the requests down will be the solution. Stopping them altogether, as is done by the temporary fix for RC, would render your traffic smoothing useless too I should imagine. Which program is it, anyway? AIseparation or AIsmooth or something else? I thought Ray said those old FSX programs didn't work with P3D4, though if they a 100% using only FSUIPC I don't see why not. Pete

Sorry, I don't understand this bit. Pete

FS controls actually form the bulk of those controls which can be assigned in FSUIPC. The list of controls provided in your FSUIPC documents subfolder cover those. The only list of those controls added by FSUIPC is in the FSUIPC for Advanced Users document. Of course. That is what was intended. Key Presses are converted to those controls in any case when they arrive in the simulator (via the Sim's assignments list). Using the controls directly is much more efficient and avoids problems when keypresses aren't assigned for some reason, or arre taken by other programs. The G keypress is, by default, assigned to "GEAR TOGGLE" in the Sim (Control number 65570). I'm actually surprised you resorted to using keypresses when al the FS and FSUIPC controls are listed for your reference. Pete

Sorry, I certainly don't have that eother. If I did all I could do is experiment to find a way. Maybe the MadDogX folks can help? If it's a sophisticated add-on it should be provided with controls or keyboard shortcuts you can assign to buttons and switches. Surely they would expect their users to want to use hardware devices? Mouse macros were designed as a sort of last resort, for where there was no other way -- and that was usually with lesser add-ons. Pete

Sorry, no. I don't have the aircraft ot experiment with. There's no science in this because it's to do with how PMDG implements things. You could try asking them, but I think they would say that you should use their documented controls. Why aren't you? PMDG aircraft are the least likely to need any mouse macros at all because it is so well supplied with its custom controls. Use them. Pete

That is not a normal FS control. It is probably a PMDG one. The parameter will be one of the "mouse codes" they list in their documentation. That's where you need to look (in case it doesn't show decimal, note that 16777217 = 0x1000001. So bits 0 and 24 only set). PMDG support is really bett over in the PMDG support forum. I don't even have an PMDG aircraft. Pete

Logging events using the FSUIPC logging facilities should do that for you. You can also log button presses if you want. It may already do, or it may not, I don't know. but thst isn't the point. I can't stop the PMDG code getting it at that priority. This is why having FSUIPC intercepting and calibrating axes can lead to conflicts, with FSUIPC sending one value whilst the PMDG code it using the original. Pete