Pete Dowson

The picture you showed does not relate to installing FS9 at all. Pete

Just make the same assignment twice in the INI file. FSUIPC will process all assignments to a button, all the press assignments when pressed, all the release assignments when released, so you want a total of 4 assignments to each, 2 press, 2 release. You can only do that in the INI file. it really isn't worth testing on a system giving only 10 fps. You'll probably have to readjust things afterwards. Well done. I was about to go solo in preparation for my eagerly anticipated PPL when I failed to get a medical certificate -- that's when I discovered I had Retinitis Pigmentosa, which a few years later also meant i wasn't allowed to drive a car either. Hence my deeper involvement with simulators. Regards Pete

I don't think you tried very hard. ;-) I just tried View1 mode set with parameter 5, and that works for what you want. Different parameters give different views. Regards Pete

I don't know offhand, but to find out what control FS itself sends when you press an assigned key or click a control with a mouse, enable Event logging in FSUIPC, use the control, then check the Log entry. Pete

The explanation is simple The format for the offset is either x then the hex value, or a decimal value instead. Because you preceded the value with 0 that is the value seen. Please do check the documentation more carefully. FSUIPC uses a simply x prefix for hexadecimal to make it easier for users, rather than the 0x used only in C/C++ where the 0 is needed to distinguish it as a number rather than a name (In VB a $ prefix is used because it doesn't allow $ for names) Note that 100/950 for the IAS will only allow you to set 0, 100, 200 , 300 ... 900 knots, which seems a little strange. I can understand an increment of 1 or 5, but 100? Regards Pete

Okay ... turned out to be real easy. I'm adding these new controls: Offset dword cyclic increment Offset dword cyclic decrement Offset udword increment Offset udword decrement Offset sdword increment Offset sdword decrement However, since there's only 16 bits each available for the increment value and the limit, the only use of the high 16-bits is to ensure it is zero (for positive numbers) or all ones (for negative numbers). So the range of numbers remains -32768 to +32767 for signed and 0 to 65535 for unsigned. This change will be in updates I hope to post later (Monday), versions 4.749 and 3.998k Regards Pete

No, that would make no sense at all. You are entering something incorrectly. Tell me exactly what you are entering in each place. Pete

The upper word could be set to zero by an Offset Word Set for the offset+2 with a zero paramter, assigned also to the same button value. That would mean editing the FSUIPC INI file to add a second assignment, but it is easy enough really. However: That's a bit of a shame as FSUIPC doesn't currently have 32-bit offset controls other than those for 32-bit Floats. There hasn't been a call for such till now. I'll take a look at my code. If it's reasonably easy to add more offset controls I will do so, but I need to take care as all the add-on controls are encoded in 32-bits with bit-fields including 16 bits for the offset (all to fit in with the wParam, lParam provisions of the Windows message system). Regards Pete

Sorry, I am not clear about what you mean by "no longer there"? Do yuo mean you entered the details then exited the options dialogue, then went back and ... what, truned the rotaries again? If you Cancel the assignments rather that press "OK" to confirm, then they certainly won't be saved. Pressing ESCape is the same as cancelling. Not sure why you want '4' as the parameter. That would be the increment or decrement you want it to use. 4 is an unusual value for that -- folks usually want increments of 1 or 10, for instance. And you should to provide the limit value as well. Please do read this up in the User Guide. It's explained in a special boxed section in the Buttons chapter, about age 31 or so Search for "Offset Increment/Decrement Controls". Regards Pete

Well of course it is all simulation, but i know what you mean. There is probably a way of telling one from the other, as I doubt that the recording and replay actually records and replays every single thing. But I'm afraid I don't know what the tell-tale item might be. It could be worth a look, possibly monitoring things with FSInterrogate. If you do find it, please do let me know and I'll document it. Regards Pete

Ah, I see. Actually it was originally the other way around -- the very first version of "wideFS" was piggy-backed onto Wideview's communications protocol and didn't have one of its own. that was back in FS95/98 days! ;-) BTW, as answered earlier in this thread, it is actually possible to run WideClient alongside FS, and/or in fact run it multiple times on the same PC. That's done by using the "ClassInstance" parameter, but it renders the different instances invisible to FSUIPC Clients looking for the normal FS classname. However, it is useful if you want to use the Button Screen option on the same PC as FS, or, as in my case, several different buttons screens on the same client PC. Since WideClient also supports almost all of the same Lua plug-in facilities as FSUIPC, it is also useful if you want to run such plug-ins on a separate PC. Regards Pete

