Pete Dowson

FSUIPC "hotkeys"? In the Hotkeys tab? What about keys assigned in the normal Keys assignments tab? Why did you choose Tab+g for the comparison in "Hotkeys" not "G". Wouldn't that have been a proper comparison? I don't know at present, before looking at it. It may be an oversight. I'll check the code, see what was intended. It's possible that P3D4/5 defeats the FSUIPC code by accessing the keyboard more directly than FSX and P3D1-3 and no one else has noticed the change. FSUIPC only works by using WM_KEYDOWN and WM_KEYUP messages. There are other ways of reading the keyboard, but I don't know if they can be made exclusive. I probably won't get to this till Monday though. Pete

I'd have to check. It isn't documented like that, and I think perhaps that the key press Event may not always be wanted in a Lua plug-in to change its assignment, but simply to know when it occurs for other purposes. Though I suppose the solution then should be to send it on before exit as intended for control or axis interception. Certainly Keys assigned in FSUIPC take precedence over those assigned in the sim. It also occurs to me that TAB+G shouldn't cause the GEAR Toggle conttrol to fire in any case -- is the Sim ignoring the TAB button? I wonder if the use of TAB as a shift (not a standard type of shift as recognised by the sim like Shift, Ctrl and Alt) is confusing the issue. Could you see what just G does? Let me know. i won't be able to check properly till, probably, Monday. Also see if TAB + G operates the Gear even if assigned to something else in FSUIPC. That would prove conclusively that the G goes through with TAB as the "shift". I assume, of course, that you hold the TAB down before pressing the G? Else the G would certsinly go through first. Pete

Ah, I see! Oops. "Toggle" (in all of its uses in FS I think) means "on-if-off" or "off-if-on" not "on-then-a-little-later-off", perhaps emulating a key press or a momentary button. That's the way the term is used in all of the FS controls called "Toggle", like SOUND TOGGLE, SLEW TOGGLE, PAUSE TOGGLE, GEAR TOGGLE, TOGGLE MASTER BATTERY, TOGGLE NAV LIGHTS, TOGGLE PUSHBACK, etc etc. To do "press then release" means sending two commands as you were doing for buttons 0 and 1, with a delay between them for them to be seen, just like real keypresses or button presses. The delay might need only be 20 mSecs or do, but 50 mSecs to be on the safe side (corresponding to the typical keyboard 20 per sec repeat rate). They were automatic repeats based on the button staying pressed and the "repeat" option set in the "Buttons & Switches" assignment. FSUIPC provides this for buttons to emulate the keypress repeats when you hold a key down. (Windows operates that for keypresses). Pete

That's a huge log with little of relevance in it. I assume it's the toggling action only you are concened isn't fast enough? The first such is here: 1618297 WRITE0[17660] 29F0, 4 bytes: 02 40 00 00 .@.. 1618297 Button changed: bRef=0, Joy=64, Btn=2, Released Because button 2 was pressed at the start of the log, this toggle released it - no action assigned. The second toggle action sent pressed it, with immediate effect on the assigned action: 1586344 Button changed: bRef=0, Joy=64, Btn=2, Pressed 1586344 [Buttons] 38=P64,2,C66741,0 1586344 FS Control Sent: Ctrl=66741, Param=0 ADF1_RADIO_SWAP This sequence, with the action occurring immediately the offset is written is the same throughout, as far as I had the patience to search. If you can find one where it failed to obey the press, or took 3-4 sdeconds to do so, please do point it out to me! As far as I can see, there is no problem. it is doing exactly what it is supposed to do! If you are simply saying that the offsets are not being written to fast enough, then that will be down to what is sending them. The log shows other virtual buttons being pressed, -- including one with Repeats enabled and assign to send a keystroke to the sim. I see the repeats building up ad causing quite a queue of keypresses to amount. That won't do any good to Sim performance -- each keypress is another message in its Message Queue. If you are trying to prove a problem with the toggle action, please ONLY send the toggle action request! Incidentally, if you are planning on using the type of encoder which alternately sends "press", "release" as you turn it, it is normal to assign the same action to both press and release, That way it operates twice as fast. Pete

