生産関連修正まとめ

生産関連修正まとめ（メモ書き）

スタックしてた色つき植物片をバラしたときにPlain Plant Clippingsになる

ServUOのバグ。
なるさんがすでに把握してそうだけど調査。
意外と闇が深いですぞ、これ。
とりあえず応急処置みたいな感じ。

既存ソースではデフォルトコンストラクターが呼び出されたときに色つきだろうとPlainの植物片を生成しようとしてる。

PlantClippings.cs

[Constructable]
public PlantClippings()
:this(PlantHue.Plain)
{
}

[Constructable]
public PlantClippings(PlantHue hue)
: base(0x4022)
{
m_PlantHue = hue;
InvalidatePlantHue();
Stackable = true;
}

追ってないからわからないけど、
錬金とか料理では生成したあとクラフト処理でPlantHue入れ替えてるんだろね。
けども、スタックを崩した場合はクラフト処理なんぞもちろん通らないのでPlantHueはPlainになる。
なので名称がPlain Plant Clippingsになると考えられる。
名称は納得いくのだけど色は色つきのままだった。意味がわからん。

修正その１
色はそのままだったことを利用し、別のコンストラクタを用意。
デフォルトコンストラクタから新規で追加したコンストラクタを呼ぶようにした。

[Constructable]
public PlantClippings()

: this(1)
{
}

[Constructable]
public PlantClippings(int amount)
: base(0x4022)
{
this.Stackable = true;
this.Amount = amount;
}

内部で自身のHueからPlantHueInfoを取得するようにしてみたが、
なぜか自身のHueに0（標準色）が返る。
つまりこの時点は見た目上の色は変化しているが内部の色コードは標準色ということだろうか。
意味がわからん。

修正その２
植物片の名称は

public override void AddNameProperty(ObjectPropertyList list)

で設定している。
名称が変わっているということはこのメソッド内ではすでにプロパティの参照が可能であると考えられる。
よってメソッド内部で呼び出しているPlantHueInfoを自身のHueから取得するよう修正。

PlantHueInfo info = PlantHueInfo.GetInfo(m_PlantHue);

これを

PlantHueInfo info = PlantHueInfo.GetInfo(this.Hue);

に修正。
Plain Plant Clippingsにならないことを確認。
もしかしたら修正２だけでいけるかもしれません。
ServUOのアイテムにプロパティが付く瞬間がまったくわからんだよ・・・。

「毒洗浄液」を作ると1個の「10 毒洗浄液」が作成される

ServUOのバグ。いやこれバグといっていいのだろうか？
作成者があえてこういう仕様にしたとしか思えない。
「10 毒洗浄液」という1個で10回使えるアイテムである。

修正案として3個浮かぶ。

スタックする10個の毒洗浄液を作成
（追加）スタックしない10個の毒洗浄液を作成
スタックしないが使用回数をプロパティの位置に持っていく

本家では1回の生産につき1個であり、
使用回数なんてものはそもそもない。
10個作成するにしろ、使用回数を設けるにしろ本家にはあわせず進める。

（以前の修正案は削除）
案１
毒洗浄液のItemIDをスタックするItemIDに変更することにより対応。

Serialize/Deserializeを修正しているのでアイテムが一時的に消滅する可能性あり。
int型の値を復元してるだけなので整合性は大丈夫かなあ・・・。
セーブデータの毒洗浄液のm_UsesRemainingがうまいことthis.AmountにDeserializeされれば消失しないと思います。
結構修正箇所多いのでソースファイルを添付します。

そーすふぁいる

うっ！まずい！ItemIDが昔のままだｗ
base(3625)を: base(0x1848)に変更お願いします。
ところで、アップロードしたファイルってどうやって消すんだろう

小型丸バスケットの材料がおかしい　SUO修正済み

