Skip to content

Conversation

Dragorn421
Copy link
Contributor

@Dragorn421 Dragorn421 commented Aug 24, 2021

Goal

The goal of this PR is to add a feature to the Object Analyzer: allow importing a ZAPD-compatible XML description of an object file. I am focused on OoT, but it should work with MM too.

Progress

Going by https://github.com/zeldaret/ZAPD/blob/master/docs/zapd_extraction_xml_reference.md
(or the xmls in the oot repo where the above document is wrong)

❌ means "No"
✅ means "Yes"
☑ means "Fallback" (using UnimplementedHolder, displays as raw data / hexadecimal, like a Unknown)

Feature Supported Implemented
<File>: Name Yes but no, see PR comment
<File>: OutName Can be safely ignored
<File>: Segment, BaseAddress, RangeStart, RangeEnd
<File>: Game ?
<Texture>
<Background> No?
<Blob> as UnknownHolder
<DList>
Scene and Room
<Animation>
<PlayerAnimation>
<CurveAnimation>
<LegacyAnimation>
<Skeleton>: Type="Normal" or Type="Flex", and LimbType="Standard"
<Skeleton>: LimbType="Skin"
<Skeleton>: other types or other limb types
<LimbTable> LimbType="Standard"
<LimbTable> other LimbTypes
<Limb> Type="Standard"
<Limb> Type="Skin"
<Limb>: other types
<Symbol> ?
<Collision>
<Scalar>
<Vector> (outside an <Array>)
<Vtx> (outside an <Array>) Only in arrays
<Mtx> Only in arrays
<Cutscene>
<Array> of <Scalar>
<Array> of <Vector>
<Array> of <Vtx>
<Path>

Currently whatever isn't implemented aborts the importing by throwing NotImplementedException. This is not desirable for actual use (we would rather have the importing skip the resource) but meanwhile useful during development.

Implementing what ZAPD supports but Z64Utils doesn't?

Eg: Collision, Cutscene, Path, various limb and skeleton types.

Should I generalize using UnknownHolder for everything that isn't yet implemented, and may never be? I could also create more phony holders that would just inherit UnknownHolder (CollisionHeaderHolder, PathHolder ...).

I since dealt with this with UnimplementedHolder, a generic phony holder.

This holder is meant for data that doesn't have an adequate holder yet
(where the unknown type holder is meant for data which purpose is unknown).
It behaves mostly like the unknown type holder, but also allows setting a
description string that is shown in the entry type column.
Due to issues with Visual Studio Designer I could not add a viewer tab where
it could be allowed to show the description string.
JSON stuff untested.
@Dragorn421
Copy link
Contributor Author

Dragorn421 commented Aug 25, 2021

See 1db6a94 for a temporary solution to allowing importing any kind of data without implementing it in Z64Utils, thoughts?

If you want to try my branch out gameplay_keep should work

https://github.com/zeldaret/oot/blob/master/assets/xml/objects/gameplay_keep.xml

screenshot

@Dragorn421 Dragorn421 changed the base branch from master to dev September 19, 2021 13:30
@Dragorn421 Dragorn421 marked this pull request as ready for review September 19, 2021 13:46
@Dragorn421
Copy link
Contributor Author

Alright I think this is good enough. It should work with most objects I'm pretty sure. Likely not with the ones with unusual limbs/skeletons ("curve", "legacy") (or "lod", "skin" if the xml uses <LimbTable> but only object_human.xml does atm)

If Z64Utils ever gets better scene/room support then this should be revisited to implement the necessary nodes (eg Path, Cutscene, Background). The oot decomp doesn't have any decompiled scene/room anyway at the moment.

Another reason this won't work with scenes/rooms is it currently can't open a xml with several File nodes, because it can't know which one to choose. (see throw new ArgumentException in Z64Object # FromXmlZAPD)
This is due to my changes in the "open object analyzer without a rom" PR, which got rid of passing _fileName to the object analyzer

@Dragorn421
Copy link
Contributor Author

I updated the table in the opening comment with colors (so flashy much wow), if/when you merge this I'll move it to an issue

@Random06457
Copy link
Owner

Nice job! I probably won't have time to look at it this week but I'll try to do what I can to clear up all the PRs the week after.

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