energy storage or something #198
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#198
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/cap-banks"
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
Added Capacitor Banks. Connected Textures are done using the Athena mod
Checklist:
This closes #177
Most of this goes over my head tbh, but seems sensible.
Don't worry about the NBT stuff until #165 is merged.
@ -27,2 +27,2 @@case WEST -> renderFace(pose, normal, consumer, texture, color, 1.0f - z, 1.0f - z, y + h, y, x, x + w, x + w, x, x, x + w, y, y + h);case EAST -> renderFace(pose, normal, consumer, texture, color, z, z, y, y + h, x, x + w, x + w, x, x + w, x, y + h, y);case DOWN -> renderFace(pose, normal, consumer, texture, color, light, x, x + w, 1.0f - z, 1.0f - z, y, y, y + h, y + h, x, x + w, y, y + h);case UP -> renderFace(pose, normal, consumer, texture, color, light, x, x + w, z, z, y + h, y + h, y, y, x, x + w, y, y + h);Is it possible for us to document this better for future, now that (i hope) you understand whats goin on :P
This should possibly be above addProvider
@ -0,0 +66,4 @@}int length = 1;//some random limitwhile(length < 16) {What is this limit?
@ -0,0 +99,4 @@}}}private static void renderIO(CapacitorBankBlockEntity capacitorBank, PoseStack poseStack, MultiBufferSource bufferSource, Direction facing) {I am going to trust that this works 😂
@ -0,0 +1,332 @@package com.enderio.machines.common.blockentity.capacitorbank;Depending on merge order, you may have to convert these to use constants, like the approach in #165
@ -0,0 +29,4 @@return new BlockEntityEnergyStorage(stack, ((CapacitorBankBlock)getBlock()).getTier().getStorageCapacity());}private static class BlockEntityEnergyStorage implements IEnergyStorage, ICapabilityProvider {Why does this need a capability? If it is necessary then maybe we should be giving this to all of our powered blocks?
@ -0,0 +71,4 @@}public void setEnergyStored(int stored) {CompoundTag nbt = container.getOrCreateTag();Same here; will need to use NBT constants
A quick look, will give it a second pass later on.
@ -0,0 +1,318 @@package com.enderio.machines.client.rendering.blockentity;very minor, but is it needed to recreate this array every time?
@ -0,0 +66,4 @@}int length = 1;//some random limitwhile(length < 16) {I think how many screens/bars can connect to each other?
@ -0,0 +29,4 @@return new BlockEntityEnergyStorage(stack, ((CapacitorBankBlock)getBlock()).getTier().getStorageCapacity());}private static class BlockEntityEnergyStorage implements IEnergyStorage, ICapabilityProvider {I have made an itemstack energy capability, but that one does not store it in the block entity tag (we could maybe change that, but I'm not sure that is needed). The reason this one is different, is because our machines don't expose the energy when they are in item form, while the powerbanks due.
@ -0,0 +29,4 @@return new BlockEntityEnergyStorage(stack, ((CapacitorBankBlock)getBlock()).getTier().getStorageCapacity());}private static class BlockEntityEnergyStorage implements IEnergyStorage, ICapabilityProvider {Yeah I mean it'd be nice to break this out into its own class
@ -0,0 +1,318 @@package com.enderio.machines.client.rendering.blockentity;Could use Direction.valuees()
@ -27,2 +27,2 @@case WEST -> renderFace(pose, normal, consumer, texture, color, 1.0f - z, 1.0f - z, y + h, y, x, x + w, x + w, x, x, x + w, y, y + h);case EAST -> renderFace(pose, normal, consumer, texture, color, z, z, y, y + h, x, x + w, x + w, x, x + w, x, y + h, y);case DOWN -> renderFace(pose, normal, consumer, texture, color, light, x, x + w, 1.0f - z, 1.0f - z, y, y, y + h, y + h, x, x + w, y, y + h);case UP -> renderFace(pose, normal, consumer, texture, color, light, x, x + w, z, z, y + h, y + h, y, y, x, x + w, y, y + h);there is still the problem of horizontal flipping of textures (I've flipped the textures again to counteract this)
the biggest problem is, that there is just a lot of things going on and I'm not sure how to make it that much better
@ -0,0 +66,4 @@}int length = 1;//some random limitwhile(length < 16) {yeah, basically, I don't want the BER to be as computationally expensive and as the energy bar is rendered from the topmost one, I would have to make the BlockEntity Render Box larger and larger which would just cost more on the rendering side. I thought that 16 blocks is a reasonable limit
@ -0,0 +1,318 @@package com.enderio.machines.client.rendering.blockentity;no, that would include Up and down which would just be annoying later down the line to deal with. I'll create a static array having only those 4 in them
@ -0,0 +99,4 @@}}}private static void renderIO(CapacitorBankBlockEntity capacitorBank, PoseStack poseStack, MultiBufferSource bufferSource, Direction facing) {thanks
@ -0,0 +29,4 @@return new BlockEntityEnergyStorage(stack, ((CapacitorBankBlock)getBlock()).getTier().getStorageCapacity());}private static class BlockEntityEnergyStorage implements IEnergyStorage, ICapabilityProvider {I would do that once we have the requirement, not now