「解析データ/未整理」の編集履歴（バックアップ）一覧はこちら

解析データ/未整理 - (2007/03/12 (月) 13:53:03) の最新版との変更点

追加された行は緑色になります。

削除された行は赤色になります。

dkbjgw wxrcm jlnh dkvgzxnla lzotf poqjbrmac pjitvcome

有用と思われるレスの引用、未整理 


>126 名前：23 ：04/12/09 02:02:42 ID:??? 
>会話イベント領域の拡張がほぼ完成したので報告。 
>まずLUNAR EXPAND（>>80)を使用してROMを32Mbitにし、容量を4Mbiteに拡張する。 
>次に会話データD0000-D261F（ヘッダ無しの場合）をコピーし、アドレス 
>100000から貼り付ける(挿入ではなく、上書き）。同様にアドレステーブル 
>E2620-2E1Fを200000にコピーする。 
>このままでは移動したデータが読み込まれない&コード04**が使えないので、 
>プログラムを書き換える。 
>0822D　04　→　05 
>01F2C　04　→　05 
>01F31　04　→　05 
>02030　BF　20　A6　1C　→　BF　00　80　40 
>02036　BF　21　A6　1C　→　BF　01　80　40 
>0203D　1A　→　20 
>0BEE7　64　F6　82　→　4C　C4　C0 
>これで完成。会話データとアドレスを設定すればコード04**にも会話 
>イベントを割り当てられる。この改造により、新しいイベントは256個 
>まで追加可能になり、会話データに使える領域が20KBほど増える。 

>152 名前：23 ：04/12/12 12:08:59 ID:???
>イベントでの会話→戦闘→会話の切り替えを操作するべく、0C**の処理 
>について調査。 
>EBD80:load　b@13F2 <- {temp <- b@13B6} 
>13F2に13B6の値（イベントバトル番号）をロード 
>
>EBD85:load　w@1396 <- {temp <- b@13B6 -<- 80 *<- 06 +<- AC00} 
>(13B6の値-80)*6+AC00をアドレスとするデータ2バイトを1396に 
>ロード（会話テーブル上の位置を指定） 
>例:デス（FB)　(FB-80)*6+AC00=AEE2 
>
>EBD91:call　BE19 
>BE19を呼び出し 
>
>EBE19:bank　09 
>バンク09に切り替え 
>
>EBE1B:load　w@1990 <- {temp <- w@[w@1396]} 
>1396で指定されるデータ2バイトをアドレスとするデータ2バイト 
>→1990へロード（戦闘前の会話の番号を指定） 
>以後、しばらく会話処理。 
>
>

>153 名前：23 ：04/12/12 12:12:29 ID:??? 
>ここまででわかったのは、09:AEE2すなわち04AEE2とその周辺が 
>イベントバトルにおける会話を指定しているということ。 
>調査の結果、4AC00-4AEFF（ヘッダ付きなら4AE00-4B0FF）の768 
>バイトが会話コード指定テーブルとなっている。 
>どうやら1つのイベントバトルにつき6バイトで構成されており、 
>最初の2バイトが戦闘前の会話、後ろの2バイトが戦闘後の会話の 
>ようだ。基本的に戦闘前会話を読み込み→戦闘→戦闘後会話を読 
>み込み、という流れで進む。ただし、選択肢などで処理終了の 
>コードが会話中にある場合はそこで処理は終わり、戦闘にならない。 
>真ん中の2バイトの役割は不明。ただ、デスのイベントでここを 
>00FFにしたところ、戦闘後に画面が暗転したままになった。処理が 
>複雑で未だよく分からないが、会話中で指定されているフラグ 
>（「3Dを2にする」とか「3Fを1にする」など）や移行処理と関連 
>しているようだ。この辺りはtalk_data.txtなどを参照のこと。 
>
>これとグラフィックが何とかなれば、シェラハイベントはほぼ完成 
>なんですが･･･。 
>

>474 名前：ゲーム好き名無しさん ：04/12/28 16:31:49 ID:??? 
>
>水龍の依頼受ける 
>7E10Dd20 
>水龍の依頼達成 
>7E10Dd40 
>水龍殺す 
>7E10Ddf0 
>
>【水龍の依頼を受けているとそれぞれ+20になる】 
>アディリスの依頼受ける 
>7E10Dd02【22】 
>アディリスの依頼達成 
>7E10Dd03【23】 
>アディリス殺す 
>7E10Dd0f【2f】 
>
>タイニイフェザーの依頼受ける（部下が攻撃してこなくなる） 
>7E10De20 
>タイニイフェザーの依頼達成（部下が攻撃してこなくなる） 
>7E10De40 
>タイニイフェザー殺す（部下の足が速くなる） 
>7E10Def0 
>
>【タイニイフェザーの依頼を受けているとそれぞれ+20になる】 
>フレイムタイラントの依頼受ける（部下が攻撃してこなくなる） 
>7E10De02【22】 
>フレイムタイラントの依頼達成（部下が攻撃してこなくなる） 
>7E10De03【23】 
>フレイムタイラント殺す（部下の足が速くなる） 
>7E10De0f【2f】 
>

