月: 2023年2月

MakingLookUpの呼び出し：現行ではNameNarabekaeではMLUは実行されていない．新規ファイルの場合はCOUPLING::OpenFamilyBaseで実行している．通常は，InitLinkTableで一度だけ実行される．CommandEndでTopologicalSortの直前に実行されるMLUは暫定的に停めてある．CommandEndでTOPOLOGY::RebuildCardListを実行している．この中でNameSortが実行されlookupが逆順になっている．lookupを並び替えるのがNameSortの役割であり，それ以外の仕事はない．

NameSortでテーブルに穴が開いている．⇒論理修正した．⇒これで一応穴を塞ぐことはできたが，RebuildCardListでテーブル並び替えを実施する必要はあるだろうか？RebuildCardListでは各種のリストを再構築している．lookupは一覧表の順位に関係するので，つねに同期を取っておくというのが正しいのではないだろうか？であるとすれば，初期オープンの場合もそうする必要があるような気がする．

NameNarabekaeはそれ自身一つのコマンドだが，その中で，BuildNumlistとRebuildCardListを実行している．RebuildCardListの引数でコマンドを渡しているので，NameSortが重複実行されることはないようだが…

▲@23を削除した後，Undoすると一覧表が逆順になる．⇒解決

▲どこかでNAMESORTを初期化している．COUPLING：CloseFamilyBase→ Cleanですべての下位クラスがリセットされるような動作になっている．TREEVIEWがやっているようにdoCleanを上書きして，必要なパラメータを保全するか，ないし，レジストリに退避して再読み込みする必要がある．NAMESORTのパラメータはレジストリで保全しているので，InitLinkTableでMakingLookUpの実行後，SortNameを実行する直前に読み直すことにした．これで上記の一覧表が逆順になったりする現象は解消した．

1. MakingLookUpはInitLinkTableでのみ実行される
2. InitLinkTableではMakingLookUpを実行し，レジストリからNAMESORTのパラメータを取り出した後，NameSortを実行する
3. テーブルソート時のリナンバーは実施しない（基準番号はパーマネント変数として原則として変更されないものとする）
4. 一覧画面では基準番号を表出しない　その代わり形式的な行番号を表示する（レコード中には保持されている）　⇒　現行のまま表示
5. テーブル並び替えはlookupの並び替えとして実装される　lookupの並び替え時には前詰めが実行される

これまではカード番号と呼んできたものが一覧画面の行番号になるとしたら，カード画面に表示される番号はどうなるのだろう？⇒基準番号がユーザから見えないようにするというのは悪いアイディアではないが，カード番号との整合という問題もあり，直ちに実装は難しいような気がする．この点に関しては現行のままとして，しばらく様子を見ることにする．⇒この問題は前々からの懸案事項だったが，ようやく一件落着としてよいと思う．ここで一度バックアップを取っておこう．

世代番号の問題はすでに解決済み．NAMEBOX::getGenerationGapという再帰関数を新設し，TRIBELIST::GetTheEldest，getGenerationGapでは動的に系列ポテンシャルを計算するようになっている．

▲垂直系線の状態がおかしい．YGroup.zelで文字数ないしフォントサイズを変更したら縦系線が伸びてしまうようになった．⇒文字数ではなく，フォントサイズの影響のようだ．文字数など別のパラメータを調整すると正常描画に戻る．⇒フォントサイズを小さい方に変更して，MARGBOX::Drawで(rect.Height() > metrix->geneHeight)のエラーになった．⇒人名枠設定パラメータを操作すれば正しい状態になる．

どうもフローがおかしくなっているようだ．UpdateDiagramもTopologicalSortも掛かってこない．フォントサイズの変更ではトポロジーは変化しないので，UpdateDiagramが

物理世代番号の計算を最終的にクリアしてしまおう．系列ポテンシャルを決定する途中計算で物理世代番号を参照しているというのがそもそもの間違いなのではないか？これを回避するためには，やはり動的に系列ポテンシャルを決定する仕組みが必要なのではないかと思う．系列木は木構造になっていて，その頂点に始系列があるという構成になっているが，最古世代系列は必ずしも始系列とは限らないため多少ややこしい話になっている．この辺りを整理する必要がある．