You shouldn't be using the Assignments tab for testing your coding. That is ONLY looking for "off to on" or "released to pressed", and whilst it is open most other actions in FSUIPC are slowed or stopped. It is in no way suitable for seeing if your software works. Only use it to make your assignments! The logs are therefore useless to show me anything, as they are entirely performed whilst within the dialogue! Assign the virtual buttons to something which you can see or can log, THEN worry about timing if it is wrong. Pete

And what do PMDG say about it? To have such an effect on a plane with as much mass and momentum as a 747 those winds aren't just gusts they are hurricane force gusts! I think something must be wrong with the flight model. I don't know any way to do that. Sorry. With FSX and the earlier versions of P3D we used a hack to enable direct control of winds, ut even that wouldn't freeze them -- you'd need to keep sending the same wind data over and over and rapidly to stop it changing. Active Sky used the direct control method too, and FSUIPC doesn't when AS is running. HiFi Simulations might be able to add such a facility. You don't say what version of FS or P3D you are using, but we wouldn't consider such hacking in P3D4 or 5. Active Sky has better internal capabilities. The proper solution is to get the aircraft model fixed. It should be able to cope with such real world conditions. Pete

That's not right. All offset writes are executed immediately. The monitor logging might not show it for perhaps half a second as it's polling the monitored offsets relatively infrequently, but absolutely nothing takes even a second, let alone 4 or 5! The button action itself is also based on polling, and that is controlled by the parameter PollInterval parameter in the main [Buttons] section. That defaults to 25 (missiseconds) for 40 times a second, so there could a maximum of a 1/40th of a second before the button change is seen! Enable ipc write logging as well as button logging and the Monitoring or those two offsets. Then show me the log for the whole sequence of press/release/toggle. And also please show me your code, AND the INI file.because you this doesn't make any sense. Pete

