シナリオ
ある居住地に行くと入植者が近づいてきました。
友達がレイダーにさらわれたので助けてほしいと依頼してきました。その割には笑顔でおかしいです。
会話が始まると困った顔になるのですが、最初から困った顔でいるほうが自然です。これをなんとかしてみました。
表情をかえるには
以下の関数を実行するだけです。
make_sad_face.psc (papyrus)
Keyword Property AnimFaceArchetypeSad Auto Const Mandatory
Function MakeSad(Actor akTarget)
akTarget.ChangeAnimFaceArchetype(AnimFaceArchetypeSad)
EndFunction
とても簡単です。
表情だけでなく、姿勢もかえてみます。
make_sad.psc (papyrus)
Keyword Property AnimArchetypeDepressed Auto Const Mandatory
Keyword Property AnimFaceArchetypeSad Auto Const Mandatory
Function MakeSad(Actor akTarget)
akTarget.ChangeAnimArchetype(AnimArchetypeDepressed)
akTarget.ChangeAnimFaceArchetype(AnimFaceArchetypeSad)
EndFunction
元に戻すには、引数を空にします。
make_neutral.psc (papyrus)
Function MakeNeutral(Actor akTarget)
akTarget.ChangeAnimArchetype()
akTarget.ChangeAnimFaceArchetype()
EndFunction
空にした場合はnoneを指定したことになり、noneを指定するとneutral（標準）になるので、元の表情に戻るという仕組みです。
余談ですが、CKでプロパティの紐づけを忘れていると、AnimFaceArchetypeSadの中身が空になってしまいます。
そのため、以下のコードは
akTarget.ChangeAnimFaceArchetype(AnimFaceArchetypeSad)以下のコードと同じ動作になってしまい
akTarget.ChangeAnimFaceArchetype(none)表情が変化しません。警告も出ないので気をつけましょう。
タイミング
今回はミニッツメンの居住地関連の「友達が誘拐された」というクエストでした。EditorIDはFallout4.esmのMinRecruit02になります。
実装方法をいくつか考えてみました。下にいくほど改良された実装になります。
依頼人のReference Aliasで処理する
依頼人がSpokesmanというReference Aliasに入っていますので、このReference Aliasにスクリプトを追加して、OnLoadイベントで制御するのがいいかと思います。元の表情に戻す処理も忘れずに実装します。
この方法はゲーム内の負荷を最小限にできます。そのかわりにQuestのレコードを変更することになるため、プラグインの競合が避けられません。
Quest Fragmentsで処理する
大抵のQuestは、最初のStageで準備を行い、最後のStage（もしくは失敗という形で終わるStage）で後始末をします。そこに処理を追加します。
この方法はプラグインでの競合は回避できますが、スクリプトでの競合が避けられません。
外部のQuestから動的に処理する
以下の処理を行うQuestを1つ用意します。
- PlayerのOnLocationイベントを検知する
- 現在のLocationを取得する
- Locationが居住地かどうか調べる
- ミニッツメンのクエストで稼働しているものを検索する
- 依頼人が近くにいるか調べる
- 依頼人の表情をかえる
元の表情に戻す処理も忘れないようにします。
この方法は競合の心配がまったくないのがメリットです。そのかわりにLocationが変化するたびにスクリプトが動くので負荷がかかります。
Story Managerを併用する
上記の実装のうち、Locationの変化からミニッツメンのクエストで稼働しているものを検索するまでの処理をStory Managerに担当させます。
スクリプトの負荷がなくなります。ですが、Locationの変化のたびに検査を行うという点はかわりません。
QuestのOnStageSetをみる
ミニッツメンの居住地関連のQuestは数が決まっているため、それらのQuestのOnStageSetイベントを外部のQuestから監視し、Stage移行を契機に処理を行うと、Locationを見る必要がなくなります。
これが競合なしにスクリプト負荷を最小限に抑えた実装になると思います。
よくなった
落ち込んだ様子になりました。
