:orphan: .. **************************************************************************** .. CUI .. .. The Advanced Framework for Simulation, Integration, and Modeling (AFSIM) .. .. The use, dissemination or disclosure of data in this file is subject to .. limitation or restriction. See accompanying README and LICENSE for details. .. **************************************************************************** WSF_UPLINK_PROCESSOR -------------------- **Derives From:** :model:`WSF_SCRIPT_PROCESSOR` **Script Classes:** :class:`WsfUplinkProcessor` .. model:: processor WSF_UPLINK_PROCESSOR .. parsed-literal:: processor :model:`WSF_UPLINK_PROCESSOR` :command:`WSF_SCRIPT_PROCESSOR` Commands ... max_weapon_uplinks_ weapon_uplink_path_ end_processor Overview ======== WSF_UPLINK_PROCESSOR is the default method of access and control for uplinks. If a :model:`WSF_TASK_PROCESSOR` or RIPR processor has uplink settings specified, those are actually fed to the default uplink processor on their platform. In the future, we envision other uplink processors being made available that might service those uplinks in varied ways. For now, the only operation of the WSF_UPLINK_PROCESSOR matches that of the :model:`WSF_TASK_PROCESSOR` and RIPR processor. See :class:`WsfUplinkProcessor` for the various query methods and control methods available. If you do not specify uplink paths (with the weapon_uplink_path_ command), then all uplinks that are started will be serviced by local track updates for the target of interest. .. command:: max_weapon_uplinks Specifies the maximum number of active uplinks the RIPR agent is capable of. Default: 0, no maximum .. command:: weapon_uplink_path If a weapon uplink path is specified, then the processor will support uplinks by sending track updates over the designated comm to the fired weapon platform using tracks from the designated sensor. Uplinks can be stopped and started from script, see :class:`WsfUplinkProcessor`. Default: no paths defined