發生於2023年07月1日～05日。
近期在用unity做乙個模擬經營類遊戲的原型。需要實現顧客走到指定目標的功能。
查閱相關資料後，發現有現成的尋路系統，可以使得顧客繞過障礙走到目的地。
我只要關心目的地、障礙物、顧客就可以了，如何到達則由尋路系統去關心。
這也非常適合目前場景需要頻繁變動的情況。
查閱資料後，演算法使用 a* 尋路就ok。並找到了幾個 a* 尋路外掛程式。
然後，基於教程數量和評價，對幾個尋路外掛程式經過一番對比後，使用了astarpathfindingproject（免費版），。
但引入尋路系統的過程，踩坑了，花費了1星期左右，才實現了我想要的功能。
回想起來，主要原因是，在涉及知識盲區時，沒有放慢腳步好好理解概念，依然選擇了快速推進。
一開始對尋路系統的概念完全是空白的，需要有哪些元件配合工作，哪些元件又是什麼樣的作用，並不知道。
基本實現了尋路功能了，但是細節做得不好，有時候尋路時，物件會被卡在路障上。
懷疑是尋路外掛程式的問題，因為是用了免費版的，猜想，難道免費版的ai比較憨？
網上找了個pro版的astarpathfindingproject，試驗了效果還是一樣。
又開始懷疑是不是 a* 尋路演算法的缺陷？然後又去對比了rvo演算法。然後也看教程，換成了rvo尋路，並且折騰、測試了一番。（這裡花了許多時間）
期間也對比了其他外掛程式，想要換個外掛程式試試。（也浪費時間了）
（此時我依然沒有完全了解 astarpathfindingproject 外掛程式裡核心引數的含義）
最後，通過修改 collider 的形狀和調整尋路元件的引數，就把問題解決了。
從 第4點開始就走偏了，直到第8點才走回正軌。
追趕開發進度就像汽車拉力賽一樣，竭盡全力的把速度拉上，但也需要加強預判，在過彎時，小心謹慎，放慢速度。
在穩的基礎上追求快。畢竟「翻車」了還更浪費時間。
vue的踩坑路
serve pure static assets var staticpath path.posix.join config.dev.assetspublicpath,config.dev.assetssubdirectory 其實只有這一行，特別注意，這個不加拿不到json 拿不到，因為webpa...
pagehelper外掛程式，踩坑筆記
在使用過程中，pagehelper外掛程式在複雜的sql查詢count時，會自動生成select count 0 from 需要分頁的sql tmp count，有時也會把排序字段放進去，導致count查詢時間很長。如，生成的分頁sql select t.select x.name from tb ...
pdfjs dist外掛程式的踩坑
新入職的一家公司，一開始去要求要改乙個bug，是關於pdf檔案上傳的問題。專案中用到了pdfjs dist外掛程式。bug是這樣的，檔案獲取不到。一開始是在頁面中引用 import pdfjs from pdfjs dist import pdfworker from pdfjs dist buil...