Handle disconnects by the Switch.

Author: Mysticial

ClientSource/Connection/PABotBase.cpp

@@ -534,6 +534,14 @@ void PABotBase::on_recv_message(BotBaseMessage message){
         }
         return;
     }
+    case PABB_MSG_ERROR_DISCONNECTED:{
+        m_logger.log("The console has disconnected the controller.", COLOR_RED);
+        m_error_message = "Disconnected by console.";
+        m_error.store(true, std::memory_order_release);
+        std::lock_guard<std::mutex> lg0(m_sleep_lock);
+        m_cv.notify_all();
+        return;
+    }
     case PABB_MSG_REQUEST_COMMAND_FINISHED:{
         process_command_finished<pabb_MsgRequestCommandFinished>(std::move(message));
         return;

ClientSource/Libraries/MessageConverter.cpp

@@ -123,6 +123,17 @@ int register_message_converters_framework_errors(){
             return ss.str();
         }
     );
+    register_message_converter(
+        PABB_MSG_ERROR_DISCONNECTED,
+        [](const std::string& body){
+            std::ostringstream ss;
+            ss << "PABB_MSG_ERROR_DISCONNECTED - ";
+            if (body.size() != sizeof(pabb_MsgInfoDisconnected)){ ss << "(invalid size)" << std::endl; return ss.str(); }
+            const auto* params = (const pabb_MsgInfoDisconnected*)body.c_str();
+            ss << "error code = " << params->error_code;
+            return ss.str();
+        }
+    );
     return 0;
 }
 int register_message_converters_framework_acks(){
@@ -329,6 +340,7 @@ int register_message_converters_framework_requests(){
             return ss.str();
         }
     );
