Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    168

Everything posted by Pete Dowson

  1. Just "Lua <name>", the same control you must have already used in your [Auto] section to start it before. For every Lua plug in seen in the same folder as FSUIPC there are a number of controls added which do different things. Please see the very first page of the FSUIPC Lua documentation ("FSUIPC Lua Plug-Ins.pdf"), which document should really have been your first point of reference if developing or using plugins. Pete
  2. When developing and testing a Lua script I always just assign a keystroke or button to it in the Assignments tab. If you invoke it through assignment the running version will be 'killed' and the current version loaded and started. Pete
  3. One other thing. By doing as I suggested above for BOTH buttons -- i.e. have one conditional on the other, both ways around -- then it won't matter which is pressed first (or, rather, which FSUIPC sees first). Pete
  4. Yes, Assign one of the buttons to do what you want, then edit the line that creates in the INI file by adding a condition, that the other button must also be pressed. If you look up Conditionals in the FSUIPC Advanced User guide you'll see how to do it, with examples. Come back if you need more help, but take a look for yourself first. The section is COMPOUND BUTTON CONDITIONS and it's on about page 22. Pete
  5. Well, I can't see the values changing. Operate the brakes and observe how the numbers change. Some increase quite quickly with little pressure. And leaving the calibrated values at -16384 to 16383, with no null zones at all and no slope considered, isn't really "smooth calibration" -- best to follow the numbered steps in the User Guide for good calibration. Toe brakes always need a healthy dead zone, and if you want more movement capability with more delicate braking, a slope with a flattened start. All FSUIPC can do is transmit the values set by your choice of settings. The rest is up to P3D and the specific aircraft modelling. Maybe you can also adjust the "fierceness" of the brakes by values in the Aircraft.CFG file, but generally A2A are very fussy about their aircraft performance, so it would be better to adjust your controls to suit your needs. Pete
  6. This shows a problem with your FSX-SE installation -- at least on of the essential DLL modules within FSX is corrupted. If the log is as far as it got before it crashed, then it really is serious. Those entries aren't relevant as they don't show the FSX.EXE crash. You need to scroll further to find the FSX.EXE crash corrsponding to the point in the Log where things terminated -- 09/05/2021 at about 08:47. If there's no crash logged, if FSX just crashed silently, then that's even more serious. It is important to note, however, that those 4 entries in Event Viewer are referring to crashes in the SimConnect installer which you were trying to install (i assume). You shouldn't need to install anything other than what is automatically installed by the FSX-SE installer. Possibly other programs may want legacy versions of SimConnect, but not FSUIPC. But it is a concern that even the installer crashed! I think you need to consider uninstalling FSX-SE completely and re-installing. You might try the later Microsoft-released Beta version on Steam (63003). That includes a number of improvements, but doesn't support some of the hacked features of FSUIPC. Pete
  7. No, macro files are not Lua plug-ins. If you want a Lua plug-in to run then you have to actually tell FSUIPC to run it. Its listing in [LuaFiles] is merely to give it an index number(1 in this case) for when you assign a button or keypress to it (via the assignment dropdowns -- look there, you will see "Lua RadioSwitchOn" listed, among others. That's exactly simiar to using macros by assigning buttons or keypresses to them. Both plug-ins and macros increase the nmuber of different things you can assign to. The other way to run them, which would normally apply if your plug-in is "event" driven (i.e. stays running and does things based on events), is to load then via an [Auto] section containing a Lua RadioSwitchOn instruction. Please refer to the Lua documents provided, and also to the FSUIPC user documentation about [Auto] sections. Pete
  8. For those offsets which provide values for which we can currently get the exact same value in MSFS (or ones which can be made to seem 100% the same) as for previous versions of FS then, yes, the offsets are the same. This applies to all of the most used ones, such as those you refer to. However, there are still currently many things not supported in MSFS which were supported in previous versions. So the offsets list should be read in conjunction with the offsets status document also supplied. That is kept up to date as far as we can work it for each successive MSFS SimConnect update. It is really best to regard MSFS as still being in Beta development and subject to ongoing changes -- not just to the more visible stuff like scenery and aircraft, but also the internals as dealt with by the likes of FSUIPC. However, many client FSUIPC applications are already working very well with the currently compatible offsets. So best not to worry about it until you find something you need which seems not to work. Pete
  9. Sounds like your differential ("toe" brakes normally described) aren't calibrated very smoothly. Yes, that is correct. They aren't applied differently when they are applied with the same pressure. Quite logical. Well in that case there's something either very wrong with whichever aircraft you are using, or with your brake pedals or calibration. When you assign or calibrate do you see the values from the brake axes changing gradually, or do they jump from a low number to a high number? If the latter then it sounds as if they are either very badly calibrated, or are defined in the registry as "digital" (i.e only on or off). Normal use of toe brakes is to just balance them with your feet (toes really) to maintain your course along the taxiway or runway. You should be able to do that easily with a little practice. If not then your controls are probably very badly set up. For more assistance you'll need to tell us more -- what simulator, what controls, how set up and calibrated? And if you are using FSUIPC, which version. Pete
  10. It's okay. The SP1 and SP2 updates apply to FSX itself, not FSX. You said you'd reinstalled FSX but I think you mean FSX-SE, right? So don't worry about those. Two things to look for: 1. Is there an FSUIPC4.LOG file in the FSX-SE Modules folder? If so please show it to me. 2. Open the Windows Event Viewer (in Control Panel) and scroll through the Windows Logs - Application entries to see if there is a crash report referring to FSX.EXE. If there is, please show the details from that. you can cut and paste from there. Pete
  11. What's changed in RC? I thought it was unsupported and no longer developed? Certainly nothing's changed in the information it gets through FSUIPC to do that trick. I was always lazy in those days. I just used the FSUIPC Zapper and event land in spite of being told to go around. No doubt I would have lost my licence with RC, but I use P2A these days. AI control or even ATC interaction hasn't arrived for P2A yet, but, nevertheless, for the sort of short flights I indulge in it keeps me busy enough. In any case takeoff status for AI just isn't enough to prevent runway encroachment. That's why the Traffic Freeze controls were added to FSUIPC -- they freeze all AI ground traffic in "taxi out " mode, so you can catch them before they get to the runway. This is used by the supplied "AI Freezer.Lua" plug-in (look in your Example Lua Plugins). That freezes AI automatically when you do things on final approach, and releases them after you land. Read the details in the file. Pete
  12. Still, though, judging by the difference between those IN and OUT values, the braking amount is being substantially reduced at the start -- still negative when the axis reached +4800. IN=4800, OUT=-128 I saw that all the axes are assigned "direct" and calibrated in FSUIPC. I didn't think the PMDG Boeings liked that for some of the controls. Perhaps toe brakes is one of them (or two rather). Though I suppose really the main question is why is it okay until P3D is restarted. I see only one of the NGXu's is assigned in that Profile: 1=PMDG 737-800NGXu BW Ryanair EI-DAL I assume it is always thant one being reloaded? Pete
  13. Ouch! When I originally asked about " another joystick driver package", that would have included whatever that "configurator tool" is, and that I knew nothing about. If that is appearing in the P3D addons menu, then it IS running, and probably has settings which need to be removed to avoid conflicts. If you want to use FSUIPC for assignments and so on then really you'd be safer uninstalling that other joystick driver package, or certainly disable it. Pete
  14. Okay. That confirms controllers are off in P3D. Can you go ahead and try the same profile with a different aircraft now, please. Pete
  15. So far neither of the Logs have ben complete. You've been starting a "New Log", which means we don't get all the very important information at the start, logged by FSUIPC before your session begins fully. I suspect that will show that you still have controllers enabled in P3D. Look to see if you have a line like this: 21031 Controllers are set to OFF If not then controllers are still enabled in P3D. You have two strange meaningless lines in your Twin Piper profile for Button assignments: 6=U3,15,C0,0 -{Custom control: <0>}- 7=U3,14,C0,0 -{Custom control: <0>}- Delete those as, although they should do nothing, they are a little worrying. The aircraft itself seems to be doing some strange things without buttons being involved in any case: in the first log you provided there were many AP_PANEL_ALTITUDE_OFF controls occurring -- for no apparent reason -- whilst in the second log this had changed to TOGGLE_MASTER_BATTERY. Very strange that they occur and even stranger that they changed between sessions. I'm starting to suspect that the aircraft installation is corrupted, so, as well as double-checking that controllers are in fact disabled in P3D, please try your existing Twin Piper assignments on a different (default) P3D aircraft. You can temporarily add any other to the Twin Piper profile (you can always delete its entry in the [Profile.Twin Piper] section after the test. It doesn't matter if it has the wrong number of engines -- it isn't a flight test but just a test to see what events are generated when you operate those switches. Pete
  16. As the documentation does explain, the Ignore facility in the assignment tab is merely to ignore it whilst assigning, in case an axis is constantly jittering and so supplanting the one you want before you can get to assign it. To "ignore" an axis for a specific aircraft or profile you simply delete its assignment. If it isn't actually assigned it is ignored when you are back in the cockpit. This is what profiles are for. Pete
  17. It's the aircraft title, as selected in the sim, and and logged by FSUIPC in a line like this: 137796 Aircraft="ProsimB738 PBR 2020 - British Airways" So, it can contain any or none of the things you ask, depending on the supplier's whim and also on you should you have edited the "title=" line in the Aircraft.CFG file. Of course you can use any part of the name, as long as it does identify it or a group correctly and uniquely. Pete
  18. There's no "deactivation" process. The key will remain valid. All you need to do is make sure you enter the exactly correct Name and Email, as well as the key. You are making a mistake. Use cut and paste. Pete
  19. He's posted many messages since May last year. There's one in this thread from as recent;y as April 27th this year: Pete
  20. You'll need to show us your settings (the FSUIPC6.INI file), and an FSUIPC6.log with both Event and Button logging enabled and you briefly operating those switches. This sort of thing is nearly always due to multiple assignments, usually controllers not disabled in P3D, or another joystick driver package also installed. Pete
  21. Not an "offset" (offsets are places in memory where data is kept for reading or sometimes writing), but a "custom control". And it may need a non-zero parameter which you've omitted. The parameters are mostly mouse codes which are also listed in the SDK. How are you starting the Lua plug-in? It doesn't load and run itself. You either need to assign it to a button or keypress to load it, or, more usually, load it via an entry in an [Auto] section in the INI file -- presumably on for the Profile you are using for the NGXu, e.g [Auto.NGXu] 1=Lua TEST Try testing the control actually does what you want first by assigning to the button directly in FSUIPC assignments and maybe having a parameter. Pete
  22. You can certainly make it much more predictable that way. The fast/slow turning rotary facility may have to be quite extreme, timing-wise, to get a really usable result. It would be much much better written as a proper program and compiled rather than an interpreted script. The Lua script is useful in two ways: 1. An alternative way of reading buttons -- directly from a USB HID device 2. Another example along with the others of a Lua script. All of the examples are provided for folks to use as a basis of developing their own. Pete
  23. Yes, it appears so. I never noticed that before! The button number is "corrected" to be the same as that FSUIPC would recognise here: mask = logic.Shl(1, Rotaries[j]-1) I don't know how that oddity arose. It is easily corrected of course, by using mask = logic.Shl(1, Rotaries[j]) Odd that this example has survived at least five years with no one spotting that! Pete
  24. I surely didn't? You did actually imply that you were completely new to FSUIPC, only just having got it because of a third party recommendation. The starting point then is normally to browse the documentation, even before purchase just in case you decide it isn't for you. Sorry if you took such a recommendation as an insult! Dealing with controls devices is one of assignment, for buttons and axes, and calibration to get the axis controls responding to your satisfaction and to suit the aircraft. Assignment methods and calibration facilities are major parts of the documentation, and whether your devices are Honeycomb or not those are still relevant. I don't have any Honeycomb devices, but there have been lots of contributions here in the Forum. I made such a suggestion so you could get some more specific hints if you find you then need to. Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.