◆トレーナーハウスドキュメント	by 岩澤　幸 09/08/19


◆関連ソース
　セーブデータソース
	include\savedata\tr_house.h			//トレーナーハウス用セーブデータ公開ヘッダ
	include\savedata\tr_house_data.h	//ハウス用セーブデータ型定義ヘッダ　公開箇所限定
	src\savedata\tr_house.c				//トレーナーハウス用セーブデータ制御　常駐

　PHC通信関連ソース
	src\tr_house\tr_house_phc.c			//PHCとのデータの送受信処理(phcオーバーレイ)
	src\tr_house\tr_house_data.dat		//デフォルトトレーナー"ヒカル"のパラメータ定義(fld_trhouse_ol.cにinclude)

　スクリプト関連ソース
	src\field\fld_trhouse_st.c			//常駐スクリプトコマンド
	src\field\fld_trhouse.c				//フィールド常駐スクリプトコマンド
	src\field\fld_trhouse_ol.c			//非常駐関数(field_tr_houseオーバーレイ)


◆PHCから受信するデータのフォーマット

トレーナーハウスに出現するトレーナーのパラメータとして、
PHC内にストックされる500byte*10人分=5000byteのレコードデータを
DSにダウンロードして利用しています。

PHCのレコードデータとして格納されているときのフォーマットは以下です。
500byte中488byte目からの2byteにチェックサムコードを格納し、破壊されたレコードの検出に利用しています。

PHCからは10人分、計5000byteのデータ列としてダウンロードされてきます。
PHC内では、より新しいデータが下位アドレスから上位アドレスに向かって詰められているので
DS側は新しいデータが配列の先頭にくるように、500byte*10の配列を逆からサーチして
セーブデータするデータを抽出しています。


●一人分のデータ構造―┌┐┘└├┬┤┴┼│

 全500byte
┌―――――――――――――――――┐
│　　　　　　　　　　　　　　　　　│
│　384byteのトレーナーパラメータ 　│
│　　　　　　　　　　　　　　　　　│
├―――――――――――――――――┤
│　空き領域　　　　　　　　　　　　│
├―――――――――――――――――┤
│　2byteのチェックサムコード 　　　│
└―――――――――――――――――┘

●384byteのトレーナーパラメータ内訳

/**
 * @biref	ハウス用ポケモンデータ型
 * 56byte
 */
struct _TR_HOUSE_POKEMON{
	union{
		struct{
			u16	mons_no:11;	///<モンスターナンバー
			u16	form_no:5;	///<モンスターナンバー
		};
		u16	mons_param;
	};
	u16	item_no;	///<装備道具

	u16	waza[WAZA_TEMOTI_MAX];		///<所持技
	u32	id_no;					///<IDNo
	u32	personal_rnd;			///<個性乱数

	union{
		struct{
		u32	hp_rnd		:5;		///<HPパワー乱数
		u32	pow_rnd		:5;		///<POWパワー乱数
		u32	def_rnd		:5;		///<DEFパワー乱数
		u32	agi_rnd		:5;		///<AGIパワー乱数
		u32	spepow_rnd	:5;		///<SPEPOWパワー乱数
		u32	spedef_rnd	:5;		///<SPEDEFパワー乱数
		u32				:2;		//余り
		};
		u32 power_rnd;
	};

	union{
		struct{
		u8	hp_exp;				///<HP努力値
		u8	pow_exp;			///<POW努力値
		u8	def_exp;			///<DEF努力値
		u8	agi_exp;			///<AGI努力値
		u8	spepow_exp;			///<SPEPOW努力値
		u8	spedef_exp;			///<SPEDEF努力値
		};
		u8 exp[6];
	};
	union{
		struct{
		u8	pp_count0:2;	///<技1ポイントアップ
		u8	pp_count1:2;	///<技2ポイントアップ
		u8	pp_count2:2;	///<技3ポイントアップ
		u8	pp_count3:2;	///<技4ポイントアップ
		};
		u8 pp_count;
	};

	u8	country_code;		///<国コード

	u8	tokusei;			///<特性
	u8	natuki;				///<なつき度

	u8	level;

	//ニックネーム ((MONS_NAME_SIZE:10*2)=20
	//EOMコードを含まないサイズなので、アクセス時に注意！
	STRCODE	nickname[MONS_NAME_SIZE];
};

//ハウストレーナーデータ
// 48byte
struct _TR_HOUSE_PLAYER{
	u32		tr_id;		///<トレーナーID
	u8		obj_code;	///<unionの見た目ナンバー(OBJコード)
	u8		region;		///<国コード
	u8		version;	///<ROMバージョン
	u8		tr_sex;		///<プレイヤー性別
	STRCODE	name[PERSON_NAME_SIZE+EOM_SIZE];	//8*2 = 16
	
	PMS_DATA	word[TR_HOUSE_PMSG_MAX];	//登場,勝利,敗退メッセージ	
};

