Pete Dowson

Please find the FSUIPC4 log file, in the Modules folder, and paste it into a message here. Make sure the Sim is closed first. Pete

Please see this thread http://forum.simflight.com/topic/81806-weird-problem-only-in-kjfk-area/#comment-493444 Scroll down to the solution found in that case, in the 5th message there. If that doesn't help, see the 4th message. Pete

Yes. In that case it seems possible that ASN does support 2 clients after all (maybe that was fixed in an update), but when it doesn't work, it doesn't work for both programs. The fact that this is intermittent is worrying and is rather pointing to some timing glitch with the ASN facility. I can't investigate this myself till I get home in 8 days, but it might be worth asking these questions on the ASN support forum. By all means point to this thread when you do. Pete

Hmm. It does look odd. When you write with FSinterrogate, I didn't realise you were writing another Weather variable. Can you test instead with a write to something completely unconnected to weather? The only thing I can think which might be going on is that the weather change requested via 0F72 is not being actioned in P3D. When you READ offsets for sim values, they are the values obtained from the sim, not necessarily those written by you. So if P3D was not obeying that request, the read-back wouldn't change. When you write the other weather value with FSInterrogate, maybe this causes P3D to really implement the weather as requested. I don't know -- really these offsets relate to FS98 style weather control, with FSUIPC trying hard to provide compatibility through all versions since then. As a test of this why not add the write to 0F74 in the Lua and see if that produces the same result as doing it with FSinterrogate? You could even insert an "ipc.sleep(3000)" delay between them, to make it a closer match, but try without first. I could probably tell more about what's going on by seeing the weather stuff being sent and received. You can get that in the log by checking the Weather logging option in FSUIPC's Logging tab. This may produce a large log, so please try to keep the session short. You may wish to ZIP the file and attach it instead (if this Forum lets you!) I would try all this on my system, and check it on FSX too to see if it's a P3D bug to be reported, but I am away visiting my son in Spain this week -- back at my system on Monday 11th. Maybe you can remind me then if I've been no help beforehand. Pete

I was puzzled about what made me advise you to remove the WxRadar lines in FSUIPC's settings, so I reviewed the first post again, and was reminded of the above. The log fragment you showed did NOT include this line -- did it not exist, or did you just not post enough of the file? If it does log such a line it (should) definitely mean the WxRadar facilities are activated in FSUIPC, and that should only happen with parameter entries in the INI file. So I am really puzzled now! It might help to see a rather more complete log for a session in which you get this problem, please? (Ideally, complete from AFTER you close P3D down, completely) Pete

If both the PMDG aircraft and FSUIPC are registering for WX radar data, that makes TWO clients for ASN's WX Radar data! I see you have no WxRadar entries in FSUIPC's settings, so it shouldn't be asking for any such data, so I'm not sure what is happening. There is one odd thing -- from the FSUIPC log file you posted earlier I see that the ASN "as_btstrp.dll" module is loading into P3D before FSUIPC. I've known that ordering to do odd things and ASN's installer takes steps to move it to the end. Could you check in the DLL.XML file (the one in the Users\<username>\Appdata\Roaming\Lockheed Martin\Prepar3D v3 folder) and make sure FSUIPC4 is listed before as connect (the as_btstrp.dll)? If not try swapping those entries around. Unfortunately you've caught me at the start of a week away, visiting my son and his wife in Spain, so I'm not in a position to investigate at my end at present. I'm trying to keep up with questions on my iPad but I have no access to FS etc. until I get back -- Monday week. BTW, in the post with the log you only showed the entries at the start. It's an incomplete log. Can you check to see whether there are any lines later mentioning Wx radar? Pete

Sorry, please show the logging with the offset monitored, as I asked. Otherwise you are just repeating yourself ... nothing new above, and I reiterate too that FSInterrogate cannot "unblock" anything -- there s no "block" it can remove, and certainly no mechanism. Pete

No, FSInterrogate does nothing differently to what you can do in Lua. I haven't sufficient information to help I'm afraid. Try using Lua trace/debug options in the Logging tab to see what it is doing, and also Monitor the offset on the right-hand side of that Tab to get all changes to it logged. Pete

It's nothing to do with versions of FSUIPC. It seems ASN cannot support more than one client for its radar services. Please ask about that on ASN support forum. Meanwhile you'd need to remove your ASN wx radar lines from the FSUIPC4.INI file. Pete