Yes, of course. WideClient is used on a PC which is NOT running FS. It pretends to be FS with FSUIPC inside so that FSUIPC applications which are NOT running on the FS PC can still talk to FS. Why on Earth do you want to run applications for the FS running on one PC on a machine running another separate copy of FS? It makes no sense at all! Please read the user guide to WideFS. I rather get the feeling you don't know what it is for. Regards Pete

You forgot to mention the FS version, but In FSX, ESP and Prepar3D I don't know how to implement those. They were implemented in earlier versions, and were on Microsoft's list of things to add in SimConnect updates ... Pete

Sorry, you give little or confusing information. You have a Server and Client install of FS? What are you trying to do with the two? What version of FSUIPC are you talking about (I need the version number). And what is "FSUIPC Co pilot"? If in your thread title you mean "Windows 98" by the cryptic "W98" then I honestly think you're asking a little too much of a modern version of FSUIPC, developed five or six years after Windows 98 and in the age of 32-bit operating systems like Windows XP, to work under such an operating system. If that's what you did mean then I suggest you upgrade to XP at least, or skip XP and Vista and go direct to Windows 7. Regards Pete

Most of the times this sort of thing has been reported it has turned out to be either the use of a self-discovered but undocumented offset, which has subsequently come into different use, or, much more likely, the addressing of a 1 or 2-byte long offset as a 2 or 4 byte value, where the bytes beyond were not previously assigned but then have become so. Check the offsets you are using. Use FSUIPC logging. But please test with the current version, 4,745 or later, as FSUIPC has been developed a lot over these last seven months. Regards Pete

Ah, sorry -- I am one out. 64122 and 64104. It's my eyes you know! ;-). Until i get to document these, they are 64100 plus the position in the FSUIPC options Calibration tab, counting 1 top left first page, 2 bottom left, 3 top right, 4 bottom left, then from 5 the next page, and so on. Pete

No idea, but when I have issues of software behaving differently from time ot time with no changes made, it lways turns out to be hardware. If not disk or memory then motherboard or heat or power. No, nor can I. Regards Pete

Do NOT test spoilers when on the ground. With FS that's normal behaviour. If the NGX is different it might be because it is a completely different animal and you'll need to work out how to handle that specifically. It may not even use the normal spoiler controls. If you want to try using "send direct to fsuipc calibration" then, instead of sending the FS spoiler control, send the FSUIPC direct one, which is 64122. (I must remember to document the direct FSUIPC axis controls. Apologies). The throttle ones are 64104 (generic throttle), 64109-64112 for throttles 1-4. [Numbers corrected later] BTW in this: ipc.set("ThrottleLastSet", ipc.elapsedtime()) ThrottleInputValue=ipc.axis("T", "Y") ipc.control(65765, ThrottleInputValue)[/CODE] instead of re-reading the axis value using ipc.axis you could just use the value supplied to you in ipcPARAM. That's what it is for. Same applies to the Spoiler one. Regards Pete

Er ... I kept asking you to confirm whether by a "turn" you actually meant a 360 degree twist of the knob or not. All of the rotary encoders I've ever used make a little 'click' (either audible or feelable or both) when turned a little, and each click either makes the contact (press) or unmakes it (release). One 360 degree turn may generate 10 - 30 clicks. The ones used on GoFlight devices generate about 24 per full 360 degree turn. I now cannot answer this until you explain your "turn". At 10 fps you'd need a pulse width of over 100 mSecs, obviously. (1000 msecs / 10 frames = 100 mSecs per frame). Pete

I never questioned the amount of memory, only it's reliability. It's got to be either memory, hard disk, or something in between which is mucking you up. How do you know? Strange that. Never mind. It isn't important, just misleading. I repeat this. if there is no log then FSUIPC has never been run, therefore there is no way you can tell whether it is registered or not. Regards Pete

