來，續上。
我想可能是因為我有強調了一下本身能夠自製插件，
而且在馬克的窮追猛打之下，
他們迫於無奈、生不出第二個所謂的抽驗插件的情況之下，
所以理所當然的，考試的型態就變成了自製插件，
事至此，其實已經能夠宣告馬克勝利了，
但是萬萬沒想到、他們會自己挖坑給自己跳。
正在ＬＨ先生意圖旁敲側擊、
又帶有一種奇妙意味的語氣問了問一句。
「那麼可以請『您』自製一個插件嗎？」
嗯，拜託不要用敬詞，會害我想繼續打爛你們的臉，
我迅速的跟友人這樣講，當然是笑開懷。
既然馬克都颯爽的表達了自己自製插件很會，
所以當然就是迅速講了「當然沒問題。」
但是強調「我是插件師 不是規劃師。」
但是這群人一聽到可以自製插件就炸開懷了，
每個人你一言我一句，
一下子是之前ＯＯＯ鑲嵌插件壞掉了，搞不好就可以讓他寫噢、
不然就是甚麼死亡訊息的插件有設定有衝突，沒辦法解決乾脆重寫一個怎麼樣。
好啊，現在當我是免費勞工齁？
所以馬克憤怒的表達了一下何謂插件師。
其實就工作性質來講，很多人都會把插件師，當作是設計師，
給它們兩、三桶油漆，就可以揮灑出一片牆的畫作。
屁勒。
插件師充其量只能算是工具人，別在那邊妄想我們變成藝術家，
尤其是團隊取向的插件師，更是只能當個工具人，
當然這是我的理解，你們參考就好。
一個插件師在製作插件，並沒有辦法獨立作業下去考慮整個核心的概念，
包括運作方式、配合周邊、配套措施等等，
我知道一定有人可以，但是絕大多數這樣是不明智的作法，
而且當一個團隊越強調它的分工性，這個狀況會越明顯。
龐大的內容以及架構，並沒有辦法獨立一個成員、或者是特定組別下去完成，
而是需要進行不斷的討論、再修正、以及可行性的評估，
才有辦法下去嘗試付諸實現。
好啦我懂，這些都只是我偷懶的藉口，哈哈。
本身就是不看好這個伺服器可以做到這種程度。
但是攤開來講，製作這個插件的目的是甚麼？
作為考核的內容，來評估適不適用，對吧？
我想應該不是，寫完一個插件，然後上線這麼簡單，
所以這種不經過深思熟慮、輕易定出計畫的東西，是無法被實現的，
更何況馬克才不要像個白癡一樣，
去把概念接下來，然後傻傻的在那邊想破頭腦幫忙寫出一個廢物。
因為配套措施的缺失，這種插件的失敗是必然的。
之於我來講，規劃有其必要性，但是視其影響層面而定，
舉例來講，ＯＯ鑲嵌系統。
可能需要配合
（１）怪物掉落 → 牽扯到自定義怪物、自定義道具。
（２）前後綴 → 還是一樣自定義道具。
（３）能力計算 → 職業、又是自定義道具。
（４）圖像組合 → 現有物品的圖像搭配。
請問ＯＯ鑲嵌系統還好做嗎？
這還只是我打文章的時候隨意想出來的。
更遑論程式碼中需要配合的部分，
ItemMeta？setDisplayName？NBTag？
我舉另外一個反例，死亡訊息區分。
順便說一下，這是目前分下來的考試題目，
因為還算可以，所以就接下來了。
簡單來講的訴求就是，要一個插件能夠區分ＰＶＰ死亡跟非ＰＶＰ死亡，
說簡單不簡單、但是困難嗎？
也還好。
粗略的概念就是，在玩家死亡的時候檢查兇手是誰。
結束。
這種就是無需跟其他插件配合（當然一樣是概略的想一下而以，凡事有例外。）
只需要一些事件，就可以輕易的達成需求。
可是其實這種小東西裏頭也藏有細節，
LivingEntity、Projectile、Magic、Lava、Entity。等等等，不勝枚舉。
我不多講，還是一樣講個粗略就好。
使用的事件是PlayerDeathEvent，所以可以簡單的獲得死亡的玩家資訊，
直接getEntity就可以獲得受害者的資料（以下稱受害者），
但是沒有getMurder這種便利的函數可以用，
我們只能從Player裏面下去呼叫getLastDamageCause來去獲得上次攻擊者的資料，
那麼簡單來講，受害者已經死掉了、然後我們去抓受害者上一次被誰攻擊，
是不是就得到了兇手是誰？
我承認好像是在弄毛利小五郎還是甚麼東西的。
聽起來很複雜之類，所以我就不多說Projectile這個東西了。
看到這邊老實說，這仨人大約是完全來鬧事的，
應該說普遍沒有概念的伺服器都是這樣，
天真的認為只要招來一名插件師、給他一個概念、
就可以等他揮灑出「自己」想要的東西。
別鬧了，拜託。
後面還有一點插曲，關於ＬＨ先生的掙扎。
一群人死要撐在那邊到底有多難看呢？
我們下回再續。
老實說有點歪掉，中間的部分。
對各位甚感抱歉，呵。
