我第一次用 AFSim 2.9 的時候光是讓一個最小場景跑起來就折騰了整整一個下午。不是軟件本身多難而是我一開始就把它的定位搞錯了——它不是一個打開就能拖模型的圖形工具而是一套由文本腳本驅(qū)動的建模仿真框架。你真正理解了這個邏輯之后后面所有的功能都是順理成章的。這篇文章我想基于 AFSim 2.9 的中文使用視角把從安裝、跑通第一個場景到傳感器/武器建模、Warlock 可視化調(diào)試、再到事件觸發(fā)和外部接口的完整鏈路全部串一遍。文中涉及的步驟和踩坑經(jīng)驗都是我實際在 Windows 和 Linux 兩臺機器上反復(fù)驗證過的。文末我會提一下配套的 B 站視頻圖文和視頻對照著看上手會快很多。1. 為什么選擇 AFSim 2.9 做建模仿真先搞清楚它解決什么問題1.1 什么是 AFSim它不是軟件而是一整套仿真生態(tài)AFSim 的全稱是 Advanced Framework for Simulation, Integration, and Modeling翻譯過來就是仿真、集成與建模高級框架。最早源自防務(wù)科研領(lǐng)域后來逐步開源現(xiàn)在官方發(fā)布包可以在公開渠道免費下載社區(qū)里也已經(jīng)積累了大量二次開發(fā)和教學(xué)資料。很多新手第一次下載 AFSim 2.9解壓之后看到一堆文件夾就懵了bin、data、docs、examples、plugins……這跟普通應(yīng)用軟件的安裝目錄完全不是一個概念。原因在于 AFSim 本身是一組工具的集合核心包括Mystic仿真引擎負(fù)責(zé)解釋執(zhí)行場景腳本、推進仿真時間、維護對象交互Warlock圖形化前端可以瀏覽場景、運行仿真、可視化調(diào)試TView地理信息可視化工具適合看大范圍航跡和態(tài)勢MysticMgr腳本管理和調(diào)試環(huán)境也就是說AFSim 給你的不是一個軟件而是一條完整的建模仿真工作鏈。你可以全程用文本腳本定義仿真任務(wù)交給 Mystic 在服務(wù)器上批量跑也可以用 Warlock 圖形化搭場景、調(diào)參數(shù)、看運行過程。兩種方式最終都收斂到同一套 Mystic 腳本語法這是理解 AFSim 的關(guān)鍵。1.2 相比自研仿真代碼AFSim 的核心價值在哪里我自己最早做體系仿真的時候團隊里都是自己用 C 寫時間步進循環(huán)每個平臺一個線程每幀遍歷所有對象做交互判斷。這種方案在小規(guī)模場景里沒問題一旦平臺數(shù)量過百、傳感器和通信鏈路多起來代碼復(fù)雜度就爆炸式增長。AFSim 把這一層全部抽象掉了。它內(nèi)置了通用的事件調(diào)度機制、坐標(biāo)系轉(zhuǎn)換、時間推進邏輯以及傳感器、武器、通信、電子戰(zhàn)等領(lǐng)域通用的建?？蚣堋Ｄ阋龅氖虑閺膶懸粋€仿真引擎變成了在框架里描述你的對象和行為工作重心回到業(yè)務(wù)本身。這個轉(zhuǎn)變帶來的效率提升是數(shù)量級的尤其是做裝備論證、戰(zhàn)術(shù)戰(zhàn)法仿真、傳感器組網(wǎng)這類需要反復(fù)改參數(shù)的場景。1.3 2.9 這個版本值不值得用我的判斷如果有人問我 AFSim 2.9 相比舊版本的最大感知差異我的感受有幾點Warlock 的三維視圖比老版本流暢了不少打開大場景縮放拖拽沒那么卡了Mystic 腳本解釋器在處理超長場景文件時速度有提升官方 examples 的覆蓋面更全基本你想驗證的雷達探測、導(dǎo)彈攔截、通信中繼、電子干擾都能找到對應(yīng)的參考場景。當(dāng)然更細(xì)的更新條目建議以官方 Release Notes 為準(zhǔn)但作為入門版本2.9 是合適的選擇。2. 安裝與運行環(huán)境在踩坑之前先跑通完整流程2.1 獲取安裝包與理解目錄結(jié)構(gòu)AFSim 2.9 的安裝包需要從官方 GitHub Releases 頁面下載下載時注意區(qū)分操作系統(tǒng)版本。官方發(fā)布包通常同時提供 Windows 和 Linux 兩個版本格式分別是 zip 和 tar 包。下載后直接解壓就能用沒有傳統(tǒng)的安裝向?qū)Лh(huán)節(jié)。解壓后你會看到一個典型的發(fā)布目錄結(jié)構(gòu)目錄作用bin/存放可執(zhí)行文件如 afsimMystic 引擎、warlock 等docs/官方文檔包括用戶手冊、Mystic 語言參考、Warlock 使用指南examples/官方示例場景是重點學(xué)習(xí)材料data/基礎(chǔ)數(shù)據(jù)比如地形數(shù)據(jù)、地圖要素plugins/可加載的動態(tài)庫插件我的建議是解壓之后先別急著跑花十分鐘把 examples 目錄瀏覽一遍。里面每一個子目錄通常就是一個完整的仿真場景包含若干 .txt 場景文件和配套數(shù)據(jù)。你之后寫的所有場景本質(zhì)上都是這套結(jié)構(gòu)的復(fù)刻。2.2 Windows 上的運行方式與首次驗證Windows 環(huán)境下我直接進入 bin 目錄雙擊 warlock 可執(zhí)行文件啟動圖形界面。首次啟動如果一切正常會進入一個空白工作區(qū)。這時候從菜單欄選擇打開場景定位到 examples 目錄下任意一個場景文件夾Warlock 就會把場景加載進來并顯示所有平臺的位置。這里要注意一個常見坑Warlock 打開場景后如果地圖背景是純黑的是正?，F(xiàn)象因為默認(rèn)沒有加載在線地圖或地形數(shù)據(jù)不代表軟件出問題。你可以直接點擊運行按鈕讓仿真跑起來觀察平臺移動和傳感器波束這個過程中如果沒有任何報錯日志就說明核心安裝是成功的。命令行驗證的方式更直接也比較適合后續(xù)在服務(wù)器上用。在 bin 目錄打開命令行工具執(zhí)行./afsim --help如果能正常打印出參數(shù)說明列表說明 Mystic 引擎可以正常工作。這一步非常重要因為 AFSim 的大量使用場景是無圖形界面的批量仿真Mystic 命令行才是主力工具。2.3 Linux 服務(wù)器上的部署細(xì)節(jié)與依賴問題Linux 上我踩過的坑主要集中在動態(tài)庫依賴。如果服務(wù)器是最小化安裝比如只裝了 CentOS 基礎(chǔ)包運行 warlock 時大概率會報缺少 libX11、libGL、libXext 之類的錯誤。解決辦法很簡單安裝對應(yīng)的桌面運行庫即可。如果只是用 Mystic 引擎跑批量仿真不啟動 Warlock 圖形界面就不需要這些圖形庫依賴這也是服務(wù)器上跑仿真最常見的方式。部署完成后我用一個最小場景做命令行驗證cd /path/to/afsim/bin ./afsim /path/to/examples/SomeExample正常的話Mystic 引擎會開始加載場景輸出初始化信息然后按仿真時間推進最后打印仿真結(jié)束信息并退出。如果在這一步就報錯多半是場景文件夾路徑不對或缺少權(quán)限先檢查這兩項。2.4 驗證安裝是否成功跑通官方示例場景我每次拿到新版本第一個跑通的永遠是官方示例場景。原因很簡單官方示例是最標(biāo)準(zhǔn)的代碼能跑通它說明你的環(huán)境和發(fā)布包完全沒有兼容性問題之后自己寫的場景出了問題至少可以排除環(huán)境壞了這個因素。跑官方示例時注意觀察輸出信息里有沒有大量 Error 或 Warning。少量 Warning 可能是數(shù)據(jù)缺失、屬性未定義可以容忍但 Error 出現(xiàn)基本意味著場景沒有正確初始化。用 Warlock 打開同一場景如果能看到平臺圖標(biāo)、傳感器波束圖形說明整個安裝鏈路已經(jīng)驗證完畢可以開始理解場景腳本了。3. 理解 AFSim 2.9 的運行機制腳本、引擎與仿真推進3.1 Mystic 腳本不是傳統(tǒng)的編程語言AFSim 的場景描述文件用的是 Mystic 腳本語言。新手最容易誤解的是以為它是類似 Python 的編程語言想在腳本里寫循環(huán)、定義函數(shù)。其實 Mystic 更準(zhǔn)確的定位是結(jié)構(gòu)化的對象描述配置語言它做的事情是把仿真中的對象、屬性、行為用文本形式固定下來重構(gòu)給引擎。真正的流程是Mystic 引擎讀取這些文本腳本在內(nèi)存中構(gòu)建仿真對象樹然后進入時間推進循環(huán)。因此腳本文件的組織方式、注釋習(xí)慣、模塊劃分直接影響你后續(xù)維護復(fù)雜場景的效率。把腳本當(dāng)作代碼來認(rèn)真對待是一個 AFSim 使用者成熟起來的標(biāo)志。3.2 一個最小場景的語法結(jié)構(gòu)拆解以你下載的官方 examples 為參考一個最簡單的場景腳本大致包含以下幾部分。我用示意代碼來說明結(jié)構(gòu)細(xì)節(jié)以你實際版本的官方示例為準(zhǔn)// 場景控制段 scenario MyFirstScenario time 0.0 stop_time 200.0 // 平臺定義段一架沿航線飛行的無人機 platform DemoUAV position 0.0 km 0.0 km 1.0 km speed 50.0 m/s heading 90.0 deg endplatform // 平臺定義段一個地面雷達站 platform DemoRadar position 10.0 km 0.0 km 0.0 km endplatform在這個例子里scenario 聲明場景名稱time 和 stop_time 定義仿真的起止時間platform 塊定義仿真對象。Mystic 引擎啟動后會按時間從 0 推進到 200 秒每個仿真步內(nèi)更新平臺位置并檢查對象之間是否有交互。我特別想強調(diào)一下格式敏感性Mystic 腳本對關(guān)鍵字的拼寫和語句結(jié)束符是敏感的。大小寫、漏分號、中英文字符混用都是新手報錯的高頻原因。所以最開始寫腳本時建議嚴(yán)格復(fù)制官方示例改參數(shù)而不是從空白文件開始敲。3.3 事件驅(qū)動的時間推進為什么 AFSim 不需要你寫主循環(huán)很多從自研仿真轉(zhuǎn)過來的朋友會問我的主循環(huán)在哪里AFSim 的設(shè)計理念是基于事件和對象而非基于幀循環(huán)。引擎維護一個全局仿真時鐘和一個事件隊列每個對象可以向時鐘注冊未來的行為事件比如10 秒后開啟雷達到達航路點后轉(zhuǎn)向。引擎按時間順序處理事件而不是每一幀去主動遍歷所有對象。這個設(shè)計的好處非常明顯在復(fù)雜交戰(zhàn)場景里大部分時間大部分對象是沒有新事件發(fā)生的事件驅(qū)動避免了無意義的空轉(zhuǎn)計算仿真規(guī)模擴大時性能下降曲線更平緩。理解這一點之后你再看到 Warlock 里Step按鈕就會知道它其實是一次性處理完當(dāng)前時刻所有到期事件然后跳到下一個有事件的時刻。3.4 場景文件的組織方式學(xué)會用加載和拆分降復(fù)雜度單個巨大的場景文件很難維護。AFSim 支持把場景拆分成多個文本文件通過加載語句互相引用。比如主場景文件只寫場景名稱、時間和關(guān)鍵平臺把傳感器定義、武器定義、通信配置分別放在獨立文件里在主文件里按需加載。這個習(xí)慣我強烈建議一開始就培養(yǎng)。拆分的好處是顯而易見的。首先是復(fù)用性一套通信參數(shù)文件可以同時被多個場景引用其次是排查問題仿真報錯時你能迅速定位是雷達定義的問題還是平臺運動學(xué)的問題最后是協(xié)同開發(fā)不同人負(fù)責(zé)不同子系統(tǒng)同時編輯不同文件合并時沖突大大減少。4. 核心建模能力實戰(zhàn)拆解平臺、傳感器、武器與通信4.1 platform一切仿真對象的基本載體在 AFSim 里任何參與仿真的對象都是一個 platform。飛機、艦船、導(dǎo)彈、衛(wèi)星、地面雷達站、通信基站全都是平臺。平臺本身是一個容器它承載位置、速度、姿態(tài)這些運動學(xué)屬性也負(fù)責(zé)掛載各類子系統(tǒng)比如傳感器、通信設(shè)備、武器發(fā)射架。定義平臺時最核心的屬性是初始位置和運動規(guī)律。你可以用靜態(tài)位置定義固定目標(biāo)也可以用航路點route讓平臺沿指定軌跡移動。做無人機集群仿真的時候我會先寫一個基礎(chǔ)平臺模板然后用循環(huán)生成大量實例每個實例在航路、速度、傳感器參數(shù)上有微調(diào)。Warlock 里能看到所有平臺的運動軌跡這一步的調(diào)試效率很高。4.2 傳感器建模從探測概率到動態(tài)交互傳感器是 AFSim 里最常打交道的子系統(tǒng)。它支持雷達、紅外、電子支援等常見類型每種類型都有對應(yīng)的參數(shù)化模型。用系統(tǒng)級仿真視角來看你不需要從麥克斯韋方程組開始推導(dǎo)核心要理解的是幾個參數(shù)探測距離、探測概率、方位角范圍、數(shù)據(jù)更新率。AFSim 用映射表Maps來描述探測概率隨距離、角度、目標(biāo)類型變化的規(guī)律。你定義好映射之后傳感器會自動計算每個仿真時刻能否探測到目標(biāo)并把探測結(jié)果發(fā)送給平臺上的數(shù)據(jù)鏈或決策邏輯。我踩過的一個典型坑是單位問題。AFSim 默認(rèn)的位置單位、距離單位、角度單位在腳本里需要明示比如 position 后面寫 10 km 還是 10000 m很容易混。一旦傳感器的探測范圍寫錯數(shù)量級結(jié)果是目標(biāo)永遠不被發(fā)現(xiàn)而且你很難從日志里直觀發(fā)現(xiàn)是單位問題。后來我養(yǎng)成了一個習(xí)慣每寫一個傳感器先用 Warlock 看它的波束覆蓋圖確認(rèn)覆蓋范圍跟預(yù)期一致再做下一步。4.3 武器與交戰(zhàn)邏輯發(fā)射條件與命中判定武器建模的邏輯鏈路比傳感器更長。一個完整的交戰(zhàn)過程涉及火控系統(tǒng)判斷目標(biāo)是否進入射界武器發(fā)射架生成導(dǎo)彈/炮彈對象飛行中的武器平臺持續(xù)制導(dǎo)最后命中判定并輸出脫靶量miss distance。AFSim 里處理這條鏈路的方式是把武器建模成平臺飛行模型導(dǎo)引頭傳感器的組合。舉個例子一枚防空導(dǎo)彈發(fā)射后它的導(dǎo)引頭就是一個傳感器不斷測量與目標(biāo)的相對位置并控制導(dǎo)彈平臺調(diào)整航向。整個閉環(huán)在腳本里定義觸發(fā)條件和行為規(guī)則其余交給引擎的事件調(diào)度。對于新手我建議先用官方示例里現(xiàn)成的武器模型改參數(shù)比如射程、速度、導(dǎo)引頭視場。等你理解了一個完整交戰(zhàn)鏈路是由哪些環(huán)節(jié)組成之后再考慮自己從零定義新型武器。直接上手從零建模會非常痛苦因為大多數(shù)報錯不是因為語法而是因為你沒有完整描述鏈路中的某個環(huán)節(jié)。4.4 通信與交互圖仿真對象之間如何對話通信建模是我認(rèn)為進階理解 AFSIM 的核心。仿真的本質(zhì)是對象之間的交互而哪些對象能感知到哪些對象是由交互圖Interaction Graph簡稱 IG決定的。IG 的意義在于它劃定了每個對象的感知范圍引擎只計算 IG 中有邊相連的對象之間的交互而不是讓所有對象兩兩計算。通信設(shè)備建模包括消息內(nèi)容、傳輸時延、帶寬占用等參數(shù)。當(dāng)兩個平臺通過通信設(shè)備連接后它們之間可以交換探測數(shù)據(jù)、指令、協(xié)同信息。這也是做體系仿真的關(guān)鍵價值單平臺的傳感器探測能力是固定的但多個平臺互通互聯(lián)之后整個體系的感知能力會產(chǎn)生112的效果。5. Warlock 圖形界面可視化調(diào)試與場景構(gòu)建5.1 Warlock 在開發(fā)流程里的位置Warlock 是 AFSim 家族里對新手最友好的工具但我不建議完全依賴它搭建場景。我的工作習(xí)慣是先用文本腳本定義場景的主體結(jié)構(gòu)再用 Warlock 加載并可視化驗證。反過來視情況在 Warlock 里微調(diào)參數(shù)并直接保存為 Mystic 腳本也是完全可行的。兩種方式并不矛盾關(guān)鍵是你腦子里要清楚最終真正驅(qū)動仿真的是腳本W(wǎng)arlock 只是展示和調(diào)試工具。Warlock 能展示的信息非常豐富平臺圖標(biāo)、傳感器波束覆蓋、通信鏈路連接、武器飛行軌跡、事件時間軸、運行日志。多窗口布局可以讓你同時看著二維態(tài)勢和三視圖視角這對理解空間交互很有幫助。5.2 用 Warlock 排查運行異常的完整過程有一次我做雷達探測場景傳感器怎么都不報目標(biāo)。我打開 Warlock先在場景視圖里確認(rèn)了兩個平臺的相對位置發(fā)現(xiàn)雷達和飛機之間有山體遮擋。但我用的是簡單的自由空間傳播模型不應(yīng)該有遮擋問題。繼續(xù)查看傳感器波束覆蓋圖形發(fā)現(xiàn)雷達的仰角覆蓋范圍設(shè)置錯了波束指向完全朝上飛機從側(cè)面飛過時根本不在波束內(nèi)。這個排查過程如果能直接用日志 Debug花了很長時間也很難定位。但 Warlock 的波束可視化讓問題一目了然。所以我建議遇到預(yù)期會發(fā)生交互但沒有發(fā)生的問題第一選擇是用 Warlock 查看傳感器波束、通信連線、武器射界這些圖形化信息往往一眼就能看到問題所在。另外Warlock 的 Step 按鈕可以逐步執(zhí)行事件配合左右面板里對象的屬性變化能清晰看到每個仿真時刻發(fā)生了什么。這對理解事件驅(qū)動機制也很有幫助。5.3 圖形化構(gòu)建場景拖拽搭建快速原型Warlock 支持直接在圖標(biāo)上拖拽移動平臺修改屬性調(diào)整航路點所有這些編輯最終都會反映到場景腳本中。對于快速驗證一個想法比如如果無人機從北邊進入雷達的探測效果會不會更好直接拖拽比改代碼快得多。但這里有個需要注意的問題Warlock 圖形化編輯保存出來的腳本格式可能與手寫的習(xí)慣不同而且有時會自動生成一些默認(rèn)值。如果你們團隊有多人協(xié)作我建議定一個規(guī)則圖形編輯只用來做臨時驗證最終版本的手工維護腳本仍然以文本為主避免同一個場景因為反復(fù)用 Warlock 編輯保存而引入大量冗余默認(rèn)參數(shù)。6. 高級功能擴展事件腳本、二次開發(fā)接口與性能調(diào)優(yōu)6.1 事件與觸發(fā)讓仿真活起來靜止的場景加上簡單的直線飛行遠遠不能體現(xiàn) AFSim 的能力。實際仿真中需要大量條件觸發(fā)的行為無人機到達指定區(qū)域后釋放偵察設(shè)備雷達探測到目標(biāo)后自動切換跟蹤模式通信鏈路中斷后平臺重新規(guī)劃航路。這些都屬于事件與觸發(fā)機制。AFSim 的事件可以在仿真時間到達某個時刻觸發(fā)也可以在滿足特定條件時觸發(fā)。條件可以基于對象的狀態(tài)、相對位置關(guān)系、探測結(jié)果等。寫事件的時候我最建議的做法是單一職責(zé)一個事件只做一件邏輯上獨立的事情然后通過事件之間的編排實現(xiàn)復(fù)雜行為。這跟寫代碼的模塊化思想完全一致。6.2 外部接口與協(xié)同仿真把 AFSIM 接入你的工作流AFSim 提供了外部通信接口允許外部程序連接運行中的仿真實時讀取對象狀態(tài)發(fā)送控制指令。這意味著你可以把 AFSIM 當(dāng)作一個仿真后端用 Python 腳本或者自己寫的程序做前端控制、數(shù)據(jù)分析和可視化。我自己最常用的一種方式是用 Python 腳本批量啟動多次仿真每次修改一組參數(shù)比如雷達探測距離、無人機數(shù)量然后讀取每次仿真輸出的結(jié)果文件做蒙特卡洛式的統(tǒng)計分析。這個流程幾乎是體系仿真項目必備的單次仿真的結(jié)果是隨機的、參考價值有限只有跑足夠多次、統(tǒng)計出概率分布結(jié)論才可靠。AFSim 對輸出的控制很靈活你可以定制需要記錄哪些對象的狀態(tài)以什么頻率輸出。6.3 性能調(diào)優(yōu)的實戰(zhàn)經(jīng)驗讓大規(guī)模仿真跑得更快仿真規(guī)模上去之后速度會成為一個繞不開的問題。根據(jù)我的經(jīng)驗影響 AFSim 運行速度的因素按影響力排序大致是對象數(shù)量、交互圖復(fù)雜度、傳感器更新頻率、日志輸出量。對象數(shù)量是最直接的制約因素平臺越多每個仿真步需要計算的位置、狀態(tài)就越多。交互圖的復(fù)雜度決定了對象間交互計算的次數(shù)如果每個對象都能感知到所有其他對象計算量是平方級增長的。合理的 IG 劃分能讓計算量保持在可控范圍。傳感器更新頻率也很關(guān)鍵高更新率的傳感器每次更新都有計算成本在保證仿真結(jié)論可信的前提下適當(dāng)降低更新率能明顯提升速度。最后日志輸出是隱藏的性能殺手在跑長周期場景時如果全開日志磁盤 IO 會拖慢整個仿真的時間。在跑批量蒙特卡洛仿真時我會優(yōu)先關(guān)掉不必要的日志輸出只保留每次仿真最終的統(tǒng)計摘要然后在無圖形界面的服務(wù)器上并行運行多個仿真任務(wù)總體耗時可以縮短到原來的幾分之一。7. 高頻報錯與我的排查思路參考報錯現(xiàn)象可能原因排查思路Error: cannot find file場景文件路徑錯誤或相對路徑基準(zhǔn)不對先確認(rèn)工作目錄盡量使用絕對路徑檢查路徑中是否有中文或空格仿真運行后沒有任何輸出日志級別設(shè)置過高或場景本身沒有定義輸出項檢查場景里的輸出、日志配置先降低日志級別確認(rèn)仿真確實啟動了Warlock 打開場景為黑屏未加載地圖數(shù)據(jù)或圖形驅(qū)動問題先確認(rèn)這是不是只有黑背景平臺圖標(biāo)還在如果是屬于正常現(xiàn)象傳感器始終探測不到目標(biāo)單位錯誤、波束指向錯誤、目標(biāo)類型不匹配用 Warlock 查看傳感器波束覆蓋范圍和目標(biāo)相對位置仿真推進極慢或卡死交互圖設(shè)置過于復(fù)雜或存在高頻事件循環(huán)檢查 IG 定義減少無效交互降低傳感器更新頻率查看事件循環(huán)中是否有互相觸發(fā)的死循環(huán)場景結(jié)束不了stop_time 未設(shè)置或設(shè)置過大檢查場景控制段的 stop_time 參數(shù)這張表里的每一項都是我實際遇到過的其中傳感器探測不到目標(biāo)是新人咨詢最多的問題絕大多數(shù)時候不是模型錯誤而是參數(shù)設(shè)置與預(yù)期不符。排查定位的核心思路是先用圖形化工具確認(rèn)對象是否存在、位置是否正確再用可視化手段查看傳感器波束、通信連線這些看不見摸不著的邏輯最后才回到腳本里檢查參數(shù)數(shù)值。這個順序能幫你節(jié)省大量時間。最后分享一個我保持了很久的習(xí)慣。每拿到一個新版本或者一臺新機器我第一件事不是急著跑自己的場景而是把官方 examples 里的示例場景從頭到尾跑一遍。這個過程花不了多長時間但它能讓你快速確認(rèn)環(huán)境狀態(tài)同時順便看看官方在示例里呈現(xiàn)的最新寫法和習(xí)慣。很多看起來高深的技巧其實就藏在官方示例的細(xì)節(jié)里。AFSim 2.9 的配套教學(xué)視頻我放在 B 站了搜索AFSim 2.9 實戰(zhàn)就能找到圖文加視頻對照著看上手會更順。