Pete Dowson

Yes, if it is is a toggle switch you are using, then of course you don't want the keys held down. If they are held down all the time the toggle is in a specific position, the Shift and the A will be pressed down all that time. So no other use of A will work and nothing can be sent unshifted. Furthermore, when you switch the toggle the other way nothing will really happen since the keys are already held down. They will hjust release but the aircraft will not receive a new press -- how can it, there's no new press! Regards Pete

You need to have it checked to stop it holding. As it says, in fact. It was checked on okay in your previous logs, but the log with 2 tries you asked me to check most certainly had it on. It doesn't make sense to me to have it held -- though perhaps if you explained what you want this button or switch to do I'd understand better. First is it a button or an on/off toggle switch? What do you actually want it to do for you? Do you mean the start levers, the ones on the 737 just this side of the throttle levers? So you've programmed the same keystroke to toggle between "cutoff" and "idle"? In that case you certainly do NOT want it held so you need the option to not hold it checked. You just want one keypress to set it one way and another to set it the other way. If you are using a press-button then you should only program the press, so the same button does both. If you are using a toggle switch then you program it as you did in the earlier logs and as not as you just showed in the picture. I've not yet seen a complete log with it done properly and without the '@ keypress getting in the way. Regards Pete

Why isn't your code valid any more? If it wasn't valid it wouldn't matter if you hadn't deleted it, it still wouldn't have worked. Have you been distributing the code to others, so causing SimMarket to revoke your license? If so you have to buy another if they haven't blacklisted you. Regards Pete

That was the release candidate for 4.70 and is identical in all but number. No idea why. That forces FSUIPC to supply weather to RC from ASE in all ASE modes, not just DWC modes. I did see one such recommendation and questioned it then. Strange how some folks want to do things. Isn't it generally available yet? Perhaps Damian is still waiting for feedback from the RC users -- this is discussed on the RC Forum and I'm sure the link was published there to get the fixed version for folks to try. Go to the RC Forum and do a search on "B646". I'm sure it'll find it. Better also ask at HiFi Sims why it isn't released yet. Maybe Damian forgot or has gone on holiday? You can but there's no point. They are identical, just a re-build for release. Pete

Instead of looking at the logs of keys being pressed, I'm looking at something very stange in the way you are programming your switch or button: These lines 193519 [buttons.iFly 737-800 Air Berlin (Normal screen)] 33=H1,23,K65,9 193519 [buttons.iFly 737-800 Air Berlin (Normal screen)] 37=U1,23,K65,9 show that you are telling FSUIPC to hold the keys down (H) when the button is pressed or the switch is on. Why? It won't release the keys pressed until you release the button, and if it is a toggle switch that could be a looooonnnnggg time, could it not? Worse, you've also programmed it to press Shift+A again when the button or switch is released or off. Why? If the keys have been held down till then, as they will have been, what do you think that does? sorry if i missed these points before, but we were concentrating on the resulting keys. I hadn't realised you were doing odd experimental things with the programming! [LATER] Ah, I just looked at your earlier log, and you weren't doing such a strange thing then. Look: 3981271 [buttons.iFly 737-800 Air Berlin (Normal screen)] 33=P1,23,K65,9 3981271 [buttons.iFly 737-800 Air Berlin (Normal screen)] 37=U1,23,K65,9 which is okay -- sending Shift+A once when pressed, once when released. Why did you change it? If you want it held you shouldn't really try to send another keypress on release. That makes no sense. Regards Pete

Sorry, but this is rather misleading and inaccurate. I can find no such problem here. I've just reconnected my MESM to check. With both 4.70 and 3.99 and the latest GFDev.DLL, LEFT GND = 166 button 0 released LEFT OFF = 166 button 0 pressed LEFT CONT = 166 button 1 pressed LEFT FLT = 166 button 2 pressed Similarly RIGHT settings are 5 released, 5 pressed, 6 pressed, 7 pressed. I think what is confusing you is that FSUIPC's buttons programming page only reacts to an "off" to "on" change -- i.e. the "press". But the "on" to "off" change is also programmable there -- it is the part below where you say what to do on "release". So all positions are programmable directly in FSUIPC as supplied. The switch is like an on-off switch but with one "off" position and 3 "on" positions, but all are equally detectable. Of course, FSUIPC only reacts to CHANGES, so it won't see a static switch position. You can deal with that in a Lua program, of course. Regards Pete

