Paul Henty

I've looked at it again and I don't think that's the case. You are clearly passing 256 for the length of the offset. I don't have VB6 so the only way you can check is to use the Logging facilities in FSUIPC. If you run your application on the FSX PC then you can enable the logging on the FSUIPC interface (logging tab - tick IPC Writes). If you run your application under wideclient then you need to edit the wideclient.exe and add or change the line Log=Yes under the [users] section. The results will be in the FSUIPC4.Log file (in the FSX Modules folder) or the WideClient.Log (in the same folder as WideClient.exe). Remember to turn the logging off when you're finished with it. This will tell you exactly what is being written to that offset by your code. If it's wrong show it to me and I'll fix the code. If the logging shows the path being written correctly then maybe the path is wrong? Paul

Well that's enough info. If it's 0-255 then that's one byte unsigned so you need the Ubyte variant. For the increment value it's how much you want to add. In your case it's 1, the max is 255 so you'll need 1,255. If you have an encoder with 'fast' and 'slow' rotations then you can increment by 1 for the slow and something like 10 for the fast. Paul

How you use an offset depends on the offset itself, not what kind of switch or encoder is attached to it. There's no way I can tell you without knowing more about the offset, e.g. how many bytes long it is, what kind of data is stored in there (integer, floating point number, bit mask etc). If you have documentation for the offset post it in here and I'll see if I can work it out. Paul

From what I've read on this forum, rotary encoders usually send virtual joystick button presses when the encoder is moved. Usually it's one 'button' for left rotation and one for right. Some have two buttons in each direction, one for when the rotation was slow and one for fast rotation. If you go into the Buttons tab and move the encoders FSUIPC should pick up the 'button' presses. You can then assign the offsets as you've been doing for your other buttons. But maybe your encoders don't work like this. Paul

