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

Allow displaying age/page and object IDs in Object Browser tree #78

Closed
wants to merge 9 commits into from

Conversation

dgelessus
Copy link
Contributor

We already have an option to display the type IDs next to the class names. This PR adds similar options for displaying the age/page IDs next to page names and object IDs next to object names. For example:

Screenshot of Tools menu and Object Browser with age/page, type, and object IDs shown

This also refactors QPlasmaTreeItem a bit so that the items are properly sorted numerically by their ID (when shown). Previously, the sorting was lexicographic based on the displayed text, which doesn't work for variable-length numbers (e. g. 1, 2, 10 was sorted as 1 < 10 < 2).

One thing I'm not sure about: I remember something about libHSPlasma automatically changing object IDs in some cases. I don't know if the displayed object IDs might sometimes be inaccurate because of that...

@dpogue
Copy link
Member

dpogue commented Mar 2, 2024

One thing to definitely be aware of here is that not all versions of the engine have object IDs (in particular, older versions of Uru), and libHSPlasma will invent numbers in that case based on the order that objects are opened. That's generally fine because those numbers never get written back, because they don't exist in the data for that engine version.

We've had so many changes to attempt to fix object ID issues in MOUL data that I can't say for sure what the current behaviour is. I believe the default behaviour is to re-assign all the object IDs when reading in a file, but there's an option to make it preserve IDs (which will cause problems if you ever add or remove objects)

@dgelessus
Copy link
Contributor Author

Ah, that's good to know - I wasn't aware that old Uru didn't use object IDs. I assumed that they always existed, because plKey in the PRCs always has an ObjID attribute. But I guess for old Uru data, those are auto-assigned by libHSPlasma, as you say.

I suppose we could hide the object IDs for data from Plasma versions that don't actually use object IDs? Or if the object IDs aren't meaningful at all in PRPShop because libHSPlasma reassigns them on load, then I can remove that part again.

@dgelessus
Copy link
Contributor Author

dgelessus commented Mar 2, 2024

Yeah, it seems that the object IDs are indeed always assigned sequentially by libHSPlasma - presumably in the order that the objects appear in the .prp files. If I manually add fResMgr.setPreserveObjIDs(true);, I can see non-sequential IDs for certain .prp files (e. g. BahroCave_District_Textures.prp or Gira_District_Textures.prp from moul-assets).

So it seems that displaying object IDs is only useful in a configuration that PrpShop doesn't actually support at the moment 🙁 It would be nice if PrpShop supported enabling setPreserveObjIDs from the GUI, so that we could use PrpShop to examine object ID problems. But I assume that would require a larger change to ensure that you can't get libHSPlasma into an unexpected state, because apparently adding/removing/changing keys isn't supported with setPreserveObjIDs enabled.

@dgelessus
Copy link
Contributor Author

I'll set this to draft for now, because displaying object IDs doesn't make sense with the current behavior of PlasmaShop/libHSPlasma. Will probably re-submit the age/page ID display as its own PR, because that part works fine and applies to all Plasma versions.

@dgelessus
Copy link
Contributor Author

Superseded by #84.

@dgelessus dgelessus closed this Mar 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants