Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,001
  • Joined

  • Last visited

  • Days Won

    158

Everything posted by Pete Dowson

  1. I've tested event.textmenu here on 6.1.1 with the capturing of SimConnect message windows and it works fine. Unfortunately I don't appear to have anything using the SimConnect menu facility on my test PC, but I can set something up tomorrow. Meanwhile could you please do two comparable logs, one for 6.0.13 or whichever it is you have success with, and one with 6.1.1, but first edit your FSUIPC6.INI file as follows: In the [General] section add Debug=Please TestOptions=x8000 Run your test exactly the same one each and show me the logs please. I'll look at this later tomorrow -- retiring for the evening now. Oh, please also say exactly what menus you are checking with. Thanks, Pete
  2. That's not true for a rotary encoder. Each click is a change -- i.e a press or a release, alternately. So you need to assign the same thing to both press and release. Pete
  3. I don't see any likely either. Are you saying that for non-PMDG aircraft that program is detecting these okay? Don't the same work for PMDG aircraft? I'm pretty sure their Boeings use the underlying simulator code for the NAV radio simulation and signals received from them, so that should equally cover LOC and GS signals which are indicated in regular FSUIPC offsets. If not then I can only suggest you ask over in the PMDG Forums. Pete
  4. The .key file is a .key file. It contains only text and can be edited in Notepad, but it is just not recognised by Windows as a TXT file. Similarly INI and CFG files are text files but are categorised as configuration files. Note that when you register ALL THREE PARTS (Name, Email and Key) must be exact. You must be making a mistake. Pete
  5. I've never had to do that. I thought you had to nominate the program by EXE name? Just as a test, can you try with the firewalls disabled at both ends? Pete
  6. John will need to see the FSUIPC7.LOG created up to the point of the crash, and also probably the FSUIPC7.INI file so he can see your settings. A description of what you and MSFS were doing at the time would be useful too, please. Pete
  7. That's very good of you. Yes please. Both of us Dowsons have a lot on our plates right now, and this one is supposed to be "retired" 😉 Pete (the elder Dowson).
  8. Sorry, I'm confused. When you said: did you mean your "previous version" also being an FSUIPC6? Are you saying you just updated, for example from 6.1.0 to 6.1.1? If so, then I misunderstood. I thought you meant from FSUIPC5 to FSUIPC6. According to your list of .mcro files, you've actually of got 4. Of these: [MacroFiles] 1=6 DHC 2=737 3=400 Q 4=9 CRJ 5=7 crj 6=DHC 6 you are missing 7 crj and DHC 6. You don't have any assignments to 7 crj, but you do have just one to DHC 6 (Button 3 on Joy #1. However, I understand that isn't the problem. You appear to be saying that none of the macro files are providing entries in the Buttons, Keys or Axes assignments drop downs. Is that correct? And they were listed with your previous version of FSUIPC? Belatedly, I now see that the INI file you posted is from FSUIPC 6.008. Why haven.t you provided the INI file from your current 6.110 version? I need to see the current one, please. Pete
  9. So your macro files are these: [MacroFiles] 1=6 DHC 2=737 3=400 Q 4=9 CRJ 5=7 crj 6=DHC 6 Did you copy your FSUIPC INI file over from your previous version? Could that list possibly have been carried over from the last installation? That would be expected and reasonable. But did you also move those 6 .mcro files over as well? They need to be in the same folder. You have assignments to macros in several different profile assignments. If not all, which ones are you saying aren't now recognised? Pete
  10. You need to show us your FSUIPC6.INI file as otherwise we have no information with which to assist! Pete P.S. I moved your question to the correct place, the Support Forum. You posted in a programming sub-forum.
  11. The log simply shows the Client requesting data from the Server (or at least, that IP address you provided), and getting nothing. The server is receiving a connection but no data with it. So, there's a firewall type block at one end or the other. That won't work. The ProtocolPreferred parameter is for those clients which connect by receiving a broadcast from the Server. That's the default method -- leaving both Protocol and Server details out of the WideClient.INI, so the client links to whatever Server is running. The only requirement for the Broadcast method to work is that both PCs ar in the same WorkGroup (as well as no Firewall blockage). The firewall blockage (from Windows Defender possibly) can be in Client or Server. It isn't possible to tell from the logs. Pete
  12. ProSim has a SimConnect mode which, when selected, means it is not using FSUIPC to control MSFS. I think that mode is recommended over the older FSUIPC mode, which is still supported. However, I have read some folks find FSUIPC mode still better than its own direct SimConnect mode. Presumably still some work to do on their SimConnect code. When SimConnect is selected in ProSim I don't think FSUIPC is used at all. You are supposed to do all your assignments and calibrations in ProSim in either case. I use ProSim, but only with P3D5. No way is MSFS yet ready for use in a full blown 737NG cockpit. Pete
  13. I don't really know, but I would have thought that MSFS sensitivity settings for specific hardware controls should (would) not be operative if MSFS was told not to use those controls? However, I don't know MSFS very well and have never played with its sensitivities. My controls (I only fly the Just Flight Piper Arrow) are direct through FSUIPC only -- I don't have a choice as my control devices aren't ones recognised by MSFS, being part of a Piper Arrow cockpit ("GA28R") built many years ago by Aerosoft Australia (no relation to the German one). Since I'm not sure and I know John is very busy at present with development work, why not check for yourself whether the MSFS sensitivities do anything? With FSUIPC the main way has always been, and remains, to flatten the response slope in the centre. This results in steeper extremes since it is normally still important to be able to span the complete movement of the control surfaces. You can "fiddle" the range actually used by FSUIPC by changing the calibration values in the settings (the INI file). For example, changing this: Aileron=-16384,-512,512,16383 to this: Aileron=-32768,-512,512,32767 goes to the extreme of pretending that the aileron axis has fully twice the range it really has, so reducing the amount you can control to half what is possible. This would mean that it needs twice the movement to do the same as before. But it does also mean your maximum movement is limited to half what it was. This is why it is generally better to use the slopes., though I suppose a combination of the two techniques could be used wisely, just not so extremely. It might also be a good idea, before you start, to check whether Windows' own calibration, in its game controllers, does anything for you. That should really have been done to start with, if not automatically by installation. Pete
  14. They are set to individual taste, and often differently for different aircraft -- especially aircraft of different types or persuasions. For example fighters and stunt jeys need sensitive fast response controls whereas large heavy multi-engined turboprops want a slower more lumbering feel. So adjust accordingly and go by results. They most certainly shouldn't as you shouldn't have them enabled in MSFS if assigning in FSUIPC. However, FSUIPC doesn't support Force Feedback, so I'm not sure how you are managing that aspect. Pete
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
×
×
  • 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.