>485 名前：23 ◆qw.Y80Jhqg  ：04/12/28 23:50:42 ID:???
> >>484 
>乙です。イベントフラグのアドレスは善行値くらいしか知らなかったので 
>大変参考になります。お礼に少し支援。 
>
>7E10D7　について補足。 
>bit4~7フラグ74（イスマス+最終試練クリアフラグ） 
>bit0~3フラグ75（バルハラント関連フラグ） 
>デスにサルーインの居場所を聞く70 
>最終試練をクリアする80 
>ガトから洞窟のモンスターについて依頼を受ける（1回目）01 
>1回目の依頼で南と西の洞窟のモンスターを倒す一体目02　二体目03 
>ガトから洞窟のモンスターについて依頼を受ける（2回目）04 
>2回目の依頼で南の洞窟のモンスターを倒す05 
>バルハラントから騎士団領へ行けるようになる06 
>凍結湖の城に入れるようになる07 
>
>最終試練クリア後にデスと話すことでまた最終試練に挑めるようになるのも 
>これで説明がつく。 
>フラグ74とか75というのはコンバータで出力されるイベントフラグ番号。 
>プログラム上ではそのように番号を振ってイベントフラグを管理している 
>ようだ。 
>
>

>17 名前： ◆qw.Y80Jhqg ：05/01/02 11:19:38 ID:??? 
>こっそりとロマサガ1の解析結果を投下。少しだけ逆アセンブルに挑戦。 
>
>敵最大HPの上限値（32768）を外す方法 
>
>04F233FAPLXXの値（敵最大HP)をスタックからプル 
>04F23448PHA 
>04F2358ATXAXの値をAにコピーする 
>04F23638SEC 
>04F237E3　01SBC　$01,sAから[$00:1EAD]（Sの値に1を足したアドレス）の値を引く 
>
>HPが32768以上の場合のみ、ここで32568が減算される。（それ以下の場合は影響無し） 
>よって、 
>
>04F237EA　EANOP 
>
>にすれば敵の最大HPを40000や50000にすることが可能になる。（最大で65535） 


>18 名前： ◆qw.Y80Jhqg ：05/01/02 11:28:12 ID:??? 
>げ、詰まってる･･･、次からは気をつけます･･･。一応見やすく書き直し。 
>
>04F233　FA　　　　　　　PLX　　　　　　　Xの値（敵最大HP)をスタックからプル 
>04F234　48　　　　　　　PHA 
>04F235　8A　　　　　　　TXA　　　　　　　Xの値をAにコピーする 
>04F236　38　　　　　　　SEC 
>04F237　E3　01　　　　　SBC　$01,s　　　Aから[$00:1EAD]（Sの値に1を足したアドレス）の値を引く 


>770 名前： ◆qw.Y80Jhqg ：05/01/06 15:07:40 ID:??? 
>ダメージ計算における乱数について 
>
>ダメージ計算において 
>乱数/(17-武器レベル)　の余りが使われる。 
>
>また、RPG INSTITUTEによれば乱数の生成式は 
>X(n+1)={3*X(n)+n　(mod 15)}(mod　256) 
>
>以下ダメージ計算における乱数処理部分の逆アセンブル結果 
>[$00:1210]に現在の乱数の値X(n)が、[$00:1211]に乱数の番号nが保存されている。 
>また、[$00:1208]には「16-武器レベル」の値が保存されている。 
>DB:00　D:1200 とする。 
>
>000888　A5　10　　　　　LDA　$10　　　　　Aに[$00:1210]の値をロード=X(n) 
>00088A　0A　　　　　　　ASL　　　　　　　　　Aの値を2倍する=2*X(n) 
>00088B　18　　　　　　　　CLC 
>00088C　65　10　　　　　ADC　$10　　　　　Aに[$00:1210]の値を加える=3*X(n) 
>00088E18CLC 
>00088F　65　11　　　　　ADC　$11　　　　　Aに[$00:1211]の値を加える=3*X(n)+n 
>000891　85　10　　　　　STA　$10　　　　　Aの値を[$00:1210]に書き込む 
>000893　E6　11　　　　　INC　$11　　　　　[$00:1211]の値に1を加える（n→n+1) 
>000895　A5　11　　　　　LDA　$11　　　　　Aに[$00:1211]の値をロード 
>000897　C9　0F　　　　　CMP　#$0F　　　　Aから0Fを引く（結果は保存しない） 
>000899　90　02　　　　　BCC　$02 
>00089D　A5　08　　　　　LDA　$08　　　　　Aが0F以下なら、Aに[$00:1208]の値をロード 
>00089F　38　　　　　　　　SEC 
>0008A0　E5　07　　　　　SBC　$07 
>0008A2　1A　　　　　　　INC　　　　　　　　　Aに1を加える→(17-武器レベル) 
>0008A3　85　08　　　　　STA　$08　　　　　Aの値を[$00:1208]に書き込む 
>0008A5　F0　0E　　　　　BEQ　#$0E　　　　 
>0008A7　A5　10　　　　　LDA　$10　　　　　Aに[$00:1210]の値（乱数値）をロード 
>0008A9　38　　　　　　　　SEC 
>0008AA　E5　08　　　　　SBC　$08　　　　　Aから[$00:1208]の値を引く 
>0008AC　B0　FB　　　　BCS　#$FB　　　　Aが0以上なら$0008A9へ戻る 
>0008AE　18　　　　　　　　CLC 
>0008AF　65　08　　　　　ADC　$08　　　　　Aに[$00:1208]の値を加える 
>0008B1　18　　　　　　　　CLC 
>0008B2　65　07　　　　　ADC　$07 
>0008B4　60　　　　　　　　RTS 
>
>[$00:1208]の値を足したり引いたりしているのは除算の代わりに減算を繰り返している。 
>乱数の値から(17-武器レベル)を何度も引き、結果がマイナスになったらその前の値を 
>最終結果としている。これは乱数の値を(17-武器レベル)で割った余りに等しい。 
>
>少なくとも物理攻撃においてはこの乱数生成部位が使われているはず。 
>