Well, I thought I would only need the [JoyNames] section really, because you must have taken my advice and used JoyLetters now -- so all the assignments in the rest should be okay. Except that I see you couldn't have used anything but the 737-800W so your other profiles didn't get updated. That means we need to try to match the numbers not just the letters, like previously. This is the part of the INI which matters: [JoyNames] AutoAssignLetters=Yes 0=Joystick - HOTAS Warthog 0.GUID={375E0230-95F7-11EA-800B-444553540000} 1=Saitek Pro Flight Combat Rudder Pedals 1.GUID={4B1F9350-95F8-11EA-8001-444553540000} 2=Throttle - HOTAS Warthog 2.GUID={4B249C60-95F8-11EA-8002-444553540000} 3=F16 MFD 1 3.GUID={B4C0B290-96A1-11EA-8001-444553540000} 5=BU0836A Interface 5.GUID={B4C34AA0-96A1-11EA-8004-444553540000} 0.WARNING=This joystick was ID 2, but was duplicated: review and fix assignments, reload settings 2.WARNING=This joystick was ID 3, but was duplicated: review and fix assignments, reload settings 3.WARNING=This joystick was ID 1, but was duplicated: review and fix assignments, reload settings 4=F16 MFD 2 4.GUID={B4C1EB10-96A1-11EA-8002-444553540000} 4.WARNING=This joystick was ID 0, but was duplicated: review and fix assignments, reload settings A=Joystick - HOTAS Warthog A.GUID={375E0230-95F7-11EA-800B-444553540000} B=Saitek Pro Flight Combat Rudder Pedals B.GUID={4B1F9350-95F8-11EA-8001-444553540000} C=Throttle - HOTAS Warthog C.GUID={4B249C60-95F8-11EA-8002-444553540000} D=F16 MFD 1 D.GUID={B4C0B290-96A1-11EA-8001-444553540000} E=F16 MFD 2 E.GUID={B4C1EB10-96A1-11EA-8002-444553540000} F=BU0836A Interface F.GUID={B4C34AA0-96A1-11EA-8004-444553540000} Now, I see you did as suggested and changed to using letters. The crucial question is: did you change this BEFORE the reinstall, and ran the sim too? Or is this new to this re-install? I see from the INI that, in any case, you only have the letters used in the 737-800W profile, and in default assignments, which is a shame. That means we have to match the numbers again to get those other Profiles working! The "WARNINGS" do actually tell you what the numbers used to be, so that helps too. From this: [Axes.PMDG 737-800W] RangeRepeatRate=10 0=CX,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 1=CY,256,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- 2=DZ,256,F,66423,0,0,0 -{ TO SIM: AXIS_THROTTLE2_SET }- 3=DR,256,F,66420,0,0,0 -{ TO SIM: AXIS_THROTTLE1_SET }- 4=EX,256,F,66387,0,0,0 -{ TO SIM: AXIS_LEFT_BRAKE_SET }- 5=EY,256,F,66388,0,0,0 -{ TO SIM: AXIS_RIGHT_BRAKE_SET }- 6=ER,256,F,65764,0,0,0 -{ TO SIM: AXIS_RUDDER_SET }- we can see that C must be a Joystick , D throttle and E pedals. Then this: [Axes.PMDG 777-200] RangeRepeatRate=10 0=2X,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 1=2Y,256,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- 2=3Z,256,F,66423,0,0,0 -{ TO SIM: AXIS_THROTTLE2_SET }- 3=3R,256,F,66420,0,0,0 -{ TO SIM: AXIS_THROTTLE1_SET }- 4=4X,256,F,66387,0,0,0 -{ TO SIM: AXIS_LEFT_BRAKE_SET }- 5=4Y,256,F,66388,0,0,0 -{ TO SIM: AXIS_RIGHT_BRAKE_SET }- 6=4R,256,F,65764,0,0,0 -{ TO SIM: AXIS_RUDDER_SET }- gives the equivalent numbers we need: C=2, D=3, and E=4. So, extracting those devices from your new [JoyNames] section and setting them right with what we found: 2=Joystick - HOTAS Warthog 2.GUID={375E0230-95F7-11EA-800B-444553540000} C=Joystick - HOTAS Warthog C.GUID={375E0230-95F7-11EA-800B-444553540000} 3=Throttle - HOTAS Warthog 3.GUID={4B249C60-95F8-11EA-8002-444553540000} D=Throttle - HOTAS Warthog D.GUID={4B249C60-95F8-11EA-8002-444553540000} 4=Saitek Pro Flight Combat Rudder Pedals 4.GUID={4B1F9350-95F8-11EA-8001-444553540000} E=Saitek Pro Flight Combat Rudder Pedals E.GUID={4B1F9350-95F8-11EA-8001-444553540000} That leaves us with the F16 MFD1, the F16 MFD2, and the BU0836A. In your old INI they were joysticks 1, 0 and 5, respectively. So just extract and renumber those, and work out which letters they should be by comparing your assignments for the 737-800W and, say, the 777: 0=F16 MFD 2 0.GUID={B4C1EB10-96A1-11EA-8002-444553540000} B=F16 MFD 2 B.GUID={B4C1EB10-96A1-11EA-8002-444553540000} 1=F16 MFD 1 1.GUID={B4C0B290-96A1-11EA-8001-444553540000} A=F16 MFD 1 A.GUID={B4C0B290-96A1-11EA-8001-444553540000} 5=BU0836A Interface 5.GUID={B4C34AA0-96A1-11EA-8004-444553540000} F=BU0836A Interface F.GUID={B4C34AA0-96A1-11EA-8004-444553540000} Now, those three are just intelligent guesswork, looking at similar assignments between two aircraft profiles. Now put those three together with the previous three, make a new [JoyNames] section with just those (and the AutoAssignLetters line), and try it out. Be sure to load each aircraft profile so the letters replace the numbers in the assignments, then you'll be a lot better off next time! Pete

No way, sorry. The CPU is being used by many other threads in the Sim, apart from those used by FSUIPC. The GPS timing is just using a regular Windows timer, but it can't get control until Windows switches to it, and that depends on loadings elsewhere. If this is critical the only way I can think of is to have an external program running a thread at high or critical priority level, (higher that other programs on the same PC), and whilst reading the data much more often in one of its threads, then doing its own interpolation for the 10Hz transmissions performed in its critical thread. Pete