1. getpotential　potentialを返す
2. GetPotential　系列枠のポテンシャル値（設定すべき値）を取得
3. getPotential　系統（始系列）のポテンシャル値を取得
4. getMax　系列最大物理世代番号取得
5. getMin　系列最小物理世代番号取得
6. getGeneration　系列枠の（最小）常用世代番号
7. DEV2LOG　物理世代番号→論理世代番号
8. LOG2DEV　論理世代番号→物理世代番号
9. DEV2GEN　物理世代番号→常用世代番号
10. GEN2DEV　常用世代番号→物理世代番号
11. MakeTribesPotential　系列を系統に分解し系統ポテンシャル値を設定→使われていない
12. callSetpotential　系列枠のポテンシャル値を設定
13. Setpotential　系列枠のポテンシャル値を設定
14. setPotential　系統ポテンシャルを設定する
15. TRIBELIST::setStartPotential　
16. TRIBELIST::SetAbsolutePotential　絶対世代番号系と物理世代番号系を一致させる

▲子ども一人の結婚枠では結婚枠背景色が描画されていない．→TYW婚は結婚リンクを持たないので，MARGBOX：Drawでは描画されない．

一番の問題はTRIBELIST::GetTheEldestの中でgetFloorを使っている点ではないだろうか？最古世代の検出に物理世代番号を使わない方法を編み出す必要がある．⇒実装した．

▲TRIBELIST::CheckAbsoluteGeneは実行されていない．TRIBEBOX：CheckAbsoluteGeneではsetnodegeneでCARDLINKの絶対世代番号を設定している．つまり，絶対世代番号は確立されていない．⇒絶対世代番号は多重カードクラスタ検定の中で計算されている．この計算には抽象グラフ検証系が必要であるため，暫定的に停止してある．

▲最小反例307.zelで@23のカードを削除してTRIBEBOX::MakeUpTreeのエラーが発生する．同じカードにMakeUpが重複して掛かっている．その後， (nbox->hideflag == HIDE_UNKNOWN)というカードが検出されている．これは，MakeUp重複ノードと同一カードだ．該当ノードは#4213@31で@47の子ども．カードテーブル上では先祖ノードの@35よりも前にある．どうも，ClearTableでリセットされなかったのではないか？という気がする．子どもを３人持っているが，親は@47だけの普通のカードだ．⇒確かに初期化がパスされている．

CARDLINKは#1522だ．このリンク自体が無視されている．ClearTableに入る前にMakingLookupが実行されていない．MakingLookupはCommandEndで実行しているのではなかったろうか？CommandEndでTopologicalSortの直前にMakingLookupを実行するようにして動作するようになったが，カード削除ではlookupでアクセスできなくなるというのはやや不審だ．⇒カードテーブル上の位置は不変だが，lookup->countが減っているのではないだろうか？

初期状態ではlookup[1]の位置に入っている．更新するとlookup[0]になる．つまり，削除されたカードはlookup[0]にあったものだ．どうも，lookupの操作に何かバグがあるのではないだろうか？⇒かなりおかしい．逆順になっている．どこかで並び替えしているのだろうか？

どうも，世代番号の問題をクリアしておかないと先に進めないという状況になってきたので，じっくり，この問題に取り組むことにする．⇒どうも，いま出ている不良ノード対は世代番号とは無関係のようだ．こちらを先に見ておこう．⇒いや，もしかすると関係あるかもしれないノード対は基本世代枠リストで管理するため，物理世代番号が確定していることが必要だ．⇒いや，そのチェックはやっているようだが…

端点一致でsamepointゼロや左端点共有で種別不一致はそれほど致命的な不良という訳ではないが，回復できないという点に問題があるように思われる．これはやはり，後回しの課題なのではないか？⇒RepairCommonEndPointないし，RepairPairBoxが動作していない．これは解決する必要がある．

▲YGroup32.zelを開こうとしたら，MakePairListCleanで無限ループしてしまった．最初に以下のエラーが発生している．SUPPORTSIMPLEGRAPHをオンにしたためだろうか？

確かにそのようだ．オフにしたら描画できた．親子連結線の不良に関係があるかどうか見るためにオンにしたのだが，無関係のようだ．このオプションに関しては後日調べることにして戻しておこう．⇒YGroup.zelで不用な親子連結線が表示されている．これは少し気になるので，見ておきたい．画面右下の連結線はどこにもつながっていない．

この線はYGroupから出ているので，YGroupの子どもと考えられるが，hiddenとcheckcidの間には，printnamaeしかない．printnamaeは一世代下の箱に入っている．YGroupの子どもは13人だ．結婚点の位置もおかしい．⇒縦系図/横系図は，DrawObject.cppのbool reverseAxisで切り替えできる．結婚点などはその切替を行っていないのではないか？本来論理座標は一つであり，描画する側で対処する必要がある．reverseAxisはDrawObject.cppの中でしか参照されていない．

