Jump to content
The simFlight Network Forums

jaxx

Members
  • Posts

    62
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by jaxx

  1. 1 hour ago, kingm56 said:

    Sorry to be nausaunse, Paul; however, I'm still unable to read any LVARS.  I continue to get this:

    Have you tried not using LogLVars and instead simply accessing the LVars directly? Very simple WindowsForms example:

    MSFSVariableServices VS;
    private void Form1_Load(object sender, EventArgs e)
    {
    	VS = new MSFSVariableServices();
    	VS.OnLogEntryReceived += VS_OnLogEntryReceived;
    	VS.Init(this.Handle);
    	VS.Start();
    }
    
    private void Button1_Click(object sender, EventArgs e)
    {
    	VS.RefreshData();
    	string text = VS.LVars.Count + " LVARS\r\n";
    	foreach (FsLVar lvar in VS.LVars)
    	{
    		text += lvar.Name + " = " + lvar.Value + "\r\n";
    	}
    	MessageBox.Show(text);
    }
    
    private void VS_OnLogEntryReceived(object sender, LogEventArgs e)
    {}

     

  2. I have written a small class that handles the connection starting, connection error handling etc.

    Reason is my app is constantly running and making requests and should not be impacted if the sim is not running or starting or shut down in between.

    With the FSUIPCConnection I could just check if the connection is open, if not try to open it and if there were an error (e.g. FSUIPC was not running) I would get some kind of exception and the app would wait a bit and try again.
    With the new MSFSVariableServices there seems to be no immediate failure (e.g. when start fails), instead the information is only then received in the log entry message events.

    Hence why I wrote this handler class.
    Usage is quite simple, when you run code through the "Try"-methods it will make sure the connection is available, start the connection if it's not and give a result if your action was successful. In case of an error it will try to stop the connection so on the next request it will try to start it again.
    Examples:

    // Initialize the wrapper. You still need your handle (e.g. this.Handle from Windows.Forms
    // or from a custom Messaging component in a console app) and optional a handler for messages
    VariableHandler variables = new VariableHandler(handle, msg => Console.WriteLine(msg));
    
    // As a connection start is implicitly ensured before each action this is enough to perform
    // an initial start (e.g. if you want to allow for time to gather the data before your first
    // real request):
    variables.Try(vs => {});
    
    // Reading all LVars:
    variables.Try(vs =>
    {
    	vs.RefreshData();
    	Console.WriteLine(vs.LVars.Count + " LVars:");
    	foreach (FsLVar lvar in vs.LVars)
    	{
    		Console.WriteLine(lvar.Name + " = " + lvar.Value);
    	}
    });
    
    // Do a refresh:
    variables.Try(vs => vs.RefreshData());
    
    // Reading a single LVar:
    if (variables.Try(vs => vs.LVars["LVAR_NAME"], out FsLVar lvar))
    {
    	if (lvar != null)
    	{
    		Console.WriteLine(lvar.Name + " = " + lvar.Value);
    	}
    }
    
    // Force a connection stop (something that should not be necessary usually):
    variables.Try(vs => vs.Stop());

    This is not a higher level abstraction layer, as you still work with the normal MSFSVariableServices object through the "Try"-methods, but you don't have to care about managing the connection or handling an Exception that occurred because you sent a request after the sim has shut down etc.

    It's not much but I think it could help someone having similar problems.

    VariableHandler.cs

  3. You're still having a default assignment for C5 configured (11=PC,5,C65759,0     -{FLAPS_DECR}-).
    Also do you want to use a button flag? From your description it seems you want a shift-function while button 134 is hold, not toggle a shift with a single press?
    11=CP(-C,134)C,5,C65759,0     -{FLAPS_DECR}-
    22=CP(+C,134)C,5,C67187,0     -{BATTERY1_SET}-

    • Like 1
  4. I tried with the new DLL and still can't read L/Hvars through it.
    But I tried writing and that works for what I can see.

    • log L/Hvars functions -> No vars found
    • get list/values functions -> nothing
    • get Lvar (name, id) functions -> returns nothing/0
       
    • set lvar functions -> works!
    • set hvar function -> works!
    • createLvar -> works!
    • createAircraftLvarFile -> works!

    So I'm not sure what it could be that writing works, but I can't read through the DLL, and the writes without the reads are not really usable, as you need to somehow get the ID from the name (which for testing I could only do through the WAPI Client).

    For reference, this is the C# wrapper I'm using around the DLL: FsuipcWapi.cs

  5. 1 hour ago, John Dowson said:

    I didn't know that but makes sense now I think about it! I can do that. I can provide both methods as they are trivial to implement. For the struct-array methods, would you prefer to pass in pre-allocated (with a size), or should the function allocate and the caller free the memory?

    I don't think I'm qualified to answer that, C# is not my main language. I can use it well enough to write standard applications, but don't know how it would behave in such cases.

  6. 21 minutes ago, John Dowson said:

    Not sure why that is - I will take a look.

    Thank you.
    I tested and can confirm that fsuipcw_createAircraftLvarFile will trigger the creation of the file in the work directory and it contains the Lvars, so at least my setup is not completely wrong.

    One more thing, would it be possible to provide an alternative the following methods?
    extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarValues(map<string, double >&returnMap);
    extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarList(unordered_map<int, string >&returnMap);
    extern "C" FSUIPC_WAPI_API void fsuipcw_getHvarList(unordered_map<int, string >&returnMap);

    C# cannot work with C++ std maps. A struct-array should work or a callback function that is called for each key-value pair.

  7. 1 hour ago, John Dowson said:

    I did this this morning, but haven't gotten around to test it yet...you could try with the following (you will still need the static lib): FSUIPC_WAPI.dllFSUIPC_WAPI.h

    As I said, its untested - I am planning to write a simple C client to test, but may take me a few days....

    John

    Thank you, I had a short look. Do you have any tips on how to call the methods?

    I call:
    - I call fsuipcw_init with the event id from the FSUIPC_WASM.ini (0x1FFF0) and a logger callback
    - Then fsuipcw_start -> logger callback receives "  [INFO]: Connected to MSFS", so it looks the general setup is correct
    - Then fsuipcw_logLvars -> "  [INFO]: We have 000 lvars: "
    So it seems I'm missing something, using the test client I can verify there are lvars present (and I made sure not to run the test client and my code at the same time in case they conflict).

    Any suggestions on what I'm missing?

  8. On 3/28/2021 at 6:21 PM, John Dowson said:

    I also have more of an idea how this can be used in managed c or, more generally, by any other language. I am aiming to upload a new dll library project in the next few days, that will use the currently provided API but expose them in a dll so that they can be accessed in other languages.

    I'm looking forward to this, I tried to wrap the module into a dll, but my C++ knowledge is decades old and I couldn't get anywhere.

  9. On 3/28/2021 at 4:21 AM, Adn said:

    hello , 

    I can't set my switch on honeycomb bravo and mag left both star on alpha . FSUIPC7 dont detect my button.

    Are you sure you're using the 7.1.0 beta version? I have the same device and could configure that through the GUI just fine
    magneto.PNG.9b582f2f1cfd01e7d9c4f32ba42dcae7.PNG
    The resulting entries in the ini were:
    60=PA,30,C66023,0     -{MAGNETO_OFF}-
    61=PA,31,C66024,0     -{MAGNETO_RIGHT}-
    62=PA,132,C66025,0     -{MAGNETO_LEFT}-
    63=PA,133,C66026,0     -{MAGNETO_BOTH}-
    64=PA,134,C66027,0     -{MAGNETO_START}-

    Do you maybe still have the LUA scripts active for the alpha/bravo buttons? I don't know, but maybe those could interfere?

  10. 3 hours ago, John Dowson said:

    How about the 128 button beta release?

    I'm using the 7.1.0a beta and no problems with the rocker switches on both the Alpha and Bravo.
    I can assign every button and switch via the normal button assignments with that version:
    53=PB,135,C66072,0     -{PITOT_HEAT_ON}-
    54=PB,136,C66073,0     -{PITOT_HEAT_OFF}-

    Before I was using my own custom lua scripts for those, but now I could shift everything of the Alpha/Bravo inputs from lua to standard configuration (except some custom logic I have left in lua to detect if I'm dialing the input dial slow or fast).

  11. 40 minutes ago, John Dowson said:

    If you could test this before then, that would be good, Thanks,

    Have tested both issues and they are fixed for me!
    Also I can confirm that setting the transponder code via offset now works again. I assume that was already fixed in the original version, but I didn't get to testing it until now.

    Thank you very much!

    Jan

  12. 4 minutes ago, John Dowson said:

    Ok, I'll look into this.

    Thank you :)

    1 minute ago, John Dowson said:

    Is that from the dev menus? I haven't tried this... Was it previously working? I will also take a look at this....

    Yes, that's from the dev menu. I just added it because I thought that selecting a plane there might cause MSFS to trigger the ready-to-fly state again, but it doesn't seem so.

     

     

  13. Same effect after switching aircraft through the aircraft selector while FSUIPC is running. When I don't start a new flight, no axes work.

    Edit:
    And the offset logging seems to be a problem when saving from the GUI, when I edit the type in the FSUIPC.ini directly it stays that way, until I do a save in the Log->Offsets dialog, then it reverts back to S8.

  14. I have two problems in version 7.0.7:

    1. Some functions are not working when FSUIPC is started when the flight is already loaded.
      For example axes are no longer processed (I can monitor the axes changes in the assignment window, but in normal usage nothing is sent to the sim).
      Maybe this has something to do with this from the change notes: update to starting/stopping [Auto] luas: now started when ready-to-fly
      As I can see the ready-to-fly flag is false/no when starting FSUIPC after the flight has loaded. Though the problem I have is with axes, not with lua.
    2. In Log->Offsets... I can no longer change the type. I can select any type, but it reverts back to "S8" when clicking OK.

    Edit:
    Just to clarify, I didn't have the problems in the last version (I think I had 7.0.6 before) and the 7.0.8 beta seems to have the same problems.

  15. I'm not sure if I did something wrong, but compound buttons seem to no longer work (existing ones that worked before and new ones), even when they are in the old <32 button range (none of those work):

    55=CR(+A,6)A,4,C65615,0 	-{ELEV_TRIM_UP}-
    56=CR(+A,7)A,5,C65607,0 	-{ELEV_TRIM_DN}-
    57=CR(+A,11)A,9,C66279,0 	-{RUDDER_TRIM_RIGHT}-
    58=CR(+A,10)A,8,C66278,0 	-{RUDDER_TRIM_LEFT}-
    
    65=CP(+B,20)B,12,C65892,0 	-{AP_ALT_VAR_INC}-
    66=CP(+B,20)B,13,C65893,0 	-{AP_ALT_VAR_DEC}-
    67=CP(+B,19)B,12,C65894,0 	-{AP_VS_VAR_INC}-
    68=CP(+B,19)B,13,C65895,0 	-{AP_VS_VAR_DEC}-
    69=CP(+B,18)B,12,C65879,0 	-{HEADING_BUG_INC}-
    70=CP(+B,18)B,13,C65880,0 	-{HEADING_BUG_DEC}-
    71=CP(+B,17)B,12,C65663,0 	-{VOR1_OBI_INC}-
    72=CP(+B,17)B,13,C65662,0 	-{VOR1_OBI_DEC}-
    73=CP(+B,16)B,12,C65896,0 	-{AP_SPD_VAR_INC}-
    74=CP(+B,16)B,13,C65897,0 	-{AP_SPD_VAR_DEC}-

    Only pressing button A4:

       407578 Button changed: bRef=0, Joy=4 (A), Btn=4, Pressed
       407578 [Buttons] 55=CR(+A,6)A,4,C65615,0
       407578 .... Condition (+A,6) = FALSE
       407766 Button changed: bRef=0, Joy=4 (A), Btn=4, Released

    Pressing A4 while holding A6, same output, I would expect condition true:

       412562 Button changed: bRef=0, Joy=4 (A), Btn=4, Pressed
       412562 [Buttons] 55=CR(+A,6)A,4,C65615,0
       412562 .... Condition (+A,6) = FALSE
       412687 Button changed: bRef=0, Joy=4 (A), Btn=4, Released


    EDIT:
    For comparison the output from 7.0.7 (same config):

        29703 Button changed: bRef=0, Joy=4 (A), Btn=4, Pressed
        29703 [Buttons] 55=CR(+A,6)A,4,C65615,0
        29703 .... Condition (+A,6) = TRUE
        29703 Repeating flag set: bRef=0, Joy=4, Btn=4 (RepeatDelayCtr=1)
        29703 FS Control Sent: Ctrl=65615, Param=0 ELEV_TRIM_UP
        29781 Button changed: bRef=0, Joy=4 (A), Btn=4, Released

     

  16. Great to hear. In that case, if you don't want any special handling like I did in my second example for the reverse thrust, you can just do what I showed in the picture of my last post.
    Use "Send to FS as normal Axes" to "Throttle1 Axis Set Ex1"/"Throttle2 Axis Set Ex1".
    The result sent to the simulator will be exactly the same. When you don't manipulate the value in the LUA script, doing axes->offset->lua->"Throttle1 Axis Set Ex1" is the same as just axes->"Throttle1 Axis Set Ex1", but the latter has much less overhead.

  17. 19 minutes ago, chrisal said:

    Hi

    Well I don't really understand what we're doing here but I've copied this throttle lua route exactly and the throttles are now moving - but in reverse.

    Any advice?

    Chris

    My solution is under the assumption that you have to reverse the axes (like, the value reported from the axes in the forward position is negative and at idle is positive, but the sim expects it the other way round).
    Maybe with your hardware this is already working correctly, then you can simply use the control directly from the "Axes Assignment" without the need with the offset->lua workaround:
    axes_assigment.PNG.0d6dddc43c9723e5af60b345665c7eaf.PNG

    Or alternatively don't reverse in the lua scripts, change
    (-1) - value -> value
    in the first lua or
    (16383 - value) -> (value + 16384)
    in the lua example with reversers.

    Also don't forget to calibrate the axes inside the aircraft on the pads options page and make sure you don't have the axes assigned in the MSFS settings.

  18. I adapted my solution a bit to also get the reverser working with the Honeycomb Bravo reverser levers.
    I map the full axis to only the positive range (0-16383):

    function throttle_1(offset, value)
    	-- 67103: Throttle1 Axis Set Ex1
    	ipc.control(67103, math.floor((16383 - value) / 2))
    end
    
    function throttle_2(offset, value)
    	-- 67110: Throttle2 Axis Set Ex1
    	ipc.control(67110, math.floor((16383 - value) / 2))
    end

    And then set the reverser levers press and release to set and release the reverse throttle:

    [Buttons.CRJ]
    0=W66C2>16300 PB,10,C67110,-16384 	-{THROTTLE2_AXIS_SET_EX1}-
    1=W66C2>16300 UB,10,C67110,0 	-{THROTTLE2_AXIS_SET_EX1}-
    2=W66C0>16300 PB,9,C67103,-16384 	-{THROTTLE1_AXIS_SET_EX1}-
    3=W66C0>16300 UB,9,C67103,0 	-{THROTTLE1_AXIS_SET_EX1}-

    Works more reliably for me than using throttle decrease for the reversers. The "W66C0>16300" is just there to prevent any reverser action when the throttle is not near the idle position.

    You have to enable "Reverser Axis" in the CRJ cockpit options for this and calibrate the "rev max" to when you have pulled the reversers switches.throttleCalibration.PNG.b44656e7ce93ac22e74d6e1ac415e45d.PNG

    • Like 1
  19. The throttles need a bit of a workaround, as most simple solutions like going through FSUIPC calibration don't work (e.g. using FSUIPC calibration will control the engine throttle somehow, but the throttle lever will not move and the CRJ detent calibration does not work either).

    From what I tried the only thing that works correctly is the controls "Throttle1 Axis Set Ex1" (67103) and "Throttle2 Axis Set Ex1" (67110) (have not found much documentation on those control numbers, seems they were used for something completely different in FSX/P3D).
    But when you for example use "Send to FS as normal axis" to "Throttle1 Axis Set Ex1", the axis is still reversed and FSUIPC seems to only support reversing when using FSUIPC calibration.

    So my solution is to send the axis to a user offset and then map the reverse of that offset to the control with LUA.
    With that I have working levers and the CRJ detent calibration also works:

    FSUIPC.ini (CRJ specific parts only):

    [LuaFiles]
    LuaPath=lua
    1=CRJ
    [Profile.CRJ]
    1=CRJ
    [Auto.CRJ]
    1=Lua CRJ
    [Axes.CRJ]
    RangeRepeatRate=10
    0=BR,32,F,x020066C0,0,0,0    -{ FSUIPC: offset word set, offset 66C0 }-
    1=BV,32,F,x020066C2,0,0,0    -{ FSUIPC: offset word set, offset 66C2 }-

    offset.PNG.c864dbcb939df59d5fdae119b92b26df.PNG

    CRJ.lua:

    -- init throttle at idle on startup
    ipc.writeSW(0x66C0, 16383)
    ipc.writeSW(0x66C2, 16383)
    
    function throttle_1(offset, value)
    	-- 67103: Throttle1 Axis Set Ex1
    	ipc.control(67103, (-1) - value)
    end
    
    function throttle_2(offset, value)
    	-- 67110: Throttle2 Axis Set Ex1
    	ipc.control(67110, (-1) - value)
    end
    
    event.offset(0x66C0, "SW", "throttle_1")
    event.offset(0x66C2, "SW", "throttle_2")

     

×
×
  • 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.