Pete Dowson

Oh dear. First, if you want multiple shifts, you do as it says, add them together. So Shift + Control is 1 + 2 = 3. How hard is that? And why are you even asking about a combination of shifts when you only want one of them? So, you know Ctrl is 2. The rest is simple SIMPLE arithmetic, surely. What is your problem with it? See that 256*2 = 512. So 512 + keycode for F12 = 512 + 123 = 635. So, why couldn't you do this simple sum yourself? How are you managing to do any programming at all without some basis in notation and logic? Pete

The weather in FS is dynamic. If there is any wind at all, the weather moves and changes. How can it not? The weather set by the weather menus or by external programs applies initially, at the weather stations they populate, and then the weather operates, as in the real world, changing all the time. Furthermore, the weather BETWEEN the stations is interpolated based on nearby weather stations. And even if a "global" mode is used, trying to set all stations to the same weather, the actual weather at each station gradually changes from that, and each separately. On top of all this, effects such as turbulence and variance are applied locally, at the aircraft, independently of the interpolated conditions but according to probabilities based on those conditions. So, summarising, there is no point in knowing what weather was set. You surely want the weather AT the aircraft? If it is only the wind vectors you need for your computations, then you should really look at offsets 2DC8-2DD8. Pete

You need 3114 as well, for the parameter. Please do read the documentation more carefully. You seem to rush into things without first reading about them! It would save a lot of time if you slowed down a little and did the research first. As it clearly says, the control number goes to 3110! Why not actually read what it says? The control number is 1070 as you have found, and as I told you before! It also tells you that the parameter goes in 3114. You must write that BEFORE writing to 3110 because writing to 3110 initiates the action. And where on Earth are you finding that the keycode for '1' is 31? It is 49 -- hex 31 maybe, but you must be more careful! Please read more before posting these incessant questions which are mostly answered in the documents. I do have other things to do, you know. Pete

No, because it is so much easier getting FSUIPC to do the hard work. The facility for the added FSUIPC control came later -- 3200 was an early facility probably not used for the last 10-12 years! Pete