ServUOのバグ。
金属容器刻印ツールの材料が小型丸バスケットにAddされている。
金属容器刻印ツールの材料をAddする際に、Indexを取得していないため、
前回取得されたIndex（小型丸バスケット）の材料ListにAddされてしまったことが原因。

DefTinkering.cs

// Rev.1(Mod S)--------------------
//this.AddCraft(typeof(MetalContainerEngraver), 1044046, 1072154, 75.0, 100.0, typeof(IronIngot), 1044036, 4, 1044037);
index = this.AddCraft(typeof(MetalContainerEngraver), 1044046, 1072154, 75.0, 100.0, typeof(IronIngot), 1044036, 4, 1044037);
// Rev.1(Mod E) --------------------

ブッシェル枡の名前がおかしい　SUO修正済み

ServUOのバグ。いやこれバグなのかな？
あえて名前付けてたみたいだよ。

RoundBasketHandles.cs

// Rev.1(Del) this.Name = "Round basket w/Handles";

ピクニックバスケットのグラフィックとガンプがおかしい　SUO修正済み

ServUOのバグ。
人のこと言えんけど、作成者は全く動作確認してねえな！

PicnicBasket2.cs

// Rev.1(Mod S) --------------------
// : base(0x9AC)
: base(0x0e7a)
// Rev.1(Mod S) --------------------

穀物ふるいのガンプがおかしい　SUO修正済み

ServUOの定義不足。

containers.cfg

0x41	35 38 110 78	0x4F	0x990,0x9AC,0x9B1,0x24D7,0x24D8,0x24DD,0x1882

0x1882を追加

麦汁のスタックが崩せない　SUO修正済み

ServUOのバグ。
ID変更でいけるはず。

WheatWort.cs

// Rev.1(Mod S) --------------------
// public WheatWort(int num) : base(3625)
public WheatWort(int num) : base(0x1848) 
// Rev.1(Mod E) --------------------

配置済みのアドオンをメンテ後に解体すると標準色になる

ServUOのバグ。
アドオンのSerialize/DeserializeにResourceがない。
メンテ前なら正常に復元されるのはResourceを抱え持っているため。
breakしないswitch文は個人的に好きじゃない！！（ここで悩んでた）
ちなみにDEED時はResourceのSerialize/Deserializeが出来てます。
中途半端だなあ。

修正適用前に配置しているアドオンは申し訳ないですが解体後に標準色になります。
直し方が思いつかなかったです。

BaseAddon.cs

public override void Serialize(GenericWriter writer)
{
  base.Serialize(writer);

    // Rev.1(Mod S) --------------------
    // writer.Write((int)1); // version
    writer.Write((int)2); // version
    // Rev.1(Mod E) --------------------

    writer.WriteItemList<AddonComponent>(this.m_Components);
    // Rev.1(Add S) --------------------
    writer.Write((int)m_Resource);
    // Rev.1(Add E) --------------------
} 

public override void Deserialize(GenericReader reader)
{
   base.Deserialize(reader);

   int version = reader.ReadInt();
   switch ( version )
   {
       // Rev.1(Add S) --------------------
       case 2:
       // Rev.1(Add E) --------------------
       case 1:
       case 0:
       {
           this.m_Components = reader.ReadStrongItemList<AddonComponent>();
           break;
       }
    }

    if (version < 1 && this.Weight == 0)
        this.Weight = -1;

    // Rev.1(Add S) --------------------
    if (version >= 2)
    {
        Resource = (CraftResource)reader.ReadInt();
    }
    // Rev.1(Add E) --------------------
}

ブローカーの週給安くして！

ベンダーの日給に合わせてブローカーも安くして欲しいという要望。
週給なので7を返すようにしてます。

CommodityBroker.cs

public override int GetWeeklyFee()
{
    // Rev.1(Mod S) -------------------------
    /*
    int total = 0;
		
    foreach(CommodityBrokerEntry entry in m_CommodityEntries)
    {
        if(entry.SellPricePer > 0)
        total += entry.Stock * entry.SellPricePer;
    }

    double perc = (double)total * .05;
    return (int)perc;
    */
    return 7;
    // Rev.1(Mod E) -------------------------
}

