funkyp

Indeed, this one worked: "C:\Windows\surun.exe" c:\windows\notepad.exe However, this one not (same error): "C:\Windows\surun.exe" "c:\windows\notepad.exe" I don't know which parser is handling that, so might be, that if you ever need to communicate a parameter with empty spaces (e.g. a path) then the problem might reoccur. For my problem I created just another batch-file "InitFSX.cmd" which is called by FSUIPC's [PROGRAMS] section. The file collects all the more complicated startups commands and does not anymore require parameters from the command line. That solved the problem, too. bests, Peter

Hi, first let me say that I don't want to hijack the topic, but it seems to me that it relates to the same underlying problem. If you find this not related to the problem or inappropriate, just ingore. It seems that special characters (as the comma or back-slash) incur problems in the Run-command. I have one very similar. This is my programs section: [Programs] Run1="C:\Windows\surun.exe notepad.exe" Run2="C:\Users\Peter\Desktop\FSX\ReHIDMacros.cmd" Run3="C:\Windows\surun.exe c:\windows\notepad.exe" The "notepad-call" is just to have something for testing that should work in any case. And this are the relevant parts of the log-file: ********* FSUIPC4, Version 4.936a by Pete Dowson ********* ... FSUIPC4 Key is provided ... 47 Trying to connect to SimConnect Acc/SP2 Oct07 ... ... 920 Run: "C:\Windows\surun.exe notepad.exe" 967 Run: "C:\Users\Peter\Desktop\FSX\ReHIDMacros.cmd" 967 FSUIPC couldn't run: "C:\Windows\surun.exe c:\windows\notepad.exe" [Error=267] The first two call works, notepad comes up, HIDMacros is restarted. The third is not, although the path to surun.exe is the same as in the first call and the path to notepad.exe is correct. It seems that the appearance of the program parameter containing special charactes as the backslash are indicative for the problem. Hope this helps to identify the root cause. For the time being I can help myself with a workaround. best regards, Peter

The Saitek Pro Flight Switch, Radio and Multi Panels can be accessed directly from FSUIPC and with the lua com library. Start with the HidDemo.lua and open the HID interface to the panels just as with a joystick. Vendor and product names can be retrieved with HIDScanner. Note that the switch panel has "HOLTEK" as Vendor/Manufacturer. Switch Panel For the Switch panel one 32-bit word is retrieved by com.read containing all the switches (incl. the rotary starter button). Adressing the LEDs works by sending a two-by string by com.writefeature(dev, s, wrf). The first byte must be char(0), the second byte contains a char which represents binary numerical representation of the LED-states: 0 b X X R1 R2 R3 G1 G2 G3 X stands for "ignored", R1 is the top, R2 bottom left, R3 bottom right LED, all in red, G1-3 the same in green. I.e. if you want turn on all LEDs in green then the character code is 0b00000111 or 7d (decimal). You can also turn on green and red at the same time by sending 0b00111111 (or 63d) to the feature data. Multi Panel It works similar for the Multi-Panel. Again, com.read retrieves all the button states. It has to be noticed that the trim wheel and the rotary button generates only short pulses in two individual bits each, indicating the turn direction. Not to miss relevant events by the proposed polling routine in HidDemo and also not to overload the lua-engine, I recommend to use at the begin of the polling routine this: while com.test(dev) >= 10*rd do CurrentData, n = com.read(dev, rd) End CurrentData, n = com.read(dev, rd) ... [/CODE] This discards effectively all but the last 10 button events and thus will provide enough rotary events to adjust trim and autopilot effectively, without having to much momentum effect after turning the knobs. Setting the display of the Multi-Panel works similar as with the Switch panel. Now the data string to the panel contains 13 bytes, which might be created like this: string.char(0, a1,a2,a3,a4,a5,b1,b2,b3,b4,b5,x) Again the first character must be a zero, then five characters follow for the first display line, and another five characters for the second display line. The last byte seems to be ingored. The displayed digit is the same as the character code. Character codes from 10-13 result in a blank position. In the second line character code 14 results in a "-". If all positions are filled with character code 15, the display is turned off. The display labels are not programmable, instead depend on the position of the mode selector switch (which is also mapped as a set of buttons). Also, when displaying courses, only the last three digits of the first line are shown. However the format of the writ string remains the same (i.e. only a3-a5 are shown on the panel). [b]Radio Panel[/b] As with the previous, the rotary, mode selector, and ACT/STBY buttons are mapped to buttons in the HID input section. Addressing the digital displays works similar as with the Multi-Panel by writing a string to the feature data. In this case the string contains 23 characters. As before, the first character code must be 0, then 20 characters follow containing the 5 digits each of the four displays. The last two characters seem to be ignored again: string.char(0,a1,a2,a3,a4,a5,b1,b2,b3,b4,b5,c1,c2,c3,c4,c5,d1,d2,d3,d4,d5,X,X) Again the first character code has to be zero, the next five codes show the upper left display, then upper right and so forth. Character codes are converted to the display as follows: [CODE]Code Display 0-9 0-9 10-15 <blank> This repeats in modulo 16 until a character code of 207. 208-217 0.-9. (decimal dot set) 218-223 . 224-239 - 240-248 0-9 250-255 <blank> [/CODE] [b]Annunciator Panel[/b] I don't have it, so I can't test it, but I'd expect it works the same way. [b]Finally[/b] Forgive me not to provide all the individual button mappings, I simply verified that it works this way and used the rotaries to dial through all possible codes at the digit positions, for finding out what they do. However, up to now I have now idea, what the effect is in writing other codes than "0" in the first byte (other than that the panel does not seem to accept anything), or in the ignored positions at the end of the string. Furthermore, the Multi-Panel has altogether two features caps, and I have no idea what the "second" means. Anyway, I know there a number of people interested in programming the Saitek Panels directly and this may help.