No, 3210 is for applications to register keys with FSUIPC so that when the user presses them the application gets notified by a flag in those offsets. It is the complete opposite of "sending a key to FS". What makes you think it is anything like what you want? There is a facility for sending the actual KEYDOWN and KEYUP windows messages to the FS window (offset 3200) but that needs an understanding of Windows programming and is quite complex to use. Easiest way is to use the added FSUIPC control for key press/release (see advanced FSUIPC guide, the list of "Additional 'FS' controls added by FSUIPC" near the back. Control 1070 is what you want. You can send any controls, FS or FSUIPC added, via offset 3110. Pete

Okay, good. I don't know what it was called C# -- I know C and C++ reasonably well, but i can't fathom C#. Pete

I don't know what language that is, but if the "4" means 4 bytes then it is wrong -- the 3367 offset is a one-byte value. The doors offset 3367 is a collection of BITS, not a single value. You have to change only the bit you want and leave the others alone -- so you need a bit of logic programming. And because I don't know what language that is I've no idea what it does. The sequence should be: 1. Open the connection at the start of your complete program 2. Request all the reads and writes you want, one after the other. This just builds up a list in memory 3. Send it to FSUIPC by the Process call. 4. Wat a while to allow FS some time 5. Repeat from step 2 until finished program 6. Close the connection 7. Exit program. There are examples in C and other languages in the SDK. I can only help with C and ASM. Don't forget you can see what is going on in FSUIPC by using its logging facilities, and experiment using FSInterrogate. Regards Pete

Okay. download FSUIPC4928d and put in the FSX Modules folder. It's an interim update -- I plan to make a new release soon, but need to wait for P3D 2.1 so I can make sure everything is still okay with that. There's no documentation for it yet. Edit the FSUIPC4.INI, adding the line DelayedMouseLookZoom=Yes to the [General] section. Regards Pete

Maybe. Perhaps you should re-post your question as a more explicit plea for help i.e. a title like "Please help me access FSUIPC offset from a web page". I'll not answer that thread then someone might feel they could help seeing no responses. Maybe also post in other forums where folks may be more likely to be doing web-based things. Regards Pete

Assign the hat to Pan View in the Axis assignments tab. Pete

Sorry, I don't know anything about web pages. Pete

Well, someone visiting here may possibly be able to help, but it won't be me. You might be better off asking in a Forum where there are more Java users -- a web developers forum I suppose. Pete

Yes, but Andrew's log, with FSUIPC4's entry delayed by 30 seconds using "InitDelay=30", shows the same errors occurring in SB before FSUIPC4 starts. So I don't think it's a contributory factor at all. Regards Pete

Well there is a Java interface package for FSUIPC included in the FSUIPC SDK. Didn't you look at that? OI'm afraid I have no idea, but if you can do it in JAVA then you have the interface. Pete

I don't really know. Maybe SB has always done this and they've not noticed, or programmed around it somehow. If there's an active support still for SB then it might be worth reporting it and asking the question, but I suspect it's long since been left unsupported? At least I haven't got any responses from the authors for a while. If it seems to work correctly for your purposes then I'd leave it. It may not harm performance once it's settled down. Pete

Please clarify, was this log from AFTER you'd applied the "InitDelay=30" change? It looks like it. Anyway, it's as I thought -- SimConnect is being swamped during startup. And in fact one of your Squawkbox modules is getting lots and lots of errors repeating throughout. I'm surprised you don't report a problem with that. Here's the timing during the startup as logged (the number on the left is the elapsed time in seconds): > 4.06666 [255, 1]Open: Version=0x00000002 Name="SquawkBox AI Control" > 4.06674 [128, 1]Open: Version=0x00000004 Name="PMDG_Options" > 4.06675 [129, 1]Open: Version=0x00000004 Name="PMDG_Events" > 4.06676 [130, 1]Open: Version=0x00000004 Name="PMDG_Sounds That's 4 SimConnect clients connecting almost at the same time. The SB AI control module gets some errors, the first being almost immediate: > 4.31907 [255, 5]RequestClientData:ClientDataID=0, RequestID=0, DefineID=0, dwReserved1=-1, dwReserved2=0 < 4.31910 [255] >>>>> EXCEPTION=25, SendID=5, Index=-1 <<<<< Exception 25 is ILLEGAL OPERATION! What is it doing sending lots of illegal operations? Another part of SB then connects and gets an error immediately: > 4.39201 [254, 1]Open: Version=0x00000002 Name="SquawkBox_Transponder" > 4.39223 [254, 15]SetClientData:ClientDataID=0, DefineID=2, Flags=0, dwReserved=1, cbUnitSize=1, pDataSet=200988708 < 4.39224 [254] >>>>> EXCEPTION=31, SendID=15, Index=5 <<<<< Exception 31 is OUT OF BOUNDS Before FSUIPC connects there are another 115 or so more of the ILLEGAL OPERATION errors, mostly then from that Transponder module, Then FSUIPC connects after 32 elapsed seconds: > 32.68946 [131, 1]Open: Version=0x00000004 Name="FSUIPC4" Then the ILLEGAL OPERATIONS by SB continue .... another 30+ before FSUIPC gets a look in. Once FSUIPC starts its requests then of course there are many. The log continues with occasional spurts of SB errors, and lots and lots of AI traffic reads by FSUIPC -- you are at a busy airport for AI by the look of it! But things are otherwise settled by then. Regards Pete

I could do with seeing the Logs first, please. And clarification of this statement: Do you really mean "Prepar3D.exe" here? Pete

Right. One contributory factor is that FSUIPC seeing lots of changing axis values from one of your devices. Immediately it enables the direct input scanning it receives the initial values from each of 10 joystick axes: 1794 ###JOY### Event seen, ID=65820 (0x0001011C), Joy=8, value=-7226 1794 ###JOY### Event seen, ID=65821 (0x0001011D), Joy=9, value=-11483 1794 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10064 1794 ###JOY### Event seen, ID=65823 (0x0001011F), Joy=11, value=-10709 1794 ###JOY### Event seen, ID=66292 (0x000102F4), Joy=5, value=-10709 1794 ###JOY### Event seen, ID=65763 (0x000100E3), Joy=0, value=0 1794 ###JOY### Event seen, ID=65762 (0x000100E2), Joy=1, value=0 1794 ###JOY### Event seen, ID=65720 (0x000100B8), Joy=6, value=7040 1794 ###JOY### Event seen, ID=65721 (0x000100B9), Joy=7, value=7040 1794 ###JOY### Event seen, ID=65764 (0x000100E4), Joy=2, value=0 Now those are fine -- that just "sets the scene" for latter scanning when things might be changing, but axis #10 is constantly changing. For example: 435742 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10193 435805 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10064 436039 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10193 436086 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10064 436413 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10193 436538 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10064 436803 ###JOY### Event seen, ID=65822 (0x0001011E), Joy=10, value=-10193 That's the axis assigned to "throttle 3 set". It's wobbling between two values constantly. Not a real problem, just a performance irritation. Now I'm not saying that this is the cause of the failure of FSUIPC to start everything, but it might be a good idea to temporarily disconnect whatever device that is and re-test. When we do get things sorted it will be worth doing a proper calibration on that device to find a stabile non-jitter setting, at idle presumably. Looking at the other problem shown up in the log ... these errors from SimConnect: 44741 Exception 12 "TOO_MANY_REQUESTS", Ref 3377, Index param -1 on unknown request! 44741 Exception 12 "TOO_MANY_REQUESTS", Ref 3378, Index param -1 on RequestDataOnSimObject for AI Aircraft id=2728 [0x00AA8] These occur at a ridiculously high rate. It's as if SimConnect is completely overloaded. I've not seen anything like that before. I've seen the odd occasional such failure, and it usually occurs when many SimConnect clients are clamouring for attention at the same time. So, I repeat my previous requests / suggestions: 1. Get a SimConnect log 2. Try the InitDelay The former would be most educational as it will show ALL of the requests made to SimConnect from every add-on running. Pete

You don't need to study any manual! What are you looking for? The axis logging is the checkbox labelled as such in the Logging tab in FSUIPC options! The assignment you made to the axis is shown in the Axes tab when you waggle the lever. What's to study? Pete

No. The Previous Flight production is in lieu of FSX doing it -- FS9 used to do it and a lot of folks like to set this as their default flight so they start up next time where they left off. It cannot do any harm -- it is saved on close down and would only be reloaded if you set it to be the default or if you loaded is explicitly. That's no use. I can't get that message with such an attachment, and it is way too big in any case. I did ask you to ZIP it. A ZIPPED text file is much much much smaller and is accepted okay. And FSUIPC connects as well. It is simply that it isn't getting the messages it needs. As I said already. Did you bother trying the IniDelay as I suggested? Dd you get a SimConnect log as I suggested? Pete

Okay. But that does probably mean there's some rogue device or device driver registered in Windows. You might want to review the device list in Windows device manager. Regards Pete

FSUIPC is "connecting" to Simconnect too. It simply isn't receiving the information is is requesting. Here, this part of the Log shows the connection AND the menu entry being added: It also receives START and STOP messages from Simconnect, as shown in your log. But it needs a lot more -- a LOT more! The main thing it isn't getting, which is illustrated by the log messages which AREN'T present, is the One Second timer calls. It is these which tells it SimConnect is actually alive, and it is on these which it depends to start everything up. The ONLY event FSUIPC is receiving from SimConnect is the "Start" / "Stop" one. There's no point in WideServer being started because there's no information FSUIPC can supply to it, and nothing it can do. Literally. Something is badly wrong. And FSUIPC is logging EVERYTHING it sees which might be relevant to this, and it isn't seeing anything, so there's no clue. In case it's all down to some sort of start-up interaction with other add-ons, you could try delaying FSUIPC's startup. The INI parameter InitDelay controls that. You can set a delay in seconds (0 to 120). There's also one other internal logging option which might just reveal more, but i'm not optimistic. It involves adding the line LogExtras=x400 to the two you already added. The log might be pretty big though -- unless really nothing is happening. Also, as a last resort you could try getting a SimConnect log file. There are instructions for this in the FAQ subforum. These logs may well be far too large to paste here, so ZIP them and send it to me at petedowson@btconnect.com. I'll certainly take a look, but quite honestly I'm not hopeful. Something is messed up in your FS installation, or there is some really severe interaction with other add-ons. (In fact, maybe that's another step which can be taken -- eliminate other add-ons one by one. The fact that you did get a success once does perhaps indicate some sort of interaction going o). Note that I've never seen anything like these symptoms before. In the few other cases of things not starting the logging you have now enabled point to a specific single cause, like the Aircraft name not being received (turned out to be a corrupt AIRCRAFT.CFG file). But in your case there simply appears to be nothing happening. Pete

