Pete Dowson

What joystick numbers are assigned to those devices? Are you looking in the right offsets? The code to keep those offsets up to date is the same for all 16 joystick numbers -- it isn't likely to be working for some numbers and not others. Perhaps you need to show me the FSUIPC4.INI file. You could also try using FSUIPC's logging. Firdt, in FSUIPC.INI, add "Debug=Please" to the [General] section. Then lod FSX, go to the Logging tab, and check Button logging AND set the "Extras" field to 2. This will log just about everything to do with buttons. You can also monitor the offsets you are interested in on the right-hand side. They'll be type U32 and best to check the 'hex' option, and "Normal log" so that the values appear there. Regards Pete

Why not simply assign the one axis to both? In FSUIPC you can assign one axis to up to 4 things. To reduce sound wave amplitudes you have to edit the sound waves to reduce the amplitude. There are plenty of easy to use sound editors about. Pete

They use a separate Lua thread which is always running to store and retrieve the variables. That thread contains only its stack, for such data. No code as such. Ah ... just checking the code, by "any type" it looks like I meant "any type of normal scalar" -- it only does numbers and strings. In fact it doesn't even do Booleans! Ouch! Sorry for misleading you. Checking the possibitlies for pushing variables onto stacks in C, I only see those for numbers, strings, booleans, and one called "values". Maybe that last is of more general use and will cover tables etc. I could try -- but only in FSUIPC4 and WideClient. I'm not doing any more development for FS9. Would you like to test such a change? No, it is not related. Using devices involves the maintenance of lots of data structures which are thread specific. You cannot handle a device in one thread which was opened in another. Why not simply have a global value which tells you whether it is open or not? In fact the handle itself. If the global hasn't been set, open the device and set it. More usually you would open the device at the start of your Lua program, during initialisation, in the part of the code never re-executed. Globals are only really used for communicating between threads. There's a lot of memory and data management going on to create the file facilities and tidy up when you close. Regards Pete

That contains this (which it would have been easier to simply paste in the message: [macros] 1=ifly73 1.1=K73,16;I 1.2=k51;3 1.3=k71;G That is NOT a "mouse macro" but an ordinary sequence of key presses. It cannot possibly be made using the "create mouse macro" facility. It can only be done using an editor and entering each line manually. It even has comments added to it (;I ;3 and ;G), so it is quite obviously made in an ordinary editor. FSUIPC never adds comments! It does TAB+ I, then 3, then G -- maybe, though there's a chance that won't work because the "shift" codes for the 3 and G keys are missing. It should be: [macros] 1=ifly73 1.1=K73,16 1.2=K51,8 1.3=K71,8 This cannot invoke an FS9 menu entry, because that needs "ALT" to start with. And key sequences don't in general work with FS menus, because once the menu system opens the focus changes from the FS screen into the menu system and the other keypresses are lost. The only way is really to program it as a Lua plug-in, because they carry on running in their own threads. So, to conclude, I think you are compeltely mis-remembering what you did with FS9. You need to work out again how to do what you want with FSX. Regards Pete

Would you like to post details, please? Pete

It will connect to WideClient just as it will to FSUIPC on the main FSX PC. The interface is identical. It doesn't need to know it is running on the client PC. There is nothing to add on the FSX PC for WideFS. You only need to register it. You said WideFS was all working in the first place! That is good. That is all you need to do for WideFS. If it is an FSUIPC application and it doesn't need to access FSX directly, then all you need to do is run it on the second PC, the one with WideClient running and connected. There is nothing else to be done. If it will not run even though WideClient is running and connected, it isn't anything to do with FSUIPC or WideFS. It may be that you are mistaken, and that your application needs a different interface -- Simconnect, maybe. You need to ask their support. Oh, one thing. I noticed on their website that they tell you to run VAFS "as administrator". If you do that (which should certainly be unnecessary) you must also run WideClient "as administrator" -- otherwise they cannot talk to each other. The same would apply on the FSX PC, FSX "as administrator" is you ran VAFS there "as administrator". Pete

You always need to tell me the version number of FSUIPC. Offsets 03C0-03FF only provide the button states of those joysticks being actively scanned by FSUIPC. For FSUIPC to scan a joystick there must be at least one assignment to one of its buttons. FSUIPC does not waste time and resources scanning joysticks not actively used in FSUIPC, which is probably what is happening in your case. Regards Pete

Sorry, I don't understand the question. You have WideFS working, you say. If the application uses the FSUIPC interface to FSX then just run it on the second PC where WideClient is sitting waiting for something to do. Pete

Yes. So? That looks perfect. They are not assignments! Assignments are those lines in places like [Axes] and [buttons]. The [Joynames] section is the essential part that tells FSUIPC which joystick numbers are currently assigned to which letters. That is the sectin which will automatically be re-calculated if you moved any devices, or moved to another PC. The whole point of the section is to allow the letters to stay correct in the assignments! Please, if you'd read the one page section about Joy Letters in the User Guide you probably wouldn't be quite so confused. I'm not sure why you went down this track in the first place -- just don't confuse assignments of buttons and axes to the business of names and GUIDs and their letter and numeric representations. In its dealings with Windows FSUIPC needs the numbers, not the letters, so it translates the letters into numbers internally, all to save you all this bother. Regards Pete

Ah, I see. Yes, there are a lot of those, mainly because I've never had time to go through checking them all myself, and not enough folks actually provide feedback. They are gradually being filled in as "OK" instead --- I've just done so here for those two after checking them. Okay. You know there are two easy ways to check offsets yourself? 1. Use the logging "monitor" feature on the right side of the FSUIPC logging tab. Just enter the offsets and their type (UB in this case) and have them displayed on screen, or just in the Log. If you put FSX into Windowed mode and enable the Console Log you can see the offsets being read and changed in real time. 2. Use the FSInterrograte utility. This is more useful when there are a lot of things to be checked, or you need some of them converting into normal units. Regards Pete

I had a little time to spare so I checked those offsets both in FS9 and in FSX with the current versions of FSUIPC3 and FSUIPC4, and they both work perfectly. Regards Pete

Sorry, but there's not enough information here for me to even guess. What simulator is this with, and what version of FSUIPC? What documentation says these offsets don't provide the right values? What does it say they provide if not right? I can check things here, but I need a little bit more information, please. Pete

Well, you can mix assignments in FS and in FSUIPC, but you have to be sure there's no assignments to the same axis or control, or they will conflict and give odd results. Unfortunately, FSUIPC cannot stop FS reading and using joystick axes and buttons -- unlike keypresses which it can easily 'capture' before FS sees them. The big danger with having controllers enabled in FS whilst you are also assigning in FSUIPC is that even if you delete FS assignments, it has the nasty habit of sometimes automatically re-assigning them. This especially happens if you ever unplug a control and plug it in again, or if some glitch occurs in the system which makes the USB connection look new. This applies to all --- FS9, FSX, Prepar3D. Regards Pete

I don't understand that -- it surely wouldn't be a "mouse macro". Perhaps you mean just a sequence of keypresses wrapped up as a macro? The mouse macro option works by calling code in gauges, it doesn't work with the menu bar. The macro "button" to finalise a macro file is the same button you had to use to start making the macros for that file. It doesn't move or disappear, only the label on it changes from "begin" to "end". There's one such button on both relevant FSUIPC option tabs -- 'Key Presses' and 'Buttons + Switches'. If it wasn't there you couldn't even start making a mouse macro. The only part of making a macro file you won't see if it isn't possible is the pop-up window inviting yu to test the macro via the TAB key, and give the macro a name. That will only appear when you click the mouse on some part of some gauge which can have a mouse macro implementation. So, I am really not understanding anything now of what you are trying to do nor how you are trying to do it. The mouse macro system is the same in FSUIPC3 and FSUIPC4. As far as I recall there are very few places on any of the default FSX cockpits (or even the FS9 frgault cockpits) which support mouse macros, so I think that would be a waste of time. And I've no idea whether the iFly gauges support mouse macros. Did you look through the User Contributions subforum at all? But whatever aircraft you load, the menu system in FS does not change, and mouse macros cannot be used on menus in any case, as I said. I suspect you are using some other mechanism and are confuisng it with the mouse macro facility. Regards Pete

But I think this is intended. The control actually assigned to NUM 5 is "Center Ailer Rudder", no mention of elevator. This is true both in P3D and FSX. So I loaded FSX and checked it there. You said: but I just checked it in FSX and it is the same -- only aileron and rudder are centered. Maybe you have something programmed for this key in FSX? Regards Pete

After a little googling I find that the C++ default precision for cout is 6 decimal places. If you want to change that there's a function: std::setprecisionC++ is new to you? (It is to me, that's why I need to look things up! ;-) ). Regards Pete