Hi Pete, here some answers: I usually took me only a few minutes to produce the crash. I think computing power margin is the key. On my rig there is not much left, maybe it would require unsane faster execution of the buttons, than manually possible, to create the problem at your side. I'd tested it in windowed mode only. For the time being there is the workaround with the resident routines. With that I have no problems at all. The only thing what happens is, if I crank all (!) scenery sliders to the max I'm getting my NV9600GT choked at 100% GPU load, still flyable at 15fps,but producing the "polygon flashing" and mesh spikes, but no crash. best regards, Peter (W7/64 HP, 4GB, NV9600GT 1GB, FSX/ACC)

Hi Pete, have modified my critical code sections now, so that re-entrance does no longer happen, and it's rock-solid now. FSX + Bufferpools=0 + FSUIPC rocks! I've sticked to the "LuaValue" method, as it required less code changes and it's doing the job. The procedure is now this: The script is initialized on loading FSUIPC, rsp. the A/C. A button calls "LuaVale <script> #param" on press, which captured by the event.param. In the script the parameter is copied to a local variable and ipc.macro("LuaValue <script> 0") resets the parameter state for FSUIPC main. There is no need anymore for a mandatory button release code, or inverted logic. However, the advantage of the flag method is a better way to combine multiple button events, e.g. one code upon press and a different one upon release. Cheers, and have a merry Christmas Peter

Hi Pete, thanks again for staying online. Yes I know, but all script commands starts with "Lua abc..." and when it comes to "LuaSetValue abc ..." you have to type the whole LUA category before it comes to my user code name. Promising, and I tried it immediately, but no difference, eventually. It seems to me, though, that I had to do more "chaotic" switching between the views than with uncompiled version in order to produce the hang. It comes back again to the termination of a script and restarting it. I tried also another solution in between: This is an endless loop, starting at the beginning with FSUIPC and evaluating the current ipcPARAM and resetting ipcPARAM to zero after handling the request. There is a problem because FSUIPC does not rewrite ipcPARAM when LuaValue is called withe same parameter on the same script (for performance reasons, I suppose). The workaround is to call "LuaValue <script> 0" upon release of the button. This again can lead to missing events if the physical buttons produce only short pulses (on/off) like the Saitek rotaries with SPAD. The workaround for that again is inverting the button logic, i.e. to excecute the desired command upon release of the button. However, I'm afraid, that I don't understand anything anymore from my own code in three weeks from now :cool:. best regards, Peter Edit (18.12.): Found one for the update problem: ipc.macro("LuaValue <script>",0) does it.

