-
Notifications
You must be signed in to change notification settings - Fork 8
Import ZAPD XML #50
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
base: dev
Are you sure you want to change the base?
Import ZAPD XML #50
Conversation
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.
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 |
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 If Z64Utils ever gets better scene/room support then this should be revisited to implement the necessary nodes (eg 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 |
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 |
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. |
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)<File>
:Name
<File>
:OutName
<File>
:Segment
,BaseAddress
,RangeStart
,RangeEnd
<File>
:Game
<Texture>
<Background>
<Blob>
UnknownHolder
<DList>
<Animation>
<PlayerAnimation>
<CurveAnimation>
<LegacyAnimation>
<Skeleton>
:Type="Normal"
orType="Flex"
, andLimbType="Standard"
<Skeleton>
:LimbType="Skin"
<Skeleton>
: other types or other limb types<LimbTable>
LimbType="Standard"
<LimbTable>
otherLimbType
s<Limb>
Type="Standard"
<Limb>
Type="Skin"
<Limb>
: other types<Symbol>
<Collision>
<Scalar>
<Vector>
(outside an<Array>
)<Vtx>
(outside an<Array>
)<Mtx>
<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 usingUnknownHolder
for everything that isn't yet implemented, and may never be? I could also create more phony holders that would just inheritUnknownHolder
(CollisionHeaderHolder
,PathHolder
...).I since dealt with this with
UnimplementedHolder
, a generic phony holder.