Pete Dowson

The offsets you are using are listed in the FSUIPC Offsets list as "reserved". Why did you choose them? They are listed in the FSUIPC as "reserved". I don't recall what for, but they may be is use for other things. As listed, and as I stated, the offsets free for users to use as they please are 66C0 to 66FF. I have no idea. What is actually reading these offsets to display them? It is that to which you need to refer, surely? I told you earlier and just above (please do read things): 66C0 to 66FF. I see spokes2112 has contributed -- his suggestion looks very good indeed. However, the big question for me is: what is reading these offsets and writing to your displays? The Log file is useless. For some strange reason you are pressing "NEW LOG" -- you did it trice, as indicated here: [Continuation log requested by user] and here: [Log closed by user request, and continued in new file] Please do NOT press NEW LOG. That starts a new blank log and you may lose the important details! Pete

I told you this: just make sure the ID's (the 0, 1, 2 before the = or .GUID= in those 6 lines) match your assignments! There in the [JoyNames] section in the INI -- the one I showed you in my first reply!!! Didn't you see them? Well that makes it easy then, doesn't it! In the Win10 INI the 0= and 0.GUID= should be 1= and 1.GUID=, and the 1- and 1.GUID= need to be 0= and 0.GUID=, respectively. That will sort your JetMax assignments. Unfortunately you have two "Flybycockpits£ devices. You'll need to test your assignments for those. If they are the wrong way around just renumber the 0 to 1 and 1 to 0. Pete

You are not using Joy Letters, and your Windows change will have changed the IDs as well as GUIDs associated with each device. You [JoyNames] section contains: AutoAssignLetters=No 0=JetMAX 737 Throttle 0.GUID={9C0DB280-638E-11E9-800A-444553540000} 2=Flybycockpits 2.GUID={2A48FB90-638F-11E9-8001-444553540000} 1=Flybycockpits 1.GUID={9C0DB280-638E-11E9-800B-444553540000} Your buttons are almost all assigned to devices with IDs 1 and 2 (the only exceptions being Pause Toggle and Auto Throttle Arm). So only the two are assigned to the JetMax! Change the IDs above to match what they ought to be for your assignments. The IDs are the 0, 1 and 2 before the = in each case, including the GUID lines. Also set AutAssignLetters=Yes so that letters are used for assignments and avoid these complications in the future. There's a chapter about Joy Letters in the user guide. Pete

Check the log file! I don't understand why you are using L:Vars for standard values available direct from P3D in existing offsets. I have no idea what you "intend", I'm just amazed that you resort to L:Vars when there's no need! Look at the main FSUIPC Offset list! BTW why are you using offset 68EC? The user offsets are 66C0 to 66FF. Your zero displays might simply be something else using that reserved offset! Pete

L:Vars are read directly through the P3D panels interface. There is no built-in delay in FSUIPC. You say "lag for microseconds". How are you measuring such a minute lag? It would take milliseconds in any case (i.e. thousands of microseconds). Nothing in FSUIPC measures microseconds. I don't know why the L:Vars you are reading alternately give 0. That has to be a function of the aircraft panel coding because if the variable was unavailable the return is nil, not zero, and trying to display that as a numeric will give an error. Run the LVar logging Lua plug-in provided and observe the values there as they change. BTW why not read the speed and heading from the normal P3D offsets? I'm sure they must be correct. Using L:Vars for such basic values seems very odd. Pete

If you looked in the FSUIPC Log file you would see the reason, as you have a definite error: The FSUIPC Lua library document tells you that the correct function to read an L_Var value is: n = ipc.readLvar(“name”) I think you are perhaps trying to use something from FS XML gauge language? Or maybe the more recent addition of Lua to FS (in P3D?). Aha! Seems for FSUIPC plug-ins you need to follow FSUIPC odcumentation instead!. That should not be surprising, I hope? Pete

There are ways of making the actions of one button or switch dependent on another button, but there is no such option for key presses or any configuration way of mixing keypresses and buttons or switched. You'd need to write a small plug-in script in Lua, as a plug-in, and assign the rocker buttons to it so it can test if shift is pressed and send one of two different controls accordingly. Pete

