Pete Dowson

  • Content count

  • Joined

  • Last visited

  • Days Won


Pete Dowson last won the day on February 8

Pete Dowson had the most liked content!

Community Reputation

104 Excellent


About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL

Profile Information

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

Recent Profile Visitors

16,676 profile views
  1. Sorry, Mario, for grumbling. That actually was the only item outstanding. I don't like making a main release knowing there may be a problem, that's all. But I realise you couldn't help a lot because of other commitments. So i shouldn't have grumbled. And no one was actually complaining about the release not being forthcoming, so there was no need. Hope you do locate the problem some time, though. I suspect it's getting stuck in one f those functions (debug/trace will surely show) and not actually ever reaching the event.sim and able to ever wait. Pete
  2. The very first control in the assignments drop down list, in FS controls, is <custom controls>. Have you not looked. After you select that you can enter the custom control number (which you have to wok out from the PMDG DDK document I told you about), and, if needed, a parameter to go with it. Their control list (controls are also called "EVENTS") will probably be different for each of the three aircraft, so you probably need to assign them in profiles, one for each aircraft type. Who mentioned anything about Lua in this context? Pete
  3. I refer you to page 36 of the FSUIPC4 User Guide, where it clearly says: "These “mouse macros” do not actually use the mouse at all, but use a set of “mousetraps” to identify how your own mouse use calls routines in the panel coding, and then attempts to replicate it." Now, since they do not use the mouse at all, why would it matter where it was? The whole point of them is to do the same thing as what you can do with the mouse, but even without the relevant switch being displayed, or off-screen in a virtual cockpit. For more information I suggest you read the User Guide, at least. There's also more details in the Advanced User's Guide. You should also note that mouse macros aren't usable on most modern add-on aircraft. Even the PMDG aircraft will not support them on all switches and knobs. But in the case of the three aircraft you mention, pretty much ALL of them are definitely accessible using the PMDG <custom control> numbers which can be worked out from their published SDK -- in the .h file in the aircraft's SDK subfolder. Pete
  4. Exactly as you already said on Sunday -- see your message above, Sunday at 04:02pm. Pete
  5. The above is what you posted as an example of the problem. are you now saying, nearly one week later, whilst I've been delaying 4.963 so I could try to find and fix a problem, that you never actually ran such a simple script after all? :-( No. All Lua scripts loaded by FSUIPC (and WideClient) have ALWAYS been one thread -- not per "lua file", just the ones loaded directly by FSUIPC. Your "require" function just makes the named script load into YOUR thread, so you can call routines inside it. Nothing of this has ever changed. You can't call functions which are not in your thread. If all 4 of your scripts ask for "simFunctions.lua" to be loaded, then it will effectively act like it is loaded 4 times, once in each of those threads. The functions in that Lua then become the same as any built-in library functions, like the ipc. and event. ones. That's all require effectively does, add yet another library of functions. I think your scripts are getting stuck executing something within your thread, maybe inside SimFunctions.lua. Why haven't you used the Debug/Trace facilities to see where it is stuck? It obviously is NOT simply waiting for the Sim CLOSE event like you seem to think! I have to give up on this now. I've delayed an important release now for six days, for nothing. You've not supplied any useful information and not even run the simple test I provided. Pete
  6. No. Memory is nothing to do with it. Why would you even suggest such? where does 'memory' come in? Without knowing what "ipcinit.lua" is doing I cannot help at all. I don't know why it is so secret! Nor do I understand why it needs to run before much else is ready in FS -- most everything should be started at ipcReady or later. When ipcInit is executed FS isn't ready at all. All it is suitable for is initialising some FS offsets. Pete
  7. Ah, you mean the DLL.XML file, not FSUIPC4.DLL which is a DLL file!!! All you proved is that something is wrong with that DLL.XML file, or it is loading something bad! Just start with the one made fresh by FSUIPC, and add the items you need one by one and test each time. Do NOT include Vistamare! You've also proved you do NOT have a problem with FSUIPC, but with something else you've added. Pete
  8. Well, you did something wrong because the file was not only written BUT THERE WAS ONE BEFORE -- even though you say you deleted it!!! See: Found Prepar3D.CFG in "C:\Users\riis1\AppData\Roaming\Lockheed Martin\Prepar3D v3\Prepar3D.CFG" Now checking DLL.XML ... ... There is a previous DLL.XML, checking for FSUIPC4 section. ... FSUIPC4 section already exists but will be replaced. (for FSUIPC4, without Loader) ... FSUIPC4 section of DLL.XML written okay The full folder name is C:\Users\riis1\AppData\Roaming\Lockheed Martin\Prepar3D v3\ Okay. FSUIPC4.DLL, FSUIPC4.INI and FSUIPC4.LOG, and the FSUIPC Documents subfolder, are all absolutely guaranteed to be there, if it appears in game. So now I'm sure you are not looking correctly. This confirms you are really in a mess when it comes to dealing with files and folders: Exactly HOW did you do this "switching"? Pete
  9. Ah, that's different. So the installer is not making one? Either you forgot to rerun the FSUIPC Installer as I told you, or you are looking in the wrong folder. Look at the FSUIPC install log. Pete
  10. Okay. In that case it seems that SimConnect is not loading it. Please look in the FAQ subforum for a thread which tells you how to make a SimConnect log file. Do what that says, then try again, and show me the SimConnect log it produces. Pete
  11. Why haven't you deleted the Vistamare entry? Try deleting or renaming the DLL.XML file completely, then re-running the FSUIPC installer. Pete
  12. I don't have FSX as such any more, only FSX-SE. However, the control list didn't change from how it was in FSX ACC versions. Your controls DLL is SP2 I think. You didn't answer me about how you determined the drop down doesn't go further than 66860 when it isn't ordered by number. Didn't you just look in the B's? There's no later version for FSX other than that installed for Acceleration., which would be build 61637. I think there must have been new controls added in Acceleration to support the new aircraft and their cockpits. But my only version of FSX for a long time had been Acceleration. When I made the controls list that was all I could go on, so I'm sorry if it doesn't differentiate between FSX RTM, SP1, SP2 and Acc. The base control list I started with was the old one, dating to just after Acceleration. I'll add a warning about that. You can't just change one module in FSX. To get the later version you'd need to update to Acceleration, or change to FSX-SE. If there's a control missing in CONTROLS.DLL it means it doean't exist, isn't supported, isn't implemented. This is why FSUIPC doesn't have a fixed list but one generated for the version of FS you are using. Pete
  13. Vistamare crashes here with P3D. Why haven't you deleted that? Migration tools are a menace. Why are you using one? Pete
  14. 4.961 is out of date and unsupported, and the list of controls currently spplied was updated some time before, last year I think. It includes the new ones for P3D versions 3 and 4. The drop down in FSUIPC isn't in numerical order, but alphabetic, so how do you work that out? The drop down list is obtained directly from the CONTROLS.DLL installed as part of FS. Is your FSX out of date too? Pete
  15. If you have all aircraft in profiles, just use the appropriate [Auto.profile] sections to say whether to load it or not. Otherwise, add an aircraft identity check at the start of the Lua plug in, restoring instead of changing the values if the aircraft name matches one you don't want it applied to. An event triggered by changing aircraft name would ensure it knows. Pete