>800 名前： ◆qw.Y80Jhqg ：05/01/06 23:24:34 ID:??? 
>ロマサガ1における物理ダメージの正確な計算式 
>
>ダメージP=B(AX/32)-DN+1　(端数切捨て） 
>
>A=腕力 
>B=武器或いは技の攻撃力 
>D=敵の防御力 
>N=打撃武器の時3、それ以外なら5 
>X=｛乱数　mod（17-武器レベル）｝+武器レベル+32（左利きの場合-1） 
>
>826 名前： ◆qw.Y80Jhqg ：05/01/07 01:16:34 ID:??? 
>SFC版で邪術「インジャリー」のダメージ上限が511である理由 
>
>虎の巣によるとインジャリーのダメージ算出式は 
>対象のHPが完全回復状態でない時に　 
>与えるダメージP＝（残りHP）X/128　（mod　512） 
>X=魔力（法力と知力で算出される値） 
>
>この式はcode1E処理であり 
>EA2C7:load　w@13D7　<-　{temp　<- b@13B6　*<- w@138D　/<- 80} 
>がそれに当たる。 
>w@13D7=ダメージ量 
>b@13B6=魔力 
>w@138D=対象の残りHP 
>
>mod512の原因はこの式の計算の順番にある。 
>例：魔力121（邪の法力100、知力93の時の値）=79 
>　　敵の残りHPが4255=109F 
>式は左から順に計算される（乗除算を優先するということはない）ので 
>最初に79*109Fが実行される。すると答えは7DB27となり、2バイトを超えて 
>オーバーフローしてしまう。結果最上位の7が切り捨てられ、DB27/80が計算 
>され、1B6=438が最終ダメージ値になる。 
>
>これを回避するには先に現在HP/128を実行し、最後に魔力を掛ければよい。 
>つまり 
>EA2C7:load　w@13D7　<-　{temp <-　w@138D　/<-　80　*<-　b@13B6} 
>にすればインジャリーで512以上のダメージを与えることが可能になる。 
>
>具体的な改造の方法 
>EA2C7-CFを以下のように書き換える。 
>改造前 
>20　D7　0C　B6　21　8D　C2　80　1F 
>改造後 
>20　D7　2C　8D　C2　80　01　B6　1F 
>
>ゴールドドラゴンなどに使えば簡単に10000以上のダメージを与えられる。 
>


>50 名前： ◆qw.Y80Jhqg ：05/01/09 01:02:01 ID:??? 
>ロマサガ1　敵の行動決定ルーチンについて 
>code1E処理の一つ。長いので少し省略。 
>
>E8470:load　b@13B3　<-　{temp 　<-　random[09]}　　　　 
>まず、そのターンで使用する術系統を乱数を用いて選択（乱数mod09を[1D:13B3]にロード) 
>術系統は00:火、01:水、02:土、03:風、04:光、05:闇、06:邪気、07:気、 
>08:魔、09:幻 
>
>E84AF:load　b@13B3 <- {temp <- random[FF]} 
>また乱数を用いて00-FFの値を[1D:13B3]にロード 
>
>E84B4:load　w@1396 <- {temp <- F350 +<- b@130C} 
>E84BC:load　b@13B9 <- {temp <- b@[w@1396]} 
>EF350+モンスター番号のアドレスにある値をロード･･･① 
>
>E84C1:load　w@1396 <- {temp <- b@13B1 +<- F450} 
>EF450+敵パーティレベル？（未確認）のアドレスにある値をロード･･･② 
>
>E84C9:if　b@13B3 > {temp <- b@13B9 +<- b@[w@1396]} 
>E84D0:then　jump　855D 
>①+②の結果がE84AFで選んだ値（2つめの乱数）より大きければ上で 
>選んだ系統の術を使用する。 
>小さければ、武器及び特殊攻撃を使用。 


