You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, foreign keys are treated as ulong. While it seems to work on .dat, the correct type of field is (ptr_size + ptr_size).
The first pointer is an actual row index in foreign dat file, the second pointer is always NULL.
I propose to add new field type foreignkey (or genericgeneric).
Specification can be auto updated thanks to the naming conventions
Yeah, that's something I wanted to do for a while, though I've not considered supporting the 64 bit files a priority. I'm not really happy with ref|generic right now - I was thinking of renaming the stuff to ref|key and ref|foreignkey respectively
size_t can't be used in python while unpacking because that's based on the interpreter, not the file. So, effectively I still have to use 32/64 bit integers depending on the target file.
Currently, foreign keys are treated as
ulong
. While it seems to work on .dat, the correct type of field is(ptr_size + ptr_size)
.The first pointer is an actual row index in foreign dat file, the second pointer is always NULL.
I propose to add new field type
foreignkey
(orgenericgeneric
).Specification can be auto updated thanks to the naming conventions
Here's example from
BaseItemTypes
: .dat at top, .dat64 at bottom.The text was updated successfully, but these errors were encountered: