-
Notifications
You must be signed in to change notification settings - Fork 12
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
BMSSD refactor #226
base: main
Are you sure you want to change the base?
BMSSD refactor #226
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #226 +/- ##
==========================================
+ Coverage 76.33% 76.84% +0.51%
==========================================
Files 78 78
Lines 3782 3874 +92
==========================================
+ Hits 2887 2977 +90
- Misses 895 897 +2 ☔ View full report in Codecov by Sentry. |
@dyceron Whenever this gets merged, someone of us needs to change the |
tests/formats/test_bmssd.py
Outdated
sr_xfail = [ | ||
"maps/levels/c10_samus/s000_surface/s000_surface.bmssd", | ||
"maps/levels/c10_samus/s020_area2/s020_area2.bmssd", | ||
"maps/levels/c10_samus/s050_area5/s050_area5.bmssd", | ||
"maps/levels/c10_samus/s110_surfaceb/s110_surfaceb.bmssd", | ||
] | ||
|
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'm not sure if I like that. Atm we have to parse s010, s030, s070 and s090 for osrr. Luckily, none of them are in this list but this list still means we are able to parse less files compared to before.
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 can look into this further. It's possible that those keys are assets removed from the bmssd, or possibly in another format like bmssa that isn't documented. I can maybe make it store the integers as a new "missing asset" type or remove them when parsing if it doesn't affect stability.
I mostly am looking for feedback on the API changes so it's good to see SR has actual use cases currently.
1664f84
to
6dc9869
Compare
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.
would love if Than can take a look at this and give the OK for MSR purposes
from mercury_engine_data_structures.common_types import CVector3D, StrId, VersionAdapter, make_dict, make_vector | ||
from mercury_engine_data_structures.crc import crc32, crc64 | ||
|
||
TransformStruct = Struct("position" / CVector3D, "rotation" / CVector3D, "scale" / CVector3D) |
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.
honestly, throw this in common_types
and just call it Transform3D
or smth. that way if we want we could optimize it in one place, and I expect it'll have uses in other formats
1: "objects", | ||
2: "lights", | ||
} | ||
|
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.
surely you can use the ItemType
enum for whatever this is doing?
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 realized just now that the way i resolved this (using the enums as dict keys) breaks dumping json through cli. should I make it use strings to prevent this?
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.
Could possibly make it a IntEnum (or a StrEnum which is better for dumping but requires py3.11)
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.
class ItemType(str, Enum)
will do anything you may need StrEnum
for
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.
about that, lmao.
https://tomwojcik.com/posts/2023-01-02/python-311-str-enum-breaking-change
i think IntEnum would still work but eugh, StrEnum would be so much nicer.
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.
ok, so override __format__()
if you need to guarantee specific behavior from it? I don't really see what the problem is
- now uses an adapter to place blocks, objects and lights in hidden keys and puts the objects in the scene group data - rebuilds all but 4 msr files with missing crc values - added function to get a block or light by name - added function to get a scene group - added function to find scene groups an item belongs to - added function to remove an item from a scene group - added function to add an item - added function to remove an item - beeg test function
for more information, see https://pre-commit.ci
- moved scene_groups.item_count calculation into BmssdAdapter.encode - removed lambda from scene_groups.item_count and compiled BMSSD - bmssd test duration -- before: 27.34s, after: 21.36s
- moved TransformStruct to common types as Transform3D - used ItemType enum more consistently - fixed tests to use new ItemType format
9b074f4
to
2d9c803
Compare
- todo: just use strenum after we stop supporting 3.10
screenshot of sample
--dump-to
output. functions should be able to do anything user would want to without requiring manipulatingraw
input.