>52 名前： ◆qw.Y80Jhqg ：05/01/09 01:03:29 ID:??? 
>続き 
>
>E84DE:if　00 <　{temp <- b@[w@1396]　L<- b@139F &<- 80} 
>E84E7:then　jump　850C 
>E84EA:(b@139F)++ 
>E84EC:if b@139F <= {temp <- 07} 
>E84F1:then　jump　84DE 
>選んだ系統の術を最高位の術から順にチェック。覚えていれば法力 
>のチェックに移行。 
>その系統の術を一つも覚えていない場合、或いは法力切れで術が 
>使えない場合は、武器及び特殊攻撃を使用。 
>
>E850C:load　b@1374 <- {temp <- 07 -<- b@139F} 
>E8513:load　w@1396 <- {temp <- b@1373 -<- 80 *<- 08 +<- b@1374 *<- 
>　　　　　　　　　　0C +<- E180} 
>E8523:if　b@[w@13B4] < {temp <- b@[w@1396] &<- 3F} 
>E852A:then　jump　84EA 
>法力が足りない場合、一つ下位の術法の習得チェックに移行。 
>法力が足りていれば、以下対象選択に移行。 
>
>武器攻撃時と対象選択のルーチンは未調査。 
>流れを追っていくと分かるが、このルーチンは武器攻撃を多用する 
>傾向がある。このルーチンでシェラハと同パラメータで使用術法も 
>同じモンスターを設定してみると、ドレインばかり使用する。 
>このルーチンを弄ることで、敵全般の攻撃パターンをある程度制御 
>できるようになる。実際、これを改造することでシェラハに高位術法 
>を連発させることができるようになった。 
>ただ、このルーチンだと高位の術から優先して使用するはずだが、 
>ごく稀ではあるが法力が残っていても下位の術法を使うことがある。 
>原因は未だ不明。 


