yekdniw的UE4學習筆記

最近在使用projectile movement component (以下簡稱PMC)的時候遇到一個問題 如果一個Actor掛了一個PMC來做移動的運算，但是這個移動的運算可能是由事件觸發，而且移動的初速度可能也是一個變數，根據事件當時計算的結果會有不一樣的初速度。 然而經過測試發現有以下幾個問題： 1. 只有在Actor的construction script 或是PMC的default值設定initial speed才會生效，其他事後的設定都是無效的 。 在default值設定初始速度， 有效 。 在Construction Script設定初始速度， 有效 。 在BeginPlay或任何其他地方設定初始速度， 無效 ，會以construction script或是default值設定的值為準。 2. 對PMC disable component active之後再enable component active會影響到整個移動的運作。 以上方的圖舉例初速度是1500，第一次active會用1500的速度噴出去，可是如果disable active之後再enable，速度就會變成0。 有關第一點，追查原始碼之後才發現 初始速度只有在InitializeComponent的時候使用到 其餘程式碼都沒用到這個值，也間接證實了比BeginPlay早呼叫的Construction Script設值是有用的。因為呼叫時間的先後順序應該是Construction Script -> InitializeComponent -> BeginPlay。 但是有了這段code之後也代表initial speed其實可以自己處理，就如同程式碼說明的一樣。只是把目前的velocity乘上 speed而已。所以下圖的寫法等同於設定初速度~(為了偷懶safeNormal我就不在圖中作了) 第二點的話，推測是停掉之後velocity被設為0，所以再開啟的時候速度也被重設了。如果想要延續停掉前的速度，可能要自己記下來，然後在重新開啟的時候重新把之前的velocity設回去。

用incredibuild來build UnrealBuildTool.exe(UBT)，UBT會再呼叫Incredibuild 形成遞迴呼叫incredibuild，導致在編譯的時候會收到錯誤： A Xoreax distributed job cannot be started from within another distributed job. 目前已知UBT跟Shader compile worker這兩個project好像都不能使用Incredibuild來作編譯。 如果想要關掉incredibuild 除了下面說的改xml的方法之外，另一個就是uninstall incredibuild了。不要想去incredibuild按stop service或是把incredibuild執行檔從工作管理員裡面停止，這兩招對unreal都沒用。 unreal都是直接去incredibuild的安裝資料夾叫起執行檔來執行的~ 為了解決這個問題，要在xml裡關掉incredibuild 來Build UBT 在檔案路徑 %appdata%\Unreal Engine\UnrealBuildTool\ 下的 BuildConfiguration.xml 或是 C:\Users\[使用者帳號]\AppData\Roaming\Unreal Engine\UnrealBuildTool\BuildConfiguration.xml 加上這行 <bAllowXGE>false</bAllowXGE> 範例如下： <?xml version="1.0" encoding="utf-8" ?> <Configuration xmlns="https://www.unrealengine.com/BuildConfiguration"> <BuildConfiguration> <bAllowXGE>false</bAllowXGE> </BuildConfiguration> </Configuration> 然後去Visu

用Unreal已經有一小段時間了 稍微分享一下自己的心得 先講結論 1. Circular reference在UE4是很多問題的根源，不要讓你的BP有circular reference。 2. 為了效能好，BP之間的Hard Reference越少越好。 本篇文章撰寫所使用的Unreal版本是4.11。 Blueprint(BP)是UE4最重要的技術之一 使用BP可以減少編譯執行檔的時間，馬上改馬上測試，不用頻繁更新執行檔等等優點。 可是大量使用BP開發的結果 應該會發現BP有幾個問題會慢慢浮現: 1. 遊戲效能不好,讀取關卡速度慢 2. 某些BP會跳不明的錯誤 3. 不好用斷點追bug (相較於Visual Studio) 4. 難以用版本控管Diff不同版本之間的差異 5. BP沒多少節點.uasset檔就上MB，甚至數十MB 6. 改名不方便，操作不慎可能會讓別的BP裡面斷線。 這邊就先來提一下至今遇過造成BP最多問題的原因之一 Circular reference。 BP在編譯的時候會根據其相依關係，把有參照到的BP class遞迴的編譯一次。 因此如果a參照到b, 而b又參照到a的話，就會形成circular reference。 Circular reference我至少遇過幾種問題： 1. BP無緣無故跳錯，打開重新編譯沒事，關掉UE4重開又跳錯 2. 讀取效能不好，profiling時發現某個BP讀取很久 如果有以上原因，我會建議利用Reference Viewer， 好好的檢查一下你的BP有沒有 circular reference的現象。 如果有，建議一定要解掉。 解法大致上有幾種， 其中一種是用參照interface取代直接參照； 另一種則是使用Event dispatcher在BP之間溝通； 最後一種則是以C++ class取代。 這邊要注意的幾個點是，如果你的interface也是用BP做的，那一樣要注意循環參照。 例如a->interface b ->a，這種狀況依然要避免。 單層的循環參照還好找，如果有a->b->c->d->a的循環參照，要找到就要多花時間。 當Circular reference減少的差不多之