-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
Control 'Set' not understood
Pete Dowson replied to grdrew's topic in FSUIPC Support Pete Dowson Modules
Yes. The Sim decides that as the on-ground indication is set (because of gear compression), you must have landed so deploys touchdown spoilers. Arm in the air. I see Thomas has explained "SET". Not that, apart from those added by FSUIPC, all the controls are defined in the Sim. They are not defined or named by FSUIPC, so quite often when the name isn't clear, the only way we have of determining what it does is to try it. 😉 Pete -
In all cases of FSUIPC7 apparently terminating (crashing), please always look in the Windows Event Viewer to see if any crash information was captured. To do this search for and execute "Event Viewer" via the task bar bottom left, then look in "Windows Logs -- Application" for Errors (red icon) mentioning FSUIPC specifically. Pete
-
I use yoke and pedals with lots of movement, but as these are part of a Piper Arrow cockpit I wouldn't bother with an airliner. From my brief experiences with many of the aircraft (actually, 787 included) I feel that only the C152 is anything like a proper aircraft at present -- lucky for me as it's probably the closest match in performance and controls for my cockpit. But I can understand your need for greater central control with any axes with limited movement. I'm just amazed that this can't be achieved with MSFS as it is. it does imply that the flight models are way off at present. Pete
-
I won't have a chance to look at what Prosim V3 is doing till Monday, but to be honest I can't see how it can be anything else but its dependence on something it expects SimConnect to provide, whether via FSUIPC offsets of directly though its own SimConnect link (which both V2 and V3 have even if you have selected FSUIPC support). Without MSFS running FSUIPC is really just dormant so it isn't adding to any processing time. it will be some part of ProSim itself. I'm a little surprised you haven't actually asked the ProSim chaps, but I suppose that you shouldn't really at present as it isn't actually supporting MSFS at present (and V2 never will of course -- meaning you'll have to update if you really want to use it in the future with MSFS). Anyway, I'll post details of what I find here, but not till Monday at the earliest. Pete
-
Camera Events Not Working (Multi-Key Presses?)
Pete Dowson replied to pilotjohn's topic in FSUIPC7 MSFS
There are added FSUIPC controls you can assign which press a key and release separately. Check the additional FSUIPC controls section near the end of the Advanced guide. . You'd need a sequence of assignments, maybe in a macro or Lua plugin. Pete -
Useful. thank you! Pete
-
Understood. But no matter what the aircraft it always seemed wrong to have control axes which cannot reach the full range of the surfaces they control. I realise you seldom need those extremes, but there may come a day ... I've always thought that the method of flattening (making less sensitive) the main areas of normal use (centre and middle ground) at the expense of very steep and sudden changes at the extremes was the best compromise. If you draw a graph of what you achieve by chopping off the extremes, as you will be doing using Thomas's method, you'll probably find it very similar to the rather flattened centre/mid zones you get using my method, just with more movement needed. Of course, i suppose on some joysticks the amount of movement you have in the first place isn't really that great, so i'd concede the point there. On the other hand with a decent yoke with full fore/back, left/right movement capability such measures are definitely less needed, and probably not needed at all. Pete
-
Camera Events Not Working (Multi-Key Presses?)
Pete Dowson replied to pilotjohn's topic in FSUIPC7 MSFS
I think John is looking at changes in this area -- not sure if it will solve that need though. More when done and tested. Not sure how this is related to the previous ...? Pete -
I can check this with ProSim V3 tomorrow (my 737NG cockpit is now completely converted to V3, I can't check V2 without a lot of changes on the 7 PC used as part of the setup). What I will do is just run ProSim V3 plus ProSimDisplay with a couple of panels displayed, and run FSUIPC7 for it to link to. I don't have MSFS installed on that system yet -- it looks to be a long time before it will be suited to proper cockpit use. But you say you don't need MSFS running in any case 9though that still puzzled me). If it looks to be very slow dealing with switch changes on any of the panels then the best way to find out whether it is because it is trying to deal with something in FSUIPC is to enable ipcRead and ipcWrite Logging in FSUIPC7's' log options. The log should show what it is asking for. I strongly suspect that it needs things happening which just won't happen without the Sim actually running, and, if the delay is the same with MSFS running, these things aren't happening then either. In other words, it needs things not yet implemented in MSFS Simconnect and therefore not supportable yet in FSUIPC. Pete
-
Yes, sorry. There were important updates for new facilities (to do with plug-ins) which needed later versions of Windows libraries. You'll be okay sticking with an older version. Pete
-
You can edit assignments in the INI whilst FSUIPC is running, but to invoke the changes you then need to use the "reload" button on the appropriate assignments tab, so that it reads them. Pete
-
It's GoFlight's own driver, and has its own assignments etc. It works completely independently of FSUIPC. The GoFlight facilities in FSUIPC have always been just a more flexible alternative to GoFlight's own provisions, but FSUIPC doesn't handle the displays or LEDs on some Goflight units without using the provisions for GoFlight units in the Lua libraries. The GoFlight EXE shouldn't be used if FSUIPC's facilities are being used instead. Pete
-
Well, it most certainly won't do anything useful. Mostly it must be waiting for certain things to be indicated in the FSUIPC Offsets. Things that cannot be there till MSFS is running -- running properly, ready to fly. I suggest you go ask ProSim support about what should be occurring before there's actually any simulator to talk to and get information from. FSUIPC will just be dormant, waiting. Pete
-
It looks exactly like the edit you've made to your FSUIPC7.INI is not in the FSUIPC7.INI file you are actually using. If there were really two assignments to the same button then you couldn't edit it in the options, and there would be a banner at the top telling you to edit the INI. The log confirms this with the entry without the condition. So please check the FSUIPC7 folder and see that you have one file called FSUIPC7.INI and that is the one you are editing. Pete
-
Actually, I've just tried a few combinations and can't get any to work at present. Pete
-
Yes. Just uncheck the "Exit with FS" setting in the Options menu. BTW I run MSFS with a "fastload" option, to bypass a load of the advertising stuff at the beginning. The desktop shortcut for this on my MS Store -installed installation is: C:\Windows\System32\cmd.exe /C start shell:AppsFolder\Microsoft.FlightSimulator_8wekyb3d8bbwe!App -FastLaunch in other words, using the Windows shell. I can't find a more direct shortcut. I've not tried the above in a "RunIf" line and currently I'm not sure where the "" need to go -- but it will need some because there are spaces. You'l have to experiment. Pete
-
Yes, thanks spokes2112. Seeing as it is only a 0 or a 1 anyway, a "B" or "W" prefix would also work. So really the only thing wrong with codatcrl's solution: is his format with "0x" before the offset value -- a habit from C++ programming, perhaps? Pete
-
I don't think ProSim does get AI data from FSUIPC, but I'm not sure. Have you asked them? You know you can check yourself, using the TrafficLook utility we provide? see: Anyway, I'll check here using TrafficLook to see if we do manage to distinguish the User aircraft among the traffic reports received. It should prvide a "TRUE" result to an "Is User Sim" value. ... [LATER] Yes: it looks like SimConnect data for aircraft does not provide proper indications. It looks like neither the "Is user sim" nor the "on ground" indications are being provided. I hadn't noticed the user aircraft being listed as AI before because although i was on the ground it was shown as airborne. seems all aircraft are. This will need fixing in MSFS. It will be reported. Thanks. BTW it wouldn't make any difference whether ProSim got the data from FSUIPC or directly from Simonnect. Pete
-
But FSUIPC is not involved in interfacing to your CPFlight or Engravity hardware -- ProSim has its own drivers for those -- and it most certainly has nothing to do with your overhead panel which is effectively part of ProSim. But FSUIPC does not interface to those devices or the overhead touch screen. ProSim will be using FSUIPC to talk to MSFS, not to those devices. This is why I want to know what part you think FSUIPC has in all this. FSUIPC is not an "IO Module" it is an Interface to the simulator. You seem to be assuming ProSim connects to your devices, including your touch screen, through FSUIPC. I am trying to understand why you think this. Has someone in ProSim told you this? We need to make sense of reports like yours so that we can understand what might be going wrong. At present i still don't understand your set up. You say it is not complicated, but seem to think it operates in a way it cannot possible do. You also said, earlier, it is the same whether MSFS is running or not. But as FSUIPC is the interface between ProSim and MSFS, there can be nothing happening in ProSim, even for your switches and touch screen buttons, until MSFS is running. ProSim will be waiting on results in Offset values which FSUIPC has to read from MSFS. I use ProSim for my hardware 737NG cockpit and I know it cannot really do anything at all till the sim is up and running. Pete
-
SimConnect is incomplete at present, and has many problems itself. There's also a lot missing and/or undocumented. FSUIPC7 is released as a Beta for wider user testing, to aid in the development of the interface and more feedback to Asobo/Microsoft, so thank you for participating. But please don't expect everything to work properly yet. In fact we've been quite surprised at how much does work already. Support for FSUIPC7 is here, in the special subforum for MSFS + FSUIPC7 -- you must have missed seeing it, but i've moved your post for you. As you have some logs which may be useful, but on a forum not used or necessarily accessible to FSUIPC Support, could you please post them here? Best to ZIP logs if they are of any size -- they ZIP up really well, being all text. Thank you. Pete
-
Hardware is hardware. We are needing to talk about software -- specifically where the software fits in. What is doing what to what? All my hardware works by itself but accomplishes nothing without software. I'm not implying your hardware is "slow". How can it be? I assume it is just switches and wires and things. You seem to be assuming I know all about your set up and what it is doing, how it is arranged. Please do not make any such assumptions! But that is all software (well, apart from the touch screen itself). So where does your super-fast hardware come in? And I certainly don't need to see pictures of the 737 overhead -- I have a proper hardware one myself in any case. Sorry, this is going in circles. I thought you said the overhead display was ProSim's display, which would be from "ProSimPanel.exe". If not,what software are you using for your touchscreen display? And why keep on about your "fast hardware"? If that display is ProSim's, then FSUIPC is not involved. The display and ProSim737.exe talk directly to each other, NOT via FSUIPC! I'm afraid that so far you've explained nothing, but only succeeded in confusing things more and more. I think you need to start again and explain exactly what part you think FSUIPC is playing in all this, and what on Earth your 'fast hardware' has got to do with it. Pete
-
Try setting the active instead. I've not had a chance to try them all yet. The active BCD16 values work okay with my VFR cockpit so possibly that aircraft is set for 25khz spacing. My hardware only has older radios. Pete
-
I think you mean offsets 05C4 to 05D0, which are documented clearly to be in hz, so 123.245 would be 123245000. BTW it looks like MSFS can be switched between 25khz and 8.33 modes, but possibly that depends on the aircraft and the radios fitted. Pete
-
Sorry, you only now mention any hardware. does this hardware have switches on it? Are the switches assigned in FSUIPC? What are they assigned to, exactly? How do they relate to ProSim and its overhead display? In which part of all this is your "delay" occurring? You need to realise that we cannot guess what you are doing or what you are dealing with. you need to say exactly what it is you have configured and how and where your problem is. For example, if you don't run ProSim or the overhead display, and if FSUIPC is programmed to change offset values by your switch changes, do you see the results of your assignments in FSUIPC? Is the delay between the switches and FSUIPC, or is ProSim not reacting to the changes in the offsets fast enough? Also, where is everything located? FSUIPC on the same PC as ProSim? Where does WideFS come in? You see, we know nothing about what you are doing! Pete
-
FSUIPC Not Installing
Pete Dowson replied to Pedro Ramos's topic in FSUIPC Support Pete Dowson Modules
Seems then that the Registry entry telling programs where your FS9 is has been deleted or broken. Didn't the FSUIPC Installer ask you to find the FS9 EXE manually? If that doesn't work then there are two choices: 1. Re-install FS9 so that the registry is corrected, or 2. Find a utility which will correct the registry. Look for the registry repair utilty. Try http://www.flight1.com/view.asp?page=library Pete