１日経過で1gp減ることを確認。
表示詐欺ではないと思いますが、
ブローカーの機能自体がかなり怪しい部類なので過信は禁物です。
同じようにPetBroker.csのGetWeeklyFee()を修正すればペットブローカーも反映されるはず。
こちらは未確認です。

植物の入れ物

植物はスタック化ができないため、バルクのようにアイテムを突っ込む形式で対応。
ソースは添付ファイルにある「FlowerBinder_5.1.zip」です。
いったいいくつまであがるんだろうか？ついにVer.5である。

※ 画像は開発中のものです。実際（ｒｙ

以下仕様

見た目
- 旧wikiの種本？に似せてます
- プレビュー部分が植物の大きさに対して広すぎるのは大体新植物のせい　貴様らでかすぎるんだ！
- 名前付けられます
登録関連
- 1000個まで格納可能
- 植物を箱にドロップすることで植物を格納
- 格納不可植物
  - マジンシアで育てた植物
  - 盆栽
  - 剪定後の生け垣
  - 剪定後の高い生け垣
  - 剪定後の西洋ネズ
- バックパック内ででかい植物を格納しようとするとできないっぽい　座標関係の問題だと思う
- なので家にロックダウンして使うことを前提
染め
- タブ染めに対応（通常タブ、白タブ、黒タブ、特殊色タブ）
- 自然染料
- トクノ染料
その他
- ラピス仕様に対応　新植物の白・黒・ファイア

植物入れ軽いテストの内容←ver.2の軽い追加調査結果追加。←ごめんver.3の巻追加

上記の不具合対応とか

自然染めによる染め対応
バックパックに入れてシングルクリックすると名前が付けられるようにした
メニューから盆栽削除
デバッグ機能追加
マジンシア植物を弾くようにした
屋内花壇植物を植木鉢植物に変換するようにした
タブ染め対応
剪定された植物は登録できないようにした
メモリ削減型に修正

Ver 5.1変更点

新植物にレアピンク、レアマゼンタ、レアアクアを追加
植物を突っ込んだ時にガンプを表示
登録数を表示

Serialize/Deserializeはいじってないので影響は少ないかな？

toなるさん
プログラム中のisDebugをtrueにすると新規で植物の入れ物を生成した場合、
自動で１０００個の植物がランダムで生成された状態になります。
デフォルトはfalseです。

Ver.5について toなるさん
小難しい話になるのでなるさん宛てです。
Serialize/Deserialize時にPlantItemそのものを使用していましたが、
今回の対応でPlantTypeとPlantHueだけを持ったデータクラスをSerialize/Deserializeしています。
これにより1度目の再起動では運用中であることを想定し、
Deserializeで
１．PlantItemを復元
２．PlantItemからPlantDataを生成
３．ArrayListにDataを格納
としてます。
DataをnewしてるのにPlantItemをDeleteすると、
なぜかこいつではない他のどこかでDeserializeが止まります。
この際Exceptionも出ない。
アドレスそのまま渡しちゃってるのかな？よくわかりません。
なので1度目の再起動時は使用していませんがPlantItemのオブジェクトを生成したままとしてます。
→内部的にゴミのオブジェクトができちゃうぜーー！ってことです

1度目の再起動以降は修正プログラムが動作している状態であるため、
SerializeでDataクラスが保存されるようになります。
よってDeserializeではDataクラスを復元し、ArrayListに格納としています。

復元時にオブジェクトの削除はしちゃいけないのかな？
なにかご存知でしたら教えてください！

錬金テーブルのグラフィックがおかしい　SUO修正済み

