五、藍圖訪問C++變量（UPROPERTY）
一.從C++角度解讀藍圖變量
1.創(chuàng)建或者打開一個父類為Actor的藍圖類
本篇用的是我們之前創(chuàng)建的那個BP_Actor的藍圖類
分別將Rendering類別里面的變量拖到藍圖空白處，做對比
引擎既能獲取這個變量又能修改這個變量
為什么會出現(xiàn)這樣的問題呢？有的變量只能get不能set，有的變量既能get又能set，那我能只能走進基類Actor的C++源碼中看一下區(qū)別
2.走進父類Actor的C++源碼
①猜測問題：為什么有的變量只能get不能set，有的變量既能get又能set？
Ctrl+F搜索Actor Hidden In Game與Editor Billboard Scale變量
仔細觀察這兩個變量找出自認為能夠解釋清楚這個問題的理由：有的變量只能get不能set，有的變量既能get又能set？
Actor Hidden In Game：BlueprintReadOnly,?Category=Rendering
Editor Billboard Scale：BlueprintReadWrite,Category=Rendering
嘿嘿嘿，恭喜你你猜對了，用你的蹩腳英文解釋一下
Actor Hidden In Game：藍圖只讀（只能get），類別=Rendering
Editor Billboard Scale：藍圖讀寫（能get能set），類別=Rendering
二、言歸正傳解釋問題：為什么有的變量只能get不能set，有的變量既能get又能set？
UPROPERTY()宏(后面簡稱UP宏)是用來修飾UE C++中的變量的；
UPROPERTY()宏搭配變量說明符可以賦予變量極大地靈活性,比如:
控制變量在藍圖中的讀寫權限;控制變量在藍圖中哪些地方可以被編輯;
控制變量在藍圖中顯示的名字;控制變量屬于那個類別等等?
UE4 C++使用UPROPERTY(屬性)說明符賦予屬性不同的特性,最常用的包括可見性(Visible),可編輯性(Edit),可讀寫性(Read/Write).通過使用不同的屬性說明符,屬性將在藍圖中具有不同的效果。
本篇還是基于上面的Cpp_Actor? C++類為測試！
1.可見性(Visible)說明符
①VisibleDefaultsOnly(在藍圖中的默認類可見)
這里的Default表示class defaults?
測試代碼：
在UE編輯器中為Cpp_Actor C++類派生一個BP_Cpp_Actor的藍圖類
②VisibleInstanceOnly(僅在實例中可見：將藍圖類放置到關卡中即為實例化 )
測試代碼：
③VisibleAnywhere(任何地方可見)
VisibleAnywhere=VisibleDefaultsOnly+VisibleInstanceOnly(可以這么簡單理解)?
測試代碼：
可見性(Visible)的完整代碼（.h文件）
2.可編輯(Edite)說明符
可見性和可編輯性說明符不能同時使用,同一個屬性,只能進行一種說明(可見or可編輯) ?。。。。。。?/span>
①EditDefaultsOnly(在藍圖的默認類中可編輯)
測試代碼：
②EditInstanceOnly(僅在實例可編輯)?
測試代碼：
③EditAnywhere(任意地方可被編輯)
測試代碼：
可編輯性(Edit)的完整代碼（.h文件）
3.可讀寫(ReadWrite)說明符（get? set說明符）
讀寫說明符與可編輯性說明符區(qū)別:?
讀寫說明符用于控制屬性能否在Variables面板和EventGraph被訪問,而可編輯性說明符用來控制屬性被配置的場景,讀寫說明符更多傾向于屬性能不能用于參與邏輯編寫(讀取/寫入),而可編輯性說明符則有點像配置文件,用于配置默認值之類.?
用最簡單的方式可以理解為下圖：
①BlueprintReadOnly(藍圖只可讀--可get不可set)
測試代碼：
我們是在Cpp_Actor的C++類中寫的代碼，基于這個C++類派生了一個藍圖類BP_Cpp_Actor；這個BluePrintReadOnlyValue變量屬于父類，子類也已經繼承父類的變量，要想在子類中找到這個變量，那我們必須在子類中顯示繼承變量（BluePrintReadOnlyValue）
②BlueprintReadWrite(藍圖讀寫--可get可set)
測試代碼：
可讀寫(ReadWrite)的完整代碼（.h文件）
4.Category(類別)
測試代碼：
5.meta說明符_屬性
meta修飾符用于說明被修飾對象(可以是屬性,函數(shù),類,結構體)與虛幻引擎和關卡編輯器等多方面的互動方式.
①DisplayName（顯示名字-----別名）
DisplayName不會改變屬性的顯示名稱,而是用于作為搜索的關鍵詞,可以將名字比較長或者拼寫比較麻煩的屬性的DisplayName設為容易搜索的關鍵詞,提高查找效率.?
測試代碼：
三、兩個小案例有助于理解
1.BlueprintReadOnly
測試代碼：（.h文件）
測試結果：
分析代碼：
此邏輯為Time_Mix隨著Tick增加,其數(shù)值被限制在0和Time_Max之間.
由于Time_Max為BlueprintReadOnly,所以在運行狀態(tài)下,Time_Max的值無法被修改,Time_Mix的數(shù)值將始終無法超過Time_Max.
這個例子解釋了BlueprintReadOnly的設計思路,即:被修飾的變量的數(shù)值不允許在運行狀態(tài)下(通過代碼)被修改.
2.EditInstanceOnly
測試代碼：（.h文件）
分析代碼：
EditInstanceOnly使每個對象都具備不同的數(shù)值,對象可以根據(jù)自身專有的數(shù)值執(zhí)行對應的邏輯.
此說明符適合場景中大量存在且對象之間有差異的情況,比如場景中多個公交站牌,每個站牌可以配置唯一的站牌名稱.
