nextclass == nextobjoffset tho
it starts to read the animationmanager but then the nextobjoffset goes nuts
An error can sometimes manifest later than where it was caused.
its just weird how the lvlfile.tell is incorrect but the others arent

You only changed in the CloneManager, right?
well of course i also added new chunks that the hook requires but that worked perfectly fine before i wrote the clonemanager code
I already told that that it might be because two arrays require to have the same element count
well i can double check of course
but normally both get adjusted
and i didnt find anything else i would neet to adjust too
```C++
void CCloneManager::deserialize(KEnvironment * kenv, File * file, size_t length)
{
uint32_t start = file->tell();
_numClones = file->readUint32();
if (_numClones == 0)
return;
_unk1 = file->readUint32();
_unk2 = file->readUint32();
_unk3 = file->readUint32();
_unk4 = file->readUint32();
_clones.reserve(_numClones);
for (uint32_t i = 0; i < _numClones; i++)
_clones.push_back(kenv->readObjRef(file));
rwCheckHeader(file, 0x22);
_teamDict.deserialize(file);
printf("Team at %X\n", file->tell() - start);
rwCheckHeader(file, 0x1C);
_team.deserialize(file);
flinfos.reserve(_numClones);
for (uint32_t i = 0; i < _numClones; i++) {
std::array arr;
for (float &f : arr)
f = file->readFloat();
flinfos.push_back(std::move(arr));
}
}```
As you can see, _numClones is used for both the **_clones** and **flinfos** vectors
```C++
void CCloneManager::serialize(KEnvironment * kenv, File * file)
{
printf("CCloneManager at %08X\n", file->tell());
file->writeUint32(_numClones);
if (_numClones == 0)
return;
file->writeUint32(_unk1);
file->writeUint32(_unk2);
file->writeUint32(_unk3);
file->writeUint32(_unk4);
for (auto &clone : _clones)
kenv->writeObjRef(file, clone);
_teamDict.serialize(file);
_team.serialize(file);
for (auto &fli : flinfos) {
for (float &f : fli)
file->writeFloat(f);
}
}```
It's a bit kinda unfortunate, but in the serialization, it doesn't use _numClones when serialization the _clones and flinfos vector, instead it uses the vector's actual sizes
So if it happens that flinfos.size() is 6 , but _clones.size() and _numClones is 5, then it will write all 5 elements from _clones and 6 elements from flinfos
But problem is, when reading the clonemanager, _numClones is used for both reading _clones and flinfos, so it read 5 in _clones and 5 flinfos, but will forget to read the 6th element in flinfos, so at the end of reading CloneManager, the file.tell() will report an offset lower than the expected end offset.
wow i completely overlooked that flinfos!
but the question is what would push_back to the flinfos vector?

Just look at what actual values were used for the existing ones.