ServUOのバグ。
ItemID:0x2DD3という１つのオブジェクト（アドオンとは別に用意されている錬金テーブル）を生成していた。
本来は東向きであれば0x3077と0x3078の２つのオブジェクトを生成し結合しなければならない。
修正後おそらく0x2DD3（東向き）、0x2DD4（南向き）の錬金テーブルはパッチレア化します。
アドオンの修正はめちゃくちゃだるいことが判明。

AlchemistTableEastAddon.cs

public AlchemistTableEastAddon()
{
  // Rev.1(Mod S) -------------------------
  this.AddComponent(new AddonComponent(0x3077), 0, 0, 0);
  this.AddComponent(new AddonComponent(0x3078), 0, -1, 0);
  //this.AddComponent(new AddonComponent(0x2DD3), 0, 0, 0);
  // Rev.1(Mod E) -------------------------
}

AlchemistTableSouthAddon.cs

public AlchemistTableSouthAddon()
{
  // Rev.1(Mod S) -------------------------
  this.AddComponent(new AddonComponent(0x307A), -1, 0, 0);
  this.AddComponent(new AddonComponent(0x3079), 0, 0, 0);
  // this.AddComponent(new AddonComponent(0x2DD4), 0, 0, 0);
  // Rev.1(Mod E) -------------------------
}

種入れるヤツ

本家にもあるアレです。
ただし仕様は植物の入れ物に準拠しているため全くの別物です。
よってアイテム名は「ラピス民のSeed Box」としています。
プログラム自体が植物の入れ物のコピペですので、
植物の入れ物が導入され安定が確認できた時点でソースを添付します。
が・・・新植物の鑑定キットを販売している検証の女帝がいますので要相談かな？
新植物の鑑定もわかりやすくできますしいいですね！

ソースは添付ファイルにある「LapisSeedBox.zip」です。

以下種入れるヤツの独自仕様

盆栽に対応
空の場合と1個以上種が入ってる場合とでグラフィックを変更
スタックした種をそのまま入れられる
染められません

以下どうにもならんこと＆どうにかなるけどなんも利益がなさそうなのこと

１．盆栽の種は入手時に「一般的(Common)」やら「エキゾチック(Exotic)」がつきますが、
　　一度SeedBoxに入れてから取り出すと全て「標準／盆栽」になります。

２．未鑑定状態の種を入れて取り出すと鑑定された状態になります。
　　これは本家もだっけ？

３．一部の新植物は「種の色／植物名」とならない。（サトウキビとか）
　　ServUOの元々の造りがそうだからとしか言えませんが、
　　種の色でわかるから大丈夫ですよね。

４．SeedBoxのグラフィックは通行障害有りです。

toなるさん＆あめりあさん
盆栽の名前適当につけるか募集しちゃってください。
固有名称がないんです。こいつら。
なので植物の入れ物のほうは導入を諦めた経緯があります。
現状、仮で盆栽Ａ～盆栽Ｈとしてます。

エルフの演壇のグラフィックがおかしい　SUO修正済み

ServUOのバグ。
エルフ式錬金テーブル同様、修正後、本付きの演壇はパッチレアになる可能性あり。

ElvenPodium.cs

// Rev.1(Mod S) -------------------------
// [Flipable(0x2D4B, 0x2D4C)]
[Flipable(0x2dde, 0x2ddd)]
// Rev.1(Mod E) -------------------------

public ElvenPodium()
  // Rev.1(Mod S) -------------------------
  //: base(0x2D4B)
  : base(0x2dde)
  // Rev.1(Mod E) -------------------------

大工の生産ガンプに表示されるプレビューは
ここ直すと勝手に直るみたい。

染料仕様検討

みんな色が好きらしい。

染料仕様検討となった経緯

ServUOのデフォルトは適当だし、本来染めらない物を染めたい要望は必ずあります。
ですが、方針上ServUOがアップデートされる度にスクリプトを手直しして追加していかなければなりません。
非常に億劫ですね！
じゃあどうするか？