座標軸の変換関数として，reversePoint, reverseRectがある．_CDCというCDCの派生クラスにはこれらを使った描画関数のセットがある．_CDCを経由して描画していれば，間違いないはずだ．他の描画関数はほぼ対応済みと見られるが，Polygonは残ったままとなっていたものと思われる．⇒対処した．これで座標軸の転換は完結したものと見られる．

上記の不明な連結線の出所がわかった．

NAMEBOX::DrawLongTailでCheckYrouteのLDR垂線として描画している．しかし，CheckYrouteのLDRはYGroupの子どもとしてすでに描画されており，CheckYroute自身は実体を持っている．つまり，余分なノード対を持っているように思われる．何か操作しているときに誤って残してしまったのではないだろうか？このノード対は，CheckYroute(2)→ (1)を連結するものだ．本来の(1)→(2)はノーマルに描画されている．このようなノード対が発生していること自体問題だ．段数が2となっている．どうも，LongTailを作り損なっているのではないか？

NAMEBOX::DumpLongTail NAMEBOX::DrawLongTail > #1157 CheckYroute(2)
   1  dum#=1 #1157 CheckYroute(2)
   1  dum#=2 #1169 YRight(2)
   2  dum#=2 #1905 YRight(3)
NAMEBOX::DumpDummyChain NAMEBOX::DrawLongTail
   1  thread        #1157 CheckYroute(2) #1169 YRight(2)
   2  #1913 [結婚枠]：[2] #1905 YRight(3)

長いしっぽの構成を忘れてしまった．確か複合的なものであったような気はするが…YRightはYgroupの子どもであり，CheckYrouteとはつながらないような気がするのだが…⇒なぜ，複合構造になるかというと，LDRは複数のLDRが束ねられる場合があるからだ．確かにYRightはYGroupの子ノードであり，CheckYrouteと共通の親を持っているから，LDR束だ．しかし，YRightは親を２人持っていて，それがCheckYrouteだ．どうもかなりややこしい話になってきた．

出力ではYRightはYgroupの子ども枠の中にLDRはとして入っているように見える．結局，この線分は下図のように引かれなくてはならなかったものと思われる．

従って，描画していることではなく，描画している位置が間違っている，つまり，一世代下がり過ぎということになるのだろう．⇒できた！

かなりノーマルなモードに近づいた．バックアップを取っておこう．⇒TYW2ExtractBoxでは問題なく動作することが確認できたが，RestoreYoungWifeとどこが違うのかをチェックしておく必要がある．このために，関数の参照関係を洗い出そうとしたのだが，関数木の原本が見つからなくなってしまった．いや，その前にYGroup32.zelで出ていた部分図の障害を見ておこう．というか，この図面は相当乱れている．

いや，今度はノーマルに開けた．インストール版でテストしていた．修正の入った版では解決している．

▲YGroup32.zelで「人名枠線を表示する」をオンにしようとして，エラーになった．ResetTooYoungWifeだ．

(topology->TooYoungList->len() != ztywcount) が起きている．

ztywcountは-1で，TooYoungListのデータカウントはゼロだ．どこかで引き過ぎているのだろう．ztywcountはZTYWのカウントでTYWのカウントではない．この辺りで食い違いが生じているのでは？明らかに行き違いがある．TooYoungListに格納されているのはZTYWだけではない．それにしてもおかしいことはおかしいのだが…ztywcountをtywcountに統合するのではなく，別途tywcountをカウントすべきだろう．同様に，SymmetryCountも別途カウントすべきだ．つまり，システムの内部パラメータはつねに，２つの方法でカウントされなくてはならない．言い換えると複式でカウントされなくてはならないというのが原則だ．この考え方は徹底されなくてはならない．

1. 系列枠は個別にTooYoungCount, ZTYWCount, SymmetryCountを管理している　これに対応して大域的にtywcount, ztywcount, symcountを管理するものとする
2. これらのカウントはそれぞれの属性のセット・リセットを行うsetghostbits, resetghostbitsで同期を取るものとする
3. TouYoungList, SymmetryListへの追加，削除のタイミングで上記カウンタとの一致を確認する
4. 系列枠のカウンタを更新した場合にもそれらの合計と一致していることを確認する
5. これらの属性はすべて結婚枠の属性であるとする
6. TOPOLOGY::CountTooYoungWifeという集計関数もある

