Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Posts

    1,652
  • Joined

  • Days Won

    74

Posts posted by Paul Henty

  1. I don't think this is anything to do with FSUIPC.

     

    Either your version of FSXSave is too old (you need V1.05 or you have not got service pack 2 for the .NET 2 Framework installed. To get the latter, either go through windows updates or try the installer here:

     

    http://www.microsoft.com/en-gb/download/details.aspx?id=1639

     

    If you have the correct versions then it maybe a problem with SimConnect itself since that's also near the top of the error stack.

     

    Paul

  2. This probably won't solve your problem but it needs correcting anyway:

     
    You need to set the data before you call Process(), not after. You should set the values of all variables you want to change and then the last thing is to call Process() to actually write that data. Like this:
    
        senderfs.Value = &H11000 + 380  '(THIRD_PARTY_EVENT_ID_MIN=0x000011000,senderfs is "offset 3110")
        ' Set other values here
        FSUIPCConnection.Process()
    
    
    Paul
  3. Hi Gwenael,

     

    I've tried this out and there seems to be a timing issue when refreshing the scenery. If you don't give FSX enough time to move the plane then the 'refresh scenery' process seems to stop the moving.

     

    If your application will not need to reload the scenery after moving, you can get around this problem by not sending the REFRESH_SCENERY control (i.e. delete the following two lines)

                    sendControl.Value = REFRESH_SCENERY;
                    FSUIPCConnection.Process();

    If you DO need to refresh the scenery, then you need to wait a bit before sending the control. I found that half a second was enough. Use the Sleep() method on the current thread to wait before sending the REFRESH_SCENERY, comme ça:

                    // Refresh the scenery
                    System.Threading.Thread.Sleep(500); // Wait for the sim to move the plane.
                    sendControl.Value = REFRESH_SCENERY;
                    FSUIPCConnection.Process();

    I'm sorry my example code was wrong. I didn't ever try to move the plane into the air.

     

    I've tried both methods for setting the altitude from my previous post and both work with the fixes in this post.

     

    Paul

  4. Hi Gwenael,

     

    Whenever you read or write and offset you must always consult the FSUIPC documentation. In this case (FSUIPC4) you need "FSUIPC4 Offset Status.pdf" from your modules folder.

     

    If you look at offset 0570 you'll see that this offset is in metres, not feet. Also the 'units' of the value are 4 bytes starting at offset 0574, so writing 1000 into 0570 is a very tiny fraction of a metre.

     

    Either you need to write your units only (no fractional metres) into 0574 by changing the offset definition to:

    private Offset<int> playerAltitude = new Offset<int>(0x0574); // Offset for moving the plane

    Then write the whole number of metres (converting from feet)

    playerAltitude.Value = (long)(1000.0 * 0.3048);

    Or, you need to scale your value by (65536*65536) and write to 0570 (Keep the offset definition the same) - e.g:

    playerAltitude.Value = (long)(1000.0 * 0.3048 * 65536.0 * 65536.0);

    Paul

     

  5. Hi Jul,

     

    This is a working example of calling makerunways using the Process() class in .NET.

     

    Note that you need to specify the "WorkingDirectory" as the path to your prepar3d folder.

     

    Your path with obviously be different to mine.

            Dim flightSimFolder As String = "C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X"
            Dim makeRunways As Process = New Process()
            makeRunways.StartInfo.WorkingDirectory = flightSimFolder
            makeRunways.StartInfo.FileName = "MakeRwys.exe"
            makeRunways.Start()
            makeRunways.WaitForExit()
            MessageBox.Show("Done")
    

    Paul

  6. Hi,

     

    I don't have very good news about this.

     

    The problem is that the Captain Sim 707 plane has 123 payload stations. FSUIPC can only deal with 61. My DLL wasn't checking this limit and so it was reading bad data for payload stations above 61.

     

    I've fixed this problem so that it doesn't return bad data and overflow, but, I can't extend the 61 station limit in FSUIPC. So the DLL now only brings back the first 61.

     

    I have added a boolean property on PayloadServices called TooManyPayloadStations. If this is 'true' then the current aircraft has more than 61 stations and therefore some will be inaccessible. Also the total payload values will also be incorrect because it can only count the first 61.

     

    Although it's not really a 'fix', at least your application can tell which planes will cause a problem.

     

    Attached is a new version of the DLL (2.7) (One targets the .NET 2 Framework, the other the .NET 4 Framework.)

     

    Paul

    FSUIPCClient2.7_NET2.zip

    FSUIPCClient2.7_NET4.zip

  7. Yeah, I guess it's so you can pretend to load individual passengers. Seems daft to me too.

     

    If it's not easy then fair enough. Just thought I'd ask in case it was something you could add in easily.

     

    I'll just cap my DLL at 61 (which I should have done anyway) so it doesn't get bad data from reading beyond the 0x1400 block.

     

    Paul

  8. Hi Pete,

     

    I see in the FSUIPC4 documentation that the Payload station area from 0x1400 only has room for 61 stations. Some add-on planes have many more than this, for example, one of my DLL users has a 707 with 123 stations.

     

    With the 61 limit, any application using FSUIPC to do payload editing isn't going to work with these aircraft because some stations are not accessible.

     

    Is there any chance you can make another area available for some more stations? Ideally up to the FSX or Prepar3d limit if there is one.

     

    Regards,

     

    Paul

  9. There is no file access or delete code in the DLL at all. I can't imaging it's anything to do with FSUIPC either.

     

    Sorry, but I have no idea what could cause a file to get deleted.

     

    All I can suggest is that you disable any other add-ons you are using. It may be being deleted by another add-on. Also try without your program running to make sure it definitely only happens with your program.

     

    Paul

  10. Hi Graham,

     

    Most, if not all of the payload and fuel information is accessed directly via the PayloadServices in my dll. This means you don't need to use the offsets directly as the dll handles all the complicated reading and writing to/from offsets for you. Your utility may need to access other information via offsets though.

     

    Any program interfacing via FSUIPC (or via my dll) can run on the FSX machine or a machine running WideClient.exe. You program won't know the difference.

     

     

    >> -get maximum takeoff weight of aircraft
     

    You can get the 'maximum gross weight' from FSUIPC. I don't know if that's the same thing. I think the max take-off weight depends on altitude and air temperature doesn't it?

     

     

    >> I am guessing that FSX starts the flight off with full fuel tanks,

     

    It starts with whatever the fuel levels are in loaded flight (or default flight if the user does not load a flight).

     

     

    but if it were a multileg flight, would I be able to add to the current fuel level, or would I have to replace current fuel with the total amount required for subsequent legs, if any? I'll assume below, that I have to start over for each leg.

     

    You can do either really. It's possible to fuel the plane for all legs before the first take-off. Or you can refuel between each leg. When you set the fuel levels through FSUIPC you just tell it the new level. It's easy of course to simulate 'topping up' by calculating the new level to be the current level + the additional fuel required.

     

     

    >> -set unit of measure

     

    The dll will accept and provide fuel levels directly in Litres, US Gallons, Newtons, Kg, Lbs and Percentage.

     

     


    >> -if fuel has to be viewed/set by tank, query each tank and enable a textbox for each active tank on the aircraft

     

    Yes, fuel is set per tank.

     

     


    >> -get fuel capacity for each tank

     

    OK - available in Litres or US Gallons

     

     

    >> -if subsequent legs, get current fuel level, then set necessary fuel for next leg, if that is possible

     

    Yes, this is possible.

     

     

    -show fuel capacity by tank

    -show current fuel by tank

    -show total current fuel

    -show total fuel required onboard

    -edit current fuel to show required fuel by tank

    -set fuel to be added to aircraft for first leg

     

     

    No problems here.

     

     

    >>Payload Section: -set unit of measure

     

    Payload is accepted and returned by the dll in Kg, Lbs, Newtons and Slugs.

     

     

    -set adult passengers

    -set child passengers

    -set infant passengers

    -set cargo

    -show all of above items

    -show total cargo/luggage weight

    -show total passenger weight

     

    Is it necessary to have more than one passenger station? IE, do I have to have more than one type of passenger class other than for realism purposes?

     

     

    The payload stations are defined in the aircraft model. Some complex aircraft like those from PMDG have a payload station per seat. Others will may only have something like 'First class', 'Economy', 'Luggage'.

     

    Unless your application is only for a specific aircraft, you'll need to present the user with whatever payload stations are defined and let them set the number of adults/children/cargo etc for each one. You'll then need to convert that into a weight to be applied via the dll.

     

     


    >> I just want to know if there is anything I would attempt to do here, that would be of the rails or violate the rules.

     

    From an FSUIPC point of view it's all possible.

     

    If you decide to do it and need any more help or pointers, feel free to ask.

     

    Paul

     

  11. Sorry but this isn't making any sense to me.

     

    First you say: "Why is it still does not connect with the simulator"

     

    Then you say "Connection is open".

     

    The code you posted is trying to open the connection. How can your connection already be open?

     

    Paul

  12. What's the problem?

     

    Just from looking at the code, I think you'll probably want to disable the timer1 in the 'else' block.

     

    Also in the catch block I recommend you call FSUIPCConnection.Close() just to clean things up if the connection failed.

     

    Other than that, you need describe the problem you are having.

     

    Paul

  13. Hi Ruediger,

     

    Have you tried checking the FSUIPC AI tables using TrafficLook.exe? If not that's the first step and you can download it here:

     

    http://forum.simflight.com/topic/66136-useful-additional-programs/

     

    If the IVAO ground planes appear in there then there maybe a problem with my DLL or how you are using it. In this case can you try with the normal flight sim traffic and see if that works for you?

     

    If they do not appear in TrafficLook.exe then they are not being injected into FSUIPC at all. In that case I can't help as I don't know anything about IVAO. You may want to look at the IVAO documentation, contact their support, or post again in the main FSUIPC support forum where more people will see it. 

     

    Paul

  14. Hi Steven,

     

    Below is the code with all the conversion formulas. As you can see, once you've converted the true heading and magnetic variation to degrees you just need to subtract the magvar from the true heading to get the magnetic heading.

     

    Take care when declaring the offsets, note the different sizes and the fact that the true heading is Unsigned.

            private Offset<uint> headingTrue = new Offset<uint>(0x0580);
            private Offset<short> magVar = new Offset<short>(0x02A0);
    
            private void someMethod()
            {
                // after calling process()
                double headingDegreesTrue = (double)headingTrue.Value * 360.0 / (65536.0 * 65536.0);
                double magVarDegrees = (double)magVar.Value * 360.0 / 65536.0;
                double headingDegreesMagnetic = headingDegreesTrue - magVarDegrees;
                // mag heading may now be < 0 or > 360, so we need to normalise
                headingDegreesMagnetic %= 360;
            }
    

    I've 'spelt it out' there, you can obviously combine some of the steps to make the code shorter.

     

    Paul

  15. Thanks Paul for the reply.

    Any chance you could post a link to the PDF's?

     

    I will place my project on hold for now and read the manuals

     

    My user guide is in the docs folder of the zip file that contained my DLL.  You can get the latest from my sub forum:

     

    http://forum.simflight.com/topic/74848-fsuipc-client-dll-for-net-version-24/

     

    The offset list is in the "Modules\FSUIPC Documents" folder under your main FSX folder.

     

    Paul

  16. Hi Steven,

     

    Pete is correct, you're not declaring the offsets correctly. Not everything is an int. Please review my UserGuide.pdf, especially page 7 which explains which .net types you need depending on the offset size. You do need to be getting this information from Pete's documents though (FSUIPC4 Offset Status.pdf).

     

    If you need any more help please post in my sub forum.

     

    Paul

  17. Hello folks,

     

    Any chance that FSUIPCDontNetClient would work with IronPython?

     

    Thanks!

    /Semir

     

    Hi Semir,

     

    I don't know anything about IronPython but a brief search turned up this page which explains how to call .net assemblies from IronPython.

     

    http://ironpython.net/documentation/dotnet/dotnet.html

     

    If you can work out the Python syntax from the VB.NET or C# code used in the examples then it looks very possible to call the DLL from IronPython.

     

    I'll be happy to answer any questions about the DLL or it's use that might help you.

     

    If you get it working maybe you could share how to do it in this forum.

     

    Paul

  18. Hi George,

     

    We have already discussed this back in January. What you are asking for is very complex code. It would take many days to write.

     

    All I can do in this forum is tell you how you might go about doing this. I can't write your code for you.

     

    In addition to Graham's help above, I can only repeat my advice from January:

     

     

     

    You would do something like this:

     

    1. Find current player position

    2. Work out the Lon, Lat coordinates of a box 5NM around the player

    3. Select the airports from the database that have coordinates within this box

     

    You can use the FsLatLonPoint class in my DLL to help with getting the coordinates of the test box. See the UserGuide.pdf (Pages 16 & 17) for more details on this class.

     

    If you get more than 1 airport back you can measure the distance to each one and find the closest. You can use FsLatLonPoint for this also.

     

     

     

     

    Paul

  19. Hi Jul,

     

    There is no way of getting L:Vars in VB as far as I know. Certainly you cannot access them via the normal FSUIPC interface.

     

    You can get and set L:Vars with a LUA plugin script. You could monitor the ones you want with an event and when they change write the value to a spare offset. Then your VB application can read them from there. But you'd need to have a Lua script running as well as your application.

     

    If your program is only for your use, you can use the free offsets starting at 0x66C0. If it's for general release (including freeware) it's best to ask Pete to allocate some offsets officially for your application.

     

    I'm no expert in Lua so there may be other ways to transfer these values to your VB program. You may want to ask about this up in the main forum if Pete doesn't see it here.

     

    @Pete: If you do see this is there a better way?

     

    Paul

     

  20. Blackhawk,

     

    The offsets are declared with a type according to the offset size, not the data type you will eventually convert the raw data into.

     

    Please review my UserGuide.pdf that comes in the zip file, especially page 7 which explains which c# types you need to use with different offset sizes. If you don't understand this you'll never be able to use the DLL properly.

     

    If you need more help, you can ask in my sub-forum under this one.

     

    Paul

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.