Pete Dowson

FSUIPC Version 4.57 is to old and cannot be supported. Please update to a supported version, 4.60 at the earliest. Regards Pete

I have no problem with a system using WinXP and a Matrox TripleHead. But I think the triple-head effectively fools the system into believing there's only one screen, so that probably stops FS creating this "Device Window" which defeats my interception. Or, just possibly, it's a difference between WinXP and Vista/Win7. Regards Pete

This means there is nothing arriving to FSUIPC via DirectInput for the affected switches. It doesn't sound like anything directly to do with USB or DirectInput, or at least the small FSUIPC use of it, because you said the lever buttons and lervers are still responsive. Phew! That is complex. It really sounds as if something in the way the LevelD is using DirectX (or causing FSX to use DirectX) is corrupting DirectInput information too. Since I assume the LevelD usage, via FSX, would only be Direct3D / DirectOutput, I wonder if something is picking out a bug in the video drivers themselves. It could be worth trying different video drivers. I know it sounds odd, but evidently one thing is affecting another apparently unrelated thing. Additionally, if it were a general fault in any of the parts which must surely be common to many LevelD users (Saitek quadrant, FSUIPC4, FSX, LevelD), you'd certainly expect more mention of it. Are there any other reports on the LevelD forum? There are no others like this here. If the problem appears specific to your system then looking at other aspects of the system, such as the video drivers, seems appropriate however unlikely it seems on the surface. Hmm. Is that reported by others? Okay, but you might want to research those two points, i.e. (1) whether it happens to anyone else, and if so do things compare at all -- like video drivers? (2) whether it occurs still with older or newer video drivers or different video settings. Regards Pete

That's why I needed to test in FS9. It works okay in FSX with FSUIPC4. ;-) FS9 = FS2004. It is corrected already. It was a typo. Please see the Download Links subforum. Download FSUIPC 3.989q. Regards Pete

I've tried all sorts of combinations here with FSUIPC4 and it works fine there. I'm just loading up FS9 to try there ... .. Yes, you are correct. There's a bug in what should be pretty much identical code in FSUIPC3! I'll attend to it directly. Regards Pete

Neither. It's a reference for the FSUIPC code to find the details for that sound. What anything else, like FS, does with wave files is completely unrelated to these facilities, so they don't affect anything. The reference is to the one "Play" request. That's why it is returned by the play request. If the sound is not repeating or is stopped, the reference becomes void, no longer a reference. I don't understand why you don't find it clear. The only use for the reference is so you can test if it is still playing and/or terminate it. The Lua sound library is about playing sounds, not hooking into sounds played elsewhere. I've no idea if detecting sounds made by others is even detectable without hooks deep into Directsound. You need a microphone and an input! ;-) Regards Pete

Sorry, what bit is confusing? The rotaries send repeating button press signals, on-off-on-off , one change for each click. the FSUIPC repeat option repeats the assigned action whilst a button is pressed. So, if you happen to leave a dial in its click position 'on' it will cause FSUIPC to repeat forever. You'd have to fiddle about to find a position which was 'off'. In any case you don't need repeats when the dial itself is sending repeats. But since it sends 'off' alternately, for an action on every click you need to program both the on (press) and off (release) actions. GoFlight dials also usually have two speeds in each direction, giving 4 effective buttons, two each way. These things are explained in the documentation. Can you tell me why you don't find it clear enough? Regards Pete

Phew! You've put a lot of work into that! I assume it is freeware? You might want to consider posting these details to the "User Contributions" subforum, so they won't get lost amongst all the general support messages here. Regards Pete

Okay. I've been all day on this. It wasn't easy because all the tools i use to debug things are hidden and inaccessible in full screen mode, and when you return to Windowed mode the things I wanted to watch don't apply, of course. The good news is that I can reproduce it, and, sort of, can see what is happening. The bad news is that nothing I can think of to work around it works It looks like FS uses a completely different window class for the 'other screen', one called "FS2K6DeviceWnd". It's used for the screen as a whole, a DEVICE more than a WINDOW. The window procedure associated with that class receives the keypresses, and i would presume it passes them on directly, so bypassing my interception. I've tried sub-classing that Windows procedure so I can get first crack at the key-presses, but there's some mechanism being used that defeats it. I've tried forcing the subclassing to repeat, to get my interception in first, but that doesn't work. Sorry, but I'm out of ideas. I can't do anything about it I'm afraid. I guess that device windows, whatever they are, are a different kettle of fish and don't really do 'subclassing'. Regards Pete

I don't know. should be okay. i'll check here and get back to you. Can you please tell me exactly what version of FSUIPC you are using, just in case there are differences? Pete

Sorry, then. I don't know how you could tell. If you learn of a method of doing it which I could implement without too much trouble, let me know. Regards Pete

