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

Dependent objects have misleading viewmodel/information #140

Open
LeftofZen opened this issue Nov 24, 2024 · 0 comments
Open

Dependent objects have misleading viewmodel/information #140

LeftofZen opened this issue Nov 24, 2024 · 0 comments
Labels

Comments

@LeftofZen
Copy link
Collaborator

LeftofZen commented Nov 24, 2024

When objects have dependent objects, like TTRAIL2, the CompatibleVehicles property will show this dependency. However CS has made a mistake-in-process with vanilla objects.

For example:
Image

Of course TTRAIL2 is not a Custom object, it is a Vanilla one. But the way vanilla objects are listed here is that only the Name and ObjectType (as part of Flags) are filled in, and every other value is defaulted to 0, ie Checksum and the SourceGame part of Flags. Unfortunately an oversight in the DAT format/values means that the default value of 0 means Custom object type, not Vanilla. So in this screenshot, the UI is correctly displaying the value of Custom, ie 0, because that's what the DAT file actually contains.

In lieu of a new object format, we will need to unfortunately add some manual correction when reading these dependent-object fields in SawyerStreamReader.LoadVariableCountS5Headers() so that the value is changed to 2 (which is Vanilla) and then again written back to 0 when the object is saved.

We also need to be careful about when true Custom objects are linked - these will have a Checksum set.

@LeftofZen LeftofZen added the ui label Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant