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