So now it is down to 3, which sounds reasonable for 1/2 degree per click. If the computer had nothing else to do but what the inputs it might not miss any at all, but we are talking about an ordinary user-level program sharing resources with a flight simluator which has other things to do as well. If you are fussy enough to demand one click per increment or decrement, and never more or less, you need to have a kernel-mode driver. Can you explain why this is a "problem"? Assuming there is nothing else for FS and FSUIPC to do, so it could actually certainly always read the USB status every 15 mSecs, then the pulse width (both high and low states) would need to be more than that to guarantee never to miss one. However, because quite often FSUIPC (or even FS) won't have the processor at the time, the only guarantee of never ever missing is N mSecs pulse width, where N is unknown but certainly pretty big. Possibly you could use your FS frame rate as a guide. If you are getting 100 fps all the time in FS then FSUIPC should theoretically have time to scan everything once every 15 mSecs. as specified. If a more usual 25 fps is the norm then maybe there will be some intervals of 40 mSecs or more when FSUIPC cannot deal with the change. The actual scanning is actually in a higher priority thread. That isn't the problem, it is the sending of the resulting command to FS. That can't be done at anything faster than the frame rate. And FSUIPC will NOT queue these up, one per click, because 99% of folks use rotaries with visual feedback -- i.e. they read the dials as they are turning the knobs. That's normal practice, so I'm not sure why you are counting clicks instead. If FSUIPC queued pulses and sent batches of commands to FS, the feedback would be wrecked, folks would over-adjust and have to adjust back, and so on. Yes, 0 is a special case meaning don't read any buttons at all. Regards Pete

All the permissable syntax formats are documented, so you must assume that anything not included is ... not included. I can't very well list every possible syntax which is not implemented, now, can I? ;-) . Debugger? That doesn't do any syntax checking, it is only a line execution tracing facility. The above syntax should give an error when the event occurs saying it cannot locate the function denoted by "2". The excess parameter "xxx" would be ignored. Lua in general doesn't care how many parameters you give, it just passes them on and lets the receiver use them if it wants to. No and no. First bit from least significant end is bit 0 which has a value of 1 in masks. Number 2 is twice 1 so it's the next bit up, bit 1. Bit numbers and values are simply related by powers of 2, so 2^N is the value of bit N. Same as in decimal, decimal digit 2 is worth 10^2 or 100 (count 1 as bit 0, 10 as bit 1, etc). Please see the FAQ thread on bits and numbers. Anyway, to do what you want to do you have to use event.offset(0x5646, "UB", "xxx") then in function xxx(offs, val) test your bit using if logic.And(val, mask) ~= 0 then ... end where mask is your bit value, 1 for bit 0 or whatever. If you just want to know when it changes oldval = -1 function xxx(off, val) newval = logic.And(val, mask) if newval ~= oldval then ... oldval = newval end end [/CODE] Regards Pete

But you set it to 25 mSecs, which is the default value in any case, so why add it? I have no idea what units FS does its Gyro Drift inc/dec in. Never used it (I fly airliners) -- so what happens to the dial with one use of the control? Internally the gyro drift amount is in 1/65536ths of a degree, so it certainly can't be one of those or it would take you forever to adjust by one degree. But equally it may not be a whole degree in any case. It might be a half? Sorry, I've no idea what all the latter stuff means. You need to talk to Leo about that sort of thing. But when you say "5 times" do you mean 5 x 360 degree turns, or 5 "clicks"? Does it click? I see you haven't even bothered to assign the button releases to the same controls, as I suggested, so it would take at least two clicks in any case. Pete

As Ian says, with different profiles for different aircraft types you can have assignments and calibrations made in FSUIPC switched according to what aircraft you have loaded at the time. In general that's the cleanest way. Alternatively, since both FS and FSUIPC only react to an axis control when the value it is sending changes what FS should be doing, in general for well-behaved controls, there should be no interference unless you move them intentionally. In your case it sounds like the Saitek yoke is jittery and not stable when left alone. A lot of folks have mentioned this. If you are calibrating in FSUIPC one trick is to simply declare a wider central "null" zone so that minor jitters are ignored when the yoke is left centred. Another technique is to assign both sets of controls directly in FSUIPC, using "direct to FSUIPC calibration" for both. Calibrate them in FSUIPC -- you might need to compromise a bit if their inputs are slightly different in range. Then FSUIPC will arbitrate between them, taking the one with the largest deflection as the active one. That way you can change over at any time. This method is really mainly of use in a dual cockpit situation with identical controls for pilot and copilot. It wouldn't work so well if the control inputs are wildly mismatching as the single calibration wouldn't suit both. Remember to disable the controllers in FS itself if assigning in FSUIPC. Having them assigned in both places will be pretty disastrous. Regards Pete

The text on the Schiratti site simply hasn't been updated yet. The download is 4.745 I think. It isn't my site so I don't have control. The best way always to find the very latest stuff and lots of other goodies is the Download Links subforum here. That's under my control and I post there frequently. As well as the 4.745 installer there's a separate update 4.747 for those already with 4.7xx installed. Regards Pete