+#if 0
     register_message_converter(
         PABB_MSG_COMMAND_END_PROGRAM_CALLBACK,
         [](const std::string& body){
@@ -340,6 +352,7 @@ int register_message_converters_framework_requests(){
             return ss.str();
         }
     );
+#endif
     register_message_converter(
         PABB_MSG_COMMAND_SET_LED_STATE,
         [](const std::string& body){

Common/SerialPABotBase/SerialPABotBase_Protocol.h

@@ -1,122 +1,122 @@
 /*  Serial PABotBase Message Protocol
- * 
+ *
  *  From: https://github.com/PokemonAutomation/
- * 
- * 
+ *
+ *
  *      Pokemon Automation Bot-Base implements reliable data transmissions over
  *  serial communication. This is done by checksumming messages along with a
  *  protocol that is tolerant to data drops.
- * 
+ *
  *  This file describes the message protocol. The data being transmitted is raw
  *  binary and not is readable text.
- * 
- * 
+ *
+ *
  *  Message Format:
  *      byte 0: Length of the entire message. (bits are inverted)
  *      byte 1: Message Type
  *      byte X: Optional data of variable length.
  *      Last 4 bytes: CRC32C of the entire message except these last 4 bytes.
- * 
+ *
  *      Thus there are 6 bytes of overhead for each message.
- * 
- * 
+ *
+ *
  *  There are currently 4 categories of message types:
- * 
+ *
  *      1.  Info: These are simple one-way messages. They do not need to be
  *          acked and may be dropped without adversely affecting anything.
- * 
+ *
  *      2.  Ack/Response: These are messages sent in response to an earlier
  *          message that was received.
- * 
+ *
  *      3.  Request: The sender requests the receiver to do something simple.
  *          The receiver must respond with an ack.
- * 
+ *
  *          This is used for things that take no clock time. For example, querying
  *          for program identifiers, turning on/off LEDs, or setting flags in the
  *          program to change its behavior in the future.
- * 
+ *
  *      4.  Command: The sender requests the receiver to do a large asynchronous
  *          operation. The receiver must ack this message. Once the command is
  *          finished, the receiver must send a request message back to the sender
  *          to indicate that the command is finished.
- * 
+ *
  *          This is used for issuing button presses or other subroutines that
  *          consume time.
- * 
- * 
+ *
+ *
  *  General Protocol:
- * 
+ *
  *      1.  Every time you send a new request/command message, you increment
  *          your sequence number (seqnum) by 1.
- * 
+ *
  *      2.  If you receive an invalid message (bad length or bad checksum), ignore
  *          the first byte and attempt to parse the next byte as the start of a
  *          new message.
- * 
+ *
  *      3.  If you receive a zero for the 1st byte of a message, ignore it and
  *          attempt to parse the next byte as the start of a new message.
- * 
+ *
  *      4.  At any point, you can send a bunch of zero bytes. This will cause
  *          the receiver to re-synchronize.
- * 
+ *
  *      5.  If you receive a request/command message, you must send the appropriate
  *          ack/response message using the same seqnum.
- * 
+ *
  *      6.  If you receive a command message, you must first ack the message itself.
  *          Once the command is finished, you must send a request referencing the
  *          command to indicate that it is finished. You will receive an ack for
  *          this short (finishing) command, and if you don't, send it again until
  *          you do. If the command finishes immediately, you can skip the ack and
  *          just send the finish request.
- * 
+ *
  *      7.  If you send a request/command message and don't get a response after
  *          a time limit, you should resend the message with the same seqnum.
- * 
+ *
  *      8.  If you receive a request/command that has a seqnum ahead of what you
  *          are expecting, it means an earlier request/command was dropped.
  *          Do not process the request/command since you will lose ordering.
- * 
+ *
  *      9.  If you receive a request/command that has an old seqnum, it is a
  *          retransmit. Send an ack for it, but don't process it again. (idempotency)
- * 
- * 
+ *
+ *
  *  Failure Analysis:
- * 
+ *
  *      -   Corrupted messages will either fail checksum or will have an invalid
  *          length/type. These are simply ignored and dropped.
- * 
+ *
  *      -   If either sender or receiver gets out-of-sync and loses track of
  *          message boundaries, it will eventually find the boundary again by
  *          simply trying to parse every byte as the start of a new message and
  *          verifying the length and CRC.
- * 
+ *
  *      -   If a request/command is dropped, no ack will be received. The sender
  *          will eventually send the command again. (#7)
- * 
+ *
  *      -   If an ack is dropped, the sender will eventually resend the
  *          request/command again. The receiver will see the duplicate
  *          request/command and ack it. But the receiver will not process it
  *          again to preserve idempotency. (#9)
- * 
+ *
  *  The current protocol guarantees that all commands are processed in order
  *  exactly once. Requests are not guaranteed to process in order and may execute
  *  more than once so they should be idempotent.
- * 
+ *
  *  The protocol also allows both sides to queue up requests and commands.
  *  In other words, it is possible to send multiple requests/commands at once
  *  without waiting for the individual acks.
- * 
- * 
+ *
+ *
  *  PABotBase Specifics:
- * 
+ *
  *      -   PABotBase can queue up to 4 commands. If it receives any commands
  *          while the queue is full, it drops it and responds with
  *          "PABB_MSG_ERROR_COMMAND_DROPPED". (Any command that results in a
  *          button press or a wait is a long command.)
- * 
+ *
  *      -   PABotBase can still handle other messages while it is running a long
  *          command.
- * 
+ *
  */
 
 #ifndef PokemonAutomation_SerialPABotBase_Protocol_H
@@ -199,6 +199,11 @@ typedef struct{
     uint16_t error_code;
 } PABB_PACK pabb_MsgInfoWARNING;
 
+#define PABB_MSG_ERROR_DISCONNECTED             0x08
+typedef struct{
+    uint16_t error_code;
+} PABB_PACK pabb_MsgInfoDisconnected;
+
 ////////////////////////////////////////////////////////////////////////////////
 //  Ack
 #define PABB_MSG_ACK_COMMAND                    0x10
@@ -308,10 +313,12 @@ typedef struct{
 ////////////////////////////////////////////////////////////////////////////////
 //  Commands
 
+#if 0
 #define PABB_MSG_COMMAND_END_PROGRAM_CALLBACK   0x80
 typedef struct{
     seqnum_t seqnum;
 } PABB_PACK pabb_end_program_callback;
+#endif
 
 #define PABB_MSG_COMMAND_SET_LED_STATE          0x81
 typedef struct{

SerialPrograms/Source/CommonFramework/Globals.cpp

@@ -25,7 +25,7 @@ namespace PokemonAutomation{
 const bool IS_BETA_VERSION = true;
 const int PROGRAM_VERSION_MAJOR = 0;
 const int PROGRAM_VERSION_MINOR = 52;
-const int PROGRAM_VERSION_PATCH = 1;
+const int PROGRAM_VERSION_PATCH = 2;
 
 const std::string PROGRAM_VERSION_BASE =
     "v" + std::to_string(PROGRAM_VERSION_MAJOR) +

SerialPrograms/Source/NintendoSwitch/Controllers/SerialPABotBase/NintendoSwitch_SerialPABotBase_WirelessController.cpp

@@ -241,7 +241,9 @@ void SerialPABotBase_WirelessController::status_thread(){
             error = "Unknown error.";
         }
         if (!error.empty()){
+            stop();
             m_handle.set_status_line1(error, COLOR_RED);
+            break;
         }
 
 //        cout << "lock()" << endl;