If, in FSUIPC Keys tab, using the review feature on the right-hand side, you do not see any of those keystrokes, then you must be using a Profile for them which you simply have not applied to this aircraft. Just click the checkbox next to where it says "Profile specific" top centre, then choose the correct profile. If this doesn't work then you have a corrupt settings file (the INI file in the Modules folder). Pete

Hmm. Interesting. I no longer have any VRi devices, else I'd take a look. but thanks for explaining. Pete

Are you not using Profiles at all? If you aren't then all the assignments you have made apply to all aircraft. If you are using profiles and you want to use the same settings for a different aircraft, just clicj the Prifle checkbox and select that Profile in the drop down list. There are pictures in the User Guide. Pete

"Many" years? All the VRInsight devices I ever had, "many" yesrs ago, were not USB HID devices, but serial port "COM" devices, and the default 'driver' was "SerialFP2". So, I'm confused. If the methods I implemented in FSUIPC to support them are now "deprecated", why have VRI users requestedsuch support in FSUIPC5, for P3D4? I thought only the more recent VRInsight devices had moved away from this method. If not, and now all their devices, old and new, are well supported by a new system, I would be delighted to be able to remove this support. Can you confirm this please? When VRI changed tack and went, as I thouht, to standard USB methods, I never got any more information or anything from them. Everything you've told me about the driver you are using is news to me. Help would be appreciated. Pete

Oh, so you can't actually assign them in FSUIPC? It seems a very odd capability, to be able to send only "a 5-digit decimal greater than 65535 plus a single value that is send as FS Control to FSUIPC". I obviously didn't fully comprehend this. And why only greater than 65535, when all of the specially-added fSUIPC controls have numbers in the few thoudads (1000 upwards)? Keystrokes are first intercepted by FSUIPC, only sent on if they aren't assigned there. Sorry, I don't know ehat this means in this context. Do you mean it addresses specific FS offsets to control things though FSUIPC? No, because most sch offsets are read-outs in any case, even if they can also be used to control. Unless you want to try keystrokes after all, you are probably best off sticking to your existing plans. But remember, FSUIPC can assign combination keystrokes, like Control+Shift+X or whatever, so there are lots of combinations probably not interfering with anything else. Pete

I dont think it's a really good idea, though this should work unless you are using some other add-on which happens to use those control numbers. The only ones i know of are the PMDG Boeing aircraft add-ons, which obviously wouldn't apply. But there could be others. There are two rather more usual ways of doing what you are trying to do: 1. Have a macro file (.MCRO) with macros for those operations. A macro can do the same L:var writes you are using Lua for. See the section "Macros to change Lvars! on about page 42-3 in the FSUIPC Advanced User's guide. That's probably the most sensible way. Then just assign to the macros. 2. Use the offsets provided for Users, 66C0-66FF. Use them to signal the action you want and detect it in the Lua plug-in using event.offset or event.offsetmask. Assign to Offset Byte Set or Togglebits to trigger the action. Method 2 would be the most similar to what you are doing, with a similar Lua plug-in and different assignments, but method 1 is by far the simpler one and involves no loading of any special plug-ins. Pete

Well, without venturing into a form of programming with a Lua plug-in (take a look at some of the samples in the ZIP in your FSUIPC documents folder to see if this is something you could do), the easiest thing to do is to assign both actions to the same axis (in FSUIPC up to four assignments can be made to axy axis). The brakes won't do anything in the air, the rudder does very little on the ground, especially if you have a tiller (which I assume you must have -- how else do you steer when taxiing? Pete

Ah! Apologies. I hadn't deduced from your inclusion of the Feelther INI that you were attempting to use the separate Profile files facility. However the parameter in the FSUIPC4.INI file is: UseProfiles=Yes You need UseProfiles=Files to make use of separate Profile files in the subfolder. Pete

