Pete Dowson

Which CSV? There are several. And they are all formatted to meet the needs of specific programs, so I cannot change them. The R4 and R5 CSV files are clearly documented as containing the threshold offset value. Why are you choosing the file which doesn't? Pete

Sorry, no, I've not seen it, and I doubt if I'd recognise a panel in any case as I don't have many add-on aircraft or panels -- my cockpit is a fixed 737NG with no panels (I have real hardware ones and Project Magenta(. Regards Pete

Er, what "tools"? There are ways (and programs) which move the aircraft around in FS to correspond with an external input like position, effectively using FS only as a display system for an extenal simulation of some kind. If you feed a poisiton into FSUIPC it will move the aircraft in FS. But if FS is still simulating flight, it will change, of course. You need to keep feeding in information at something like the frame rate. You'd also need to feed in pitch, bank and heading to get the aircraft orientation correct. You don't need an external program to do that. A little Lua plug-in can do it, provided it has a way of getting your position and orientation information. Maybe you need to explain a bit more about what is is you want to achieve, as what you ask really makes little sense to me at present. Regards Pete

Does it work as a flaps axis without the detentes? If not, get that sorted first or there's no chance. All the detentes do is divide the range up into little sections, with the resulting output suiting the correct value in FS for that flap position. Check by using FSUIPC's axis event logging (Logging tab, left hand side). Neither FS nor FSUIPC obey any axis till it sees it changing. And how will you ever manage to keep a flap setting if it self-centers. Are you going to hold it in position all the time? A picture of the above three lines on page 44? No way. If you mean the example of using ranges for specific actions, then the example on that page is for a Gear lever, and it is all explained there, exactly how to do it. What is confusing you? Pete

Do you mean "mouse macro" creation mode? Does it only crash when doing tha? Earlier you said "whenever I attempt to allocate Button and Switches" I understood you tyo mean simply assigning buttons in the buttons tab. Is that not really so? It makes a lot of difference. The mouse macro creation facilty is a lot more complicated and might be influenced by the aircraft loaded. I'd need to check, but I could do with clarification first, please. Okay, checking that now ... ... Nothing wrong with the INI file. But I can't check with your "linda" or "NGX_AUTO" files. I see you have the latter loaded automatically when you load the PMDG737. Maybe it is something in that I used your INI and created a few mouse macros whilst in the PMDG 737NGX SP1c virual cockpit, and had no problems, and they all worked fine, so there's something different in what you are doing. Many others also seem to be using it successfully. So, I need to know every little detail of what you do to make the crash occur. I also need more details of the actual crash -- the data from the Windows error log in particular, please. Regards Pete

It's done that to try to rationalise an erroneous input. You missed the , between the first and second value in the FlapStarts, giving a number "-16384-16219". Try thid: FlapStarts=-16384,-16219,-15450,-12975,-6980,-573,4606,15600,16217 FlapEnds=-16256,-16200,-15417,-12950,-6950,-550,4644,15650,16384 Flaps=-16384,16384 FlapDetents=Yes

Well, that's really good then. :-) Regards Pete

Well that's perfectly understandable. Most folks would have wideClient starting the applications using the "Run" options in the INI. Again I am sure it is much more the norm to have all the clients waiting for FS to be ready than the other way around. I'm surprised that you always waited for FS in the first place! Thanks. I'll take a look tomorrow. It's getting late here now! [LATER] Just a quick comment, from the details above. The crash is actually occurring in DINPUT.DLL, which is the DirectInput part of Windows. WideClient will be using that to scan for buttons to be sent to FS. Could it be that you have some old or unwanted joystick driver on that PC? Try setting "ButtonScanInterval=0" in the [Config] section of the INI. That'll stop WideClient trying. If that stops the crash, then that is what it is. Do Phidgets boards look like a Direct Input device or have a Dinput driver, perhaps? Maybe there's a clash between WideClient's attempts to read things and FS2Phidget's, but when FS2Phidgets gets in first, as it would if you have it all waiting till FSX is started, the clash doesn't happen because FS2Phidgets has initialised things correctly? Regards Pete Regards Pete

That doesn't sound right!. No idea -- but how come it worked fine on your XP machine? I thought you'd eliminated possible hardware / connection problems that way? Maybe it's related to the voltage/power provided on the XP machines serial signals compared to those on the other ... but both the USB adapter AND the PCI card? Regards Pete

Were the files named something.lua? If so then each one of those will lhave added a number of files to each of the assignment drop-downs in FSUIPC: If the name was xxx.lua then you'll see: Lua xxx Luadebug xxx LuaKill xxx LuaClear xxx LuaSet xxx LuaToggle xxx LuaValue xxx You get all of those for every Lua type file placed in the FS Modules folder. you can't very well miss them, there will be so many! There's nothing else to it! Pete

