Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Content Count

    1,007
  • Joined

  • Days Won

    34

Paul Henty last won the day on June 3

Paul Henty had the most liked content!

Community Reputation

52 Excellent

3 Followers

About Paul Henty

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Profile Information

  • Gender
    Male
  • Location
    Gloucestershire, UK

Recent Profile Visitors

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

  1. Dear Expert,

    we are working on a 6 DOF motion simulator for FSX/ P3D. Actually we are new in this field so we are confuse in the selection of 6 offset values for our 6 stepper motors. We are using the paulhenty code to get the data from the FSX game and done it successfully. But the main confusion is which offset we will use to assign the rotation of motion for motion simulator? We were thinking to use " 3060, 3068, 3070" values for x y and z axis? but not sure on that. Can anyone of you help us in this regard. Your earlier response will be highly appreciable.

  2. Hi George, Apologies for the delay in replying. The reason it won't show after the first time is that the values of the offsets have not changed since the first time Process() was called. The DLL will not write normal offsets unless their values change. To solution is to mark the offsets as 'Write-Only'. These type of offsets will be written every time Process() is called, even if the offsets values have not been changed. The messaging offsets are a good example of write-only offsets. You would never have to read value from them. Because they are written on every process, you should also put them in their own group so that you can control exactly when they are written. (You process that group only). Here are the offset declarations, placing them in their own group called 'message' and marking them as write-only: (Last parameter is set to true). private Offset<string> messageWrite = new Offset<string>("message", 0x3380, 128, true); private Offset<short> messageDuration = new Offset<short>("message", 0x32FA, true); Here is the code for writing. It's the same except we are now processing the specific group. string Message = "my message test"; this.messageWrite.Value = Message; this.messageDuration.Value = 2; FSUIPCConnection.Process("message"); Paul
  3. Hi MR, Lua questions should really be posted in the main support forum. This sub-forum is for programming with .NET languages. However, looking at the documentation, event.sim doesn't fire when the sim loads. Only on CLOSE, FLIGHTLOAD, FLIGHTSAVE and AIRCRAFTCHANGE. You can run a LUA script when the sim has finished loading and is ready to fly by naming your LUA file 'ipcready.lua'. That might be useful to you. I'm not an expert on LUA so if you need more help please ask in the main forum. Kind Regards, Paul
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Hi Emerson, I'm glad to hear you got it working. Congratulations on creating your landing gear product, and good luck with it. Paul
  14. 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
  15. 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
×
×
  • 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.