There's no change in any area related to weather in FSUIPC 4.70 specifically -- the changes for ASE DWC mode went in a while ago. I can't tell from what you say whether you were already using the new ASE-derived weather for RC or not. If not then possibly you are seeing some problem with ASE's new facilities to provide proper local METAR's when using global weather (i.e. its DWC facilities). I think they were wrong until the updated build B646. If you don't want RC to read the specific local weather from ASE, set or add UseASEWeather=No into fSUIPC4.INI [General] section before loading FSX. By default FSUIPC4 only gets the weather data direct from ASE when the latter is setting FSX into global weather mode. This is to overcome the incorrect weather reported otherwise. DWC mode makes the weather the same all over the world. However, none of this can possibly affect the actual weather in FSX. Your "strange (too high) winds aloft" (huh?) and "in ASE program screen it says -50C but in FSX I'm getting -20C ... the other day it just stayed at +21C even at flight level" cannot be anything to do with FSUIPC whatsoever as it doesn't have any control over the weather if you are using ASE. Only ASE has any say in what FSX is doing in those areas. Regards Pete

Okay. Found a bit of time so knocked this up. I've put in a load of comments (something I never do for my own code! ;-) ), because I want you to read it and hopefully understand it. Then you can extend it or alter it to your specific needs - eg add more rotaries or whatever. Save the whole lot as "ipcReady.lua" into your FS modules folder. Vendor = "Bodnar" Product = "BU0836X" Device = 0 -- Multiple devices of the same name need increasing Device numbers. cwise = 31 --Button number for clockwise turn ccwise = 30 --Button number for counter-clockwise turn dev, rd, wrf, wr, init = com.openhid(Vendor, Product, Device, Report) if dev == 0 then ipc.log("Could not open HID") ipc.exit() end -- Set the boundary time in milliseconds between -- "fast" (shorter) and "slow" (longer) signalling FastTimeLimit = 60 -- Adjust to taste -- Polling time in milliseconds: should be much shorter than -- the boundary time Pollrate = 20 -- same as 50 times per second -- Initialise variables used to keep track of things LastTimecwise = 0 LastTimeccwise = 0 Lastcwise = false Lastccwise = false -- This function will be called by a time event, set at the end of the program before exit. function poll(Time) -- read any data available from the device (only need most recent report) data, n = com.readlast(dev, rd) if n ~= 0 then -- Data was returns, so get the status of two two "buttons" we are using Thiscwise = com.TestHidButton(dev, cwise, data) Thisccwise = com.TestHidButton(dev, ccwise, data) -- See if they've changed since last time if Thiscwise ~= Lastcwise then -- Clockwise button changed -- See if changed in less than the "boundary" time fast = 0 if (Time - LastTimecwise) < FastTimeLimit then fast = 1 end LastTimecwise = Time -- Toggle a virtual button accordingly ipc.togglebitsUB(0x3340, 1 + fast) -- Joy 64, Buttons 0 (slow) or 1 (fast) end -- Same for counter-clockwise if Thisccwise ~= Lastccwise then -- Clockwise button changed -- See if changed in less than the "boundary" time fast = 0 if (Time - LastTimeccwise) < FastTimeLimit then fast = 4 end LastTimeccwise = Time -- Toggle a virtual button accordingly ipc.togglebitsUD(0x3340, 4 + fast) -- Joy 64, Buttons 2 (slow) or 3 (fast) end end end event.timer(Pollrate, "poll") This assumes the "buttons" are 30 and 31 as shown in the log you submitted. The parts you'll probably want to adjust to achieve decent results are: FastTimeLimit: this determines the time between button changes (there are two for each of your "clicks") below which the turn should be considered "fast". Pollrate sets the interval between the checks into the state of the buttons. It needs to be a lot shorter (i.e. faster) than the "fast time", but not so fast that it affects the performance of your FS. The "togglebits" functions do the job of toggling "virtual buttons" in FSUIPC, which can be assigned in its Buttons tab. Offset 3340 has 32 such buttons. I'm toggling button 0 for clockwise, 1 for fast clockwise, 2 for counter cw, 3 for fast ccw. In FSUIPC's buttons dialogue you'll probably see the buttons 30 and 31 first, on whatever joystick the card is on, then you should get the joystick 64 buttons -- that's these. Ask questions about anything you don't understand. I might move much of this thread over to "User Contributions" sub-forum when we're done so it remains in view for others. Regards Pete