Crashes in what? Your program or mine? I need more information. If in FS, the crash error code, the module and its offset. The whole point of a separate "Process" call to the "Read" and "Write" calls is for efficiency. The read/write calls simply add a request to a list, in your own memory. Aren't you using a development system with a debugger? If should tell you exactly where and why a crash is occurring. Regards Pete

Thanks! It is very encouraging to receive the occasional positive feedback message now and then! Best Regards Pete

Sorry, I'm a little confused. You say:the windows are "supposed to appear on one screen, and they always do", but then go on to say sometimes they don't? The default size, because you omitted it in the opening call, would probably be something like a quarter of the screen. It sounds like the "ext.position" call is being executed before the opening of the window has been completed, so it doesn't find it. Try inserting an "ipc.sleep(5)" after each wnd.open call, just to be sure. Or, alternatively, do all your wnd.opens then all the ext.positions. Ah, that's easy ... You have a line wnd.textcol(w2, 0x000) setting black when you set the background to green, but no equivalent wnd.textcol(w2, 0xfff) to set it white in the other case. Of course. Lua doesn't know or care where the text comes from or how it is generated. It just displays whatever string you provide. Luas variables can be strings or numbers, and Lua converts one to the other automatically. If the OAT is read into a variable "oat" that would simply be something like: wnd.text(w, "OAT " .. oat .. "C") depending on whether "oat" was read as an integer or a floating point value. If it was floating point the more accurately youd use the 2string.format2 function, str = string.format("OAT %2.0fC", oat + 0.5) wnd.text(w, str) I added 0.5 to round up when the temperature is x.5 or more. Regards Pete

I've seen reports elsewhere of problems with USB 3 and Saitek devices. Try a USB 2 or 1 port. Pete

No. Are you looking in the right place? It's part of the [JoystickCalibration] section , which will only be there if you've calibrated something. It's there so it can be different for different aircraft, and it is only operable for direct to calibration axes in any case. What could it be used for? It's an arbitration mechanism between two axes. Please read the boxed text on this in the User Guide. It explains it all there. FSUIPC cannot override FS assignments. It's one or the other. If you assign in both they will conflict. FSUIPC supports all possible FS axes and more than can be assigned in FSX in any case. What!??? That's bad. Please see if this happens with the latest version -- 4.81 or 4.811 (see Download Links subforum). If it still crashes I need more information. It sounds like a corrupted INI file, so I'd like to see that please. Pete

FSUIPC cannot "forget" axes. They simply send signals when they want to. FSUIPC has no control over that. If they stop responding -- i.e. stop sending messages -- then it is down to the hardware, the USB driver, or Windows turning off the power. All that visiting the options does is make FSUIPC rescan the USB devices for new connections. That makes the Windows USB drivers send out re-initialisation signals to the devices, which must be waking them up again. If your devices are going to sleep you either need better power for them or you must turn off Windows USB power management. If none of that helps you have faulty drivers or faulty hardware. The same would most certainly also occur with FS assigning, except in FS's case you've no option for re-scanning but have to reload FS! Regards Pete

Ooops! Sorry to have wasted your time. The Log line should be Log=Debugall I see there was a typo in my last reply. Your log is therefore no more useful than the last. Yes, please check the windows error log and find the WideClient crash. I need the error code and module offset address. Oh, and does the crash occur if you run the Phidgets program BEFORE FS is running -- i.e. before Wideclient is connected? Regards Pete

I suppose you could do that by assigning to View zoom set and using the axis scaling option in the INI assignment line. You'd need to work the latter out based on the range of inputs from the Axis, whch you will see in the assignments tab. For example, with an axis range of -16384 to +16383 (i.e. a "perfect" input range), I find good Zoom values are obtained by scaling of *0.01 (i.e divide by 100) and +164 (to make the minimum positive). On the axis assignment line in the FSUIPC INI file this looks like: 3=2Z,256,F,65701,0,0,0,*0.01,+163 Your axis might have a different range, and you might want the top Zoom value to be smaller or larger, so obviously you need to adjust the multiplier and adder accordingly. Regards Pete

Hmm. Very suspicious. Not surprising, as it most certainly sounds more hardware or driver related. Did you try on that older system with a USB adapter or your new PCI card? That might help determine where the problem lies, though of course the Windows 7 drivers will be different to the XP ones, especially if your Win 7 is 64-bit. So some output is getting there. Just not enough. I think to blank the displays only takes a couple of bytes or so. I don't think it is Windows 7. I have Win7 64-bit running on two separate systems, both with PFC stuff connected, including displays (a console with the stack built in), and never have any problems. I'm still betting it's bad drivers, especially for 64-bit Windows. The Brainboxes card was 50 UKP the first time I bought one. The last time it was over 60 UKP. A lot of difference to 8 bucks shipped! Yes, but I think the problem is drivers. Before giving up on the 8 bucks card, go online and see if you can find an updated driver -- 64-bit if that's what you are using for Win7 (which I assume, though you never stated so). Regards Pete

