Pete Dowson

If you are assigning in FSX, then the cause will normally be your Sensitivity slider in FSX is not set to maximum (full right). If you assigned in FSUIPC instead then full thrust will always be obtained, otherwise you've not actually calibrated it. FSUIPC calibration is merely the spreading of whatever range of values it sees over the full range for FS (-16383 to +16383 for normal generic all engine throttle). FSUIPC4 recognises all 8 possible axes on any joystick type device which is recognised as such by Windows. Please update to the latest interim version, from the Updates announcement above. It may simply be that your joystick is timing out. The check was a bit too stringent in version 4.57. Regards Pete

Ah! Right. Good logic! I shall try something out hereOn my Development PC I have SP2 Simconnect working okay, but neither the Original nor the SP1 versions are functioning. This is on a Win7 64-bit system, and I've not been able to repair those so far, for some reason. I'll try removing the other files and re-running the appropriate SimConnect.msi files! Well, that's certainly some achievement. Well done! I wonder if that will stop other installers from installing SxS modules? Regards Pete

3.93 is out of date and unsupported. 3.96 is the earliest supported version, and there's a 3.971 available in the Updates announcement above. Operation of the auto-throttle cannot be affected by a real throttle axis unless there are inputs arriving from it. The only reason any inputs might arrive is if it jitters or is manually moved. If it suffers jitter then you need to calibrate with a more generous dead zone at both full throttle and idle ends of the movement, and make sure you park the throttle there when engaging A/T. Pete

Yes. There is a "toggle taxi lights" FS control. Can't you assign that in FS? You can in FSUIPC of course. But if you want an "on" and an "off" separately, you can use the FSUIPC added controls "Offset Word Setbits" and "Offset Word Clearbits" to set or clear the light switch in offset x0D0C. The taxi light switch is bit 3 (2^3), so you use a parameter of 8 (= 2 x 2 x 2 = 2^3). Regards Pete

As it says in the documentation, WideClient is an FS "eliminator". It runs INSTEAD of FS on client PCs so you can attach FSUIPC applications there. If FS is running, WideClient cannot be, and vice versa. How would applications know who to attach themselves to? Regards Pete

Sorry, I don't understand why it should need to recognise it "as a different card". You can have up to 16 joystick type devices. Provided it's ID number, assigned by windows, is within the first 16 then FSUIPC will see it. Can you explain what you mean by " fsuipc does not recognize that it's a different card"? It will only look to be the same as another if it has the same assigned ID. Regards Pete

I use the BGL updates for time zones which come with FSRealTime. But I don't know if they cope with the 30 minute zones. http://www.3dsoftworks.net/products/fsrealtime/ Regards Pete

I think if you thought about it a little more you would relise that you really answered it yourself -- in the second case, the "tonumber". In the line if whichradio==1 then the variable "whichradio" is a string -- ipc.ask returns a string, not a number. A string will never be equal to a number. You can USE a string as a number (Lua will automatically convert it for you), but comparisons don't do conversions. You have to compare like with like. You can either do something like if whichradio == "1" then or, probably safer if tonumber(whichradio) == 1 then http://www.amazon.co.uk/s/ref=nb_sb_nosua&x=0&y=0 The first two -- "Programming in Lua (2nd Edn)" and the Reference Manual are pretty essential. I haven't got the "Beginning..." one, but it doesn't look like its a "Dummies" type book judging by the synopsis! Regards Pete

IVAO uses FSInn plus another DLL I think, or Ivap. None of those use FSUIPC, and the internal DLLs won't have any different privilege to FS as they are inside it. Yes, if they are on different levels they cannot talk. Why are you running FS as administrator in any case? Regards Pete

So do you suppose, as I must from what you say, that this indicates some clash between SIOC/Opencockpits MCP, and the way IYP sends those commands? I'm not sure how that is causing FSUIPC to stop responding, but going on the assumption that the IYP commands are special for your PMDG aircraft (I think they issue mouse macros or similar, don't they?), then I would need more information to help track it down: 1. First see if you can make a complete list of the IYP commands which cause this trouble. You said: So, is it all commands which affect the cockpit switches? Or only specific ones? The autobrakes one shouldn't interect with the MCP at all as it is not related. 2. Update to the very latest FSUIPC3 version (3.971 is available in the Updates announcement). This is to ensure you have the same as I. 3. Then, before using a command you know will cause the problem, go into FSUIPC options and enable IPC write and Event logging (not axis events). Just the two checkboxes. Then cause the problem, and when it is obviously wrong, make a copy for me of the FSUIPC.LOG file. It would be best if you could do this with ONLY IYP and SIOC running -- none of the other FSUIPC applications, or it will get too complex to work out. Not even the WideFS connection. 4. ZIP the log and send it to me at petedowson@btconnect.com. Also, if there are any FSUIPC macro files (.mcro) in use for your PMDG aircraft, please include those in the ZIP. I might then ask you to do more specific logging when I know more. First we have to narrow it down to a particular combination of actions inside FS. Well, you might need to ask for more information on what SIOC does. I've no idea at all. Regards Pete