I don't think that has anything to do with it. It occurs simply if Actigate is loaded, which it will if it is in the Modules folder. I suspect it is to do with the way it adds and checks its own menu entry. First just try removing Actigate from the modules folder before running FS. I'm pretty sure that'll be the issue. It has all the signs. There's no code in FSUIPC which can possibly stop the standard Windows dialogue drawing routines in mid-track as shown in the picture (FSUIPC just defines the pictures, it doesn't draw them at all). The hang is occurring in other code, and Actigate is certainly the prime suspect. Regards Pete

No, it can't do that. That's not a fake layer, that, as it clearly says, is merely the upper altitude of the reduced visibility. Before Active Sky and its fancy facilities the visibility being set often applied all the way up. This FSUIPC facility enforced an upper altitude, that's all. A lot of folks found the effect noticeably odd, especially around hills, where the fog runs to a sharp delineated edge where the hills appear out of it. I think this only applied to pretty dense layers, but I have difficulty remembering as I've not used FS9 for over 6 years now, and my little gray cells are fading away with age. Maybe asking around in the FS2004 Forum will elicit some advice. But i think that was added as the solution. Regards Pete

Yes. It's one of the benefits. ;-) Regards Pete

As with all purchases on SimMarket, all your codes and details are available at all times in your account there. Just log on and look at your products. Regards Pete

The word "sensitive" is ambiguous. Do you mean that the aircraft reacts excessively with small movements of the controls, or that you need to move the controls too much before the aircraft reacts? For the former you really only want the slower reactions near the centre, the area of normal flight, so a flatter center slope is best. But when using that don't make the centre null zone too wide or you lose the advantage. The centre null zone should only be wide enough to ensure you always get the zero output whenever you let go of the controls. If you mean the latter then you either want the linear (no slopes option) reaction, or an even steeper slope, but this is unusual. It would usually only apply to stunt aircraft and jet fighters which certainly do have a hair-trigger control system. That's a problem with FS. I'm afraid FSUIPC cannot fix that. I think Active Sky does offer a method of overcoming it by using a thin cloud layer. Have you checked? It certainly cannot be done with visibility settings. Regards Pete

This can only be one of two things, really. either a joystick driver is hanging, or, if it only ever happens in the dialogue, it could be interaction with another FS add-in (like actigate.dll -- an older version of that could quite often cause hangs in dialogues. I never knew why, but the author did fix it eventually). So, please check what other add-ins you have, especially other non-FS DLLs in the Modules folder. Make a list and test without each one in turn. Regards Pete

Something is faulty then. either the USB port you are using is bad, or the cables, or the devices themselves. I don't think software can be responsible for such behaviour. If you are using a USB hub, try bypassing that and going straight into the PC. If you've already tried that try a different port. If windows doesn't see them consistently in Game Controllers, and FSX cannot see them consistently, then neither will FSUIPC. They all use the same Windows interface. If you want to uninstall whatever Saitek software you did install you only need to go to the Windows control panel, find "Add and remove programs" or "programs and features", find the Saitek stuff in the list, right click it and select uninstall. Even with it uninstalled, FSX should still see them, as they are standard joystick devices. I think you should be talking to Saitek. Regards Pete

Hmm. strange. That would suggest 59 degrees. Maybe the chap who supplied the information for FS9 got it wrong, or maybe it's being modified for the gauge for some reason. Have you checked that it is the same for all aircraft? Well your test is for > not >= so the value read would need to be 6924 or more, wouldn't it. Haven't you tried logging in your program at all? I can't really debug your program from here. Logging is a very valuable debugging tool. [LATER] I've just been monitoring, on screen, the value of 08B8, with the default FS9 737. comparing the crude analogue gauge with the offset value isn't accurate, but as I left the thing running and watched the oil temperature rise, when the needle passed the 50 C marker on the gauge the offset correctly read about 5800. So at least for default jets it seems good. So i loaded the default Cessna. Its oil temp gauge reads Fahrenheit. At the 150 F mark the readout in the offset was around 7800, which is 65 C or 151 F, so that seems good too. If you aren't getting matching results with an add-on aircraft it maybe that their gauge isn't showing the actual FS value, but some 2fiddled" value to approximate more to realistic values according to the way the aircraft has been written. If I were you I'd always test things first with default aircraft. Regards Pete

Looks like 4 clicks counter-clockwise, actually. Yes and yes, thank you. However, on my return I find my development PC is playing up a bit so I'm going to be a bit delayed. I'll try and show you a solution before the end of the week, though. Regards Pete

as the log showed quite clearly, the Shift key is released immediately after the A key. Why do you think otherwise? Where is the log showing this? If this happened then many thousands of users would be reporting problems, including myself! So far it is looking like a problem of the aircraft. But show me a log without you pressing the '@ key in the middle! Pete

Where did you log that? If in your program, not in FSUIPC, then did you correct your program and read the Oil Temp INSIDE the loop? Remember, I said: If you haven't fixed this it will of course never change in your program. Pete

Why not use logging to see what values you are getting? Maybe the aircraft you are using doesn't update this value. Add the offset to the Monitor in FSUIPC's logging, and do ipc.log(OilTemp1) or something more sophisticated if you like, in your program. Logging is really the only way to see what is going on. [LATER] Oh, one thing wrong, at least in that latest version you showed: You only read the offset once, then go around a loop forever checking the same initial value. If the Oiltemp is over 80 when you START the program, it will work, but then it'll never change again. was your original program like that too? I didn't notice. Pete

I'm trying to envisage from this what it is you are actually doing, and I'm not succeeding. Are you saying that it's slowing down to a stop whilst in the dialogue, programming lots of things without ever pressing OK to exit? I have never heard of anything like this at all. I really have no idea what is going on in your system. If you could say, step by step, what it is you do to create the problem, then maybe I'd have a better idea. Regards Pete

It looks fine. Here's where it sees your button being Pressed: 3981271 Button changed: bRef=0, Joy=1, Btn=23, Pressed 3981271 [buttons.iFly 737-800 Air Berlin (Normal screen)] 33=P1,23,K65,9 3981271 SendKeyToFS(00040041=[shft+A], KEYDOWN) ctr=0 which it correctly interprets as a request to send Shift+A. Then here's the Shift being pressed: 3981271 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 3981271 [buttons.iFly 737-800 Air Berlin (Normal screen)] 37=U1,23,K65,9 3981271 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 3981271 .. Key not programmed -- passed on to FS and then the A: 3981318 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 3981318 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=1 3981318 .. Key not programmed -- passed on to FS then 3 seconds later (because the button was still down I assume?) the KEYUP signals for first the A then the Shift: 3984906 SendKeyToFS(00040041=[shft+A], KEYUP) ctr=0 3984906 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1 3984906 KEYUP: VK=65, Waiting=0 3984952 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=1 3984952 KEYUP: VK=16, Waiting=0 That is all correct. Here, another 2 seconds later is where you released or turned off the button: 3986934 Button changed: bRef=0, Joy=1, Btn=23, Released 3986934 [buttons.iFly 737-800 Air Berlin (Normal screen)] 33=P1,23,K65,9 3986934 [buttons.iFly 737-800 Air Berlin (Normal screen)] 37=U1,23,K65,9 3986934 SendKeyToFS(00040041=[shft+A], KEYDOWN) ctr=0 and again the same sequence, exactly (to start with), is sent: 3986934 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 3986934 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 3986934 .. Key not programmed -- passed on to FS 3986996 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1 3986996 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=1 3986996 .. Key not programmed -- passed on to FS BUT before it was completed with the KEYUPs, you or something else (not FSUIPC) is sending another keyprress twice -- for 192, which is the '@ key on my keyboard (ma be different in non-UK keyboards). This is arriving within 250 mSecs of you operating the "off" toggle of that switch, so if you didn't touch the keyboard yourself it sounds like you have some other software acting for your joystick switches/buttons. 3987199 KEYDOWN: VK=192, Waiting=0, Repeat=N, Shifts=1 3987199 .. Key not programmed -- passed on to FS 3987339 KEYUP: VK=192, Waiting=0 3988104 KEYDOWN: VK=192, Waiting=0, Repeat=N, Shifts=1 3988104 .. Key not programmed -- passed on to FS 3988213 KEYUP: VK=192, Waiting=0 Whatever's doing it is sending it twice in quick succession. I think that key is normally associated with the ATC window -- to call it and close it. This interference in the keyboard sequence is causing the previous pressed Shift+A to be never released -- I guess the Windows routine discarded it when it saw the interfering key presses. Check with a different aircraft loaded, like a default. That should tell you whether it is related to the aircraft or something else, something processing your buttons in parallel with FSUIPC. Regards Pete

Well, if FSUIPC is programmed to send Shift+A when you switch the toggle on and also when you switch it off, it will be doing so. You need to find out why that iFly aircraft doesn't recognise two separate identical key presses. FSUIPC doesn't care how many times you press and release a button, if it sees it being so operated it will do what you ask every single time. Just to check you could try programming a different keypress of the release. Then, if the aircraft sees each press (or toggle on) you know that it is the aircraft which is in error. If you still have to press another button first, instead, then you know there is something wrong with the joystick or its driver. Also you can check things using the logging facilities in FSUIPC. Enable Button/key logging, the press / release the button or operate the toggle and you will see what happens in the FSUIPC log file. Regards Pete

Well, the first step is to say what you are doing. Is this key press programming or joystick button programming. What are you assigning to? Basic information like that is missing. Er, now I am really confused! WHAT "command" are you sending? How are "joystick" and Shift+A related? Where does Word come into this? Sorry, you need to tell me what you are actually doing. If you are pressing a joystick button, tell me that. Then tell me how you programmed it in FSUIPC, if that is actually what you are doing. Or tell me what keys on the keyboard you are pressing and how you programmed those. So, what is Shift+A supposed to do? If you have set up a button to act like a toggle, then when you press it it either goes off to on, or on to off (unlike a button which goes off-on-off with one press). If you've only programmed FSUIPC to do anything when it is pressed, then obviously it will only do it on every alternate pressing. If you want to use a toggle like a normal button you have to program the press and the release, of course. Regards Pete

I'm afraid version 3.44 is many years out of date and completely unsupportable. If iFly actually use FSUIPC I wouldn't be surprised if that wasn't the problem. The oldest supportable version is 3.99. Regards Pete