Ok. I'm sorry, then, but I think you've got some serious problems which aren't really specifically to do with FSUIPC at all. Evidently something got severely messed up when you installed Acceleration. None of the crashes you've had have been in or directly related to FSUIPC, they have been in other unrelated areas. I think you are really looking at an FSX repair job, maybe even a reinstall from scratch. Regards Pete

You put its pathname into a [Programs] section in the FSUIPC4.INI file, like: [Programs] Run1=CLOSE,"<full path to EXCA exe file>" The CLOSE should make EZCA close when FS is closed. Alternatively you could let it keep running, but use RunIf1="<path>" so it is only loaded if not already running. If CLOSE doesn't manage to close it you can try KILL instead. Less tidy but stronger in action. If that creates a problem you can use Run1= (or RunIf1=) with READY as a keyword (as well as CLOSE or KILL), so: Run1=KILL,READY,"<path>" Then it won't start it till FS is ready to fly. There's a section about all this in the FSUIPC advanced user's guide -- it has its own chapter listed in the Contents. Pete

There's something very odd going on ... FSUIPC needs to see certain essential messages from Simconnect before it decides the SIM is set to fly. It seems one or other of those isn't getting sent. That's worrying as it suggests a Simconnect installation error. There is some logging you can enable which may point to what is missing. Please add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please TestOptions=x800 Then run FSX, till you are sure it isn't working correctly. close down and show me the whole of the Log file. Regards Pete