Which one is that? 3.96, 3.971, 4.57 or 4.587? Those are the current latest and supported versions. You need to be more specific please. If this is with FS9, is the a Modules menu entry with FSUIPC listed? If this is with FSX (you do really need to mention this sort of thing, please), is there an Add-Ons menu entry with FSUIPC listed? Are you running FS "as administrator" but not your program, or vice versa? Running things at different privilege levels prevents them talking to each other. Did you let FS install itself into Windows "Program Files"? If so, those folders are protected on Vista and Windows 7. Maybe the program you are running needs to access them? Does the documentation for the program say exactly what it means by "FSUIPC NOT FOUND"? Do the authors or publishers have a support site? Do you have any other programs using FSUIPC and working okay? Regards Pete

I can't imagine what is stopping the installer re-installing them. That is really most peculiar. The damned WinSxS system is so complicated and unforgiving I don't know if anyone understands it. The only thing I can think of it using the SimConnect.msi -- there will be three in the SP2/Acceleration SDK, one for the SP2 version, and two in other folders for the original and SP1 versions. They should install SimConnect and they are used for that purpose when installing on a Networked PC for communication to the FSX PC. If that fails then There's something wrong in the Windows installation which is stopping the folders being created -- probably the same thing which originally caused the problem by stopping them being correctly accessed. If you have a Restore Point saved in Windows, I would suggest rolling back to one before the tragedy began. I did once start digging into how all this stuff worked, with a view to writing a program to check everything and repair it where possible, but I didn't get very far. It becomes far too complicated very quickly. Whoever thought the system up should be hung drawn and quartered, or at least given a severe telling off, in my opinion! Final ides: I wonder if you can locate anyone from the FS team still around who can help? Tim Gregson sometimes makes an appearance. If he doesn't know, he will probably know someone who will. I saw a message from him over in the FSX Forum here just recently -- yes, "Beatle" in thread viewtopic.php?f=230&t=79293#p481910 Regards Pete

The format I produce is exactly to the AV400 specification I have. I am not in a position to compare a specific example to yours -- you omitted non-printable control characters in any case. You need to capture the actual frame, the whole of it, and show it in hexadecimal, or saved to a file and Zipped for me to look at. If you can do the same from GPSout and see what the differences are, I'll check to see if I can make those changes without affecting others. If you can't do that I'll see what I can do if you provide better information. Without any GPS devices here which can accept anything from GSPout I am dependent on feedback, and so far, for 12 years now, the AV400 format I provide has been accepted. I am therefore reluctant to change anything without knowing why and what, and I cannot do that with only the information you gave because that is only partial. I you need to send me anything do so to petedowson@btconnect.com. Regards Pete

Hmm. As mentioned there, that could be as problem. In fact I think maybe that procedure only works for the main FSX install / repair. And I cannot make it work at all on Windows 7 64-bit, so I think it best that I delete it altogether now. Sorry -- it was the fastest and easiest method originally and has helped many, but certainly Vista and Win7 present new problems in that area. It should be easier than that. Rename your current FSX folder to, say, "FSXorig". Then install a fresh copy, including all the updates, and after that rename the new folder to "FSX virgin" or similar, and rename the original one to what it now should be. I've done this several times. It is also worth keeping the new "virgin" installation so you can check things out or copy over good bits if anything bad happens to the other. Regards Pete

Sounds like the usual problem with a rogue joystick driver in your system. I fixed that by using a joystick timeout in the current versions -- it sounds like you are out of date. Please always make sure you are up to date before asking for problems to be solved because they often already have been. Current main version for FS2004 is 3.96, but after installing that please go and get the latest increment from the Updates announcement in this forum (3.972 at present). Click on the reload button in the Buttons tab. Regards Pete