Hi Pete, thanks for your immediate reply, wow that fast, many thanks! This means, e.g. trying to open FSUIPC config dialogue from the Addons-Dropdown menu, which terminates the 3D window and goes into the dialogue-mode. Same with calling the weather menu etc... Sometimes it happens by switching to another application and clicking into FSX 3D window. I'm using 9600GT 1Gb, Nvidia inspector reports 500 Mb (+/-) of RAM usage, so not the obvious out of VRAM reason. RejectThreshold, Usepools=0 or 4000, and even =32MB produce the same behavior, i.e. better visual performance but crashing, when I involve LUA scripting. As long as they work, I recognize some sluggishness in button processing, apparently events get lost, probably due to high CPU load. Without the tweaks my CPU chokes in the 80-90% utilization, with the tweaks I get into the 98% range (thus leaving less capacity for concurrent threads) Actually I mean re-executing with some other parameter, diverting to some other action, thus forcibly terminating the thread if it has not finished normally. However, the codelets are designed to re-assemble their environment from scratch each time, so there shouldn't be problems with non-initialized variables. In order to avoid clogging the CPU there is an ipc.sleep in those parts running in a loop. Most likely, this is the state in which the re-call stumbles in. The same part of the code has been executed several times before the freeze. The downside of splitting is that the drop-down box of FSUIPC button mapping get's quickly overcrowded. Therefore I try to build libraries for well defined sciopy (say an aircraft) were a number off short functions are addressed by the calling parameter. But I understand that loading and compiling can take time. Well, actually, only one piece is executed at a time (1, 2, or 3) with the exception of the while-loops which are designed to presist and update the view-pitch axis constantly regarding the bank of the aircraft until another call to the script is made. Actually meanwhile I have tried your proposal and it seems a workaround (FsxViewsEvents.zip). This one is loaded once at startup (or triggered by a key for testing purposes). However, I'm a bit concerned about the underlying problem, since re-entrance may happen at any time, by incidence and possibly shoot the sim. As an example I have a trim wheel (Saitek Multipanel) which fires sequential virtual button events (by SPAD) which are handled by a LUA script to operate the freeware Constellation's autopilot pitch reference. Or could it be, that the problem arises from the LUA-compiler which may go haywire if captured in the middle of compiling the same script? You said previously, that at each call the script is compiled new. I'd like to do anything but keeping you away from enjoying Christmas! Good idea, will try this. So far it only occured in combination with LUA, not even with the FSUIPC button mapping to standard FSX commands. Again, thank you very much for your effort, and please keep on going with FSUIPC (but enjoy X-max). FSUIPC is my Swiss Army Knife for FSX! best regards, Peter

Hi Pete, I have a problem with reentering a LUA script library which produces a weird problem that FSX/FSUIPC stops executing LUA scripts, still accepts key commands and jystick buttons via the FDSUIPC button programming and hangs, at any actions which affects the screen mode, e.g. suspending the sim for showing a dialogue windows. The problem has become obvious after using the bufferpools=0 tweak (or similar) which results in reduction of stuttering and improving visual performance of FSX. So far I could track this down to terminating and restarting LUA scripts. As long as I don't attempt this the SIM runs normal. Maybe this is an old one as I have read here in this older post from Guenseli: http://forum.simflig...fsx%20%20freeze In the readme of the newest 4.749f version I found: So I was optimisitic that my problem had something to do with that, but unfortunately persists. In the FSUIPC-log I fond eventually these two last lines: 1718943 *** LUA Error: ... (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FsxViews.lua:6: '<eof>' expected near 'if' 1722672 *** LUA Error: ... (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FsxViews.lua:6: '<eof>' expected near 'if' This is the questionable code: -- 1 : Pan right with bank -- 2 : Pan left with bank -- 3 : Pan reset -- 1 : Pan right with bank if ( ipcPARAM == 1 ) then PanViewHeading = 67.5/180*16384 ipc.control(66504,PanViewHeading) SinHeading = math.sin(PanViewHeading/16384*math.pi) ACbank = ipc.readSD(0x57C)/2^16 PanViewPitch = -SinHeading*ACbank ipc.control(66503,PanViewPitch+1) PanViewPitchOld = PanViewPitch while 1 do ACbank = ipc.readSD(0x57C)/2^16 PanViewPitch = -SinHeading*ACbank if math.abs(PanViewPitchOld - PanViewPitch) > 0 then PanViewPitchOld = PanViewPitch ipc.control(66503,PanViewPitch) end ipc.sleep(33) -- slows down the loop end -- 2 : Pan left with bank elseif ( ipcPARAM == 2) then ... (and so on) [/CODE] I have attached the complete lua-code, log- and ini-file to this thread. The function is an alternative PAN-command which keeps your sight parallel to the horizon during banking. It has three entries: "1" and "2" for activating a fixed angle pan left or right, and "3" which resets the view to normal. The problem was provoked by quickly changing the views, e.g. during a circuit pattern. The function principle is that starting the function with codes 1 or 2 triggers an endless loop, adjusting the view axis according to the bank angle. This loop is forcibly killed (on purpose) by each new call, typically by code 3, which resets the view direction and terminates the script normally. The weird error code pointing to line 6 (where the actual code starts) let me think of some memory corruption problem. I have the same problem with another LUA script, which works likewise. In both the problem seams to disappear (or at least become much less frequent) if I don't apply the Bufferpools tweak and reduce CPU load by that. Of course my programming style is not the smartest, but it allows me to take easily advantage of FSUIPC button mapping fdacilities that makes the use of such special commands very flexible and easily aircraft-specific. This would become much more complicated when checking hardcoded button events from within the script. best regards, Peter FsxViews.zip