TopologicalSortの冒頭でTOPOLOGY::ResetExperimentが実行されている．このとき，3つのカウンタがリセットされているが，オブジェクトは温存されているためカウント不一致が発生する．⇒SymmetryList，TooYoungListの廃棄とtywcount，ztywcount，symcountのリセットはClearTableより後に実行することにした．ResetExperimentもそのタイミングでよいのではないだろうか？ただし，genelist, tribeListの初期化はClearTableに先行させる必要がある．

YGroup32.zelでは多重カードが３件出ている．これは削減できないのだろうか？あるいは，どこかで機能劣化してしまった可能性もある．

一番左のYGroup(♀)は祖父のYGroup(♂)の配偶者なので，多重となるのは避けられない．真ん中のCutBranch(♂)は娘のCutBranch(♀)の配偶者なのでやはり不可避だ．CheckYroute(♂)は親を3組持っているが，そのうちの一人は兄弟のCutBranch(♂)なのでやはり，避けられないということのようだ．これは，再帰ないし再入呼び出しを表現するための苦肉の策として取られた手段ではなかったろうか？

ゼルコバの木では血統循環を禁止しているため，婚姻関係を使って擬似的な血統循環を成立させていたのだと思う．⇒関数木では再帰的な呼び出しを，同名の子ノードを作りそれを親ノード（呼び出し先）と配偶させることで擬似的に表現している．再帰呼び出しは必ず血統循環を発生してしまうので，ゼルコバの木では禁止されているが，多重カードになることを許容するのなら，血統循環を許すという設計も（将来的には）考えられなくもない…

関数とその所属するクラスとの関係もある種の木を構成すると考えられるが，関数木ではクラスを部分図で代替している．ゼルコバの木では最大32個までの部分図しか登録できないが，ゼルコバの木の実装ではおおむねそのくらいの数のクラスしか扱わないので，ほぼカバーできるのではないかと思う．⇒部分図自体を一つのオブジェクトとしてその包含関係を明示できれば，部分図木のようなものを構成することも可能となるが，現在の実装では部分図は単純な集合であり，必ずしも順序関係を定義することはできないので，多分実装は難しいと思う．（関係グラフのようなものは構成できるかもしれないが…）

TYWに関係する処理の見直しを進めているところ．基本的には，「moveがゼロのときはZTYWとしない」という方針だが，障害が発生する原因は突き止めておかなくてはならない．また，衝突回数上限を決めるMAXCRUSHCOUNTと処理終了するまでの時間が必ずしも比例するものではないという点に関しても調べる必要がある．現行では，ZTYWに制限を掛けていないため，衝突回数オーバーですべてのTYW婚を解除するAbortAllFloatingBoxが発動しているが，にも関わらず障害が止まらないという問題がある．

このとき，①Yリスト上位ノード不在，②TYW婚の吸収合併成功，③NAMEBOX：CheckUnerasable 結婚枠不在のような事象が大量発生している．従来論理ではAbortAllFloatingBox→ StopTooYoungWife→ TYW2ExtractBoxでTYW→抽出枠転換していたが，現行では暫定的にRestoreYoungWifeを使っている．この理由は，TYW2ExtractBoxでは抽出枠が残存してしまうが，RestoreYoungWifeなら完全に元の状態に復元できると考えたためであるが，どうもどこかに不備があるような感じだ．⇒TYW2ExtractBoxを復活させれば正常動作可能だ．

TYW2ExtractBoxではZTYWの場合は，RestoreErasedYoungWifeが実行される．RestoreErasedYoungWifeではRestoreErasedYoungWifeで消去された仮ノードを取り出して，RetrieveGhostでそれを復活させている．従って，この処理にはぬかりはないと言える．逆にRestoreYoungWifeではそれが不十分な動作になっているように思われる．この辺りは，一度整理してドキュメント化が必要だ．呼び出し関係だけでもチェックしたいのだが，その手始めとして「関数木.zel」を復活させるというのは悪いアイディアではない．どこかにあるはずだ．

デスクトップ 2020-02-11\テストサンプル\関数木グラフというフォルダがあった．ただ，一部関数のコレクションばかりで，全体木のようなものが見当たらない．フォルダ名は2020となっているが，中身は2017～18に作られているようだ．どこかにもっと大きなサンプルがあるはずなのだが…別の場所にもいくつか関数木という名前のファイルはあるが，NONファイルに変換されてしまっていて，名前が短縮されているものしか見当たらない．2018-02-04の記事には「血統循環関係の関数参照木を作って不用関数を整理」とある．