>67 名前： ◆qw.Y80Jhqg ：05/01/09 10:15:53 ID:??? 
>ロマサガ1　敵グラフィックのヘッダについて 
>画像番号Nの値（画像サイズ）によって算出法が異なる。 
>画像番号については構造体の敵データ及びコンバータの出力結果 
>（monster_data.txt）を参照。 
>
>8*8画像の場合（N=00-3Fの場合） 
>{(N and 3F)*100+0B}/17+1EB3E8(F33E8) 
>
>16*16画像の場合（N=40-7Fの場合） 
>{(N and 3F)*100+23}/7+1EB6A8(F36A8) 
>
>このアドレスにある値3バイトをリトルエンディアンで読んだアドレスが 
>グラフィックデータの先頭に当たる(ヘッダ無しのアドレス）。 
>ただし、それだけではまともな画像にならず、以降29バイト（多分） 
>のデータで画像パーツの配置？（補助画像の情報なども含んでいるようだ） 
>を指定している。 
>
>例：精霊（画像番号08） 
>{(08 and 3F)*100+0B}/17+1EB3E8=1EB440(F3440) 
>C0 8F 0F　→0F:8FC0=ROM上のアドレスは078FC0 
>
>これを利用すれば適当な空き領域に画像データを配置して読み込ませること 
>が可能だが、上記の画像の配置の法則とパレットデータの位置がわからない 
>ので、まだ実用的ではない。 
>


>253 名前： ◆qw.Y80Jhqg ：05/01/10 13:17:04 ID:??? 
> >>151 
>もう見ていないかもしれないけれど解説 
>時間経過処理について（以下全てヘッダ無しのアドレス） 
>4BC60-4BC9Fで時間経過処理を行う基準となる戦闘回数を設定している。 
>2バイトずつで（リトルエンディアン）全32段階まである。 
>最後の段階は戦闘回数1040回で、これ以降は時間経過処理が 
>行われないため（最終時間経過を除く）、仲間も再配置されなく 
>なる。（仲間の再配置は時間経過処理の一環であるため） 
>
>また、いわゆる最終時間経過についてもある程度原因が推測できる。 
>最終時間経過が起こるのは10000戦闘前後と言われるが、上記の 
>時間経過処理の最終段階（戦闘回数1040回）の後、0F　27が 
>延々と続いている。0F　27をリトルエンディアンで読むと 
>270F。10進法に直すと9999。つまり戦闘回数が9999回以上で 
>時間経過ポイントを通過すると、上記の戦闘回数設定領域の 
>下にある0F　27をプログラムが時間経過基準戦闘回数と誤認識 
>し、おかしなことがおこると考えられる。 
>
>そこで、この時間経過処理基準戦闘回数の設定表自体を別の領域に 
>移し、理論上の限界値である戦闘回数65535回までフォローした表を作成する。 
>ガラハドパッチでは1F8000-81FFに戦闘回数表を移している。 
>ただ、時間経過処理では内部で段階をカウントしており、最大でもFF（=255段階） 
>までしか設定できないので、それに留意して表を作る必要がある。ガラハドパッチ 
>での1040回以降での時間経過処理基準が256戦闘ごとになっているのには 
>そういった理由がある。自分でやる場合、移す場所は1FFFFFまでのどこかに 
>したほうがよい。それ以降はメモリのミラーの関係でお勧めしない。 
>

>254 名前： ◆qw.Y80Jhqg  ：05/01/10 13:18:38 ID:???
>次に仲間フラグについて 
>仲間を外すとその仲間のフラグがCになり、どこにもいない状態になる 
><A href= 
>
>255 名前： ◆qw.Y80Jhqg ：05/01/10 13:20:39 ID:??? 
>次に仲間フラグについて 
>仲間を外すとその仲間のフラグがCになり、どこにもいない状態になる 
>ttp://karen.saiin.net/~g-kaizou/c_rs1_5.html 
>（ロマンシングサガ1 仲間コード） 
>時間経過処理時にこれらのフラグが再セットされるが、そのデータは 
>E70D0-E76AFに記述されている。（恐らくイベントフラグ変更データもここに） 
>
>例えば 
>E76A0-A3：55　55　55　55 
>は全員がクリスタルシティに集合している状態を示している。 
>パッチを当てると、これらも丸ごと別の空き領域（1F0000〜）に移し、 
>32段階以降の仲間の配置を書き加えて新たな表としている。 
>詳しくは調べていないが多分クリスタルシティだけでなく、別の場所 
>に仲間を集合させたり、ミリアムやゲラ=ハなどを再出現させたりする 
>ことも可能だと思われる。 


>256 名前： ◆qw.Y80Jhqg ：05/01/10 13:30:45 ID:??? 
>
>最後に時間経過処理を司るcode1E処理部分を書き換える。 
>処理自体が長いので変更点だけ。 
>EC08F:load　w@1396 <- {temp <- b@10F5 *<- 02 +<- BC60} 
>1396から2バイトに｛10F5の値*2+BC60｝の値を代入 
>BC60→8000に変更 
>
>EC09A:bank　09 
> >バンク09に切り替え 
>09→3Fに変更 
>
>ED458:load w@1396 <- {temp <- b@10F5 *<- 60 +<- b@13BB /<- 02 +<- F0A0} 
> >(10F5の値*60+13BBの値)/2+F0A0を1396から2バイトに代入 
>F0A0→8000に変更 
>
>ED467:bank 1C 
> >バンク1Cに切り替え 
>1C→3Eに変更 
>

>913 名前： ◆qw.Y80Jhqg ：05/01/18 05:14:37 ID:??? 
>逃走不可フラグについて 
>
>イベントバトルにおいて最初に会話がある場合、初めに 
>処理コード[フラグ3Fを1に変更する] 
>というコードが入っています。そこから選択肢などで戦闘に入る場合、 
>処理コード[フラグ3Fを3に（あるいは2）変更する] 
>というコードがあります。つまり、最初にセットしたフラグ3Fの 
>値が変化したら戦闘になるということです。 
>この時、フラグ3Fの値を変更するコードの直前あるいは直後に 
>[フラグ3Dを1（2や3の場合もある）に変更する] 
>というコードが入っていることがあり、これがあると逃走不可能 
>になります。コンバータのtalk_data.txtを見て会話の流れを追うと 
>分かると思います。凍結湖の城でのヘイトとの会話が分かりやすい 
>でしょう（会話0179)。 
>会話無しでいきなり戦闘になるパターンにおける逃走不可については 
>まだよくわかっていません。 