No, I was just pointing out that the value you had for button 2 (x06) might be wrong because it was affecting bits 1 and 2 at the same time. I understood from one of your first posts that each button corresponds to one bit, not multiple bits. I wrote the number 6 in binary so you could see it was affecting bits 1 and 2 (where the 1's are in the binary number). If you look at the other binary numbers they only have a single 1 in them because you only want to affect one of the bits in the offset. If you press button 2 do you really want it to be like you pressed button 2 AND 3 together? Maybe you do. I was just questioning if that was correct. I suggested that instead of x06 it should just be 2 or x02 if you prefer that way of writing it. That way it only affects bit 1 which I suspect is what you really want. Paul

Yes, but that is what you're doing at the moment with your toggles. You have a toggle when pressed (0 gets changed to 1) and another toggle on release (1 gets changed back to 0). Setbit and clearbit do exactly that. It's possible that using the toggles could get you into a situation where the action is reversed - pressing would change to 0 and release to 1. I don't know how likely it is because I don't know what these buttons are for or how the software on the other end interprets the 0 or 1 in the bits. It just seems to me that if you need two toggles to make it work the the more logical thing to do would be to set and clear. Paul

It may be that these bits shouldn't be toggled then. You can try using "Offset Byte SetBit" on the press and "Offset Byte ClearBit" on the release. Use the same parameter values. If this works that would be the more correct way of doing it. Paul

Well these are just the same numbers I gave you but written in hexadecimal rather than decimal. You can use either, they are exactly the same value. However your button 2 looks wrong. If we write the values you have in binary you can see that button 2 is toggle bits 1 and 2 at the same time. Hex -> Decimal -> Binary Button 1 x01 -> 1 -> 00000001 Button 2 x06 -> 6 -> 00000110 Button 3 x04 -> 4 -> 00000100 Button 4 x08 -> 8 -> 00001000 Button 5 x10 -> 16 -> 00010000 Button 6 x20 -> 32 -> 00100000 Unless pressing button 2 should also affect button 3, I think button 2 should just have 2 or x02 if you prefer that format. Paul

You don't need anything else. The parameter (bit value) tells FSUIPC which bit to toggle. If the bit is currently 0 (off) it changes it to 1 (on). If it's 1 it changes it to 0. If you were using SetBits then that bit is always set to 1. For clearbits it's always reset to 0. Paul

Sorry, the ^ means 'raised to the power of' in most programming languages - I forget not everyone is familiar with that way of writing it. So 2 squared is 2^2, 2 cubed is 2^3, So for your buttons, starting at button 1 (bit 0) you need these values: (Bit -> Value) 0 -> 1 1 -> 2 2 -> 4 3 -> 8 4 -> 16 5 -> 32 6 -> 64 Pete has written a more detailed explanation of binary and hexadecimal numbers... http://forum.simflig...nd-hexadecimal/ Paul

Since Pete is away I can try to clear things up for you, although I've never done this myself... It's difficult to answer this because these offsets are proprietary and so there's no telling how they work unless you have the product. I suspect that if they are meant for momentary switches as you imply then you need Togglebit. That is, you press the mechanical switch and it goes 'on' (the bit in the offset is set to 1), you press it again and it goes 'off' (the bit is reset to 0). You have correctly identified that you need the 'byte' variant of the Offset Togglebit because the size of the offset is 1 (although you seem to refer to it as the 'number'). So you should use Offset Byte Togglebit. Only the offset address goes in the Offset box. To use the Hexadecimal value given in the documentation you must prefix with x. So enter x73F8 The parameter is always a number but it's use varies depending on what function is chosen. For offset togglebit this number needs to be an integer that tells FSUIPC which bits in the offset location to toggle. The number you need is 2^n where n is the bit number starting at 0 and going to 7. For example if you want to toggle bit 0 you enter 1 because 2^0 is 1. If you want to toggle bit 4 you enter 16 (2^4). Note that you can toggle more than one bit at a time by adding the values together. E.g. to toggle bit 0 and bit 4 at the same time you enter 17 (16+1). I think you're correct - you don't need the release part. However, without knowing anything about the products you are using or the way these offsets work I cannot say for sure. It will be obvious if the offsets work in a different way than we expect in which case post back here and I'll see if I can work out what to do. Any documentation about offset 73F8 from the product manufacturers would be useful. Paul

You need to build the entire array first, then send it to FSUIPC in a single write. To do this you just use the address of the first byte of the array. Because you're passing 256 as the size it'll take the next 255 bytes as well. I've modified your code. It should be OK but I have no way of testing it. Public Sub Load_Plan() Dim dwresult1 As Long Dim plnx(256) As Byte PLANTXT = "\\FSX-PC\Users\ffffff\My Documents\File di Flight Simulator X\LIRA Ciampino - LIML Linate.pln" For i = 1 To Len(PLANTXT) plnx(i) = Asc(Mid(PLANTXT, i, 1)) Next plnx(i + 1) = 0: rem put null char at the end of the sring Call FSUIPC_Write1(&H130, 256, VarPtr(plnx(1)), dwresult1) Call FSUIPC_Process1(dwresult1) End Sub Paul

Pete is correct. VB strings are Unicode not ASCII. To write a string to FSUIPC you need to build a byte array from the string, converting each character into its single-byte ASCII equivalent. To read string you must read a byte array and convert each byte into the equivalent Unicode character. A discussion of both these techniques (including sample code) can be found in the UIPC_SDK_VisualBasic.zip file in the FSUIPC SDK. It's called "VB6 and strings in FSUIPC.txt". If you need further help understanding what's written there or getting the sample code to work, post back here and I'll try to help. By the way, the '\' is not an escape character in VB so your path string is fine as it is. (Apart from being in Unicode of course!). Paul

Longitude and Latitude need to be written as 64 bit integers. While VB6 doesn't actually have them, there is a 'currency' type which stores decimal numbers as 64 bit integers scaled by 10000. You can use this to fake a 64 bit integer. Below is some code that writes the latitude. You can do the same for longitude and reverse the process for reading. Dim latitude As Double Dim FakeLat As Currency latitude = 51.45 latitude = latitude * 90# / (10001750# * 65536# * 65536#) FakeLat = latitude / 10000# FSUIPC_Write(&H560, 8, VarPtr(FakeLat), dwResult) FSUIPC_Process(dwResult) [/CODE] Paul

The log you've posted in the spoiler is the runtime log (FSUIPC4.Log) not the install log (FSUIPC4 Install.log). Paul

You could try doing a system-wide search for the FSUIPC.KEY file. The installer may have put it in the wrong folder. You could also look at the FSUIPC Install.log to see what the install program did. That should also be in the modules folder. Paul

Offset 3BF8 only tells you how many positions are allowed for the flaps (e.g. a Cessna may have 3, a 737 will have 9). To get the current angles in degrees, it looks like you need offsets 30F0 onwards, depending on which particular flaps you want. I think in most cases you'll just need the left inboard trailing edge flaps (30F0 and 30F4) but check the others with a few different planes to see what you get back. All these offsets are 2 bytes, unsigned (so UShort in VB.NET) and scaled by 256. Here's an example for the left inboard trailing edge flap: Dim Flaps As Offset(Of UShort) = New FSUIPC.Offset(Of UShort)(&H30F0) Dim FlapsPosition As Double = Flaps.Value / 256 Me.FlightLogBox.Text = FlapsPosition.ToString("F1") Paul

The losing of the connection isn't really an issue, the important thing is if Flight Sim was unloaded or not during that time. If not then everything will carry on as normal. If it was then all the registered buttons/menus etc will be lost. They are stored in the FSUIPC dll which runs in the Flight Sim process. Calling CheckForInput or KeepAlive() will not throw any errors if nothing is registered, or if the registered buttons etc have been cleared (because FS was unloaded). These will throw errors if the connection is broken however - the same ones as process(). The safest way to handle things would be: 1. Detect the loss of connection. 2. Wait until it reconnects. 3. Call UserInputServices.RemoveAll() 4. Reregister all the buttons/menus 5. Carry on as normal. That way you don't need to worry about testing if FS was unloaded or not. Step 3 is important because it will clear the registrations from my DLL as well as FSUIPC. If nothing was registered it will just do nothing, it won't throw an error. Paul

I haven't updated the documentation yet, which is why the official version is still 2.0. The new stuff is 2.3 what put in for a few users that needed/requested them. There are: 1. Payload reading/writing facilities (includes fuel tanks) 2. Responding to user input in Flight Sim (keystrokes, joystick buttons and menu items - includes adding the menu item to FS). The only documentation I have is the supplied intellisense and some sample code in VB: Payload and Fuel data =================== The payload and fuel data is accessed from a new property on the FSUIPCConnection class called 'PayloadServices'. It's a good idea to assign this to a local variable to save typing FSUIPCConnection.PayloadServices all the time... ' Get a reference to save so much typing... Dim ps As PayloadServices = FSUIPCConnection.PayloadServices Whenever you want to get the latest payload and fuel data you just need to call RefreshData() on the PayloadServices object... ' Get the latest data from FSUIPC ps.RefreshData() Once you have done that there are lots of properties on the PayloadServices class that will give you weight and fuel data for the aircraft overall. For example: ps.PayloadWeightLbs ps.AircraftWeightLbs Most are self-explanatory and there is Intellisense on everything. You also have access to the individual payload stations and fuel tanks. Here is an example of iterating through each payload station. ' Go through each station and get the name and weight For Each (payloadStation As FsPayloadStation In ps.PayloadStations) Dim name As String = payloadStation.Name Dim weight As Double = payloadStation.WeightLbs Next payloadStation You can also write new values to individual payload stations or fuel tanks. To change the value of payload station, just change one of the weight properties for that station (Lbs, Kg etc). When you've made all the changes you want call WriteChanges() on your PayloadServices object. This will send all the changed values to FSUIPC. Fuel tanks are the same except, in addition to changing the weight, you can also change them by setting a new % full level or a volume in Gallons or Litres. Note that WriteChanges() send both Payload and Fuel changes in one go. User Input - Menus ================= 1. First, declare a UserInputServices object using the WithEvents modifier ' Declare a UserInputServices object so we can use it in the code Private WithEvents userInput As UserInputServices 2. After opening the FSUIPC connection you need to set the variable above and add your menu items: ' Open the connection to FSUIPC FSUIPCConnection.Open() ' Set our userInput object to the UserInputServices userInput = FSUIPCConnection.UserInputServices ' Add our menu items (2 examples) ' First parameter is the ID we use to identify this menu item ' Second parameter is the Text for the menu item (Max 30 chars) ' use & before a letter to make it the shortcut key ' Third parameter specifies whether or not to pause FS when ' the menu item is selected. userInput.AddMenuItem("Menu1", "Menu Item &One", False) userInput.AddMenuItem("Menu2", "Menu Item &Two (Pauses FS)", True) Note that if you use a pausing menu item it will be your application's responsibility to unpause FS by writing to offset 0626 at the appropriate time. 3. You need add a new method to handle the MenuSelected event. This will be called when the user selects one of your menu items: Private Sub menuItemSelected(ByVal sender As Object, ByVal e As UserInputMenuEventArgs) Handles userInput.MenuSelected ' This sub gets called when a menu item is selected ' Use the e object to see which one (Check the ID) Select Case e.ID Case "Menu1" MessageBox.Show("Menu item 1 selected") Case "Menu2" MessageBox.Show("Menu item 2 selected") End Select End Sub 4. You need to call CheckForInput() regularly to check if the user has selected any menu items. If they have the above method above will automatically be called for you. Add this code in one of your timers. ' Check for input. Recommended every 200ms userInput.CheckForInput() 5. FSUIPC will delete your menu items after about 14 seconds. To prevent this you must tell FSUIPC that your application is still running and stills needs the menu items. You must call KeepMenuItemsAlive() regularly. Pete suggests every 8 seconds. So on an 8 second timer call: userInput.KeepMenuItemsAlive() 6. Before your application exits, call the RemoveAll() method to clean up your menu items. ' Remove our menu items userInput.RemoveAll() User Input - Buttons and Keys ========================== Similar to above except you use AddKeyPress() and AddJoystickButtonPress() to register the buttons/keys. You then sink the KeyPressed or ButtonPressed events to detect the user pressing the button/key. You still need to call the CheckForInput() regularly but KeepMenuItemsAlive() is obviously not required for buttons/keys. If you need any more help with the new features just ask. Paul

Of course this means the start position is fixed to whereever the user was when they started your application. It would probably make sense to put a way of resettting the start position in your application (like a button) and calling a method: Public Sub SetStartPosition() ' set start position FSUIPCConnection.Process() Dim StartLat As FsLatitude = New FsLatitude(Latitude.Value) Dim StartLon As FsLongitude = New FsLongitude(Longitude.Value) StartPoint = New FsLatLonPoint(StartLat, StartLon) End Sub Paul

OK, that wasn't clear. I don't think your aircraft appears in the AI Traffic tables in FSUIPC. I can't check at the moment, Pete do you know? Paul

You could put this in the timer, it depends on how often you want this information. If your main timer is running 5 times per second then you might consider creating a new timer to get the AI Traffic less frequently. There will not be one state, there will a state for each AI Plane created by Flight Sim. Now I'm not sure you want traffic information at all. In your first post your code is trying to read the TCAS (AI Traffic) information. That's what I thought you wanted, but your other questions don't match up. Can you please explain again what information you want because I think we're talking about different things. Paul

If you want TCAS data you should use the facilities built into my DLL. This will be much easier than trying to get it yourself, especially using VB.NET. See the section starting on page 22 of the UserGuide.pdf called "AI Traffic". Paul

My DLL will do the trigonometry for you: Create a new fsLatLonPoint class from the current position, then get the distance from another fsLonLatPoint (the previous measured position) using one of the DistanceFrom... methods. The fsLatLonPoint takes in an fsLatitude and fsLongitude class to define the location. These two classes can be given the raw 8-byte values from the Lat and Lon offsets in FSUIPC, so you don't even need to convert them to degrees or anything. For more details and examples, see the UserGuide.pdf: "Reading and Displaying Longitudes and Latitudes" on Page 15 and "Distances and Bearings between Two Points" on Page 17 Paul