//ハウス　対戦相手データ構造体 384byte
struct _TR_HOUSE_TRAINER{
	TR_HOUSE_PLAYER				player;			//トレーナーデータ
	struct _TR_HOUSE_POKEMON	poke[6];		//手持ちポケモンデータ
};


PHCは実際に出会った人同士のレコード交換が基本ということで
プレイヤー名およびポケモンのニックネームに対して、NGワードを回避する処理は実装されていません


●PHCに送信するデータ

PHCに送信するハウスデータは、PHC通信を行った時にセーブされている手持ちデータを
_TR_HOUSE_TRAINER型に収集し、500byteの末尾に2byteのチェックサムを埋め込んで
トータル500byteのデータとしてパックしたものを、PHC側に引き渡します。

この時、手持ち内のタマゴは無視してデータを詰めます。

<スカイフォルムシェイミに対する特殊処理>
シェイミがスカイフォルムだった場合、このパラメータをそのまま格納してしまうと
夜なのに対戦相手がスカイフォルムを出してくるという、設定的に不自然な状態が発生します。
この現象を回避する為、_TR_HOUSE_POKEMON型には
強制的にノーマルフォルムのパラメータを書き込みます。


●無効データの検出

PHCから受信するハウスデータは10人分5000byte全ての領域をサーチします。
この時、_TR_HOUSE_TRAINER型にキャストした際、手持ちの一番目にあたる
モンスターナンバーデータが"0"であった場合、その領域は無効としています。

また、2byteのチェックサムを照合し、これが不一致だった場合に無効データとして無視します。


●データの押し出しアルゴリズムについて

セーブデータ領域には、ハウストレーナー10人分のセーブ領域が確保されています。
PHCからハウスデータを受信した際は、10人のデータを１つ１つサーチし、
セーブの空き領域を見つけたら、そこに新規データを書き込みます。
10箇所全てが有効データで埋まっている場合は、もっとも古いデータ(idx0)を押し出し、
末尾の空き領域に一つずつ格納していきます。

ただし、あるプレイヤーAの新規データと、既にセーブされているデータ群を照合し、
同一プレイヤーのデータであると判定された場合、idx0を押し出すのではなく、
発見されたプレイヤーAのデータが格納されていた領域を削除、以降のデータを前詰めし、
末尾に新しいプレイヤーAのデータを格納するようにしています。

これは、同一プレイヤーのデータが複数同時に存在しないようにするための処置です。
ある2つのデータが同一プレイヤーかどうかの判定は以下のアルゴリズムで判定しています。

　以下に列挙したパラメータが同一ならば、同じプレイヤーのデータとみなす

　・プレイヤーのトレーナーID
　・カセットバージョン
　・言語バージョン
　・プレイヤーの性別
　・プレイヤー名




●トレーナーハウスのフィールドOBJ設定について

トレーナーハウスでは、デフォルトキャラ(ヒカル)以外の10人のトレーナーは
スクリプトのFLAG_CHANGEのタイミングで表示・非表示、見た目の制御しています。

各トレーナーの見た目は OBJCHARWORK1〜10までの連続ワークを使用して制御。
バニッシュフラグは、その日は既に対戦済みであることを識別するためのタイムフラグも
同様に連続IDを持つフラグ領域を割り当てています

　バニッシュフラグ	FV_TR_HOUSE_TRAINER01〜FV_TR_HOUSE_TRAINER10
　タイムフラグ		TMFLG_TR_HOUSE_TRAINER00〜TMFLG_TR_HOUSE_TRAINER10

トレーナーハウス内でセーブを行い、PHCとの通信を行ってハウスデータを更新すると
対戦済みであることを示すタイムフラグがずれてしまうことがありうるため、
PHCからのデータDL&SAVE処理にて、タイムフラグも書き換えて整合性を取るようにしています


●デフォルトトレーナー

トレーナーハウスには、PHC通信によらず常にヒカルというデフォルトのトレーナーがいます。
ハウス内のトレーナーに割り振られるヒカルのIDは10(=TR_HOUSE_TRAINER_MAX)です。

ヒカルのトレーナーパラメータは src\tr_house\tr_house_data.dat に定義されています。
手打ちのデータです。


●トレーナーハウスのファイトタイプ

トレーナーハウスバトルのファイトタイプは以下です。

#define	FIGHT_TYPE_BATTLE_TR_HOUSE	(FIGHT_TYPE_1vs1_TRAINER|FIGHT_TYPE_TOWER|FIGHT_TYPE_TR_HOUSE)	///<トレーナーハウス戦

基本は1vs1 WiFiタワーバトル準拠です。
経験値・賞金は手に入らず、使用したアイテムは対戦後に元に戻ります。
また、対戦相手のポケモンは図鑑登録されません。

なお、トレーナーハウスのマップでは連れ歩きを明示的にフックしているため
トレーナーハウスバトル側は、連れ歩きはないものとして構築されています。