It's still the [JoyNames] section in the INI file, as before, but the one really useful would be the one saying there were duplicates! Evidently you reinstalled Windows and/or reconnected all your devices differently? Why not leave well alone? Sorry, but "ASAP" might be tomorrow now! Pete

Make sure you have the 64-bit version of the GFDEv module included in your FSUIPC6 installation folder. GFDev64.dll frim this SubForum thread:

You'll need to purchase FSUIPC6.DLL. FSUIPC4 is for 32-bit versions of FSX and P3D. But that's nothing to do with your profiles and other settings. Just keep a safe copy of the FSUIPC4.INI file in your Modules folder, which is where your settings are saved. Plus any Lua and MCRO files you use,. Then aftrer you install FSUIPC6 you will be able to use pretty much everything without change -- excepting renaming FSUIPC4.INI to FSUIPC6.INI. If you have your Profiles in files, you need also to save and copy over your Profiles folder complete. Pete

No. It's always enabled in a Registered installation. It works fine. here is the Log from a test I just carried out: 718088 Monitor IPC:29F0 (U32) = 0x0 718088 Monitor IPC:3340 (U32) = 0x0 ... 797914 Button changed: bRef=0, Joy=64, Btn=0, Pressed 797914 [Buttons] 45=P64,0,Cx0D0066E0,x01 797914 IPC Offsets Control: Ctrl=x0D00, Length=1, Offset=66E0, Param=x1 797914 Monitor IPC:29F0 (U32) = 0x14000 797914 Monitor IPC:3340 (U32) = 0x1 ... 987377 Button changed: bRef=0, Joy=64, Btn=0, Released 987393 Monitor IPC:29F0 (U32) = 0x24000 987393 Monitor IPC:3340 (U32) = 0x0 To have these log entries I used the Monitor on the right-hand side of the Logging tab, entering 29F0 as a U32 with Hex checked, and 3340 similarly, checking "Normal Log" below. I also enabled Button/Key logging on the left. Then in another program, I wrote 0x00014000 to 29F0 with the result that Joy 63 Btn 0 triggered an assignment previously made in Buttons & Switches. Of course, once the button was "pressed" in order to use it again it needs releasing, so I wrote 0x00024000 to do this. Note that the order in which these events are logged isn't necessarily exactly the order they occurred. The "monitoring" action is done by periodic scanning of the specified offsets, while button/key logging is done when it occurs. The buttons & Switches tab will also show the virtual button when the press action is done. It won't show it when it is released, or if it doesn't change. That tab is looking only for changes from "off" to "on" or "released" to "pressed". If you still can't make it work, please do the logging as above and show me. Pete

Good. Glad you got it sorted. Now ... good flying! 😉 Pete

It's not "pounds per gallon", but punds per gallon * 256. The * means "multiplied by". If you are getting 6 you are ignoring the fraction! 6.7 would be 1715. It's a 2 byte integer, so a 16-bit value. in C is would be a "short", or in Windows terminology, a "WORD". After you read it, if you want it as a floating point value, divide it by 256.0. Please do read the details in the offsets list more carefully. Where they are floating point they are explicitly listed as such -- as "double" (64-bit = 8 bytes), or "float" (32-bits = 4 bytes). Pete

You have your two profiles defined for specifc aircraft: [Profile.1Milviz350] 1=Milviz KA350i LN-KYV 2=Milviz KA350i C-GRJZ [Profile.1QW787] 1=QualityWings 787-9 Virgin Atlantic Airways -SATCOM which is fine. BUT you have nothing defined specifically for either of them! I think what you misunderstood is that for Buttons and Keypresses you have general assignments which will apply unless they are overidden by specific assignments to the same buttons of keys. You end up with a mixture of those assigned generally which are not overridden, and the overridden ones assigned specifically. When you visit the Buttons or Keys assignments tab you will see a little check box near the top, centre, labelled "Profile Specific". If you want to make a specific assignment, make sure it is checked. Otherwise you are making a general one, which is what I think you've done. The profile it is specific to will be shown in the Options title bar. Pete