ラピスオリジナルの染料システムを作ればいいじゃない。

独自の仕様にすることによりアップデートの影響はごくわずかになるはず。
さらに本来はない染料を作り上げることが可能となります。
まさにWinWinである。
作る人だけが負けです。

何が問題なの？

自然染料を例にしてみますと、

自然染料の染められる対象を増やしました！
ServUOのアップデートで元に戻りました・・・
手直しで対象を戻すざます
ServUO「やあ＾＾またアップデートだよ」
手直しで対象を元に戻すざます・・・
ServUO「やあ＾＾」
いい加減にしろ

思案中の仕様

各染料を格納する箱みたいなイメージです。
この箱みたいなのに染められる対象を設定することによりServUOのアップデートの影響を受けなくなります。
花箱とか種箱と違うのは、「入れて取り出す」のではなく、
箱に入れることにより、

入れた染料のチャージ数を増やす
染めるボタンを押すとチャージを消費してアイテムを染める

っていう仕組みを想定します。
ドーンのオルゴールが近いかな？
あれは一度登録すると無限ですが、こちらは有限です。

おおまかな登録の流れ

ピグメントチケットなるものをつくり、染料箱（？）にドロップして登録する仕組みにしようかと思ってます。
じゃあこのピグメントチケットはどうやって入手するのか？
生産で入手、戦闘で入手を思案中。

今ある染料・今後出てくるクリンアップの染料

ブランクピグメントチケット（仮）をダブルクリックする。
対象の染料をターゲットする。
染料の名称とチャージ数が書かれたピグメントチケットに変化する

考え中の新染料（生産）
アイテム鑑定スキルを参照して新染料を作れるようにしたいなあと考えてます。あくまで予定。

ブランクピグメントチケット（仮）をダブルクリックする。
対象のバルク報酬布100枚とかAsh板100枚とかをターゲットする。
染料の名称とチャージ数が書かれたピグメントチケットに変化する

考え中のトクノ染料（戦闘）
イルシェナー全域、トクノ全域でMobを倒すと
確率でTMAFトクノ染料のピグメントチケット　チャージ1が入手できるとか。
イルシェナー、トクノのチャンピオン討伐でTAFトクノ染料のピグメントチケットとか。
ただし、ネズミは確率低い。
だってネズミだし。
これは仕組みを考える必要あり。

現在の状況

● 資材からチケットの作成機能　完了
チケットっていうよりビスケットである。
本当はクッキーだよ。

ダブルクリックで資材（１００個）を選択することによりチケットが変化。
そのまま内装に使えそうなのです。

資材は以下を想定して作成してます。

バルク報酬布
鉱石
皮
木材

作成にはアイテム鑑定スキル80.0以上が必要です。
また、スキル値によって作成時のチャージ数が変化します。

スキル値	チャージ数
80.0～89.9	1
90.0～99.9	2
100～	3

果たしてServUOでアイテム鑑定スキルは正常にあがるんでしょうか？
プレイヤー：「アイテム鑑定スキルは普通に上がりますよ。もちろんGMです。」
なかなかマニアックなプレイヤーがいらっしゃるようです。

● 戦闘で入手機能（雑魚）完了
既存のロジックに2行追加するだけでいけそう。
案外いいかもしれないこの機能。
staticにすれば1行だけで済むんだけど、ちゃんと同期取れるんだろか？

イルシェナー全域、トクノ全域でTMAF染料のチケットを入手できる可能性があります。
死体湧きにしたけど、鞄湧きのほうがよかったりしますかねえ？
現状確率を固定にしてますが、最終的にフェイムと幸運を参照するようにしたいところです。
→アイテム鑑定スキルGMボーナス、フェイム参照、幸運参照を追加
　スキルGM、幸運1000くらいでチャンピオンエリアにEVでも置おけば生産でも結構落ちる確率になってます。