metalnwood

Similar problem with the vertical speed setting on the autopilot. When working in feet, no problems. I wonder if the problem is because FSUIPC is using the somconnect calls XXXXXX_ENGLISH when there are also simconnect calls XXXX_METRIC and internally . No idea. I have been playing around in fsinterogator with the field and it needs to be set in feet, I set it to 328 feet and when the value is 91 on the vert speed on the AP. in fact, a change of a number of feet doesnt seem to alter the vert speed reading at all.. Very confusing..

Hi All, I have been working through my program, figuring out little bits about FSUIPC as I go along. Right now I am a little stuck and can't figure it out. I am setting the AP altitude offset 07d4. I set it externally and use fsuipc to set it in game. This is the piece of c# code that sets it. Offset AP_ALT = new Offset(0x07d4); <-- this is the offset declaration --this code is within a function if( unitOfMeasure == 2) { // if the game is using metric units AP_ALT.Value = newAltitude*65536; } else { AP_ALT.Value = (int)(((newAltitude/3.28084)*65536) +.5); } The problem is when the game is set to metric units and I try to set the AP ALT to 2300. I know from the debugger that 2300 is passed in to the function and newAltitude is set to that. It is multiplied by 65536 which is 150732800. In FSUIPC's logging tab I set up that offset to monitor. It is set to the value I expected. The problem is that the display on the autopilot reads 2316. Where did the extra 16 meters come from??!!? I would understand if there was a bit of rounding error when converting to feet but there is no conversion here, I pass in a value of meters and set it as meters.. Very strange that the display doesnt match the current value of the offset/65536. Any ideas? Thanks, Jason

Thanks Pete, thats fine. Happy to know I was on the right track. Now, back to the code. Thanks, Jason

Hi all, I haven't done any pc development for a long, long time. I am now writing some software to talk to fsx and the chosen language is C# as it's the closest to java which I have been using for a long time as well. I know there is a java interface to fsuipc but I am not planning on using it as I know it's going to be easier to distribute an app based on c#. For the last 8-10 years working with java most systems have been event driven in the areas that I work. I have been working with simconnect which is also event driven, like the lua plugin you register an interest in an event and your code is called when something happens. I am looking to move from simconnect to fsuipc and it seems the general practice is to poll for the information. So I have a couple of questions based on my possibly antiquated ideas of how polling was bad way back :) I have looked through the posts and documentation but I haven't seen any guidance on the subject. I want to poll for changes in most of the switches, all the autopilot, com, nav, transponder, dme displays/knbos/buttons etc. This adds up to a lot of different things to monitor. Performance is what I am worried about - there may be nothing to worry about, I don't know yet. Would it be advisable to get all the information every time or break it up in to groups, e.g. get the radio displays every 200ms and the lighting panels every 500ms as they are less often used and it wont matter so much if my external screen is out of sync for that much longer. I have read that one call with many vars is better, but up to a certain point? With simconnect I know when something has changed because I get an event, I then read the value and pass it off to my display. Is the standard practice with fsuipc to keep a copy off all values in your app and compare with every polling cycle, I haven't seen if there is a different way. Sorry, this has turned in to a longer post then I expected but I want to start the right way from the beginning. Thanks, Jason

Hi Peter, you don't have a PM link otherwise this would be to you. I am writing some software and right now I am using FSUPIC to talk to FSX. If I decide I want to sell the program I either need the user to already have FSUIPC purchased or distributed with my software like some other addon's currently do. What is involved in distributing it with my software, for use with only my software? Thanks, Jason