▲デスクトップ 2020-02-11\テストサンプル\関数木グラフ\AccidentalCollisin.zelを開こうとしてエラーになった．

エラーを無視して描画は可能．⇒開発環境ではエラーにはならない．対処済みと思われる．

もっと大きな網羅的な関数木を作っていた記憶があるのだが，残っているのはどれも，特定の処理に関するコレクションばかりだ．もっとも大きなYGroup32.zelでも58点しか入っていない．

▲ YGroup32.zelで部分図 Bobject を選択して，(topology->TooYoungList->len() != ztywcount)で停止．図面もおかしい．カード数6と表示されているが，実際には7点あり，親子連結線もおかしい．⇒いや，カード数は６で正しい．多重カードが出ている．多重カードの解消機能が十分動作していないように見える．

ここでリリース版を起こしておこう．⇒インストールしたが，動作がおかしい．古い版が残ってしまっている．アンインストールして再インストールで正常動作するようになった．

仮修正が少し残っているので，フィックスしておこう．

1. BCMDTABLE::BCMDTABLEの仕様変更：呼び出し時の引数を追加　⇒　現状でフィックス
2. TRIBEBOX::HorizontalSegment：セグメント数=1のとき，CheckMaximalSegmentで再検査→廃止　⇒　フィックス
3. TRIBEBOX::HorizontalSegment：出口でCheckMaximalSegmentの再検査→廃止　⇒　現状でフィックス
4. TRIBEBOX::MinimumContactDistance：すでに検定完了している場合は停止するようになっていた→停止しない　⇒　FIXED
5. TOPOLOGY::ClearTable：MARGBOXの初期化でdataCleanを使う　⇒　FIXED
6. ClearTableでlookupを使う＠20230214　⇒　FIXED

▲COUPLING::TopologicalSortでEraseTreeViewを呼び出さないようにしたところ，系統並び替えを実行しようとして，ClearTable→ NAMEBOX::CLEARで停止した．TRIBELISTのgetstarttribeが空を返している．tribelistはすでに廃棄されているが，基準ノードは始系列の優先ノードなのでSelectBaseBoxで参照が掛かっている．⇒startが空のときは処理をパスするようにした．

これでEraseTreeViewを実行しなくても，処理を継続することができるようになった．ClearTableを止めるのは無理のようだ．現在，系統並び替えでは13.7秒掛かっている．うち，ClearTableの消費時間は407msだ．サンプルBではClearTabledeだけで20秒掛かっている．その後のステージ９：Decomposition，ステージ11:GODOWNSTREAMもかなり掛かる．⇒CheckMaximalSegmentの出口で行っていたCheckMaximalCompactionの再検査を止めてかなり高速化した．それでもサンプルBの系統並び替えでは253秒で４分以上掛かっている．とりあえず，今のところパフォーマンスについてはここまでとしておこう．

◎現在開発機にインストールされているのは，V2.2.2.008 REL 2022-04-26 でカードテーブル上限は8192だが，サンプルAを読み込んでもまったく表示できない．現行バージョンのリリース版を起こしてみよう．

▲リリース版をビルドしようとして，STOPマクロでエラーが出ている．Dump関数をCObject::Dumpと取り違えている．なぜだろう？CObjectはMFCライブラリの基底クラスなので，我々も使ってはいるが… ヘッダはafx.hだ．DrawingObject.hはいつも最後に読み込まれるので，それ自身は他のヘッダをまったく参照していない．_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)という警告が出ている．⇒DrawingObject.hではCDCの派生クラスを定義している．おそらく，この辺りでMFCのクラス定義が持ち込まれているのだろう．

意味がわかった．_CDCはCDCの拡張クラスなのだから，その中から呼び出すとすれば，当然その系統のメンバー関数になる．ということは，当然_CDCの中からNODULEクラスの関数を呼び出すことはできないということだ．しかし，どういう訳かデバッグモードでは動作しているので切り分けておくことにしよう．QUICKDBでもエラーが出ている．コードは変化していないはずなのだが…⇒いや，PickRecordは今回新設した関数だ．_STOPなら使える．

IsAinstanceOfで_mbscmpの代わりにstrcmpを使うようにした．

▲nodule::CheckSansyoCountでSTOP文野中で，Dump「静的でないメンバー関数の呼び出しが正しくありません」エラーになった．⇒CheckSansyoCountは確かに静的関数として宣言されている．⇒_STOPなら問題ないようだ．

