☆※冰の引言※☆?

上一章節(jié)對于科技方面屬性的修改作了系統(tǒng)而全面的敘述,這也宣告了屬性函數 xsEffectAmount 函數全方位的360度感知體會正式收官。本期作為一篇雜談,我們將放眼多人聯機場景,解決一個在聯機場景中很常見但又十分頭疼的問題——那就是聯機編號ID 的混沌錯誤現狀。讓我們一起來撥云見霧,扭轉乾坤,尋覓校正的不二法門。

模式篇作為屬性函數壓軸登場的部分,重要性自然不言而喻。模式篇共有四個篇章,分為青龍、白虎、朱雀、玄武四個子篇章。本篇為讀者娓娓道來的是最后一篇玄武篇——科技馳騁--璞玉縱有璧瑕不掩瑜。

本節(jié)主要內容是對科技方面屬性的修改進行庖丁解牛以及對科技研究函數的使用作了鞭辟入里的分析解讀,還有就是對產生單位這一刷兵新方法進行介紹。隨著模式篇最后一節(jié)的終了,不知不覺中關于xsEffectAmount屬性函數超全面敘述的帷幕也緩緩落下。這便是屬性函數講解的全部內容。下一節(jié)我們將聚焦聯機場景中座位排序問題,如何從混沌中撥亂反正,尋覓真正的光明之路。路漫漫其修遠兮,道阻且長上下需求索！

原文“這個條件是恒成立的?！卞e誤。
此條件不是恒成立的，有可能為真，也有可能為假。原因是函數會將本函數中調用的最后一個有返回值函數的返回值，作為本函數的返回值返回，雖然由于函數類型是?void，這個返回值不能被一般的函數讀取，但它會影響判斷條件的成立與否。
如果希望此條件恒成立，則將返回值改為?bool，并在函數結束時?return(true);?或其他類似方法，總之，為了防止返回一個未預期的其他中間過程的值，最終自行返回一個值覆蓋掉。
這個情況類似于匯編中，有的函數不修改?RAX/EAX/AX?等寄存器，當作不返回任何數據，但是主調方卻檢測?RAX/EAX/AX?作為結果，這就導致了實際上接收到的結果是最后一次有修改該寄存器的函數的賦值。

驗證上述言論非常簡單。
新建一個觸發(fā)，默認是關閉狀態(tài)，條件是腳本調用
bool?man()?{
????return(true);
}
再新建一個觸發(fā)，默認是開啟狀態(tài)，在屏幕上顯示，添加一些簡短描述，條件是腳本調用
void?test()?{
????man();
????xcChatData("Hello,?World");
}

如果這個觸發(fā)的條件真的是恒成立，那么，屏幕上的說明應該劃線。
但實際上，只要把函數?man?中的返回值改成?false，就會發(fā)現這是一個恒不成立條件，屏幕上的說明沒有劃線。

另外，對原文的第?2?條補充一點說明。
條件不成立時，才會在下一幀再次嘗試調用這個腳本判斷條件是否已經成立。如果條件已成立，且本觸發(fā)中的其他條件都成立，那么效果執(zhí)行完后，下一幀，若觸發(fā)不循環(huán)或沒有再次被其他觸發(fā)激活，那么條件腳本就不會再被執(zhí)行了。
即，有需要判斷觸發(fā)是否應該被執(zhí)行效果時，才會判斷條件是否成立，才會找到條件中的腳本調用，才會檢測腳本的返回值。
返回值會被轉換為?bool，為真滿足，為假不滿足

xs?更為底層，xs?中的“玩家”是“玩家?ID”，而不是“玩家顏色編號”。玩家?ID?實際上是玩家在大廳中的座位號，而玩家顏色編號是該玩家選擇的顏色中的數字，藍色不一定就是?1，地編中的玩家?1?的顏色才一定是?1。

官方?xs?和上層之間是有一層轉換的，只是這個轉換沒有公開。如果玩家?ID?和顏色編號不統(tǒng)一，就能發(fā)現這種轉換，例如在觀戰(zhàn)時按?Ctrl?+?Shift?+?F1，是切換到玩家?ID?為?1?的玩家，而不是玩家顏色編號為?1（默認藍色）的玩家。這也是單機中無論自己是何種顏色編號，Ctrl?+?Shift?+?F1?始終能切換到自己的原因——自己始終是座位?1。

在地編中，顏色編號對應的顏色是可以修改的，例如，將玩家?3?顏色改成紅色，那么紅色就是編號?3。在?xs?出現以前，一切“玩家”都指玩家顏色編號，而不論玩家?ID，即座位號。例如，在大廳中玩家?1?選擇了編號?8，此時是藍色，進入游戲后，就會看到自己名稱是藍色，且玩家名稱前有一個藍色的?8。此時對他生效的觸發(fā)，是玩家?8?的觸發(fā)。

但?xs?出現以后，更為底層的?API?被允許使用，xs?中的“玩家”不再是“顏色編號”，而是“座位號”，我們稱之為“玩家?ID”。

在自定義場景中，如果只用?xs，或者只用場景觸發(fā)，是不會有任何問題的。但如果同時使用兩者，座位號和顏色編號的不同會影響到場景邏輯。

為方便使用，可建立九個全局變量?p0,?p1,?p2,...,?p8，分別代指玩家?ID?為?0~9?的玩家對應的顏色編號。其值通過場景觸發(fā)的玩家編號賦予。

思路與馬桶游擊隊帖子中的方法相同，只是考慮到場景觸發(fā)永遠不需要使用玩家?ID，因此并不需要設置觸發(fā)變量，而是在腳本中定義變量：

然后在場景觸發(fā)中建立新的觸發(fā)，九個效果分別是設置玩家?0~8?的某些無用資源為?0~9

最后一個效果調用函數：

?

xs?的完整代碼是：

此后，在腳本中，凡是確定使用玩家?ID?的，直接填寫數字，凡是與觸發(fā)交互的，填寫?p1?等，例如
xsSetPlayerAttribute(p3,?cAttributeGold,?999);
將顏色編號為?3?的玩家黃金設置為?999，
xsSetPlayerAttribute(2,?cAttributeWood,?888);
將?ID?為?2?的玩家木材設為?888

附相關的不統(tǒng)一的三類數據

玩家?ID
玩家在大廳中的座位號，范圍?0~8，0?蓋亞，1?座位號?1……

玩家顏色?ID
更改對象顏色等觸發(fā)使用的值，范圍?1~8，1?藍色，2?紅色……

顏色?ID
指代顏色的索引，范圍?0~15，0?藍色，1?紅色……

內部的邏輯是
玩家?ID?是玩家數據的索引，通過玩家?ID?能夠找到玩家類。
類中有玩家顏色?ID?成員，這個成員有指向顏色?ID?的成員。

xs?直接使用第一項，玩家?ID?索引玩家
場景觸發(fā)使用第二項，玩家顏色?ID?反向索引玩家。

第一項與第二項的映射，體現在?xs?與場景觸發(fā)的不同上。
第二項與第三項的映射，體現在玩家顏色的編號和實際顏色的不同上。
實際上只有第三項是確定顏色。