Jump to content
The simFlight Network Forums

Paul Henty

  • Content Count

  • Joined

  • Last visited

  • Days Won


Paul Henty last won the day on June 3

Paul Henty had the most liked content!

Community Reputation

52 Excellent


About Paul Henty

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Profile Information

  • Gender
  • Location
    Gloucestershire, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Paul Henty

    How to use flaps offset to a servo

    Hi Emerson, The C# code looks fine and it sound like you are getting sensible values from FSUIPC. (I think you made a mistake here though (in red) as the the number should change from 2 to 5 degrees) >> When I set flaps 2, flaps value == 4096 and servo moves 90 degrees approximately. Then I set flpas == 5 and and txt.flaps value == 4096 a Yes possibly. I don't know what values your servos need to make them move. At the moment you are just sending the raw flaps values. It would be a lucky coincidence if those were the same values the servo needs. It's likely that you will need to do some maths to translate the flaps value into the correct range for the servo. If you can explain to me what values are needed to make the servo move I can help with that. Paul
  2. Paul Henty

    Connection to FSUIPC Fails in C++

    As Pete suspected, my DLL only implements the external FSUIPC interface, not the internal (gauge) one. The DLL is aimed at people who want to use .NET instead of C or C++. Since a gauge can only be written in C/C++, I didn't see any point in implementing the internal interface for .NET. Paul
  3. Yes, the checking for changing values has also changed. Before it was sometimes writing when it shouldn't and causing problems for some users. Now it compares the current and previous values so you can't write the same value twice with a read/write offset. If you need to do that you should be using a write-only offset in a named group. The SendControlToFS() is easier to use than manually writing to those offsets. The DLL uses those offsets behind the scenes anyway so it's not really any different. I've no plans to publish the source code at the moment. Paul
  4. Hi Sebastian, The main change was that offsets marked as write-only now write every time you process them, even if you haven't set a new value. It sounds like your offsets for sending the events/controls were marked as Write-Only. I had to change this because for some offsets you need to set the same value as before. The DLL didn't see this as a change in value so the offset didn't get written the second time. There were also problems if you wanted to write a 0 as the first value. Because the initial value is 0 you couldn't write a 0 as the first value. With the new behaviour, you need to put write-only offsets into a named group and only process them when you need to send the new values to the sim. Offsets the are not marked as Write-Only work the same as before. They read unless you've set a new value; then they will write. Paul
  5. Paul Henty

    FsFrequencyCOM and P3D4 Comm Offsets

    Those new offsets in FSUIPC5 won't work with the FsFrequencyCOM class. The documentation says that the new offsets store the frequency in Hz rather than the old BCD format. So you just need to read the offset as a normal Int and divide by 1,000,000 to get the frequency in the more common Mhz units. The frequency helper classes was added to help people with encoding and decoding to/from the old BCD format. Because the new offsets are not in BCD I can't really add support for them in the same class in a way that makes sense. The new format is very easy to use now so there really isn't a need for the helper class any more. Paul
  6. Paul Henty

    Joystick number

    Further to Pete's reply, the DLL facility is just a wrapper over the joystick scanning facility in FSUIPC provided at offset 0x2910. As Pete says, this can only read real Joysticks 0-15. I can see offset 0x3340 deals with Virtual joysticks but there is no wrapper in the DLL for this. You'll need to access this offset directly. I recommend declaring an offset of type BitArray (4 bytes) for each Joystick. Then you can directly access each bit (button) as being 'true' or 'false' without needing to do bitwise masking. Each joystick will be at increments of 4 from the base offset of 3340. e.g. 3340, 3344, 3348, 334C etc... Paul
  7. Paul Henty

    Offset's 3160, 313C and 3148.

    There is Aircraft Model which you could use in addition to the Aircraft Type... private Offset<string> aircraftModel = new Offset<string>(0x3500, 24) There is also Aircraft Name. This often includes the livery as well. private Offset<string> aircraftName = new Offset<string>(0x3D00, 256); The contents of these offsets depends on what the developer of the aircraft has written in the Aircraft.cfg file. Paul
  8. Paul Henty

    Offset's 3160, 313C and 3148.

    Hi Quinch, This code doesn't look correct to me: string aircraftData = "({ATCID} - {ATCTYPE })"; It should have a $ in front of the string to use variable concatenation. At the moment this string would have the value "({ATCID} - {ATCTYPE })". You don't show your output code, but I suspect it's not outputting the 'aircraftData' string but something else. The code below works. You can try it for yourself and change it to fit into your code: private Offset<string> aircraftType = new Offset<string>(0x3160, 24); private Offset<string> aircraftID = new Offset<string>(0x3130, 12); private void Button6_Click(object sender, EventArgs e) { FSUIPCConnection.Process(); string ATCID = aircraftID.Value; string ATCTYPE = aircraftType.Value; string aircraftData = $"({ATCID} - {ATCTYPE})"; MessageBox.Show(aircraftData); } Paul
  9. Paul Henty

    Offset's 3160, 313C and 3148.

    Hi Pete, This is going to be a specific issue with using my DLL (or C# programming). I'll investigate further and help the OP. In the mean time it's best to move it to my sub forum. Thanks, Paul
  10. Paul Henty

    Simple offset extraction to Arduino

    Hi Emerson, I'm glad to hear you got it working. Congratulations on creating your landing gear product, and good luck with it. Paul
  11. I'm not sure an infinite loop is the best way to do this. You might have better performance using the event system. This monitors the LVar values in the background and fires an event when they change. Here's an example from another user... writeN1(varname, value) ipc.writeUB(0x66C0, value) end event.Lvar("B200CFuelCrossfeed", 100, "writeN1") writeN2(varname, value) ipc.writeUB(0x66C1, value) end event.Lvar("B200CRvsNotReady", 100, "writeN2") writeN3(varname, value) ipc.writeUB(0x66C2, value) end event.Lvar("B200CLBld", 100, "writeN3") writeN4(varname, value) ipc.writeUB(0x66C3, value) end event.Lvar("B200CRBld", 100, "writeN4") You declare a function that sets the value to the offset and then register this with the event system (event.Lvar). See the FSUIPC Lua docs for full details but in summary the call is: event.Lvar(lvarName, polling_interval_in_ms, function_to_run) If you prefer you can make only one function that is called by all the events. This would need to test the LVAR name (varname argument) and write to the correct offset. I don't know about the logging as I don't use lua at all. You'll need to ask Pete about that in the main support forum. Paul
  12. Good to hear that worked. These are the only official user offsets. However, if your application is only for your use you can try using the blocks marked as reserved. These are allocated to third-party software. For example 0x04E0 (88 Bytes) is for Project Magenta software. If you don't use that then you could try that block. Or there is a block from 0x6420 to 0x65EC (640 bytes) which is for PMDG aircraft if you don't have those. If your software is for general release (free or commercial) then you need to ask Pete (in the main support forum) for some offsets to be allocated for you so you don't clash with other software. Paul
  13. Hi Agoston, That's what the DLL does when you call ReadLVAR(). It's just a nicer way of using the offsets provided. Yes only one LVAR can be read or written for each process() call. That's just how FSUIPC works with LVARS. When you use ReadLVAR() in the DLL it does a process call. When you need to read a lot of LVARS then the time adds up. On my machine with FSX and default aircraft it takes about 20ms to get one LVAR. So reading 25 lvars will take half a second for me. No it won't make it faster. FSUIPC communicates on a single thread. The DLL is 'thread safe' which means if you use it from multiple threads and nothing bad will happen. But each thread will have to wait for the others to make Process calls. Only one thread can be talking to FSUIPC at a time. You could look into SimConnect. It's not very easy to use from .NET languages and the documentation is very poor for .NET. It might let you read LVARS faster, but I don't know. The LUA scripting in FSUIPC also allows you to read LVARS and also monitor them for changes (an LUA event is fired). You could write a LUA script to monitor your LVARs and send the values to user offsets where you can read them from your program. LUA scripts can only be run with a licensed copy of FSUIPC however. Documentation for the LUA library can be found in the Modules/FSUIPC Documents folder. Paul
  14. Paul Henty

    Negative Vertical Speed 030C offset

    You've declared the offset as an unsigned integer. That's why you are not getting negative values. private Offset<uint> verticalspeed = new Offset<uint>(0x02C8); My code again: private Offset<int> verticalSpeed = new Offset<int>(0x02C8); // 4-byte offset - Signed integer  That will fix it. Paul
  15. Paul Henty

    Negative Vertical Speed 030C offset

    You can post in the main support forum here: https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/ BUT: There would be no point if my Example Application shows the correct value. Please try that first. If that works then your code is wrong, not FSUIPC. If you post the relevant parts of your code here I can check it very quickly. I can't help much without seeing the code. Paul

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.