In the editor code, CMaterial starts with an object reference to the Geometry
So that means Alice (or maybe Spyro?) added a new byte at the beginning of CMaterial just before the geometry.
Could it be that it's also just part of the kobjref but just goes unused?
I don't think kobjref has ever changed since like XXL2
ok yea, i've added a reflect for the first byte, and it's reading the kobjref fine, but it's crashing now at the AOG float
and if i add another check to that so its not reading that for alice, it instead crashes at flags, presumably a different object since the previous one didnt have all bytes read?
i have noticed these objects are a strange size sometimes. like they aren't aligned seemingly at all
The best would be to look at the deserialiation method of CMaterial in the disassembly of the game.
Then compare with what is currently done in the editor and check for differences.
I'm looking through all of the classes methods here. I know Ghidra isn't the best tool, but I don't think serializing/deserializing is done the same. Like I'm not seeing any calls that look like parent class calls in the functions that *should* be serialize/deserialize
I just have a feeling it's going to be done through a more "global" class or function
I believe the deserialization for CMaterial in Alice is at 0x4744E0
seems to only be for the RTTI build, and im not sure if its src code was a match with the steam build
even still, i'd expect to see a function call passing all of 0x4744E0's params, yknow like a super class call
Reads are done by calling virtual methods on a file class, so in the disassembly it looks like calling some function pointer from a table:
cus of that im not convinced this is a serialization related function
would it not know the parent function's address now though? from the wii binary i'm used to seeing direct function calls since those addresses are known. saying this, it's probably a different compiler used, so maybe just a quirk of that?
and for references, usually there is an if condition that will, depending on some variable, call the usual read function with 4 bytes, or another function that will properly decode the reference
The deserialization function of a class may call the superclass's deserialization function, but not always, especially if the class is already at the top of the hierarchy and/or doesn't really have a superclass (or the superclass doesn't serialize anything).
CMaterial is already at the top.