You appear to misunderstand. Buttons and Keys are treated differently to Axes. You can have "generic" buttons and keypresses which apply to all, AND profile spcific ones which apply only to those aircraft. If a button or key occurs in both the specific one applies. This gives the most flexible arrangment, as there are many aircraft functions which will apply to almost all aircraft. Axes cannot be treated this way. You may have a yokeassigned for some aircraft (boeing airliners and many GA aircraft) but a stick for others (Airbus and fighter aircraft). If both were being scanned for aircraft there would be conflcts. So you either have profile specific or generic assignments for each aircraft. On the buttons and keys assignment tabs you can check nd uncheck the Profile Specific checkbox to swap back and forth between the two sets. You can't do that with Axes for the above reason. As it is, in any case you do not have any Profile Specfic buttons defined, only a few default ones: [Buttons] PollInterval=25 ButtonRepeat=20,10 1=RA,1,C65886,0 -{TRUE_AIRSPEED_CAL_DEC}- 2=RA,0,C65885,0 -{TRUE_AIRSPEED_CAL_INC}- 4=RE,19,K113,8 -{Key press: F2}- 5=PE,15,CL1:R,0 -{Lua DynamicFriction}- 6=RE,20,K113,8 -{Key press: F2}- 7=UE,20,K113,8 -{Key press: F2}- These will apply UNLESS overridden by profile specific assignments, which you don't have. Pete

Checked this morning. There's no case dependency. it can be YES, yes, Yes, yES etc etc. The spelling of that and the parameter name is critical though. Pete

Then it is working, but there are no wet rain clouds wthin the radar scan, so a blank image is produced. The latest Beta for ASP4 is for P3Dv4.5. Maybe you need to go back to the official ASP4 release if you are on 4.4.? Pete

You used Lua logging to check this? Or did you add an ipc.log line in the function? Did you enable the 737NGX offset data by editing the 737NGX_Options.ini file, as described at the beginning of the PMDG offsets list provided? Also check that this parameter in the FSUIPC5.INI file: PMDG737offsets is set to 'Yes', or 'Auto'. not 'No'. If both are ok, add the offset to the Monitor (right-hand side of the FSUIPC Logging tab), to check if the offset value is changing. Pete

Hmm. It could be a P3D bug. I doubt if any software other than FSUIPC uses the extra things L-M put in for the mouse macro making facility. John or I will look at it later in the week. Pete

Well, Yes, yES, yes etc should all be the same really. Still, glad it worked and i'll make a note to double check that. Pete

That's 3 positions not 6. You have to have one button for "on-off" and the other for "retract-off". For the two separate ones, if you want to operate them separately, then you'll either need two more buttons, or you'll need a Lua plug-in to work something out by program. To operate them in sync, however, just give them the same name when you make them. You'll get a multiaction macro like this:I dug up from an FSX example 9slightly different numbering system): 5=Namewithheld 5.1=RX10013,3 5.2=RX10014,3 5.3=RX10015,3 That's three actions executed in sequence with one assignment. Well, it is worrying -- if, in fact, it is FSUIPC. Does everything else carry on normally? You said you can complete the macro making, which means you can go back to the menu. Perhaps rather than freeze you meam that it doesn't want to make further macros then? still serious to e, but not the same level. Pete

Any value you like. For less sensitivity you need more than the 16383, that's all. You'd need to try values to suit yourself. Just be sure that the lowest value (the negative one0 is the same, but negative. Generally it is better to use the Slope option in calibration, however. Just use the ones which flatten in the centre (horizontally, not vertically). But really a well-designed add-on aircraft should work properly with standard calibration. If your FSLabs aircraft needs the sort of rudder fiddling you are wanting, then something must be wrong with it. Have you visited their Support Forum? Pete

That's very strange. Unfortunately I have no aircraft with a cockpit worth setting mouse macros up for, though I suppose i could try it on one of the default aircraft. Perhaps John could try this. I'll ask him to take a look. Can you remind us what you are using -- is it P3D4 with FSUIPC5.151? Could that ChasePlane actually be contributing to this, do you think? is it possible to try without it running, just to see? A list of other add-ons you are using would be useful too, please. Pete

My systems are off at present. Maybe not on till Manday now. But if you post your FSUIPC INI and your Wideclient.INI -- and your P2A settings (can't recall where they are or what the filename is, offhand), I can compare them with mine and sort it from there. Pete