Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Add new field type to support dat64 #134

Open
SnosMe opened this issue Oct 2, 2020 · 1 comment
Open

RFC: Add new field type to support dat64 #134

SnosMe opened this issue Oct 2, 2020 · 1 comment

Comments

@SnosMe
Copy link

SnosMe commented Oct 2, 2020

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

if (string.endsWith(field.name, "Keys") && field.type == "ref|list|ulong") {
  field.type = "ref|list|foreignkey"
}

if (string.endsWith(field.name, "Key") && field.type == "ulong") {
  field.type = "foreignkey"
}

Here's example from BaseItemTypes: .dat at top, .dat64 at bottom.

unknown


image

@OmegaK2
Copy link
Owner

OmegaK2 commented Oct 2, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants