Pete Dowson

WideClient and ASN are totally independent and disconnected. The only possible way you could have affected it with any SimConnect settings is by selecting the same Ports for your SimConnect connection as WideFS -- 8002 and/or 9002. To do that you would have had to put one or other of those port numbers into SimConnect files on both the FS PC and your client PC. But then, if you did that, it would have stopped working when you tried to put ASN on the Client, not on the Server. From the Logs you supplied it looks like the Client is simply awaiting broadcast details from the Server. For that to work both PCs need to be in the same Windows workgroup. Are they? You could also try putting the ServerIPAddr and Protocol parameters into the WideClient.INI file, so it isn't dependent on the broadcasts. See the User Guide. Pete

Sounds like you have the directions reversed. It might seem that way, but many controls are that way. This is why "REV" options are provided both in FS and in FSUIPC calibrations. "REV" stands (obscurely?) for REVerse, and checking those options with reverse the values to owrk inthe other direction. Easy, eh? And even fully documented! In FSUIPC you should do that BEFORE calibration, else calibration witll be wrong. Just press the RESET button for each affected axis first, then SET, then select REV and then calibrate as per the numbered steps in the documentation. Pete

You are making a mistake. All three entries must be EXACTLY right. Use copy and paste. Pete

Sorry, I don't think those encoders were available when I had a Cirrus Console. Have you checked with PFC support? I don't even know what "DGencode". Is it supported in FS default? PFC may have added these for use in X-Plane. I know they work more on the X-Plane side these days. I've not heard from them for years. As far as I'm concerned my development with PFC device had finished. Pete