The NGX is probably the least easy to set up, because it really implements pretty much all of its own systems, ignoring the FS controls entirely for the most part. PMDG have, however, provided all the controls you need in their own range, listed in the SDK file of type ".h" (for "header"). Towards the end of that file you'll see a long list of controls defined in terms of a number added to a base value, which is also defined, at the start of the list. I can't easily help you with a specific command as I don't actually use any PMDG aircraft (though I do have the file here someplace). Once you've computed the number of a control you want to assign, you can do so by selecting <custom control> in the drop down assignment list in FSUIPC. Selecting that allows you to enter the control number. Many controls will also need a parameter -- most likely 1 for 'on' or 0 for 'off'. I'm not far North of Stoke, near Biddulph. You'd be welcome to visit some time, when I'm at home -- these days my wife and I take a lot of trips (packing as much in while we can, be are both getting on!). Send me an email some time, but don't hide behind a false name please. petedowson@btconnect.com. Pete

No. There is no internet or even networking stuff in FSUIPC whatsoever. If you enable WideFS (after installing with a valid WideFS Registration Code) then it waits for connections, but only from your local Network, not the Internet. However, applications you are running on the same PC, or gauges and other add-ons, can, using the FSUIPC interface into FS, affect what FS is doing -- of course, as the interface FSUIPC provides is primarily to allow applications to interface to FS. Pete

There was no point in posting a screenshot here. It is nothing to do with any software I can support. If I knew anything about iVap I would help, but as I said, I know nothing about iVap programs. This obviously declares itself as an iVap error. Please try iVap support. Pete

Sorry, I don't know anything about any of the on-line flying programs. Best to ask in one of those forums. Pete

Assuming the path and EXE name you have is correct (Windows is on D:, not C: ?), there are two things you need to do: 1. Change the ; to a , (there are no semicolons in the format) 2. Because the path includes spaces you need to enclose the whole path in "". So, a correct line would be: Run1=READY,CLOSE,"D:\Program Files (x86)\IVAO\IvAp v2\ivap_dllhost.exe" Pete

You'd need to use profiles, and only have it loading for the profile to which you assing the NGX -- i.e. via [Auto.<profile name>] Pete

Of course -- the Monitoring facility in the Logging tab, right-hand side. Just enter 66C0 as the offset and FLT64 as the type, and select Normal Log or FS Window below (or both). Pete

No no no! It is writing values to the user offsets in the range 66C0-66FF. The default FS values will be constantly overwritten by the FS values, on every frame or even more often! For most aircraft your script is simply copying over the default FS values, but for selected aircraft it is getting the L:Var (Local panel variable) values and copying those into the user offsets instead. There IS a facility in FSUIPC to "spoof" FS offsets, by feeding applications false values instead of the FS ones, but that is not so straightforward. This is described at offset 0024 in the FSUIPC4 Offsets Status document, and there is a Lua example of it being used in the Example Lua plugins ZIP -- it's called "Liar.lua". Pete

You can do that, or you can make it load automatically by adding it to an Auto section in the FSUIPC4.INI file, thus: [Auto] 1=Lua A2Agauges If you already have some entries then just number the next one. Pete

An A2A add-on using FSUIPC offsets? I don't think so. There are certainly none reserved for A2A and they've never requested any. Looking at your Lua briefly, it seems to only be reading standard FS offsets. and, for a "C172" and a "C182" amd a "Cherokee", a series of L:Vars (local panel variables). Are these the A2A ones -- not offsets but gauge values? Does the script work with default aircraft? How are you loading it? You can check the names of the L:Vars and see their values by using the "List local ..." control in FSUIPC's assignments. If no error is being logged for the Lua script in FSUIPC's LOG file, then it will be doing what it says. I think you may need some assistance with your 3rd party gauge supplier. Pete

Good. The .WX and Wxstationlist.bin files, you mean? If so then it was a Weather data corruption. Just off that it only affected the KJFK area. Pete

Further to the above suggestions, and maybe easier to check first, is based on a similar thing happening nearly two years ago: This thread http://forum.simflight.com/topic/76695-fsuipc-prevent-fsx-termination ended happily when corrupted weather files were deleted -- the WX file loaded by the default flight, or possibly a subsequent flight if you load one to go to KJFK, and the Wxstationlist.bin file. Either seem to be able to be easily corrupted if there's any sort of interruption or problem on Internet links to the weather sources. Usually I've seen such a corruption cause FS to crash during loading, as soon as FSUIPC starts asking for weather data. The crash then is usually in WEATHER.DLL. However, the thread above also shows that it can be geographically based. i.e. only reading the corrupt data and so messing things up when in the area concerned. I've always wished that those files had some checks built into them. They are binary files with all sorts of data structures inside, and when corrupted can do any amount of damage internally to FSX. There was a later thread where a similar thing was happening but it was fixed only by re-installing FSX: http://forum.simflight.com/topic/77688-fsuipc4-not-launching-from-the-add-on-menu-in-fsx/ Finally, one of the add-in DLLs aso responsible for problems like this was PMDGOptions.DLL. If you rename that so it doesn't load, then test again and everything works, you need an update for that DLL, as it was fixed a long time ago. Pete