I see. The Lua language I'm supporting for plug-ins is like that only more so. No declared types at all. But even I came unstuck in one piece of advice. I was thinking "C" style and told someone to do if ipc.testbutton(joy, btn) == 0 then ... completely forgetting that this function of mine returns a BOOLEAN which can only be true or false, not 0. If fact the only thing that's ever 0 is the number 0! Everything else is effectively non-zero in the sense that it isn't equal to it. There's even a nil value, which is simply the "value" something has when it doesn't have a value! That's not 0 either. ;-) Flexible? Yes, very. Confusing too at times though, you're right! ;-) Pete

Yes, that looks like AV400, except of course you don't show the unprintable STX character (x02) at the start and the ETX (x03) at the end. I think all the Garmin x96 units are confirmed working with GPSout's AV400, certainly the 296 and 496. Pete

Good, well done. You mean the SDK utilities? Just re-use the same DLL.XML, the one you posted here a few messages ago. Be sure to put that missing first line in, though! ;-) In the "True" lines? Yes -- if those entries are still there. Regards Pete

The easiest way would be to simply use a variable for the sleep: delay = 1000 --adjust first delay to taste repeat ipc.macro("PMDG 1900:Altimeter Inc") ipc.sleep(delay) delay = 100 -- adjust repeat to taste until not ipc.testbutton(joy, btn) Are you learning stuff this way? Time to try your next need yourself? ;-) Pete

Okay. Thanks for the heads up! Pete

That's probably only true for some values because your requests can't be serviced because FSUIPC isn't getting the access yet. If you moved to FSX that certainly wouldn't be the case. The proper way, used by my accessories for instance, is the 3364 offset, "ready to fly". 3365 is related. You should read them together as a 16bit word and assume "ready to fly" when both are zero. They will be non-zero as soon as you can read anything. Regards Pete

Do you mean the FSX default Airbus A321? If so, then I did add offsets for those EFIS functions which were accessible via L:vars -- see 0E00 - 0E1A. If the ones you want aren't there they aren't easily accessed. Generally speaking, default aircraft panels in FS have always had those EFIS functions local to the gauge -- except of course the "BARO" knob which does have an offset as it is the altimeter setting. The other functions control things peculiar only to the gauges being used so never get as far as the central simulator engine, which is where variables are accessible to programs like FSUIPC. The "L:var" fiddle is just that, a way of messing with a gauges internal values. sometimes that works, sometimes it doesn't. If you mean an add-on aircraft then I expect they too keep all that stuff internal, but there might be ways with mouse macro or, again, L:var programming. It depends entirely on how it is written. And of course it can get complicated -- take a look at some of the stickies above in this Forum for examples of work-arounds for an assortment of aircraft. If you aim to build a complete cockpit then eventually I think you are likely to decide on a package like that. Maybe Sim-Avionics or Flight Deck Software, or one which does simulate most of the subsystems and instrumentation more accurately and more amenably to hardware interfacing. However, you can do a lot without as others have shown. Regards Pete

Ah, never mind. I can send you the stuff in anycase. You can have some fun with it. Won't be till next week -- maybe over the weekend if I get time. Send me an email as per the stickie. Sorry, all that is way over my head, or someplace. I don't know anything about "key commands" with VRI. I'm reading and writing to the devices directly. No. That "bug" must be to do with SerialFP2 or one or other of the DLLs that uses. I'm not using any VRInsight software at all. Regards Pete

Oops! I forgot that "testbutton" returns a Lua BOOLEAN, either true or false. It is never 0 because it isn't a number in Lua (unlike in C which I normally use). Try until not ipc.testbutton(joy, btn) Regards Pete

No, that is the Installer log for version 4.30. Haven't you installed 4.57? It's the FSUIPC4 log you need to find. If there isn't one from the last run of FSX you did, then FSUIPC4 isn't loading. THEN I'd need to see the Installer log, but for 4.57 not 4.30. Okay, that's the FSUIPC4 log, but again it is for 4.30 not 4.57. Yes, that confirms it. Your SimConnect installation is corrupted somehow. You may need to uninstall Accelerator or SP2 (whichever you last installed) and re-install it. Hmmm. Something happened amongst that lot which messed SimConnect up somehow. It was the SP2 version of the SDK was it? You shouldn't use the original once you've updated FSX -- there are updates to the SDK matching each update to FSX. Regards Pete