Module gff_compare 

Comparing a rewritten GFF tree against its original. Comparing a GFF tree against the one it was derived from.

A typed view reads a GFF, models some of it, and writes it back. Two questions decide whether that was faithful, and neither can be answered by looking at the view alone:

• Did every field it rewrote keep the value the original had?
• Did it write a label the original never had?

Both are pure tree work: which labels are present, and whether the values under them match. Nothing here knows what a module or a creature is, which is why it sits in this crate rather than above it.

Both the test suite and vanilla-inspector use these. That is the point: if the tool and the tests grew separate implementations, the tool’s verdict would quietly stop meaning what the tests’ verdict means, which is the same parallel-definition drift that has produced real defects here before.

Why a nested struct’s id is not compared

Such a comparison has no subject. A nested struct is reached by label through CResGFF::GetStructFromStruct, which builds its result from the field’s data_or_data_offset, the struct’s index rather than its id, and the whole class hands back a wrapper holding only that index. No caller outside it ever holds a pointer it could read an id from. Of the class’s sixty-four methods exactly one reads a struct’s id, and it is not on any path that resolves a struct by label.

So the value that comparison reported on cannot be read by the code that reaches these structs, and every difference it found was about nothing. Three sat in the output permanently, which trains a reader to skim a guard that is right the rest of the time.

A list element’s id is a different question and a live one: several loaders test it against a per-list constant and silently skip an element that does not match. Nothing here covers that, deliberately – pairing elements between two trees is not a tree question, since the rewrite’s order is the view’s. vanilla-inspector’s validate struct-ids compares them against the schema and against both corpora instead.

The closure is within CResGFF, which is the only GFF parser found across the tracing done so far rather than one proven unique against the whole binary. If a second reader exists, the exposure is writing 0 where vanilla writes something and nothing reads it, which is the risk already taken on CameraList and the two encounter-nested lists.

What this does not decide

Whether a difference is a defect. A view is a projection and is entitled to drop fields, and a label written but absent from every file may be a field the engine omits at its default rather than a wrong label. The caller supplies that judgement; this module supplies the observation.

Structs

AbsenceCensus

How often each path was absent, counted per occurrence rather than per file.

AbsenceRate

How often one path’s reader fallback would fire across a corpus.

CaseVariantGroup

A family of labels that differ only by letter case.

LabelCensus

Which labels a view writes that no file was seen to contain, accumulated over a corpus.

LabelObservation

What a corpus was seen to carry under one label.

LeafPathSplit

One leaf label the view models at some of its corpus paths and not others.

ValueDifference

One field whose value changed between the original and the rewrite.

Enums

InventedLabels

Whether a corpus can decide the invented-label question at all.

SchemaShape

Whether one schema serves one reading of a file or two.

Functions

value_differences

Reports every field the rewrite changed the value of.