What does << do there? I assume that's some sort of C++ output method? (I use C and ASM, not C++). What is the actual value of the doubles before you output them? Check with a debugger, or do your own formatting. You probably have whatever << does set to format things to 6 decimal places. Also, it's easy enough to test even without a debugger -- multply the value by 100 before sending it to << and see if there are still 6 decimal places! ;-) Pete

Yes, it is the same with P3D version 1.4 here. Pete

Just getting FSUIPC ready for it. It isn't released yet. Go to the AVSIM Prepar3D forum for more. Pete

How are you managing to only get 4 decimal places in degrees? Both latitude and longitude are very accurate. The values at offsets 0560 and 0568 are 64-bit precision stored in such a way that the maximum precision is preserved -- theoretically more than the precision offered by the 64-bit floating point form where some of the bits are reserved for the exponent. Of course, in FSX (unlike in FS9 and before), those offsets are computed from the 64-bit floating point values supplied by SimConnect, so just retain exactly the same precision. It sounds like you have some limitation in your code or in the way you are displaying it? There is also a GPS latitude and longitude in 64-bit floating point at offsets 6010 and 6018, but I don't think those are updated every frame like the 0560/0568 ones. Pete

That sounds as if the pot in the control is worn at one end and is simply disconnecting at that end. Not that I've noticed, but I'm testing P3D V2 at present. If I get time later I'll take a look. Certinly FSUIPC won't have anything to do with that in any case. Regards Pete

Use the FSUIPC4.INI file from FSX in P3D -- just copy it over. If you do that AND make sure the controllers are definitely disabled in P3D as they should be in FSX, then as far as FSUIPC is concerned all is the same and you know the problem is with P3D. Report it on their website. Regards Pete

As far as FSUIPC is concerned there's no difference between elevator trim and the other axes. Is this happening with all aircraft models? What methods of assignment are you using and to which controls? More information might be useful, maybe even your INI file sections for Axes and calibration. Have you tried using FSUIPC logging to see what is happening. The logging tab is in the options and explained in the user guide. Axis logging to start with. If you temporarily switch FS to windowed more you can display the live logging in a console window. What you are describing sounds more like something using the Elev trim up and Elev trim down controls rather than the axis. Pete

How was it done in FS9? No in a menu then? Pete

With AutoAssignLetters=Yes the assignment would have been automatic. AND it should cover all of your normal devices, so I'm puzzled. This is why I asked "what devices still have numbers?", which you've not yet answered. Are you sure you aren't mixing up joystck identification and button numbers. Buttons all still have numbers. If you are as confused as it appears, perhaps you should simply paste in your INI file here so I can see what it is that confuses you? It might be quicker? Regards Pete