Pete Dowson

That is almost certainly only implemented locally to the gauge. There'd be no FS control for it as it isn't implemented in FS, only in the gauge. Mouse macros work by calling the internal code of the gauge directly. There is documentation on how to create these -- see your FSUIPC User Guide and Advanced Users guide. If you browse the User Contributions subforum you'll see lots of folks using these, but they don't apply to all add-ons -- less and less these days. Local panel variables work inside local panels, or gauges. They are named variables used by the code in the gauge. If you can find the name which stores the state of the switch you may be able to program a button or key to write values to it using a macro. Again, it's all in the documentation. You can list the local panel variables using an assigned FSUIPC control, and you can log them to screen as they change using one of the supplied Lua plug-ins. Pete

z8 and z9 versions were virtually identical, so I wouldn't worry about it. FSUIPC3 is no longer being developed. Pete

No. Why? Pete

They are breakpoints for P3D debugging, not really FSUIPC exceptions. I can get them when using a debugger even without FSUIPC loaded. Just tell it to continue. FSUIPC does not use any managed code at all. It is all plain C with a few snippets of ASM. And of course the Debug version is not issued so there's no debug code supplied and no PDB. Pete

FSUIPC was certainly told that FS was closing. I've already explained that if it crashed BEFORE it was told to close then FSUIPC could not possibly show the lines in the log for a tidy closure. If it crashed at all it must have been AFTER it was told to close, I'm not going to explain this again. You are trying to refute something which is a certainty. Plwease desist. I referred to the crash identified by Windows. Remember? FS was closing normally. Go and read what I said again. FSUIPC was closed normally. If the crash you got was associated with the same session as the log (and I've seen no evidence that this is the case) then it was AFTER FS was being closed normally and FSUIPC had tidied up and closed the log, normally and without a crash beforehand. Oh dear, go read it again "Such a log" was in answer to your statement about a log for a supported version! You seem to be deliberately misreading and looking at things out of the context in which they occur!. Yes, and that was true. It was successful until FS was closed. The closure was instigated BEFORE the crash! Please just read things more carefully and STOP quoting me out of context!. It is that which makes the contradictions as you would clearly see if you were just a little more careful and less deliberately argumentative. I am locking this thread now and it is just going in circles. If you do actually get a crash identifying FSUIPC again and can supply the data please start a new thread. Pete

By "debug mode" do you mean Event logging? What engine system function are you trying to change? Many individual gauges on both default and add-on aircraft do't use FS events. The switches are programmed only internally, in the gauges themselves. For those you may hsve to either use Mouse Macros or Local panel variables (L:Vars). Mouse macros don't work on a lot of recent add-on aircraft because they are not written in C/C++ using the Microsoft gauge SDK. L:Vars are quite commonly used on gauges written in XML. It is also possible that there is no way to operate switches without using a mouse. Pete

You need to post support questions here, the support forum, not to the assorted subforums. Otherwise generally they'll either be deleted or not get attention. I've also re-titled it, as a title like "fsuipc" is in no way helpful to anyone. Please read the part of the WideFS user guide which explained how to configure your network. It tells you what to do there. It's the part with a RED line asking you to at least read part of it! Pete

Ouch! This would make FSUIPC act as if the FS version it was running inside was something completely different (P3D version 1.3, which it doesn't even support nowadays!). No wonder it crashed! Okay, and that's the same version for the proper Prepar3D.exe version 3! In the next update of FSUIPC I'm logging these things. Here's an example for a properly installed and unmolested P3Dv3: ********* FSUIPC4, Version 4.948a by Pete Dowson ********* Prepar3D.exe version = 3.0.10.14945 ... (other lines, omitted here) 795 ------ Module Version Check ------ 795 acontain.dll: 3.0.10.14945 795 api.dll: 3.0.10.14945 795 controls.dll: 3.0.10.14945 795 fs-traffic.dll: 3.0.10.14945 795 G3D.dll: 3.0.10.14945 795 sim1.dll: 3.0.10.14945 795 visualfx.dll: 3.0.10.14945 795 weather.dll: 3.0.10.14945 795 window.dll: 3.0.10.14945 795 ---------------------------------- At least, this way, I'll spot such odd things like yours right away! Pete

The crash is happening because although the main P3D exe program appears to be the correct, the modules which FSUIPC needs to hook into are not the versions which should be installed with P3D. This shows the results of it attempting to hook into P3D: 484 ------ Setting the hooks and direct calls into the simulator ------ 484 Failed to find CONTROLS timer memory location! 484 ### Failed to obtain SIM1 Frictions access: no frictions facilities available! 484 Reason 6: SIM1 base=77C00000 484 FrictionAddr=77C30108 contains 100FF200 484 BrakingAddr=77C313C8 contains 8B088B5E 484 Hook Error: can't find .37 in SIM1.dll 484 Hook Error: can't find .37 in VISUALFX.dll I don't understand how your installation can be so different. There are lots of folks using FSUIPC quite happily with P3Dv3. Here's part of a normal FSUIPC loading log:for P3Dv3: 1857 ------ Setting the hooks and direct calls into the simulator ------ 1857 --- CONTROLS timer memory location obtained ok 1857 --- SIM1 Frictions access gained and basic values patched 1857 --- FS Controls Table located ok 1857 --- Installed Mouse Macro hooks ok. 1857 --- Wind smoothing fix is installed 1857 --- SimConnect intercept for texts and menus installed ok 1857 --- All links okay (except older global weather setting method) I'll see if I can add some extra logging, before the hooks are attempted, to provide the details of the P3D DLL modules it needs to be correct. Meanwhile, perhaps you could check one or two yourself? Go to the main P3Dv3 fold and find these modules: ACONTAIN.DLL API.DLL CONTROLS.DLL FS-TRAFFIC.DLL SIM1.DLL VISUALFX.DLL WEATHER.DLL WINDOW.DLL Right-click on each and select Properties. Then "Details". Check that they are all shown with File Version 3.0.10.14945. Pete

Sorry, I don't know anything about Wideview, it isn't my program. It is by Luciano Napolitano. I assume there's a separate support forum or website for it. However, I wouldn't have thought it would notice any difference between them. Pete

Well, maybe not. But it isn't a question for Paul Henty and his .Net DLL either. I don't often notice messages there, Paul picks them up. Windows controls the Registry. All of the information you need to locate FS is in the Registry. Therefore you need to use functions provided by Windows to access the relevant parts of the Registry and obtain the information to locate FS. "API" means "Application Programming Interface". You are programming an application to interface to Windows, therefore you use Windows APIs. You'll find all of the Registry API functins start with the letters "Reg" which makes them easy to spot. I cannot teach you Windows programming so you'd need to do some work on this if you are new to Windows programming. For the Registry functions, check out this section in the MSDN: Registry Reference Pete

The crash data isn't timestamped. However, it is was timed and dated for the same closure which FSUIPC was logging, then the crash could not possibly have been during normal FS flight mode -- FSUIPC was closing down tidily which can only be a result of FS signalling that the session was closing -- SimConnect sends an "End" to all of its clients and Windows itself calls an exit function in the DLLs. Now the closing of FS may possibly not have been of your doing, but I don't know anything else which would instigate it unless you had some application sending the CLOSE message or a Ctrl-C keypress, but it cannot have been actually instigated by the crash in FSUIPC which must have been only in the exit routine, after pretty much everything was closed in any case. If the crash data was for the current version of FSUIPC I could have pinpointed the actual place in the code where that was. But it would not explain why FS was closing. You've not actually supplied such a log yet. Suspect all you like, but the loading error you've shown is a known problem with FSX SimConnect, which was much worse in the original release of FSX and which Microsoft did try to solve in SP1 and more in SP2/Acceleration, but they never fully solved it. It is all to do with the "Trust" system they used, which thankfully was dropped in ESP and P3D. All the information I know of about the loading warning you are getting is in the FAQ thread I pointed you to. I doesn't affect everyone and in all of the cases ever reported it is a temporary state. You just need to allow it to continue to load FSUIPC. For some folks it has taken a few attempts before it disappears, but it always does. If you do ever get a crash which indicates the current version of FSUIPC (now 4.948 incidentally) then please do report it here, with the Windows crash data AND the FSUIPC4.LOG, as far as it got. Pete

You read it. There is no issue at all in my software. The log clearly shows a normal closure -- this part here, the proof: 5923016 System time = 23/10/2015 18:56:19, Simulator time = 13:55:03 (22:55Z) 5923016 *** FSUIPC log file being closed Minimum frame rate was 11.0 fps, Maximum was 16.8 fps Minimum available memory recorded was 2693Mb Average frame rate for running time of 5777 secs = 16.0 fps G3D fix: Passes 11776, Null pointers 0, Bad pointers 0, Separate instances 0 Memory managed: 5281 Allocs, 5281 Freed ********* FSUIPC Log file closed *********** After that last line FSUIPC was no longer running. It exits. Additionally you can clearly see it closed at 23/10/2015 18:56:19. If you look near the beginning of the log you'll see it started a little before 23/10/2015 17:17:37. You do the maths -- 1 hour 38 minutes and 42 seconds, plus start-up time. FSUIPC is simply not involved. You have a different problem. I hate it when there are problems in FSUIPC and do my utmost to eradicate them, but it does come in for a lot of incorrect accusations, and I'm sorry, yours is one of them. I cannot help with your SIM1 crash. As for a supported version of FSUIPC you have only shown a log of a successful run. If you look through the History and Changes documents supplied with current versions you'll see FSUIPC has gone through many changes and some of them are error or bug fixes. I fix bugs and consequently release an update. How else do you think I can proceed? There's no way I can resurrect an old version just to prove one way or the other that your original report was due to a bug now fixed. The proof is in using a fixed (and supported) version! Pete

Flightsim.com has no business supplying old versions. I have no control over that website, it is nothing to do with me or FSUIPC. The only legitimate suppliers for my programs are here, in Download Links subforum, or on Mr. Enrico Schiratti's site -- that is his but he links to here. The links on the sales sire here at SimMarket are to the Schiratti site. That's the occasionally occurring timing bug in the SimConnect loader, which is well documented as detailed in the FAQ subforum -- see the thread entitled "fsx fails to run after fsuipc4 first installed". It is not in FSUIPC, it occurs before FSUIPC has even started. You should use the Installer in any case. 4.947j was an interim update supplied in another thread here for some other specific testing. The current release is 4.948 and you need to run the Installer if you are updating from such an old version! Pete

You posted your question, with an unhelpful title, in the wrong place. I've moved it and re-titled it for you. Please use the Support Forum in future, and use more helpful titles. Are you are programmer? If not I wouldn't try. If you are, then you just use the normal Registry API. Please refer to the copious Windows API documentation available on-line. The places to look in the Registry are clearly shown in the Installer log. Isn't that enough help? Pete

I don't know any flight data recorder which uses FSUIPC, but whether it does or not it is obviously checking whether the Flight Sim is FS9 or FSX or ESP. You need to change it so that it accepts P3D as well. I cannot do that for you. If it is yours you should be able to change it. Pete

This is definitely not at all related to FSUIPC. Because you have Windows Explorer's folder options set to hide filenames from you. Change thast option or you'll never know the real file names! This is mentioned in the FSUIPC User's Guide but of course no one reads that. :sad: So, that tells us two things: 1. FSUIPC has never been run since 23/10/2015 17:17:37 2. The log shows everything worked fine and FS closed norrmally after a session lasting nearly 1 hour and 40 minutes. This shows that no DLLs or EXEs were loaded by SimConnect at all. So your crash is nothing to do with either FSUIPC or any other add-on which is being loaded by SimConnect. You have some other problem. I am sorry, but I cannot help with this. You might try the FSX CTD forum over in AVSIM. Pete

They are in version 4.948, just released. Check the changes document. Pete

Okay. They're on the list. I have a revised version almost ready to go out. I'm just awaiting some test results. Pete

I didn't really need a screenshot, merely a reference (or proper names). Found them now. would 16-bit integers be okay? I don't really want to use more space than necessary, and there hasn't been any demand for this in the 10 years since FSX was born. Pete Pete

Sorry, I don't see those in the FSX SimConnect SDK. Pete

Yes, of course, by program. Read the values, save them, write them back when needed. If you look in the Lua examples provided in the FSUIPC Documents folder, you'll find an example of using Lua plug-ins to link two PCs running FS and making one slave of the other, mimicking its flight. See "SlaveServer", "MasterClient". You'd need to do something basically similar but storing the values instead of sending them over a Network link. Of course, if you want to do your own autosave just save a flight and load it when needed. You can do that with FSUIPC or direct with SimConnect. BTW since none of your questions are really specifically related to the use of Paul Henty's .NET DLL you should really be posting in the Support Forum itself, not in this subforum. Please do so further further support questions. Pete

Well, there's absolutely no relationship whatsoever between that and FSUIPC. Apart from it being a VERY old version, the Log proves that it is running fine, at least up to the point you closed FS. What exactly is the problem? What do you means by "FSX will not allow me to fly using FSUIPC"? How is it stopping you? And if you submit any more logs please make sure they are ONLY for a supported version. Pete

Why are you doing this? Do you not want FS to take care of the time zones for you? All the date and time values are in the Offsets list from 0238 to 0248 inclusive. How could you miss them? And how could such a thing drive you crazy? Pete

Well, it isn't related. MakeRwys isn't "installed" it is simply placed in the FS folder for which you want the data files created. It is just a utility which creates files for other programs. It doesn't change anything whatsoever in any FS installation or scenery. It does nothing if you don't run it, and if you do run it then the only files it creates are those listed in the text file contained in the ZIP, and NONE of those have anything to do with Fs and are not in any way used by it. No, it most certainly doesn't! It cannot. Pete