Thanks a lot and :-D Cheers, Peter

Hi Pete, I got a new problem with the event.timer today. After success with my first timer function I tried to add a second timed function in another Lua-plugin. To isolate the cicumstances I have prepared to timer-plugins, "timer1.lua" and "timer2.lua". timer1.lua goes like this: function timer1function(CurrentTime) ipc.display("Timer1="..CurrentTime) end event.timer(1000, "timer1function") timer2.lua goes like this: function secondtimer(CurrentTime) ipc.display("Timer2="..CurrentTime) end event.timer(100, "secondtimer") I have mapped the scriptfiles on two keyboard keys by FSUIPC. When I trigger the first script it installs the event.timer for every second reaction, and the "Timer1=nnnnn..." shows up with the correct rate. When I trigger now the second function, "Timer2=nnn.." might be considered to show in between the updates of the first timer function. However, all what happens is, that the update frequency of the "Timer1=nnn..." accelerates by a factor of 10. If I kill the second timer function, "Timer1=nnn..." ceases to update. My understanding was that only one timer function can exist in one Lua-plugin. Therefore I made the two plugins, but apparently only the first function is being registered as a timer callback, while the event.timer call in the second function doesn't register its callback. Nevertheless it changes the update rate of the first function. It happens also vice versa, i.e. if I start with the fast timer function, then "Timer2=nnnn" shows up and is slowed down by firing the timer1-script. The same effect happens if I try firing the two functions by "ipc.runlua()". Did I misunderstand the timer thing or have I missed something in the documentation? Cheers, Peter Edit: I'm using V4.661

I think I got it now. Previously I had mistaken the sleep function as a timer, too, which is not. Thanks for your help, Peter

I have rechecked it and found that the lock-up only occurs when using ipc.display in the loop: while true do ipc.display("Something") ipc.sleep(0) end In this case FSX stopped to react on user input and was frozen. Different to that, the next works without a problem (also when the commented line is activated): function timerfunction(time) -- event.timer(0, "timerfunction") ipc.display("Something") end event.timer(0, "timerfunction") BTW, for checking the actual execution rate I had included a call to "ipc.elapsedtime" in the loop for measuring the delay between two calls, retrieved the FPS from offset 0x274 to compare, and averaged both. In order not to introduce extra delays during the test, the display function was inactive and toggled active with a flag at the end to show the final result. Cheers, Peter

Hi Pete, thanks for the feedback. The question was raised by the observation, that the repetition rate of my LUA script resulted exactly in the FPS rate when I chose 0, and as long as I didn't use the ipc.display-function. With the latter, there was jitter in the rate which could be very well explained by skipping individual frames. Howeber, it did not happen this way that the the machine was locked up when 0 was the timer rate. Different to that, using the sleep(ms) function immediately blocked FSX, when used with a parameter of 0. Yet, it might be a coincidence. From your response I would conclude that it is not recommended using a call like "event.timer('F-Name',0)", or equivalent. Indeed, frame-synchronised ("SimFrame" (60/s const.)and "VisualFrame") events are offered by SimConnect, but their precision and reliability is still poor in SimConnect clients. best regards, Peter

