Soul Data (for soul bound machines and items) #119
No reviewers
Labels
No labels
Area-Assets
Area-Backend
Area-Conduits
Area-Datapacks
Area-Lang
Area-Mod Compat
Area-Parity
Area-Rendering
Good first issue
MC-1.19.2
MC-1.20.1
MC-1.20.4
MC-1.20.6
MC-1.21
MC-1.21.1
Modtoberfest
P-0-High
P-1-Medium
P-2-Low
Status-Awaiting Response
Status-Behind-Flag
Status-Blocked
Status-Cannot Reproduce
Status-Duplicate
Status-Help Wanted
Status-Incomplete Report
Status-Invalid
Status-Needs LTS Backport
Status-Needs Updating
Status-Stale
Status-To Implement
Status-Triage
Status-Wontfix
Status-Wontmerge
Type-Backport
Type-Bug
Type-Documentation
Type-Enhancement
Type-Question
Type-RFC
Type-Suggestion
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Team-EnderIO/EnderIO#119
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "soul-config"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Adds a json codec based system, similar to recipes. It collects them as a map of the entitytype and a record of the wanted data. It contains an example using the powered spawner.
Todo
Checklist:
Looks like a solid proposal thusfar, just noting my comments for you. Nice work!
@ -39,2 +49,4 @@@Overridepublic void tick() {if (entityType == null) {complete = true;Might be a good idea to just store the soul datum rather than storing each field separately. Might be a neat way of doing it :)
Ensure that if this is the case, the machine doesn't softlock due to the job not concluding.
@ -141,4 +184,4 @@blockEntity.setReason(PoweredSpawnerBlockEntity.SpawnerBlockedReason.UNKOWN_MOB);break;}I would argue that only living entities should be targetable. If there is any kind of exception discovered later, we can go for adding in additional cases.
What would the case be for removing this? If I'm thinking about this correctly, this check will have to remain as the soul vial will not be using soul data, right?
No, but I did add a blacklist tag for the soul vials as well, since I also added one for the spawner. That way other mobs can be blacklisted using the tag so this check isn't needed. There also is a bosses tag now to replace this method I think?
@ -141,4 +184,4 @@blockEntity.setReason(PoweredSpawnerBlockEntity.SpawnerBlockedReason.UNKOWN_MOB);break;}Yeah I agree
Oh good catch!
Wait; so there's a tag to define what mobs are bosses/blacklisted and we check that now? If so then thats perfectly fine :)
Yes forge added that tag some time back. I made a blacklist tag that has the forge bosses tag inside of it. So for the soul vials and spawners, both have a single tag (which has bosses as well).
@ -39,2 +49,4 @@@Overridepublic void tick() {if (entityType == null) {complete = true;I'm not a 100% sure on this, I found this cleaner but that's just preference
would simply setting completed as true be enough here? That should end the task.
Yeah set completed to true to end the task
Just a couple of pieces; nice work!
@ -137,16 +180,18 @@ public class SpawnTask extends PoweredTask{}}Why is this commented? what is the purpose of the commented logic?
Could you change this to EntityTypes to match EntityType :)
@ -137,16 +180,18 @@ public class SpawnTask extends PoweredTask{}}Oh good catch! That shouldn't be updated, but forge made changes and I didn't get it to compile without removing it.
I'm happy with how this looks, thanks!!