▲SetupTitleBox.vb(3274,24): error BC30451: ‘CommandLine’ は宣言されていません。アクセスできない保護レベルになっています。⇒CommandLine As Stringは以前はWindows.vbでpublicとして定義されていたのだが，現在はMDIForm_Loadのローカル変数になっている．UnlockTitleではスプラッシュウィンドウをクローズするための判定に使っているが，UnlockTitleの中でスプラッシュウィンドウを操作するというのはおかしいので，止めておくことにしよう．

なかなかいい感じだ．リリースモードではサンプルAを５秒以内に開くことができる．サンプルBの系統並び替えが55秒だ．悪くないと思う．バージョン番号を更新しておこう．現在のバージョンは2.2.2008だが，2.3まで上げてよいのではないだろうか？⇒インストールに成功した．

▲パッケージにはテーマファイルは入っているが，サンプルがまったく入っていないような気がする．配布パッケージの添付ファイルを置くとしたらドキュメントフォルダがもっとも適していると思われるのだが… どこかの時点で外してしまったのだろう．⇒対処した．

▲タモリさんちの超複雑な家系（拡張版）.zelをアイコンのダブルクリックで開こうとしてエラーになった．標準版のタモリんちは開けたが，横書きだ．

横書きと縦書きをオプションで切り替えられるようにする必要があるが，横書きでも違和感のないレイアウトになっている．ただし，描線にはあちこち問題がありそうだ．というか，現行では結婚線というのをまったく見ていないはず．ルーゴン・マッコール家系図でも同じエラーになった．

それに続いて，以下のようなエラーが出る．

軟体動物も開けたが，それ以外は全滅だ．

この原因として考えられるのは，記録データが取り込まれていないのではないか？という点だ．おそらくタモリんちと軟体動物には記録部への書き込みがまったくないのだろう．実際，コラッツで作ったサンプルは相当大きなものでも問題なく開けている．12146点のサンプルも問題なく開けた．ともかく，ここから再出発するしかない．

「ユーザの個人用データフォルダ」というのに格納するようにしたら，ドキュメントに入るようになった．バラバラで入れるのも何なので，「ゼルコバの木系図ファイル」というフォルダを作ってそこに入れるようにした．この問題は，まず，これで解決だ．

KAKEIZU::getcarddataでエラーが出ている．item[27]が空になっている．撮影日付だ．この部分は，QUICKDB::pickrecordを廃止して，PickRecordを新設しているが，論理は基本的に変わっていないはずなのだが…つまり，データが存在しない場合には空のままとしていたはずなのだが…実際の個別データはquickfile(“TAKE:8”)で取り出していたので，必ずポインタを渡すようになっていたのかもしれない．実行関数はquicktakeだ．以前は一件ごとにrespbuffというところを使って受け渡ししていたので，ポインタが空ということは発生する余地がなかったのだが…データがないときは空文字列を指すポインタを渡すというのでもよいが，それも煩わしい気がする．ポインタが空のときは無動作とするというのが早いのではないだろうか？文字列関数でエラーを出さないようにするということも考えられるが…

▲天皇家系図でエラーが出た．

MergeUpperSegmentでエラーが出ている．(head == mbox && mbox->realsons && !mbox->getCritical(FATALSTARTEND｜NOGOODSONEXIST) && mbox->NextSibling()) のような条件でmakeGoodSonを呼び出してgoodsonが特定された場合に停止するようになっている．停止しないようにして描画できた．那須記も描画できたが，かなりおかしなことになっている．

添付ファイルは一通り開けることだけは確認できたが，かなり悲惨なことになっている．一番惨めなのは源氏かもしれない．一見して相当緩くなってしまっている．これを締め直すのはかなり大変そうだ．もっとひどいのは，Ancestry.zelだ．これはほぼ壊滅と言ってよい．とりあえず，読み込むことができたというだけでもよしとするしかない．

「結婚連結線をサポートしない＠20220228」と「MakePairListCleanを一時止める＠20220215」を止めてかなりまともな図面が出てきた．連結線がところどころ切れているのと，ゴミ粒のようなものが散らばっているのを除くと，ほぼまともな図面に戻ったと言ってよい．

▲天皇家でかなりひどいスプリットが出ている．

▲53直系血族図.ZELを開いて，TRIBEBOX::SolveMargboxCollisionで衝突検定ループカウントオーバーが起きている．986個のTYW婚を廃棄したとしているが，衝突は収まらない．「コラッツ特注版ではTYW婚不用＠20211217」を復活させたら収まった．