Hi Pete again a (simple?) question. I'm trying using the "event.timer" function. Is it correct that 1) the trigger of the callback function goes maximum with the framerate? 2) setting the timer period to "0" results in an (almost) frame-synchronous execution? Is it allowed to use "0" to get something frame-synchronized function, or is there a risk of malfunction? best regards, Peter

Hi Pete, thanks for your action, I will try it out next. best regards and all the best for the new year, Peter

Hi Pete, many thanks for dealing with this problem. I think it's also an advantage for FSUIPC to support this. Please don't bother with timing, enjoy your guests, best regards, Peter

I think something like that could be achieved already right now by using the "virtual button" offsets, and indeed, overlapping use would become a problem in any way. I think that would solve it 99%. 32 is actually pretty limited, although a workaround could be to have not more than 32 functions in one library. If more are needed, a second library would be used, and so on. Increasing the number would keep the whole thing more elegant, though. Why not 256? This would offer also a some margin for encoding extra information, e.g. selector switch states, more conveniently by flags. And still, hardware configuration by end users is simple, because all what is required is a 1:1 translation table, for mapping flag numbers to the implemented actions. I cannot find, however, a library call for manipulation of the flags by a Lua script itself. It would be very helpful if there is also the option to clear (and possibly also to set, something like ipc.setflag and ipc.clearflag) a flag by the Lua script, too. This would allow capturing even very short button actions, because there is no need to reset the flag already by releasing a button, if it can be cleared from the Lua script after processing it. best regards, Peter

Hi Pete, hi Kosta, thanks for your extensive and helpful feedback. I think I didn't consider the "flag"-option yet, this could indeed by a solution for the isolated problem with the mode switch. The reason why I didn't go to the continuously running script (yet) was to keep the possibility to map the commands by means of the FSUIPC user interface. I think this is a great advantage of FSUIPC that you can adapt the function mapping easily to any controls hardware or user preferences. Actually I started with a bunch of some 20 different scriptfiles, handling a different function each. The functions could have several modes, say "on", triggered by one button, and maybe "off", triggered by some other button, which were adressed by parameters (ipcPARAM). As described above, this didn't work reliably for the mode switch, so for this I had to provide an individual script for each button event. After all I ended up with more than some 30 scripts populating the modules folder and overcrowding the drop-down list in the FSUIP user interface. So I tried to put it into a single library, plus a sort of dispatcher that navigates the individual events to the appropriate library routines. This what I put recently into the "User Contributions" section of the forum. Because of the 66 ms blanking time this actually works, because of the specific sequence of the button events. Regarding the variables, I mean of course the globals, created with ipc.set(“name”, value), but also the Lvars, extensively used in custom gauges, and last not least aircraft variables at offsets. I have all the documentation of FSUIPC and the LUA plugins and I make extensive use of it. While simultaneous pressing of buttons might not be the usual case in standard game controllers, the mode switch of that particular Saitek Aviator Joystick operates two buttons (12 and 13) almost simultaneously when switching from A to B. As these coincident events are occuring at the foremost end of the signal chain, the overlapping execution seems unavoidable, if two conditions are met: 1) You are using FSUIPC to map button events to script files and (highly preferred) 2) Both buttons are mapped to the same script file (obviously with with different parameters, e.g. in case of providing one library for a particular aircraft). As you wrote (and as I did initially), a solution is having different scriptfiles, which can become pretty messy, if a more complex set of scripts is considered. Basically, this situation suggests, as Kosta said, to realize the button handling (and mapping) entirely in LUA which makes it much more difficult for an average user to adapt a script to his own hardware. And, the fact, that a script may be terminated at any time, requires special attention to the consistency of variable sets. I'm not yet sure, but after using Guenseli's Catalina-library, I observed occasionally some alteration of the flight dynamics, after using the FSUIPC interface. This might come from such an interrupted routine in the panel system which adjusts the drag and lift poperties by sets of invisible flaps and spoilers, and left inconsistent after an interruption. Might be his problem with the rotary knobs has something to do with this either. As I said, I don't know what the ideal approach for this problem could be. Another idea might using "virtual control mapping" by FSUIPC, which can be adapted with the user interface, and use a looping script which polls continuously the state of the virtual buttons and axises. This would avoid the killing-problem and keeps the flexibility ease-of-use in the mapping of controls. I know there is already a set of "virtual buttons" for use with external hardware, but I'm not sure if this would be recommended use of it. Anyway it would allow configuration by offset-commands from the user interface. Might be better to have some sort of "user-scratchpad" area in the offset-section. best regards, Peter

