Pete Dowson

Moderators
  • Content count

    30,916
  • Joined

  • Last visited

Community Reputation

91 Excellent

2 Followers

About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male
  • Location
    Near Stoke-on-Trent, UK
  • Interests
    Flight Simming, Steam Railways, Table Tennis

Recent Profile Visitors

15,513 profile views
  1. First, please ALWAYS post support questions to the support forum NOT to the assorted reference subforums which are for reference. It won't get replies there and might be missed altogether. You are lucky I saw it! Second, the FSUIPC installer relies on the Registry correctly stating where your FSX, FSX-SE or P3D is installed. As you can see from the log extract you showed this isn't the case -- none of the valid places for that path name are in the registry. It looks like at some stage after installing FSX-SE you restored the Registry (maybe Windows?) to an earlier state. I can't think was else would lose the entries required. If the Installer cannot find FSX, FSX-SE or P3D through the Registry it will ask you to find the correct place (with FSX.EXE or Prepar3D.exe) and it will then even fix the Registry for you. Didn't you get this option? It doesn't care where you run it from provided it in on the same PC. It is totally dependent on the correct entries being in the Registry. All proper installations of FSX, FSX-SE and P3D do place all the details needed in the Registry. You have somehow got that messed up! If that is where you put the Installer (the EXE) then the ONLY file it "dumps" in the same folder is the Install log, which you showed a fragment of. Next time you post a log please show ALL of it. Fragments do not show all the necessary information and just makes helping you properly near impossible. I suggest you uninstall FSX-SE and get Steam to reinstall it. That should fix the registry. And if I were you I'd install it anywhere but in Program Files or the X86 version of it. Folders in those locations are protected by Windows and you'll then have much difficulty with many add-ons. Also, FSX-SE is 32-bit program and "Program Files" is the repository for 64-bit programs! The X86 one is for 32-bit programs. It might well be worth uninstalling Steam as well, and starting from scratch without Steam going into Program Files. Pete
  2. Yes, of course. That's what the parameter is for. Yes. All the drivers I've written, for FlightLink EPIC stuff many years ago, and for all the PFC stuff a little more recently, does this. Whether you encode for fast and slow separately (it isn't needed for some types of values), it is always best to display locally immediately, send values at sensible periods to the sim (certainly not faster than it can display), and also ignore values sent for display from the Sim until the user has stopped turning the dial for a while (1/2 to 2/3rds second in my experience). This applies even to the fine encoders I have. Pete
  3. I've not opened all that stuff, I'm not interested in proof that it goes wrong because I believe you. Did you try the reconnection to SimConnect after changing to multiplayer as I suggested?I And what about just showing me the FSUIPC4.LOG? I deliberately added a line which logs the user aircraft ID whenever a change is noted. I did tell you these things. Please refer to my previous answer. BTW are you the only person out there using multiplayer, with FSX or P3D? I'd be interested to know if this problem is specific to P3D, because if it is it will be up t Lockheed-Martin to fix it -- FSUIPC is doing the same with both FSX and P3D. There is no difference required in any of the SimConnect interface it uses. Of course it may be specific just to your system, but I've no idea what the reason could be for that. I think it would still need the P3D guys in L-M to resolve it. Pete
  4. Yes, it certainly is. "Offsets" are hexadecimal numbers in the range 0000-FFFF which represent positions inside FSUIPC memory which contains data. You can normally read all of them, and write most of them. Writing to them usually makes some actions happen -- FSUIPC detects the write and determines what to do about it by the offset value. The PMDG offsets aren't writable -- they only provided a way of reading all their data so it could be displayed. "Controls" (also known in FS as "Events" or even "Key Events", are numbers representing an action, a request to be passed. The assignments you make in FSUIPC or in FS, whether for keys or buttons, are to controls. They don't represent any data specifically, but a thing to be done or set. They can provide data (via the parameter). I think pretty much all of the PMDG cockpit switches and dials have their own assigned custom control numbers. That's because Lekseecon was programmed to do this, to interpret the offsets for you. No. PMDG did things differently. It wasn't until later versions of the 737NG that you could do anything like now -- no custom controls, no data readouts. The stuff they did later and published in the SDK was an eventual concession to cockpit builders and the like. But I still don't believe it's the right path to take for full hardware implementations of cockpit controls. I use a flight model with no cockpit at all. My cockpit support is external, via Prosim737 at present -- it used to be Project Magenta. There's also SimAvionics. Pete
  5. None of the PMDG offsets are writeable -- they are just readouts for display. You have to use the controls they provide. Pete
  6. FS and FSUIPC handle frequencies xxxx.x (1234.5) , but there are many add-on radio stacks which only support 4 digits. For the PFC serial port stacks, I had to use one of the other ADF buttons to switch between displaying (and adjusting) the xxxx (1234) and xxx.x parts (234.5). Pete
  7. If there's a limit it isn't imposed by anything in FSUIPC. FSUIPC simply calls the appropriate functions in the panels interface to FS, same as a gauge might. That is related to how long to allow if you try to re-run the same plug-in, to alloww it to terminate before killing it and starting it again. The list is the same for each in any case. I suspect they are created by a common component, not a specific gauge. Maybe a DLL for that aircraft And how are you stopping the gauges not being checked from running in any case? You'd need to keep editing the PANEL.CFG file and reloading the aircraft. Pete
  8. The PMDG 737NGX and 777X add-ons do NOT use FS systems, and certainly not the default APU. Both of those addons have their own mapped offsets which are documented in other documents into your FSUIPC Documents folder. But you must also set some parameter correctly in a file associated with the addon to make it export those values. I'm afraid I cannot support PMDG aircraft since I do not use them and don't know enough about them. Check the SDK folder in your PMDG folders, maybe there's help there. Else ask in the PMDG forums. The offset lists predates things like Lua by many years. Are you volunteering to do all the work? The whole system you are trying to use is aimed more at system implementers and programmers who have at least learned some basic programming. One of the basic things you need to understand in all programming languages is the types of numbers you can have. You only have to tie the number types together. In the case of 0B54 the words "32-bit float" occur in both the description in the offsets list and the description of the ipc.readFLT function. Why not match these up as I suggested? Pete
  9. Why on Earth are you guessing? UB = Unsigned Byte (i.e. a single byte). There is a column in the offsets list which surely isn't hard to understand. It is headed "Size". The size is in bytes (the offset numbers are actually byte numbers, in hexadecimal). So 0892 is two bytes, or a Word (W). And the names UB, UW and so on are described in the Lua library reference, for each one. So why not simply try to match the one to the other? Surely that is simple enough? If not, why not? In the case of 0892 a UB would actually also work because the value there should never exceed the capacity of that one byte (0-255). 0B54 is listed as a 32-bit float. Why not find the correct read function in the library to match that? It isn't hard, and it certainly is not SD. (Both parts of SD are wrong -- an RPM can't be negative so it isn't signed, and it isn't a DWORD (D) which is a 32-bit integer). Do try looking things up. It takes more time for you to come here posting such questions and for me to see it when they can be so easily answered yourself faster with just a little effort! Pete
  10. That's not surprising when you are reading 34B0 as a two signed DWORD (32-bit) structure into one variable, and discarding the other. If you refer to the offset list you'll see 34B0 is a double float value (64 bits or 8 bytes) which you'd read using ipc.readDBL. No way can you read just half of it in the wrong format and expect it to be anywhere close! Also it is in metres (as, again, you'd see if you referred to the offsets list). So just multiply by 3,28084 to get feet. A stabilised jet engine is one with more or less the correct N1%. Mostly the Start switch trips automatically from GND back to off just as it reaches around 20% I'd check for something between 18 and 22, then wait another second or two. Pete
  11. The FSUIPC installer wouldn't have created that. There are other installers for other programs which use the Modules folder. Pete
  12. I don't have a program called "FSClient". Do you mean WideClient, the remote part of WideFS? Why do you need both? WideFS supports FSUIPC applications on a separate computer. It doesn't need a registered FSUIPC to work with. And FSUIPC supports applications on the main FS PC without registration. Purchase of FSUIPC is only necessary if you want to use any of its user facilities or plug-in capabilities, not for application support which has always been free. Anyway, the package deal is on both the FSUIPC4 and WideFS7 purcjase pages. Just select the package where is says "Select Package" just below the picture icon top left. The selection to the right of those words contains the bundle which you select. Anyway, I think you need to read more of the PanG manual. It just downloaded it to take a look (I've never used PlanG). For FSX PlanG doesn't need either FSUIPC or WideFS to work over a Network, it can use SimConnect which is preferred. It's up to you. If you are likely to want to use FSUIPC/WideFS for other things, go for it. But I'd always check the actual needs first if I were you. Pete
  13. Not in FSUIPC itself, but I think someone wrote a Lua plug-in to do that a while back ... ... Yes, take a look in the User Contributions thread I think the thread entitled Throttle manager to allow axis forwardreverse toggle Pete
  14. Assuming that IP address is correct (check), it looks like a firewall type block on one end or the other, probably the server. Pete
  15. For help with that you'd need to show me the WideServer.log and the WideClient.log files. An updated FSUIPC won't change it. Pete