Asterix Gaming Guild Logo GeneralXXLXXL 2XXL 3XXXLOlympic GamesXXL EditorToolsOff-TopicXXL RomasteredXXL 2 RemasteredOther GamesModsCaesar's ChallengeUnfair XXLPatchesFan ArtPersonal ArtSpeedrunningMediaRandomizerBETA RomeHSKALPresence AdrienPresence SPQRSupport Bot Helpdesk

#editor

adrientd
In the editor code, CMaterial starts with an object reference to the Geometry
adrientd
So that means Alice (or maybe Spyro?) added a new byte at the beginning of CMaterial just before the geometry.
pegperegogaucho
Sounds like the solution
deathhound246
Could it be that it's also just part of the kobjref but just goes unused?
pegperegogaucho
Probably not
deathhound246
why not?
adrientd
I don't think kobjref has ever changed since like XXL2
deathhound246
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
deathhound246
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
adrientd
The best would be to look at the deserialiation method of CMaterial in the disassembly of the game.
adrientd
Then compare with what is currently done in the editor and check for differences.
deathhound246
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
adrientd
I believe the deserialization for CMaterial in Alice is at 0x4744E0
deathhound246
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
adrientd
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:
deathhound246
cus of that im not convinced this is a serialization related function
deathhound246
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?
adrientd
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
adrientd
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).
adrientd
CMaterial is already at the top.