-
Notifications
You must be signed in to change notification settings - Fork 100
[OOT/MM] Get enums from game_data part 1
#556
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: main
Are you sure you want to change the base?
Conversation
|
I noticed earlier there's an export bug I have to address |
| bl_options = {"REGISTER", "UNDO"} | ||
|
|
||
| chest_content: EnumProperty(items=game_data.z64.actors.ootEnumChestContent, default="item_heart") | ||
| chest_content: EnumProperty(items=lambda self, context: game_data.z64.get_enum("chest_content"), default=1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work? I thought properties had to have enums which were permanently fixed. What happens if the enum was {A, B, C}, the property was set to B, and then the enum was changed to {D, E, F}? Does the property change to the default value of the new enum? If it keeps the index, what if it was previously C and the enum was changed to {D, E} (out of bounds)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can supply a function to the items to make it fetch the list at runtime, I think in your first example the value would be E since it saves the index (or at least I think it does? I have a small doubt now), I guess that's an issue then but idk why anyone would edit the enum, also the data parser fills the blanks, like say you remove one entry it will add a dummy placeholder to avoid breaking the enum like in your examples (actually it's filling all of the list with the placeholders then it replace them, so you'd have to shrink the length of the enum to cause any issues but same idk why anyone would do that, I never seen a case where someone edits the xml data tbh)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mean if someone edits the XML data but if someone changes the selected game. This could be, import something from OoT, change to MM, export it, or it could be just start Blender in the default scene and change the game. I'm not really worried about correctness, but about Blender not crashing. Anyway just test it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
each game got their own enums, only the operator is common iirc so it should be fine, see get_prop_name and create_game_props (previously initOOTActorProperties) in actor/properties.py
|
found another tiny issue with my test blend, the fade out seq player type enum is acting strange, I have one blank item and nothing makes sense, this PR's enum and the main branch one are literally the same except for the explicit indices and even after adding the necessary stuff for the seq player it's still broken so idk, not a big deal though you just have to set the value again and that's it but yeah idk, not a big issue anyway so I think it's fine (also I don't think a lot of people will be affected by this anyway, at least I hope lol) otherwise I fixed the surface type export issue I found the other day so I think this PR should be ready to merge 💪 |
Reonu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exported a few different things with it, seems fine with the latest fix
This PR moves enum usage to the
game_datamodule, also switches some of the enums to the ones generated from the xml data for the ones that are already present in the xml file, the other ones will be treated in another PRThere's a change in the new actor panel that I don't think will cause issues, basically I moved the generated props to
.oot.XXXfor both games instead of having them directly under.ootActorProperty, there's still changes needed for actors though