今天深入探索了細節除錯的重要手段——日志與step結合使用，
在Kernel GUI界面注意到了某個agent后，點擊它查看它的ID，然后在logs檔案夾中找到相應的日志，當前只有警察和消防有詳盡的日志，
消防agent有包含本身屬性的xxx.logs和buildingdetector的日志，以及commandexecutor的日志；警察agent有包含本身屬性的xxx.logs和policeoffice的日志，以及commandexecutor的日志，
找到日志后在kernel GUI界面點擊step，可以很好地追蹤某個智能體在每個周期的情況，
上面三張張圖片是berlin這張地圖下前13個周期內ID為38524528的消防的日志，而再上面的第一張圖中顯示已經有三座建筑著火，但detector的日志里顯示無論是全圖還是簇內，著火建筑數目都是0，
而在joao這張圖下，著火建筑從第4周期更新為2（實際為大于3個），到第七周期更新為5個（實際為7個），
消防1643941687未被卡住，目標始終為空，而消防站不分配目標，這也應該是executor接收不到任務訊息的直接原因，
而結合linesight視圖下消防1643941687的視線和其位置，以及所有消防和警察的視線和著火建筑位置之間的關系（下圖淺藍色視線是某警察的視線）：
下圖是消防1643941687的視線，視線左邊的紅點就是他，
下圖是另外一個消防的視線，
第七周期內，中間三個連續的著火建筑在第一周期就出現，早已在消防1643941687的視線中出現，
而在第八第九周期，世界模型中的著火建筑分別更新為6個和7個，符合了實際情況，因為這兩個新更新的著火建筑分別在一個救護車和一個居民的視線內，故我推測是著火建筑出現在人的視線（不只是消防的而是所有agent的包括居民）內，消防的世界模型才陸續更新，且一定小于等于上一周期視線內的著火建筑數，
我繼續向下step，到第12周期，著火建筑實際變為8個，13周期變為9個，期間世界模型都沒有更新，而在16周期實際著火建筑變為14個，世界模型更新為8個，
列成表格：
| 周期 | 實際個數 | 視線內個數 | 世界模型個數 |
|---|---|---|---|
| 7 | 7 | 7 | 5 |
| 8 | 7 | 7 | 6 |
| 9 | 7 | 7 | 7 |
| 10~12 | 8 | 7 | 7 |
| 13 | 9 | 7或8 | 7 |
| 14 | 9 | 7或8 | 7 |
| 15 | 9或更多 | 8 | 7 |
| 16 | 14 | 10 | 8 |
| 17 | 15 | 12 | 8 |
| 18 | 15 | 12 | 10 |
| 19 | 21 | 15 | 12 |
| 20 | 27 | 小于20（數不明白了） | 12 |
| 21 | 27 | / | 13 |
| … | 27 | … | 13 |
| 25 | 28 | / | 14 |
基本可以證明上面粗體文字描述的推斷大致成立，至于延遲更新的原因和具體資料，暫時不必深究，
這可能就是“視線”這一概念的重要用處之一，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/253552.html
標籤：其他