The detection is based on normal polling rates on the joystick. but if the axis values are changing, any very small zone could be missed. You probably need to widen the zones. You could try increasing the poll rate (descrease the poll interval parameter) but take care or you risk affecting FS performance. Please explain. Who says they don't? The internal handling is the same for assignments no matter where they are made. Regards Pete

No. FSUIPC (and I) are both totally ignorant of all multiplayer facets of FS. Sorry. It's an area I never managed to get into. Can't you check the Squawkbox offsets in FSUIPC? Seems like something it would indicate. Regards Pete

I only assume that you haven't bothered to read it when you do not ask specific questions about what it advises. How do you think the manual has been improved over the 12 years of FSUIPC if not for the questions asked about its contents? The whole point of having a manual to to answer questions there, once, not having to do so individually and repetitively here over and over again! There is absolutely no point me just quoting sections of the manual here in response to your most general question about "how do a assign axes in FSUIPC"! There is a complete chapter, with pictures. If you don't understand part of it, point it out and say why. But you come here and say nothing of that, you simply ask how to do something which is fully spelled out in the manual. If FSUIPC "jams up on you", whatever that means, you may be reporting a problem or a bug, but you say nothing of that nor what you've done. I cannot read minds. I cannot see what you've done. Please calm down and be sensible. Look at it from my point of view. I spent many hundreds of hours on explaining things in the manual, only to be asked to do the same here -- or at least that is precisely how your request came across. If you have some specific difficulties then you need to say so. I can work with information supplied. Please supply it so I can understand your problem. And please be very specific -- INCLUDING, please, the actual FSUIPC version number. If it is not at least 3.98 please update first. Pete

For FS2004? Isn't that to do with Microsoft? If you mean for one of my programs (and you don't say), you must buy one from SimMarket, as it tells you in the documentation. Pete

I didn't forget. I've got my Notebook set up ready for a test this week, and a "spare" Monitor I can plug in for a second screen. I just hope FS doesn't crash when I switch to full screen mode -- that is what is happening on my normal test PC where I have all my debugging tools. Something to do with video drivers I guess, but I've not been able to fix it. Yes, if i don't get back before the end of next week, remind me in January. But I hope to try somerthing tomorrow or Friday. Pete

Didn't you find the FSUIPC User Guide where it is installed in your FSUIPC Documents folder, inside the FS Modules folder, as pointed out by the Installation guide? Pete

That shouldn't be necessary unless you want to change the thrust. If you have to waggle it a bit before it does anything, that's wrong. Are you sure it isn't just your throttle going to sleep? Make sure you have Power Management turned off in Windows -- Control Panel, System, Device Manager, check the Properties of all the USB hubs. When you disconnect the A/T the system should maintain the last setting. That's the point -- same as elevator trim. If it automatically set whatever was left on your controls it could cause a nasty accident. Of course in the real aircraft the A/T would be moving the motorised throttle to the correct place all the time. To emulate that without a motorised throttle you could move it manually to the approximate place, a guesstimate, before releasing A/T. This is particularly important during approach and it's always worked well for me. ;-) Regards Pete

So it effectively acts like 4 buttons, one each way for an inner and outer knob? If it can be driven by keypresses, FS controls, or L:Vars (Local FS Variables) then you can program it with any button or knob device recognisable to FSUIPC, which means pretty much all GoFlight stuff. In case it uses anything simple like FS controls, just enable FSUIPC event logging, then operate it and check the log. To find out if it uses L:Vars, if you have a registered FSUIPC, put the "log lvars.lua" file, which you will find in your FSUIPC documents folder (in the FS Modules folder) inside the Example LUA Plugins ZIP, into the Modules folder, then load FS and assign a button or key to "Lua log lvars". Run that with the Reality XP gauge running, and it will also list all of the L:vars, in the log AND on screen, and, better, show what happens when you mouse-click the up/down buttons on the EICAS gauge. Compare what that does to what your assign EFIS button does. Regards Pete

Sorry, someone else will have to answer that. I know nothing about VB.net. There are examples and tools in the SDK though. Did you look? Also check the "FSUIPC Client DLL for .NET" thread in the Download Links subforum. That library provides a much easier route for .NET users, or at least that is what I understand! ;-) Pete

Yes, but they are in different units so you would need take care. In this case the size isn't so important. The one at 0580 is much more precise -- down to minute fractions of a degree. You can simply get away with ignoring the first two bytes (at 0580) and taking the next two (at 0582). You are then only losing parts of 1/65536ths of a degree! However, it 's more than that.. 0580 is degrees TRUE. Normally the A/P is operating in Degrees MAGNETIC, so you'd have to do some arithmetic to convert it too, using the deviation at 02A0. Look it up, it is explained there how to do it. No. When I say "changes the offset" I meant "changes the value at the offset". I'm slipping into the way many users talk when they use the term, as if offsets were the values rather than a reference to where they are (or rather were, in FS98). Sorry, I should be more precise. Regards Pete

