-
Notifications
You must be signed in to change notification settings - Fork 16
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
First pass at an update to 1.21.2. #95
Conversation
- Make it build against 1.21.2 - Fix broken things - Replace basically all of the boat API
- PillarLogHelper.of methods removed - PillarLogHelper.settings methods added They provide AbstractBlock.Settings instead of PillarLog - Improvements to the testmod
Things I've noticed but don't yet understand:
|
BTW I have Traverse fully updated to use this Terraform version, so if anybody wants that for testing, let me know and I'll push it. |
* | ||
* This method should be called once for each boat type. | ||
* Created items and entities will have identifiers similar to | ||
* {@code id.withSuffixedPath("_boat")} and {@code id.withPrefixedPath("chest_raft/")}. |
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 the item ID be examplemod:mahogany_boat
and the entity type ID be examplemod:boat/mahogany
, then? I assume the second identifier refers to the entity model layer.
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.
Yes. Now that we are doing this entirely the vanilla way, we create an item, entity type, and model layer. For our mods, there is no need to know the identifiers (although they are predictable, as needed to put the assets in the right place). I doubt anybody needs the model layer. I have wondered if others might need either the identifiers or the entity type. If we think folks might need things like these, I could refactor so the getters of TerraformBoatData are exposed in the API.
...m-wood-api-v1/src/main/java/com/terraformersmc/terraform/wood/api/block/PillarLogHelper.java
Outdated
Show resolved
Hide resolved
...m-wood-api-v1/src/main/java/com/terraformersmc/terraform/wood/api/block/PillarLogHelper.java
Outdated
Show resolved
Hide resolved
...m-wood-api-v1/src/main/java/com/terraformersmc/terraform/wood/api/block/PillarLogHelper.java
Outdated
Show resolved
Hide resolved
...m-wood-api-v1/src/main/java/com/terraformersmc/terraform/wood/api/block/PillarLogHelper.java
Outdated
Show resolved
Hide resolved
I was trying to keep them short, but I didn't really like the names either, so I'm fine with this. Co-authored-by: haykam821 <[email protected]>
This is fixed now in 1248758. |
This is the nice clean way I wanted to do but can't because somebody decided the DFU should init before mods do...
This is the icky version I hate to have to make, but the DFU initializes way too early to do this in any nice way...
OK, I think the API is fine; perhaps things could have better names but we can always fix that in 1.21.4 or whatever. If we do want to improve this in 1.21.2/3, it would be via API additions or internal changes, which shouldn't be disruptive. I'll release this as |
This PR makes the API generally work from my testing so far. The boat API is completely replaced under the hood, but the API interfaces are similar to before. The main change is treating all boat and raft types of a single wood type as a group. API calls use the group's Identifier and the API becomes the authoritative source of other identifiers. Maybe some people won't like this; I think it is worth the convenience and simplicity. One reasonable question is whether TerraformBoatData should be part of the API.