>914 名前： ◆qw.Y80Jhqg ：05/01/18 05:18:11 ID:??? 
>弱点属性ダメージ1現象について 
>
>これは戦闘中の回復量が異常に高いことと密接に関係があります。 
>戦闘時に回復術法を使うと器用さ*1280の値が加わりますが 
>（これもまたバグなのですが）、この時00:13EB-EFにその値がロード 
>され、回復量の計算後もそれがクリアされずに残っています。 
>
>術法のダメージを算出する時、通常なら13EBには対象者の精神*3の値が 
>ロードされる（=上書きされる）ので問題にはなりません。 
>しかし弱点属性の場合、精神の値をロードせず、その時00:13EB-EC 
>に入っている値をそのまま精神*3の値としてダメージ計算に使ってしまいま 
>す。 
>（おそらく13EBの値が通常は0であるという前提でプログラムしたと 
>思われます） 
>この値（通常40000程度）が術法ダメージの計算（虎の巣参照）で、 
>精神*3の値として減算されるため、ダメージ値は確実に0となります。 
>そして計算の最後に1が加えられ、最終ダメージ値は1となります。 
>この13EBの値は術法ダメージ計算後もクリアされないため、弱点属性 
>以外の術法で誰かがダメージを受けない限り、この状況が続くことに 
>なります。 
>「弱点属性の術ダメージは、敵・味方を問わずに、その直前に弱点以外 
>の術でダメージを受けた者の精神に依存する」というバグもこれで説明 
>がつきます。 
>
>これを修正する為に回復量算出、および術法ダメージ算出を担うcode1E 
>処理に変更を加え、回復量算出後と術法ダメージ計算前にそれぞれ 
>00:13EBの値を0にするよう処理を書き加えました。 
>
>当然ですが、これにより呪われた靴を利用した裏技は使えなくなります。 
>


>915 名前： ◆qw.Y80Jhqg ：05/01/18 05:23:45 ID:??? 
> >>912 
> >後半になると術しか使用しなくなる 
>術の使用率はある程度操作できます。EF550-64F（256バイト）で術使用率が 
>決められています。各モンスターごとに1バイトずつです。この値が高いほど 
>術法の使用率が高くなります。逆に値を下げれば武器や特殊攻撃を多用する 
>ようになります。 
>
> >>895 
>ディアナを仲間にすることは可能だと思いますが、ディアナ絡みの 
>イベントを希望するのであれば、台詞などをテキストデータにして 
>アップしてもらえないでしょうか（イベント作りは苦手なので）。 
>台詞の容量に制限は（実質的に）ありません。 