It works perfectly here. So, either you have made a mistake, or perhaps your FSX is not fully updated (I am using FSX + SP1 + Acceleration) and the EFIS L:Var is different in the version you have. To find out, assign a button or keypress to the "List Local Panel Vars", then use it with the aircraft loaded and check the FSUIPC log for the names of all the L:Vars. Or, better, put the "log lvars.lua" file, which you will find in your FSUIPC documents folder, in the FS Modules folder, inside the Example LUA Plugins ZIP, into the Modules folder, then load FS and assign a button or key to "Lua log lvars". Run that with the aircraft loaded and it will also list all of the L:vars, in the lgo AND on screen, and, better, show what happens when you mouse-click the up/down buttons on the EICAS gauge. Compare what that does to what your assign EFIS button does. Sorry, I can't help much more than providing something which works. Please double check everything. If all else fails, enable Button logging and show me the FSUIPC log file -- include the tests using Lua as I explained above. Pete

Sorry, you seem to have finished prematurely there. I've no idea what you were about to say. But you are most certainly completely wrong when you say " i think this type of configuration is for persons who have the trim wheel device" (whatever a trim wheel device is). What is described in that box is for separately assigned trim up and trim down button actions, whether those button inputs come from a knob, a wheel, a spring-loaded lever, or two separate actual buttons. It makes not one bit of difference, except that probably with a wheel or knob you wouldn't enable "repeat" in FSUIPC because the device would repeat whilst you are turning it. That would be exactly the same, then, as doing in it FS itself. Implement the suggested method, the one you've found. I don't understand why you haven't. Pete

No. FSUIPC interfaces with FS by all means possible, including its event system -- which, incidentally, is the very same event system you use when assigning keys and buttons and axes in FSX's own assignments. There's no difference, except FSUIPC exposes ALL of the events defined in FSX, whether they are useful or not and whether they work or not, whereas FSX only exposes those the authors deemed okay for such exposure. If the only function of FSUIPC was to provide a slightly wider source of events, it would never have been writrten and wouldn't be worth supplying or using. That's certainly one possibility, just as FSX would do if you assigned there. But FSUIPC offers a lot more possibilities. Please, why not read through the User Guide one day so you can see what is offered? FSUIPC added controls are for functions added by FSUIPC. Please read the list! No they most certainly don't! Where do you get such garbage from? I thought I clearly pointed out that events are ACTIONS! Memory contains DATA! ACTIONS are things being done, maybe acting on data, maybe on something else. Some actions may result in data being changed, but that could be indirect, due to simulation simulating something happening. DATA is just that, values, numbers, strings, whatever. It sits there. It is not an action! Writing to some offsets triggers FSUIPC into sending Events to FS, some do other things. The offsets list tells you what they do, if anything. Many offsets are simply informative, doing nothing but providing information, for things like display on gauges, or reporting things, like weather data. Mostly, nowadays, by me, by FSUIPC. But many were defined in FS98, as I also already explained. After FS98 most values previously directly accessible in FS at specific offsets in specific modules were no longer so. Microsoft gradually re-wrote FS using "object-oriented" programming techniques, whereby the values we use were boxed up tight in their own functional parts. They were re-exposed by myself working thousands of hours, and mapped back to the same "offsets", or at least it was made to look that way to applications so that they didn't need re-writing for each new FS version. These values moved and changed from version of version of FS, and every time it took thousands of hours to re-map them. Finally, in FSX, Microsoft actually agreed to help, and devised SimConnect which made it a bit easier for me, but also necessitated a complete re-write of FSUIPC. Hence the separation between FSUIPC3 (which works with FS98, CFS1, FS2000, CFS2, FS2002 and FS2004) , and FSUIPC4 (which works with FSX, ESP and lately Prepar3D). No, not at all. Events are ACTIONS, Offsets contain DATA, or VALUES. One may influence the other, like if there's a "HEADING SET" it changes the offset containing the Heading -- and even possibly changing the offset containing the heading produces, perhaps, a HEADING SET event (but this latter part depends on implementation between FSUIPC and FS -- it probably actually doesn't, in this case). But you must not continue to confuse the two, or make any assumptions about how things are implemented internally. Pete

Doesn't an FMS need more than just one rotary control? My FMS needs a full keypad and two sets of selector buttons. I've no idea for the RealityXP but if it can be operated by keypresses or controls, not just by mouse, then of course you can assign any joystick button or knob to those functions. If it can only be operated by mouse you'd probably need Key2Mouse to deal with it. Don't RealityXP have a support forum? Regards Pete