Simulator gets stuck when using StartCommand

[maduranma]

I use the DataRefTool and I discovered for my purpose that sim/flight_controls/pitch_trim_down and up is perfect.

Just for testing I do: CancellationTokenSource trimTokenSource = xPlaneConnector.StartCommand(XPlaneConnector.Commands.FlightControlsPitchTrimUp);

After 3 seconds I cancel the token.

During the 3 seconds the sim just hung up and the trim doesn't change.

Am I missing something? Tested on FF A320

Edit: Tested in a Cessna 172 default, it gets trimmed after closing the program, same, it hungs, but after the hung the trim that was being applied appears.

Edit 2: I've looked the code of the connector. It seems like there's a thread making an infinite loop sending the command, in my case it overloads the simulator, isn't there any alternative? I've tried sending the command every 20ms and less, but not enough even to move...

[MaxFerretti]

Hello, sorry for the late reply. I think this issue could be related to the high network traffic the StartCommand is generating. When SendCommand is invoked it starts a Task where the command is continuously sent until cancellation. Could you send me your operating system along with some information about the spec you are using? I will check if I can adapt the StartCommand in order to not saturate the network in this way.

Thank you, Max

Il giorno mar 23 feb 2021 alle ore 14:37 Martín Durán < notifications@github.com> ha scritto:

I use the DataRefTool and I discovered for my purpose that sim/flight_controls/pitch_trim_down and up is perfect.

Just for testing I do: CancellationTokenSource trimTokenSource = xPlaneConnector.StartCommand(XPlaneConnector.Commands.FlightControlsPitchTrimUp);

After 3 seconds I cancel the token.

During the 3 seconds the sim just hung up and the trim doesn't change.

Am I missing something? Tested on FF A320

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MaxFerretti/XPlaneConnector/issues/21, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYWYQVXGC6VK5XK3IPCHRTTAOVR3ANCNFSM4YCQAWPA .

[maduranma]

I have an i7 4790k OCed at 5.2GHz, which is still a quite decent processor. Windows 10 latest update.

I've seen that you just do a thread that is sending the command in an infinite loop.

I've tried adding a delay but the cockpit did not react, but I have not reasearch too much, I was just waiting.

[BirdyB]

I have the same issue with Xplane 11.55r2 on MacOS Monterey. If i use your example with engaging starters X-Plane crashes immediately.

[DocMoebiuz]

The problem is that the task repeats the Command too fast. A thread.Sleep(10) will help, e.g.

public CancellationTokenSource StartCommand(XPlaneCommand command)
{
    var tokenSource = new CancellationTokenSource();

    Task.Run(() =>
    {
        while (!tokenSource.IsCancellationRequested)
        {
            SendCommand(command);
            Thread.Sleep(5);
        }
    }, tokenSource.Token);

    return tokenSource;
}

The starter will work and xplane won't crash for me, but we have a general limitation with this approach: It is a repeated "press" and not a "hold" - the effect of "holding" a Command is different, e.g. GNS530 CLR Button. It will bring you to the default page. I cannot trigger this behavior with the repeated command.

As far as I can tell, the UDP interface does not expose the https://developer.x-plane.com/sdk/XPLMCommandBegin/ and https://developer.x-plane.com/sdk/XPLMCommandEnd/ - so in my opinion there is no option to do it correctly at all without actually using a XP Plugin that is able to receive a special UDP message type and then trigger the respective API functions.