What version of FSUIPC4? If you haven't downloaded the 4.949h installer, do so and retry. Then if you still need help you need to show me the resulting Install log -- that's what it is for, to help resolve issues --(which are invariably caused by old registry entries which should have been removed, or by folks renaming their Prepar3D.exe in order to fool other installers which don't know about Prepar3D. In fact the migration programs which do that are a menace because they make a mess of installing processes for programs which do know about P3D. You can paste the complete Install log into a reply here. Pete

Hmm. not sure it is "limited". There are some excellent programs which do a lot with AI, including controolling it to some extent. I know nothing about multiplayer. Sorry. You need to talk to others about that. The most FSUIPC does is allowing third parties to put data into its AI Traffic tables so that other programs can read it. Pete

Two problems: 1. Version 4.948 was released BEFORE P3D3.1 and is not compatible at all. You will probably get crashes. ALWAYS keep your FSUIPC up to date. Nothing before 4.949h is supported at present, and that works with P3D up to version 3.2.2. 2. You cannot use any Lua plug-in without paying for an registering FSUIPC. Plug-ins are one of the benefits of purchase. The friction changes you see in FSX must be from the default patch FSUIPC applies in any case. Do NOT modify SIM1 ever. You'll wreck many things. Pete

Does FSUIPC show F1 when you press F1 on the keyboard? If so, then FSUIPC is correctly detecting keypresses. I can only assume that VRInsight program is not sending a correct sequence for the key. Have you checked with VRInsight or the Support Forum? Seems it doesn't like FSUIPC add-on control numbers. By insisting they must be 65536 or more it is saying it only supports FS controls. FSUIPC's are deliberately outside the FS range, and those used by programs such as PMDG, to avoid conflicts. Pete

If you are careful about which encoders you get you can have those which are dead simple to program. Those have three contacts, as others, with a common ground. But they signal each "click" by a rise or fall in the logic level of one of the other connections, depending whether you turn clockwise or anticlockwise. That type can feed into the PC as just two buttons, one which is alternately pressed and released for clockwise turns and the other for counter-clockwise turns. Then you just assign as needed, taking care to assign for both the press and release if you want all clicks to matter. You can even use a Lua plug-in with FSUIPC (or write your own program) to have two or more speeds of Increment and Decrement -- in fact I think there's an example in the Lua examples collection installed with FSUIPC. The other type of encoder is more difficult to program. I think there's a section about those in the FSUIPC Advanced guide. They produce signals one both signal connections for both directions, but just in a different phase. I think that might be the type alaxus was talking about in his reply, above. I've avoided those. Pete

The control is in the list of controls you can assign to in FSUIPC's drop-down assignments, both in the Button & Switches tab and the Keys tab. If you need its number, it is listed in the Advanced Users guide along with all the other FSUIPC-added controls, in the section entitled "Additional “FS” Controls added by FSUIPC4". Pete

No, there all still there! Just take a look. As I said, they are all assigned to A, B and C. If you change the letters, as you have done, how do you expect ANY software to work out which of your new letters are A B and C? You've simply destroyed the links! Just change back to A, B, C for joysticks 0, 1, and 2. The only way of changing letter assignments otherwise is either starting again with a new INI, or editing all those A, B, C assignments you can see. Sorry, P3D assignments are not relevant to FSUIPC. You need to disable controllers in P3D if you assign anything in FSUIPC or you will get conflicts! Pete

I assume you must have first let it autoassign the letters, so it did do so and assigned A, B, C. You need to use A, B, C now because all your assignments are made that way (I assume -- I still can't tell because you STILL provide insufficient information, like the actual INI contents!). If you wanted to choose your own letters you need to do so at the beginning, NOT after everything has been automatically assigned to A B C ... Pete

Well, as it is not an FSUIPC.INI parameter, it can't have made any difference. I seem to remember that parameter from FS9 days, as part of FS's CFG file. It probably got carried over into FSX too. It certainly is nothing to do with FSUIPC iitself. I think it changed some sort of hysteresis (time-based) algorithm used in FS and instead allowed the real values through unmolested, so making things more precisely and predictably handled in FSUIPC -- but only when FSUIPC assignments aren't being used. Assigning in FSUIPC bypasses all that nonsense. That's all to do with the sliders in FS -- you must have the null zone slider set fully left and the sensitivity slider full right. I'm sure that old "stick" parameter can't do that. However, as I said, those only apply to fS assignments. Why? Assigning in FSUIPC does away with all those worries, provided you disable controllers in FS to avoid conflicts. Pete

Okay. Was the one byte reserved in the offsets enough, then? Pete

I can't help with that as you supplied no information. As I said, I can't even guess. Pete

The SDK won't help you. All you need to know is what I told you before, that each bit on those offsets from 3340 on represents one button -- pressed when 1, released when 0. All you need to do is find out how to express that in SIOC terms. If their documentation doesn't tell you these things, I just hope someone who knows about SIOC will read this and help you, but I think you'll be far better off seeking help in places where there are more SIOC users. Have you not tried the MyCockpit forums at all? http://www.mycockpit.org/forums Honestly, I don't know why you think FSUIPC documentation of any sort will help you program a completely different application. I cannot support you with SIOC, I know nothing about it. Sorry, Pete

Last point first -- programming is part of the SDK. There's never been any guide to using offsets apart from the offsets list. I've no idea what can and can't be done in SIOC, nor how to program it. You really do need their support, not FSUIPC support. The virtual button offsets are 36 bytes -- actually 9 x 32-bit words -- giving up to 288 "virtual buttons". Button presses are indicated by setting one of those 288 bits and releasing it by clearing that one bit. Your SIOC thingy needs to be able to set and clear specific bits, i.e. offset xxxx (3340 onwards) with bit number n (0-7 for a 1-byte declaration, up to 0-31 for a 32 bit word. If your SIOC documentation doesn't tell you that you can do this then maybe it can't be done. But, I'm sorry, SIOC is not my area. I know nothing about it, and it is THAT program you will need to understand. Pete

The event system is used to enable a suspended Lua (one which exited, I.e stop processing) to run again with a call to the given function. It cannot interrupt one which is running in order to transfer control elsewhere in the same Lua. I'm not sure what sort of mess would be created that way. Many of the earlier Lua examples were created before the event system was implemented. Then, yes, the program had to stay in a loop looking for whatever it needed itself. When the program terminates "naturally" (not by express termination), if there are any events being awaited, FSUIPC merely suspends the program and watches for those events. The thread itself continues to exist and in fact is running -- that is where the event checking is done. Really it's as if that part of FSUIPC is part of the Lua program. It is just coded in C and inside FSUIPC proper. I'm not sure how any other way of implementing such facilities could be done. I do not know the innards of the Lua code very well, only enough to make it fit. Anyway,I thought your callbacks couldn't occur unless the program exited awaiting an event? At least the use who had the problem said the callback function wouldn't get called without an event -- I asked him specifically to try it all with a loop and no events in case that solved the original problem. Pete

Yes, but surely you don't need me just to compare lines. Why the title "GUID help" specifically? Sorry, I've no idea what you've done nor what your INI file looks like, and I can't guess. FSUIPC never discards assignments, they are as stored in the INI file, or possibly in separate Profiles files if you opted for UseProfiles=Files. Pete

You can assign a hat to "Pan view" in the FSUIPC axis assignments tab. You do not need to use any FSX assignments. Pete

I'll reserve 736D. I think 8001 might be overwritten by other things internal to FSUIPC and WideFS. -- there are 0x300 bytes for them to talk about things. So you'll change the offset to indicate a callback, right? Suppose there's more than one plug-in all using your software - they'd all get the same callback? Maybe some way of differentiating them will be necessary. Not sure how. And what about the parameters supplied to the callback function? Perhaps you'll need rather more than one offset, or even code assistance in FSUIPC? Pete

But obviously there MUST be assignments in FSX! Haven't you disabled controllers in FSX? That's really essential if you want things assigned elsewhere. BTW, you appear to have enabled Event logging instead of Button logging as I suggested.. Did you fancy that more or something? Pete

For Hagstrom support you need someone else, I can't help there. But it obviously identifies itself as a joystick type device. However, if you are using FSUIPC for assignments it is a BIG mistake not to disable all controllers in FS. FS will always tend to make its own assignments for joystick devices it thinks are newly connected. Why? I don't understand why you ever need to do that! If you assigned them surely you still want the assignments. Why have assignments to joystick #0 if you can't get to its buttons? More to the piont, HOW did you assign buttons in the first place? As you can see, there is also another device, the Logitech, as Joystick #1. But you've made no assignments to that? If what you are really trying to say is that the device joystick ID numbers have changed, then, yes, that can happen when you have multiple devices and reconnect them, or reinstall Windows, or even update Windows. To avoid this you should use Joy Letters -- there's a chapter on this in the FSUIPC4 User guide. Because it tells Windows it is. It's not in FS or FSUIPC's control. It's what the USB data sent to Windows says. You need to talk to Hagstrom. You mean your device #1, the Logitech? See above about changes in IDs and why Joy Lettering is a good idea and why it was implemented! Pete

Have you tried looking at the Offset list installed in your FSUIPC documents folder? Check offset 3340 in that document. Or, probably better, find the standard offsets for the functions you require! Pete

You could simply enable Button logging in FSUIPC, and check the log. If you put FS into Windowed mode and enable the console log you could view the logging action in real time. In that case it certainly likely to be assignments in FS which are doing it. Unless you disable controllers completely in FS it has a nasty habit of assigning things automatically. This happens particularly when it thinks it detects a new or changed connection, which it does on the slightest provocation. Pete