When programming a collection of LUA scripts for Manfred Jahns L749, where I wrote a library, that allows full hardware operation of the plane, I hit upon a tricky problem with the occurrence of (almost) simultaneous button events, that comes from the fact that LUA plugins are terminated and restarted by subsequent calls, regardless if they have previously completed or not. By reasons of portability I wanted to have the button and keyboard association by means of FSUIPC rather than hard-coded in the script. Saitek Aviator Joystick has a rotary switch with three positions (off, A, B) which is orginally used as a mode switch. Nevertheless, positions A and B are simply connected to joystick buttons 12 and 13. In off position neither of the buttons is active. It appeared attractive to use the switch as the structural deice control of the L749 which also has three positions (off, on, extended). The idea was using event 12 for going to "deice on", 13 for "extended mode", and "off" by means of the release of button 12 to go back to "off mode". Obviously the sequence of the events would be important. Therefore the transition to "deice off" was allowed only from the "on" mode but not from "extended". By this, so the idea, it could be achieved, that independent from the sequence, switching to position "B" would reliably result into "extended" mode. Even if the release of 12 wold occur after the down-event of 13, going back to "off" would be blocked, if "extended mode" has already been set. Otherwise, if the release of 12 would occur before the down-event on 13, the deice would go to "off" for short, but immediately return to desired "extended" mode. Unfortunately, this worked only if I had different LUA-script files for each sub-command, because calling the same script just with different parameters resulted into a premature termination of the running script, ending with the effect that I could not produce the transition to "extended"-mode at all. Instead the position of the virtual know always went back to off-position. Now, with the 4.645, it turns out to work, because incidentally the release of button 12 occurs slightly after the down-event of 13. The result is that the first call (button down 13) does the transition to the desired "extended" mode. The call of the release event of 12 is not executed at all, because it falls into the 66 ms blanking time. I was lucky, indeed. However there is a substantial risk that the problem reappears wiht other hardware, or after some future software update. Other might have had a similar problem also. Another problem of the killing of a running script is a high risk that a set of script variables might be left in an inconsistent condition, i.e. there might occur a situation where parts of the variable set refer to some updated situation, while other parts still reflect the original situation, because the script didn't update all of these. As a programmer one has to keep in mind that the script might be interrupted at any time, with all consequences of the variables state. I would like to suggest to consider a more explicit handling of this situation. I was thinking of some flag that controls if a new call is queued until the previous has completed. Another option might be to allow several instances of the same script, although this might introduce further problems with thread safety (maybe not so a good idea). Another idea could be the introduction of a sort of "critical section", which allows to protect sensitive parts of the code. best regards, Peter

Inspired by the work of Guenseli I converted my messy LUA-script collection for the L749 from Manfred Jahn into a more sleek package. It allows operating almost everything by buttons and keyboard commands. Unzip the archive into the modules folder and assign the functions to your preferred buttons and keycodes. I'm using a modified Rush-Pad (10€)which I had relabled with stickers as a generic "Pedestal Panel". L749LUA.zip

It seems to me more like a model railway. It's not about having the trains running all the time but creating the landscape and making it all neat and as real as it gets. At the end of the day you roll a few trains for half an hour or so, pleased with the realism of your own good work, and then go to bed happily. The other day, you'll start with the next "challenge". Merry Christmas, Peter