The reason for that is that this arm detente occurs on the real aircraft -- well, certainly on the Boeing speedbrake levers. I can't speak for others. The little amount of movement on the real aircraft between spoiler down to the speedbrake ARM position actually does nothing. After the ARM position the axis movement takes you to the flight detente (if off the ground) or the fully deployed spoiler. The latter position is automatically reached if the speedbrake was armed -- when landing is detected by the landing gear compression. If this operation was not so well simulated by the Sim, and the only way of arming the spoiler was to send what is really a button event, it would be more complex to program for those of us who do really want a realistic implementation. On the more general implication of your criticism of FS "redundancies", just consider: there are quite a lot of "redundant" button or key operated functions which are also performed (probably better) if you have the controls, via axis control assignments. Just think of the button/keypress controls folks without joysticks use on the NUM pad on the keyboard in order to fly! And the default combinations along with the function keys used to control the level of the mixture, prop pitch and throttle settings. All those use those key controls you can assign also to buttons. You can of course just use a big array of (labelled?) buttons, all assigned to the controls you need for the complete aircraft. This would be the same as using the keyboard, and would save having joysticks and other more realistic flight controls. Thinking the sim would be simpler by removing these flexibilities is not what more users would do. I hope MSFS turns out to be as fully as accommodating to all simmers needs as FS and P3D have been over so many years! Pete

Strange -- I definitely tested it when I put it up. It seems to have been completely lost on the server. I've uploaded it again. Pete

Sorry, we can't try to guess what you've done1 You need to show us your settings -- the contents of the FSUIPC6.INI file (as in your list of files above). Pete

This "discussion" seems very strange to me. The path for macros and the default for Lua files is the path in which you also find FSUIPC6.DLL, FSUIPC6.INI and FSUIPC6.LOG, as it has always been. Why is this so alien and disagreeable? @John: apologies for adding to this, but I had to express my perplexity at Andrew's confusion. Pete

It doesn't matter if you use FSUIPC or not. FSUIPC just lets you choose where on the spoiler axis the speedbrake ARM position occurs. You don't need to use it. If you don't calibrate the position in FSUIPC you just have to accept the position giving the relevant value. I don't really understand your problem. FSUIPC simply gives you more flexibility. Use it as you wish. Pete

You need to show the contents of the Install log file. It'll be in the same place as the installer you ran. Pete

Apart from What Thomas has illurstratedfor you, this is a misunderstanding on your part: That is not FSUIPC's doing. FSX and P3D automatically Arm the spoiler at a certain point along the axis travel. it isn't FSUIPC "converting the Axis into an ARM instruction" as you seem to think, but just a facility for you to ensure that the arm value it does use occurs on a particular point on the axis travel, lining up with a detente and label perhaps. If you don't need that, then as Thomas showed from the documentation, you are able to avoid using it. Pete

You can program axes to send different controls for different ranges of an axis movement. It's the right-hand side of the Assignments Tab. You'd need to determine what axis values are needed for each position, and assign each range to send it via perhaps one of the Axis_Throttle Set " controls with the value as parameter. The use of that type of assignment is covered in the documentation. Alternatively it would need a Lua plug-in. Pete

So it's a Lua script? I thought from this: that it was a program access rather than a plug-in. In the Lua script you are evidently detecting the switch change if you then write to 66C6. What happens if on a failure to do this you then repeat the write to Lua? I really cannot see anything that FSUIPC does which can change whether the switch operates or not. Now i know you are using a Lua plug-in then it may be related to the different timings when switching threads. Something is different in the way the gauge module detects the change. I suspect the only way to work out what is happening would be to debug the gauge concerned, to see what it is receiving and doing about it. But that's a job for the aircraft author. One thing you could try, just to see if it really is a difference in FSUIPC between the way it works with buttons compared to the Lua plug-in and 0D70 method: instead of writing to 0D70, toggle a virtual button (see offset 29F0 or 3340), then assign that button to the macro which works for you. Pete