I could do with a fuller log from WideClient. Could you do this please: 1. Replace WideClient.exe with version 6.953, from the Download Links subforum -- so that we are both using the same version, and 2. Edit the WideClient.INI file, changing the Log option to "Log=DebugAll" in the [user] section, or add [user] Log=DebugAll if there's no [user] section at present. [CORRECTED from "DebgAll"] This will make quite a big log. If the same crash does not occur with this setting, try again changing the Log option to "Log=Yes" which will merely log whatever the FS2Phidget app is doing. For large logs, Zip them and send to me at petedowson@btconnect.comn. Otherwsie paste them here as before. When you run the FS2Phidgets program, does it get to do anything before the crash? Would I be able to reproduce it here with no Phidgets hardware? Regards Pete

Which SDK? The FSUIPC SDK? Same place as you download all the rest of my stuff, including FSUIPC. Where did you get that? There's the Schiratti site where it's been now for 12 years or more, and the Download Links subforum here. Pete

I have been visiting the support site and checking whether there's a reply yet regularly. I didn't know whether to expect an email or not. I have a short-cut taking me straight there, so I check it as often as i check my email. Still no joy. Regards Pete

I want to provide supporting offsets for at least a significant subset of the data available. I'm not sure if I'll do all of it, but hopefully all those entries which matter to a cockpit builder. Yes, I noticed. I need an answer from PMDG about my questions regarding the EULA first. Like Nico, I am greatly concerned over several of the clauses, especially the one which would appear to make me responsible for how the data is used -- even though i'm only providing a window onto it and am not the "End User" but a facilitator, just as the SDK is. I have no direct links with anyone at PMDG these days -- I used to have good relationships with Lefteris but of course he's no longer there. So all I could do is raise the question and request 'permission' through the ticket system, as it says to do in the EULA. That was Sunday morning. There's still no reply now. I've raised it on the NGX support forum too, asking someone from PMDG to email me. Again, nothing. All I can do is wait. :-( Once I am okay to go without fear of legal consequences it can be very quick indeed. The code for interfacing to SimConnect client Data is already implemented in FSUIPC4 in any case, as it's used for other things like the AES status and Squawkbox4 transponder modes. I would just need to work out the offset details and map the data. Maybe make some of them writeable as well, with FSUIPC operating the events, but that wouldn't be the first priority which is to get the data out. Regards Pete

Sounds exactly like you have the lever reversed! Maybe you are assigning in FS, reversing it there and in FSUIPC too? If so by reversing twice it is the wrong way round again, the two will obviously cancel. You are most certainly doing something wrong then. The spoiler in FSUIPC works perfectly if you do it right. I can't help you any more than I've done already. Don't test spoilers on the ground. Regards Pete

What value for the Throttle produces "reverse idle" as opposed to "idle"? I'm not familiar with such terms. If you want the reverse thrust value to decrease more quickly, either reduce the "sleep" value from 10 mSecs down to 5, say, or use two controls instead of one, i.e. ipc.control(65964) ipc.control(65964)[/CODE] Play with both methods till you get it right. If you want it to only increase to, say, -1024, check against that value instead of 0 in the line: [CODE]if throttle1 >= 0 then[/CODE] You'll need to have another loop, then, watching N1 instead of the Throttle setting. i.e, this added to the end: [CODE] while true do N1 = ipc.readSW(0x0898) if N1 <= X then break --exit when N1 slow enough end ipc.sleep(10) end ipc.control(65967) -- Throttle1 cut[/CODE] You'll need to replace X above with the correct value. N1 in FS ranges from 0 (0%) to 16384 (100%), so compute the figure you need. I thought I already told you the values to change for Engine 2? Yes, I did -- in the last line of post #2. Didn't you read that? The N1 for Engine 2 is at 0x0930. And you can surely look up the control number for Engine2 Cut yourself. i've gone further that I should in this matter. Normally I prefer to help folks help themselves. It is more constructive that way, and if they understand what they've done they can progress and do more, for themselves. I suggest you try to understand what is going on with these simple examples, and arm yourself with the Offsets list and the Controls list, and the Lua documentation, for future use. You'll find the Offsets lists in the FSUIPC SDK. They'll show you where I got values 088C, 0924 etcera from -- I don't remember all this stuff, I have to look it up just as you would. Regards Pete