Pete Dowson

Those sliders won't have any affect at all if you disable the stick in FS. they are only relevant to FS's reading of axes, not FSUIPC's. You can adjust the response curve in FSUIPC. The facility is called "slopes". Once you've calibrated properly, just adjust it to suit your style. You do really need a "dead zone" at the centre, the hands-off position, because, at least with all the yokes and sticks i know of, each time you let the spring-loaded axes re-centre themselves, they stop in a slightly different place. You should always calibrate so that there's a region in the centre which, with hands off, the aileron and elevator readouts (the "OUT" value in FSUIPC) are zero. If you want a rapid response either side of that zone, then use a linear slope or a steeper one -- but most folks find the slopes with the flatter centre give better control -- less over-controlling for normal gentle manouvering and straight flying. Only fighters and stunt planes tend to have over-rapid response to small stick or yoke movements, and even then that response would be built into the aircraft flight characteristics in the aircraft modelling, not in the yoke or stick. But experiment. You can't do any harm. Regards Pete

Yes. It is very annoying. On Wednesday this week I am expecting an Engineer over from Sacramento to fix some long-standing faults on my PFC 737NG cockpit and to update the overhead panel with a fully populated and indicated version. if this blasted cloud doesn't shift before then it's all going to get cancelled. I've no idea when we can re-schedule. It's taken months to sort this trip out! :-( Regards Pete

I couldn't resist looking into the ipc.get() problem todayI used this: You said this was "not very useful", though it may also indicate a small misunderstanding. There is no point in the "y=0" part, because the Global variable "y" is not the same as that local variable y. If you wanted the ipc.get to actually return a value other than nil you'd have to use ipc.set() before the loop, to set "y". Anyway, the problem of the crash was nothing to do with starting and stopping threads. That loop alone, just started once and allowed to continue, would crash eventually. My "ipc.get" function retrieves the global value (even "nil") to the global thread's stack, then transfers it to the calling thread's stack, but it didn't pop it off the global stack. Result -- eventually a stack full crash on that global thread. How long that takes is related to the space taken up by the variable. For "nil" it takes more iterations than for a long string, for example. I've fixed it here, ready for the next FSUIPC release. Thanks for finding this bug! Regards Pete

Okay. Assuming you weren't moving all your controls violently during the first 3 seconds of this session, it most certainly looks like you have conflicting assignments. Look, here I have sorted the first few references to each axis so you can see the values zapping up and down: I think you at least have these axes assigned in both FS and FSUIPC, which is calamitous to start with. For some axes it also vaguely looks as if you have more than one assignment in FSUIPC as well. You need to make up your mind where you want to assign things. Do NOT ever assign any buttons or axes in both FS and FSUIPC. Do it in one place or the other, else you will get these conflicts. If you do not understand this, then I recommend that you DELETE the FSUIPC4.INI file, which removes ALL of your FSUIPC settings, make sure all your assignments are okay in FS, then only use FSUIPC to calibrate. Do NOT go near the Axis assignments facilities unless you first disable those axes in FS. Regards Pete

The log file, of course, FSUIPC4.LOG! When you enable logging, that's what happens -- the data goes into a log file. That's the whole point. The on-screen console option is just an extra goodie for you to see what is going in the log. Okay? In the FSX Modules folder, same place as FSUIPC and the Install log and the settings in the INI file. Pete

Okay. That's good. Meanwhile, I've been thinking about what might have been the problem crashing FSX. I suspect I have a weakness in the Global Variables handling. In order to provide global variables I have a global stack set up in Lua -- effectively another thread permanently suspended except when asked to access the variables it stacks. I'm wondering if that's not as well protected against multiple re-entries as the normal Lua threads. I suppose it could affect "ipc.get" more than "ipc.set" simply because the latter doesn't need the calling thread to be help pending a result. Anyway, even though you shouldn't need it sorting now, I'll get onto it tomorrow. I don't like faults and weaknesses if I can fix 'em! ;-) Regards Pete

All those show everything running fine. There's simply no applications even trying to connect to WideClient on the Client PC, so it is simply idling with the 2/3 second update frame to keep the connection.. You aren't running WideClient and the applications at different privilege levels are you? If you run one program "as administrator" and the other normally, they can't talk to each other -- Windows prohibits it. Why aren't you having WideClient load your PM apps via the RunReady parameters? The only other way you can stop clients connecting to WideClient is by setting ClassInstance in the INI file, but you only ever do that to run FS on the same PC as WideClient, or possibly to have several parallel instances of WideClient running (for several "button screens" perhaps, as I do. Regards Pete

Well, not with WideFS in any case. If it uses SimConnect (in FSX) then that operates over Networks too. Regards Pete

Did you find out if there's any way to use the same programmed camera views in Slew mode? I programmed my camera view keystrokes onto rocker switches (like a hat) on my PFC yoke, but with ECZA I miss using the same switches for viewing in slew mode too. Regards Pete

They are "View mode" and "View mode rev" controls. Generally it is more efficient to program controls directly. "Next Sub view" and "Prev sub view". That's FSX . don't know about FS9, it's not the same I think. Regards Pete

There are several different controls in this area which do different things. And they are different for FS9 and before and FSX. Without knowing any more about what you are using or wanting to really do I can't help. What version of FS, and what keypresses do what you want? Pete

On their own, or after you have done something in FS or FSUIPC? 1 cm? That sounds quite reasonable. You should have a centre dead zone which doesn't cause you to change course just because you knocked the yoke a little! Like a fighter jet, you mean? Hair trigger? You are a very young flier I assume? ;-) Have you actually calibrated this yoke anywhere? Is it assigned in FS? If so, check the sensitivity and null zone sliders in FS. The sensitivity should be maximum (full right) and the null zone minimum (full left). If you then calibrate in FSUIPC you can choose as small or as big a centre zone as you like. Just follow the steps enumerated in the User Guide. OR just don't calibrate in FSUIPC, as I think the default FS behaviour (which I hate) may possibly be more up your street? ;-) Note that, if you do calibrate in FSUIPC, as well as setting no measurable central zone at all (so you cannot take your hands off and expect level flight), you can also exaggerate the effect using the steeper "slopes" option instead of the "flattening" ones (via the "slopes" button). You are using FSUIPC? In that case I assume you must have set the "dead zones" deliberately? Or you are assigning in FS and have forgotten to set its sliders correctly? If you would like to explain what you are doing, maybe things will become clearer. Why don't you simply start from the beginning. Cancel all of your FSUIPC settings (eg delete the INI file before loading FS). Then get things right in FS first. Then, if you still want to use FSUIPC, do it the way YOU prefer it. no dead zones -- easy, just don't set any. Vicious response? Easy -- set a near vertical slope! All your choices are there, but I don't know what ones you've made already. Regard Pete

No, I don't think that can be the case. It's actually got a lot less to do than most. Wouldn't it more likely be that, without those, your code was actualy doing something different? Anyway, I'll try to work out what was happening. But it won't be today, and maybe not tomorrow. Guests have just arrived! Hmm. That is weird. I don't understand that -- if it is timing, "set" should take longer! That's less surprising. One involves file access and the other calls to complex routines inside FSX which are probably not re-entrant. I'll add to this thread when I've had a further look. Maybe tomorrow, maybe monday. Regards Pete

Not my page, but Enrico Schiratti's. I'll have to remember to ask him to update that. I hadn't noticed -- FStarRC has so few users that no one told me before! Good! Thanks for letting me know. Regards Pete

Phew! That's a long and complex program for your "first attempt"! It's rather longer than anything I've ever tried, for a "plug-in". I'm not sure when I'll be able to get through that to understand what you are trying to do, but first I will encompass it in "code" brackets (see the "code" button above when you are editing messages). This enables the program to be within a scrollable AND selectable window. Very useful for anything more than a few lines: -- **************************************** -- -- My EZdok & FSX View Tracking Script -- version: 1.0 -- -- **************************************** -- Passing Parameters -- 0 = Initialize -- 1 = TrackIR enable/disable -- 2 = EZdok state tracking -- 3 - View Next in current catagory -- 4 = View Prev in current catagory -- 5 = View Next Catagory -- 6 = View Prev Catagory -- **************************************** -- Public Variables iMaxView = {12,21} -- EZdok custom views = 10,11,12 VC views & 20,21 outside view (increment when adding new views) iView = {} -- Saved EZdok custom view states iMaxEZCat = 2 -- 2 EZdok catagories (increment when adding new catagories) iMaxCat = iMaxEZCat + 3 -- 2 EZdok catagories + 3 FSX catagories -- **************************************** -- Public Subroutines -- Toggle between 0 and 1. function toggle (iStatus) if iStatus == 0 then return 1 else return 0 end end -- Change TrackIR state -- 0=disabled, 1=enabled, -1=toggle function TrackIREnable(iNewState) -- Get saved state iCurrentState = ipc.get("TrackIR_enabled") -- Check for no previous initialization and assume enabled state if iCurrentState == nil then ipc.set("TrackIR_enabled",1) return end -- Check for toggle if iNewState == -1 then iNewState = toggle(iCurrentState) end -- Send keystroke ONLY if state changed if iNewState ~= iCurrentState then ipc.keypress(120,8) ipc.set("TrackIR_enabled",iNewState) end end -- Change EZdok state -- 0=disabled, 1=enabled, -1=toggle function EZdokEnable(iNewState) -- Get saved state iCurrentState = ipc.get("EZdok_enabled") -- Check for no previous initialization and assume enabled state if iCurrentState == nil then ipc.set("EZdok_enabled",1) return end -- Check for toggle if iNewState == -1 then iNewState = toggle(iCurrentState) end -- Send keystroke ONLY if state changed if iNewState ~= iCurrentState then ipc.keypress(68,8) ipc.set("EZdok_enabled",iNewState) end end --- Select Aircraft View function ShowView(iNewView) TrackIREnable(0) EZdokEnable(1) -- EZdok VC Forward if iNewView == 10 then ipc.keypress(104,2) -- EZdok VC Left elseif iNewView == 11 then ipc.keypress(103,2) -- EZdok VC Right elseif iNewView == 12 then ipc.keypress(105,2) -- EZdok Outside 1 elseif iNewView == 20 then ipc.keypress(100,2) -- EZdok Outside 2 elseif iNewView == 21 then ipc.keypress(102,2) end end -- **************************************** -- Main -- Get the last catagory index, 1=EZdok VC, 2=Ezdok Outside, 3-5 FSX iCat = ipc.get("LastCat") if iCat == nil then iCat = 1 end -- Get the last EZdok VC view iView[1] = ipc.get("LastView10") if iView[1] == nil then iView[1] = 10 end -- Get the last EZdok outside view iView[2] = ipc.get("LastView20") if iView[2] == nil then iView[2] = 20 end -- 0 = Initialize if ipcPARAM == 0 then --Nothing needed here yet end -- TrackIR, -1 = disable, 1 = enable if ipcPARAM == 1 then TrackIREnable(-1) -- Prev View (EZdok) elseif ipcPARAM == 5 and iCat <= iMaxEZCat then -- Decrement to the previous view. If at first EZdok view, -- wrap back to last view iView[iCat] = iView[iCat] - 1 if iView[iCat] < iCat*10 then iView[iCat] = iMaxView[iCat] end ShowView(iView[iCat]) -- Prev View (FSX) -- "Shift-A", as assigned in FSX elseif ipcPARAM == 5 then -- Just issue the keystroke since we dont need to track FSX views. ipc.keypress(65,1) -- Next View (EZdok) elseif ipcPARAM == 6 and iCat <= iMaxEZCat then -- Increment to the next view. If at last availabe EZdok views -- wrap back to first view iView[iCat] = iView[iCat] + 1 if iView[iCat] > iMaxView[iCat] then iView[iCat] = iCat * 10 end ShowView(iView[iCat]) -- Next View (FSX) -- "A", as assigned in FSX elseif ipcPARAM == 6 then -- Just issue the keystroke since we dont need to track FSX views. ipc.keypress(65,8) -- Prev Catagory (EZdok & FSX) elseif ipcPARAM == 7 then -- Decrement catagory counter iCat = iCat - 1 -- Check to see if counter is 0 -- and leave at first catagory (1=Virtual Cockpit), thus no wrap to last catagory. if iCat < 1 then iCat = 1 -- Check to see if now in range of EZdok catagories, typically 2, the VC and outside views. -- and show the saved view in the previous catagory elseif iCat <= iMaxEZCat then ShowView(iView[iCat]) -- Otherwise user still in FSX catagories, so perform a "View Mode Prev" command else ipc.control(65749) EZdokEnable(0) end -- Next Catagory (EZdok & FSX) elseif ipcPARAM == 8 then -- Increment catagory counter iCat = iCat + 1 -- Check to see if exceeded the maximum number of available catagories -- and leave at max, thus no wrap back to virtual cockpit. if iCat > iMaxCat then iCat = iMaxCat -- Check to see if in range of EZdok catagories, typically 2, the VC and outside views. -- and show the saved view in the next catagory elseif iCat <= iMaxEZCat then ShowView(iView[iCat]) -- Otherwise user now in FSX catagories, so perform a "View Mode Prev" command else EZdokEnable(0) ipc.control(65567) end -- Absolute View Selection elseif ipcPARAM >=10 then -- From the user supplied jump-to-direct-view, -- store new catagory and view to be used later iCat = ipcPARAM/10 iView[iCat] = ipcPARAM ShowView(iView[iCat]) end -- Save off these values to use for next time LUA is executed ipc.set("LastCat",iCat) ipc.set("LastView10",iView[1]) ipc.set("LastView20",iView[2]) -- **************************************** -- End So, before I looks at it and think about it, is the only problem that it crashes FS at some stage? Otherwise does it do what you want? And how, out of all that, did you identify, as you thought, the "ipc.get()" function as culprit? What pointed you towards it? One way around the terribly inefficient destruction and creation of threads, and the need to use Globals to communicate from one instigation to the next, it is have a version which is loaded once (by ipcReady.lua, for instance) and tests for Lua Flags being toggled by your buttons (i.e using the LuaToggle control), instead of those buttons instigating new thread executions. You would obviously need to make it a never-ending loop then, but with it running only the once that would be fine. I think it would be much more efficient and safer that way. Even so, even if you do that, I'd first like to know what is going wrong with it as it is so I can possibly take more precautions than I have already taken to avoid the thread stacking problem. Can you please confirm what version number of FSUIPC you are using? Maybe it is one before I fixed the last bug I found in that area? Regards Pete

What's "the large vertical trim"? "Elevator trim set" with a parameter of 0 will certainly set the elevator trim to centre. That's what it does. But maybe you have something else working against it? Please try using the FSUIPC logging to see what is happening. You'll need to enable both axis and normal event logging (two check marks). Pete

Well, if you cannot read them on screen, why not look at the file? Post a section here too. Evidently you have some axis which is furiously changing very fast. Sounds like a broken joystick or a bad driver. Biut let me see part of the log -- that is what it is for! Regards Pete

What do you mean, exactly? What multiline message are you trying to get, and what does it have to do with mouse macros? If you mean the prompt for naming the macro and which shows you that you've clicked a place which may be subject to such a macro, then the only time that won't occur is when you've not clicked in such a place. It will never appear unless you find an aircraft with gauges which are written in such a way that it can work. If you don't see it then you can't make a mouse macro. Maybe all of the planes you've tried are made by Microsoft (who did not follow their own rules), or made using XML, not the C/C++ panels SDK. Many new planes, especially most of those for FSX, use XML, not C/C++. Regards Pete

What do you mean by deadzones? Perhaps some details of what your problem really is might be useful, if you want help. Pete

I'm using FliteMap 9.3 with FStarRC 2.001 on Windows 7, and that works well. I don't know if it will work with 9.4.7 (Jeppesen have an awful habit of changing things in their print formatting, which is where FStarRC gets its data from), but I'm pretty sure FStarRC 1.86 won't even work with the 9.3 I have. Why don't you try using the updated release of FStarRC? It's available with all the rest of the updates in the Updates announcement above. Regards Pete

It isn't specifically ipc.get() which crashes FSX. In your scenario you are creating hundreds of threads, each one running the same Lua program. Eventually this crashes FSX because it cannot create any more threads for its own purposes. Look: That's a Lua program which never terminates of its own accord. And because the never-ending program is "sleeping" most of the time, ignoring any attempt to do anything with it, even though every time FSUIPC tries to delete it and restart it, on one of your repeated button presses, it takes longer for Windows to forcibly terminate it than it does to create the new thread. The end result is ... because of the accumulation of threads sitting in uninterruptible "sleeps" waiting to be terminated. But your Lua program never completes. Even if it did it is incommunicado most of the time (200 mSecs out of about 201). It is nothing to do with any particular command. I am puzzled as to what you are trying to do. Why would you want to keep reading a global variable in a never-ending loop, and, not only that, keep doing so repeatedly on a button being held? If you'd like to explain what it is you are really trying to do, maybe I can advise you on a sensible way to do it? Never ending Lua loops are okay providing they are just loaded once and left to do their job. To keep calling them over and over seems odd when they are running already and still doing the same thing. What's the point? Regards Pete

No, because it is actually a video screen, connecting just like any other to your video card's VGA output. You could only do that if you could use the second computer's own acreen -- which would need another copy of FS running in that computer. Pete

I don't know. Does it interface to FS via FSUIPC? If so then it should work via WideFS, because WideFS is merely a Network extension of the FSUIPC interface. Regards Pete

Have you done any elementary checks? Does WideClient say it is connected (it its title bar)? Did you read the notes on configuring your network in the WideFS user guide, the section after the one about Installation? Are your PC in the same workgroup, or if not have you provided WideClient with the parameters telling it where the Server is and what protocol to use, just as instructed? There are Log files produced by FSUIPC, WideClient and WideServer. These are produced specifically to help you find out what is going on. Take a look. Show them to me if you don't understand what they are telling you. Additionally, in any query whatsoever I always need version numbers -- FSUIPC and WideFS. If not currently supported versions (see the Announcements) update first and re-test. File-sharing is irrelevant to FSUIPC and WideFS. That may be needed by PM, but not by anything of mine. No. Regards Pete

Glad it is all sorted out, and I think it was more a case of misunderstandings than lack of cooperation! Good flying! Pete