Ah, so FSUIPC is working, but something is stopping the standard Windows dialogue from opening? I've heard of that once only before, some time ago now. FSUIPC doesn't really have much to do with it once SimConnect allows it into dialogue mode, but I think what was happening before was that another DLL or EXE was clobbering SimConnect and it isn't switching to dialogue mode nor telling FSUIPC it can go ahead and use the display. I take it that the screen doesn't even go black, as it would normally for dialog mode BEFORE telling FSUIPC it can go ahead. STOP PRESS: More references discovered. Please see my next message before doing this test, in case it is easier Try a process of elimination, first on the DLL's listed in your DLL.XML, then on the EXEs in your EXE.DLL. I suspect what's happening to your other add-ons is caused by the same sort of thing, an inability to get SimConnect responding correctly. Just to double-check that the problem is with SimConnect, could you do this: 1. Add to the [General] section in the FSUIPC4.INI file these two lines: Debug=Please LogExtras=x8000 2. Load FS (without going to JFK area, and check that you can open the FSUIPC Options. 3. Go to the KJFK area and do the same again. 4. Go back to the first place and see if you are still stopped from opening the options. 5. Try to close FS normally. Find the FSUIPC4.LOG and show it to me. Also, just to check that it isn't corruption in the scenery files for the KJFK area which is causing in-memory corruption too, try temporarily renaming your DLL.XML and EXE.XML files (or moving them to a safe plae, then re-run the FSUIPC installer. That will make a DLL.XML file with only FSUIPC being loaded. Run FSX, and repeat the above checks.2 -- 5. Show me the log from that too. Okay? Pete

Sorry, this could do with clarification. 1. When you say "load the sim", do you mean KJFK is your default airport, so it loads immediately? And then if you change airports FSUIPC magically starts working? Else how do you mean "only in KJFK area". 2. If you start in another area, FSUIPC is working? Thenit stops as you fly to the KJFK area? 3. What exactly do you mean by "FSUIPC is not working"? What are the symptoms of this? 4. What do you mean by "the other dependencies"? Nothing you mentioned depends upon nor uses FSUIPC. FSUIPC is not at all involved in PMDG aircraft loading their systems. If the yoke buttons don't appear to work with it it will probably be because the systems they are assigned to are not loaded. It can't be anything to do with scenery in any case. FSUIPC doesn't care or know where you are. It is only passing information back and forth between SimConnect and other programs. If there's something interacting with other programs it will be another EXE or more likely DLL being loaded by your DLL.XML or EXE.XML files. FSDT and GSX in particular use things like COUATL and BGLMANX. You probably need those updated to start with. From which previous version? Over the last 6 months to a year there have only been changes to keep up with P3D developments, plus some minor user facility additions which aren't involved unless used. The log shows everything working fine, though it would have been more informative to close FS and show the complete log. The termination data tells me a lot too. So, since nothing appears wrong with FSUIPC, please explain why you think it isn't working. Pete

No, sorry, but I thought you might notice it is just the same stuff over and over again, so a sample would have done. Never mind. That suggests it is being trapped by that program as a Windows "hotkey". But I don't know why that would also hook the messages -- it might do though, but not send the needs "hotkey occurred" message. To check this you could try without running ivap. Not really a guess when it says "SendKeyToFS" ;-) Sorry, I see no where that I am doing any such thing. As I said earlier, I do not understand why this is happening on your computer. It is NOT directly related to either P3D3.3.5 or Win10, as both of those are in use a lot and thoroughly tested with this mechanism. That's why I simply suggested that you'd need to do a process of elimination. Try to see which process or service might be responsible. I do try my best and if I'm at home I respond very quickly. Support occupies most of my days and it has been going on with FSUIPC now for 18 years, over many additions and improvements nearly all as requested by users. I don't expect thanks but I don't expect such nasty criticism from someone I've been trying to help. I'm sorry I failed to, and I'm sorry if I sometimes appear impatient with someone and point out things which might be obvious, but they are never intended to make anyone feel as you seem to do. It seems that I cannot help in this matter without know what is causing it. If you can find out what is doing it (by the process of elimination I mentioned), then maybe I could add whatever it is here and find out why. Finally, however: Yes, the keypress is not reaching FS. We know that. but we don't know why. If you look back to the log extract I included from my test, in the second message in this thread, you'll see that same for a button sending a keypress. Pete

Thanks. I don't know that one. I'll look that one up. There is a JoyIds.exe program I recommend for those moving to Win10 where some drivers (Saitek predominantly) don't put the full information in the Registry which FSUIPC needs. I refer to it with a link in the FAQ thread entitled Fixing joystick connections not seen by FSUIPC. That can be used too, to change IDs around to match whatever you used to have. However, it is easier to let FSUIPC sort it ot for you if possible. And another advantage of using letters for Ids instead of numbers is that you can assign your own more meaningful ones, like T for Throttle, Y for Yoke, R for Rudders. Pete