Hi Pete, Thanks fro the quick reply. After installing the latest NV driver 195.62 the problem is gone again. Until recently I used 191.62, which seemed to have worked either. Seems that the graphics driver distributed by the MS driver base has been the cause of the problem. Though, it makes me currious how this gets triggered by some SimConnect Add-on that does not interfere with graphics at all. Some indicator that something is weird is a long sequence of alternating RequesID=14 and RequestID=24's in the SimConncet.Log (c.f. below). This starts at 83.98635 seconds, then comes the break until 85.1349 seconds. Apparently, a number of the 14ers and 24ers have queued up which are flushing now into FSUIPC. There were no transmits before from FSUIPC after 83.2 s or so, when only the SimState was requested, so indeed, it doesn't seem to have anything to do with FSUIPC directly. I have also some trouble with a Windows 7 test installation, where it turned out that out-of-process add-ons gets way less reliably queued compared to XP and VISTA (indeed VISTA is much better here). It urges me to move some time critical parts of my app into a new DLL. As it seems fixed I'm not going to try 4.53 for the moment. best regards, Peter [EDIT]: I can confirm that the Windows 7 jerks are a completely different story, and I can confirm your findings about irregularity. In out-of-process add-ons it is very relevant and I found up to 0.5 seconds delay in activation of the add-on even with 195.62. In in-proc-DLLs it is much better, but still not as good as in Vista and XP. &lt; 83.95244 [0] EventFrame: 0 29.908175 &lt; 83.95266 [0] ObjectData: RequestID=9 DefineID=9 dwSize=56 &lt; 83.95280 [0] ObjectData: RequestID=10 DefineID=10 dwSize=400 &lt; 83.98502 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 83.98523 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 83.98549 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 83.98566 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 83.98598 [0] EventFrame: 0 29.859402 &lt; 83.98622 [0] ObjectData: RequestID=9 DefineID=9 dwSize=56 &lt; 83.98635 [0] ObjectData: RequestID=10 DefineID=10 dwSize=388 &lt; 85.13849 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 85.13894 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 85.13969 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 85.14020 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 85.14193 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 85.14225 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 85.14281 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 85.14542 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 85.14655 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 85.14771 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 85.14808 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208 &lt; 85.14835 [0] ObjectData: RequestID=24 DefineID=24 dwSize=68 &lt; 85.14873 [0] ObjectData: RequestID=14 DefineID=14 dwSize=208

Hi Pete, I have some trouble with the latest 4.558, but I'm not sure if this is not already since 4.53. Precisely every 10 seconds the entire desktop including FSX SP2 freezes for a second or so. It is clearly not related to any other add-on, as these are all deactivated for testing. Aircraft is stock King Air 350 on EDDK. It might however sneaked in after falling back to the MS-supplied VISTA display driver, which I did a few days ago, after having continuous trouble with "FSX has stopped working"-errors (the error has remained, btw). I'm going to try the latest NV driver package 195.62 now. The freeze does not occur when I do not load FSUIPC. I have prepared a bundle of logs, inis, etc. for information. System is VISTA 64 Home Premium, Asus P5Q, E8400, 4GB, NV9600GT/1GB. best regards, Peter

Hm, is the Sim1.dll used by all aircraft? I'm currently experiencing some weird behaviour with the DG808, where wind effects in the Shift-Z and by aircraft and gauges behaviour is actually are much worse with smoothing on as without. It appears as an unstable siutation, when the ambient wind speed oscillates with increasing amplitude, while interpolated METAR info remains stable. I have still 4.241 in place, but I will start with 4.250 tomorrow. I found this with "Thunderstorms" theme (or so) near Sion, simulated date 21.06.07 around 13:00 LT, in appr. 5000ft. regards, Peter

Thanks for the clarifications, obviously I had still some misunderstandings. From your "horrible hack" remarks I assumed that there was still something else. That was one reason for my questions. Still, even when it is done through METARs (what I meant with FSX Weather stations), then it's ok for my purpose if the principal METAR winds (Edit, was: surface winds) stays unaffected, which I understand is the case. It's important for me to achieve compatibility with FSUIPC, and not urging the user to enable or disable important options. Principally I agree with you, with respect to the main controls. In this particular case this is not exactly what I want to do. I found it very conveninet to map the twist handle to the Pan Heading axis, but I would like to restrict the pan angle from -90° to +90° (or so), rather than the normal +/-180°, to get a better control when looking sideways. Scaling down the sensitivity in FSX makes the axis gain very low around the center, but even more sensitive the more you turn the handle until you reac +/- 180° again. In this situation, the convenient user interface of FSUIPC suggested to me, that there might be a chance to make the adjustment here, but of course there was not. (? or:is not?) Thanks for the hint and I will have a look into it. That's the thing with MS Software: Most of the essential support is from third party. best regards, Peter