>441 名前： ◆qw.Y80Jhqg ：05/01/28 01:22:41 ID:??? 
>ロマサガ1　敵グラフィックについて 
>以前書いた敵グラフィックのヘッダ算出式が間違っていたので訂正 
>画像番号をNとすると 
>8*8画像の場合（N=00-3Fの場合） 
>(N and 3F)*0B+1EB3E8(F33E8) 
>
>16*16画像の場合（N=40-7Fの場合） 
>(N and 3F)*23+1EB6A8(F36A8) 
>
>このアドレスにある値3バイトをリトルエンディアンで読んだアドレスに 
>グラフィックデータがある。 
>
>例：土の精霊（画像番号08） 
>(08 and 3F)*0B+1EB3E8=F3440 
>
>ゴールドドラゴン大（画像番号46） 
>(46 and 3F)*23+1EB6A8=1EB77A 
>
>アドレスヘッダの後に数字が並んでいるが、これは恐らくグラフィックデータの 
>読み取り範囲などを設定していると思われる。 
>
>また、F32E8-F33E7でモンスターごとにグラフィック枠の大きさを指定している 
>（各１バイトずつ）。精霊系は00、リバイアサンは44、ドラゴン（大）は40だった。 
>例えば8*8のグラフィックのモンスターの画像を16*16に変えたいならばその 
>モンスターの枠指定部分をドラゴンなどと同じ40に書き換える必要がある。 
>
>
>モンスターのパレットデータについて 
>ZSNESのステートセーブデータの000069A-00006B7辺りが敵パレットデータ。 
>ただしこれは敵が1体の場合であり、敵が複数の場合はさらに何箇所かあるはず。 
>ROM上のパレットデータはあまり調べていないが、とりあえずグリーンドラ 
>ゴン（大）はA96C2-A96DF(ヘッダなし）。多分モンスター番号順に並んで 
>いる。キャラクターのパレットも周辺にある可能性が高い。 
>パレットデータは32バイトで構成。最初の2バイトは無効。つまり実質的には 
>15色。 


>977 ：gloss ：sage ：2006/07/06(木) 01:44:32 ID:gJoPoJNv 
> >>976 
>乙です。 
>
> >>960 
>イベントコードなどの資料は、rsdataに同梱されているテキストに色々書いてあります。 
>配布は制限無しと書いてあったのでバイナリなにあげておきました。 
>
>コンバータそのものは拡張領域に対応していないので、使えないと思いますが 
>資料は役に立つと思います。 
>
>talk_info.txtに書いていない分 
>40 46 XX :識別番号XXのキャラを仲間に加える(00~16は、控えのデータから復帰。17~はXX-17番の初期データ) 
>40 69 XX :XX番目のキャラを仲間から外す 
>
>

>987 ：gloss ：sage ：2006/07/08(土) 03:09:59 (p)ID:AM3vB0al(2) 
>ナタリー加入パッチに不安要素が見つかりました。 
>
>もしかしたらパブでナタリーを外すと、必要なイベントフラグを破壊してしまうかもしれません。 
>地底で別れたり、デスの生贄に捧げるのも同様です。 
>使用される方は了承の上という事で、お願いします。 
>
>現状では、こうすれば安心という方法が無いのでパッチの修正も不能です。 
>もしそうなってしまった場合は、外す前のデータからパブではなくチートなどでナタリーを外してください。 
>もっとも、不具合が出る可能性は低い気がします。 
>
>
>以下はロマサガ1の改造に興味がある人向けに。あまり役立つような情報では無いですが。 
>
>パブで仲間を外す際に呼ばれる[1E 24](code1Eの24番)。 
>これはフラグ"40 + 外すキャラの識別番号"にCをセットする処理です。 
>(補足：「外すキャラ」とは、「直前の選択肢の選択番号」番目の仲間ではないかと推測します。) 
>(補足：識別番号は、構造体の「RS1_キャラ性能」などのキャラの並び順どおりに00から。) 
>
>アルベルト(識別00/フラグ40)からブラウ(識別0F/フラグ4F)までは、実際にキャラの居場所管理に 
>使われているので問題ないですが、直後のフラグ50から別のイベントフラグとして使用されています。 
>
>ナタリーは(識別16/フラグ56)。 
>talk_data.txtを見る限りフラグ56は使用されていないのですが、code1Eなどからもフラグが操作される 
>可能性があるので安全とは言い切れないですね。 
>
>ついでにナイトハルト、ジャン、テオドール、ラファエルもブラウより後なんで、 
>パブ等で外すのは危険かもしれません。 


>988 ：gloss ：sage ：2006/07/08(土) 03:14:37 (p)ID:AM3vB0al(2) 
>余談。 
>[1E 24]は内部で[1E 27]に処理を引き継ぎます。 
>cod1E_info.txtでは、27番の処理を地底と冥府での離脱としていますが実際の離脱処理は[40 69 01]です。 
>
>[1E 27]は、b@13F1の値をb@13B7番目の仲間の居場所フラグ(40 + 識別番号)に設定する処理みたいです。 
>地底ではb@13F1にC(パブで別れる時と同じ)を入れているのに対し、 
>冥府ではD(ガラハド殺害時と同じ)を入れています。 
>
>居場所フラグの値は、こんな感じです。 
>0=北エスタミル　1=難破船の辺り　4=ウロ　5=クリスタルシティ　6=ローバーン 
>7=ブルエーレ　9=南エスタミル　A=ノースポイント　B=アルツール 
>C=どこにも居ない　D=死亡　E=仲間　F=主人公？ 
>
>とはいえ、本来出現しない場所に設定してもシンボルが配置されていないので現れる事は無いです。 
>ガラハドが出現する時期にパブから居なくなるキャラがいるのは、時間経過でBが設定されているためですね。 
>
>
>もう一つ余談。 
>パブに現れる仲間は特殊な処理で表示、非表示を切り替えているようです。 
>通常、マップシンボルはフラグ番号の値がX~Yだったら表示するようになっていますが、 
>パブの仲間は0~Fと、常に表示されるように設定されています。 
>
>フラグ番号を他のキャラに変えても無意味だったり、 
>条件を変えて非表示にすると他のシンボルの配置が滅茶苦茶になってしまったりと 
>思い通りには動いてくれません。 
>
>以上のことから、単純にシンボルの定義順でキャラを判別している気がするので 
>パブのデータを弄る時は、仲間キャラはそっとしておくしかないですかね。 
>
>仲間と同様の処理は、条件指定だけで出来ると思うんですが 
>何故、こんな仕組みにしたのか謎です。 


>989 ：名無しさん＠お腹いっぱい。 ：sage ：2006/07/08(土) 07:53:01 ID:PNVrZb58 
>おお！ロマサガ1の解析すごいですね。 
>
>ロマサガ1自体がバグの多いゲームだし、 
>特殊なキャラをパブで外すとイベントフラグがおかしくなるっていうのは 
>RS1オリジナルの頃からの症例っぽいですね。 
>
>gloss氏の言う通り、以前ジャン連れ回しという技を 
>使ってジャンを連れ回したことがあったのですが 
>その後パブでジャンを外したら色々とイベントフラグがおかしくなりました。 
>たしかメルビル下水の盗賊アジトに、 
>ジャンを外した時点で(序盤なのに)フラグが立って入れるようになったりとしました。 


>25 ：gloss ：sage ：2006/07/10(月) 03:20:26 ID:6W+WL/Ig 
> >>24 12さん 
>これだけ解析が進んでいたのにガラハド＆シェラハ戦パッチ以降、続かなかったのが勿体無いですね。 
>
> >ディアナのシンボル 
>アルベルト(フラグ40)が主人公、仲間以外のとき(0~D)表示するということですが 
>この条件設定の仕方だとアルベルトとディアナ両方いない時と設定するのは難しいですね。 
>
>フラグを48に置き換えると、アルベルトと鉢合わせ。 
>全く別にディアナの出現を管理するフラグを設けたとしても、 
>仲間に入れるときは、まだいいですが、外す時にまで別途フラグをオフにする処理を入れるのは大変です。 
>
>複雑な条件を指定してシンボルを配置出来るのが理想なんですが。 
>
> >コンバータで〜 
>#03FFの最初の処理2つは、マップにコパー峠を表示するフラグですね。 
>コンバータに通すと次に処理コード[04]と出ますが 
>恐らく[04 1A]で[会話イベント041Aに移行]なんじゃないでしょうか。 
>
>会話データの範囲は、次の会話データの一つ手前のアドレスまでですが 
>#041Fは、次の#0420が0000なんで区切りのいい表示にはならないと思います。 


>31 ：名無しさん＠お腹いっぱい。 ：sage ：2006/07/11(火) 01:27:35 ID:u0wx7GuT 
> >>gloss氏 
>なるほど、#4200は読めなくても特に問題はないのかもしれないですね。 
>処理コードのことですけど、ソースをみるとline211で{0,TALK_ERROR},/* 0x04 */と、 
>頭が04XXだとエラーをはきだすっぽいですね。ここを{1,TALK_JUMP},にすると 
>普通に飛ぶっぽいです。 
>
> >>29 
>自分もちょうど時間経過について過去ログみてたので、４スレめからのコピペですけど、 
>
>また、いわゆる最終時間経過についてもある程度原因が推測できる。 
>最終時間経過が起こるのは10000戦闘前後と言われるが、上記の 
>時間経過処理の最終段階（戦闘回数1040回）の後、0F　27が 
>延々と続いている。0F　27をリトルエンディアンで読むと 
>270F。10進法に直すと9999。つまり戦闘回数が9999回以上で 
>時間経過ポイントを通過すると、上記の戦闘回数設定領域の 
>下にある0F　27をプログラムが時間経過基準戦闘回数と誤認識 
>し、おかしなことがおこると考えられる。 
>
>そこで、この時間経過処理基準戦闘回数の設定表自体を別の領域に 
>移し、理論上の限界値である戦闘回数65535回までフォローした表を作成する。 
>ガラハドパッチでは1F8000-81FFに戦闘回数表を移している。 
>ただ、時間経過処理では内部で段階をカウントしており、最大でもFF（=255段階） 
>までしか設定できないので、それに留意して表を作る必要がある。ガラハドパッチ 
>での1040回以降での時間経過処理基準が256戦闘ごとになっているのには 
>そういった理由がある。自分でやる場合、移す場所は1FFFFFまでのどこかに 
>したほうがよい。それ以降はメモリのミラーの関係でお勧めしない。 
>
>のようです。 
>シンボルの関係でシェラハの位置がつかめなかったので、 
>シェラハ追加パッチは難しそうですけど、デスはいけそうですね。 
>まだ作ってないので、妄想ですけど。 
>


>44 ：gloss ：sage ：2006/07/13(木) 00:47:01 ID:GqZympYE 
> >>31 
>処理コード04は、オリジナルに出てこないため不明だったわけですね。 
>
>
>ロマサガ1において、戦闘中の術によるHP回復量が多すぎるバグを修正してみました。 
>原因は次の箇所です。 
>
>E9E7A:load w@13EB <- {temp ?<- w@[w@1398] *<- 05} 
>
>w@1398は体力のアドレス。 
>読み出す際、体力は本来1byteなのに2byte扱いしているため、 
>隣の器用さが含まれてしまっています。 
>1byteにしてあげれば正常な回復量になります。次の箇所を書き換えてください。 
>
>E9E7C: 
>74 
>
>ついでに回復術の計算に使い道の無い愛を使用してみます。 
>(術者の愛 + 法力 - 術者の愛 * 法力 / 128) * 術性能 + 対象の体力 * 5 + 乱数[0~術者の愛] 
>
>E9E81: 
>05 09 C5 00 B6 12 26 1F 
>
>EC509: 
>05 AD CC 20 B4 6C 9A 01 26 C2 80 1F 20 B4 6C 
>9A 03 26 24 B4 1F 20 B4 0C CA 21 B4 1F 06 
>
>EC509からの00が並んでいる領域に知力の代わりに愛を使った計算式を入れています。 
>補助効果などは考慮していません。