Team-EnderIO/EnderIO
1
0
Fork 0
Code Issues 114 Pull requests 13 Projects Releases 79 Packages Wiki Activity Actions

Aversion Obelisk backport to 1.20.1 #777

Merged
krxdev-kaan merged 16 commits from lts/1.20.1 into lts/1.20.1 2024-10-01 20:46:47 +00:00
Conversation 26 Commits 16 Files changed 41 +1493 -4
krxdev-kaan commented 2024-08-20 12:09:16 +00:00 (Migrated from github.com)
Copy link

Description

Obelisk Manager system (required for any obelisk) is backported in accordance with 1.21. ChunkBoundLookup (required for the manager system) was backported/imported as is since it did not include anything conflicted between 1.20.1 and 1.21. Aversion Obelisk backported, without Entity Filter support since it isn't present in Ender IO in 1.20.1. Everything was implemented in harmony with the whole structure of Ender IO's implementation. The backport required many things to be changed to their 1.20.1 counterparts, such as: Data Attachment -> Capability, and Generic Network Slot Usage -> (whatever required) Network Slot Usage.

Additional Note: I implemented a new GUI Widget called MessageWidget, to render a custom tooltip/message on any desired area of a GUI without needing a placeholder element rendered. This was implemented to render "This part is a work in progress." message on the Entity Filter slot.

EDIT: Entity Filters were not implemented when I first opened this pull request because I wasn't sure if it was bound to changes even in 1.21 but I have decided to backport it also because it is really useful for Aversion Obelisk and it felt like an unfinished business. If it ever recieves any change, assuming I see it, I can just open another pull request to adjust it to match 1.21 behaviour.

TODO (Maybe)

  • The Aversion Obelisk does not support entity filters as of now, because Entity Filter Item is not present in Ender IO 1.20.1. I did not plan on implementing this since it's even controversial in 1.21 (doesn't have an item slot in the GUI) but if it is requested, I can implement it and write support for it in a couple of days.

Breaking Changes

  • No behaviour has changed but IFilterCapability has been changed to not extend from Predicate This was done because of a double Predicate extend caused by individual capabilities extending from Predicate along with IFilterCapability. This was not a problem for Item and Fluid filters since they did not have 2 different test() methods. This change has literally no effect on any other filter.
# Description Obelisk Manager system (required for any obelisk) is backported in accordance with 1.21. ChunkBoundLookup (required for the manager system) was backported/imported as is since it did not include anything conflicted between 1.20.1 and 1.21. Aversion Obelisk backported<del>, without Entity Filter support since it isn't present in Ender IO in 1.20.1</del>. Everything was implemented in harmony with the whole structure of Ender IO's implementation. The backport required many things to be changed to their 1.20.1 counterparts, such as: Data Attachment -> Capability, and Generic Network Slot Usage -> (whatever required) Network Slot Usage. Additional Note: I implemented a new GUI Widget called MessageWidget, to render a custom tooltip/message on any desired area of a GUI without needing a placeholder element rendered. <del>This was implemented to render "This part is a work in progress." message on the Entity Filter slot.</del> EDIT: Entity Filters were not implemented when I first opened this pull request because I wasn't sure if it was bound to changes even in 1.21 but I have decided to backport it also because it is really useful for Aversion Obelisk and it felt like an unfinished business. If it ever recieves any change, assuming I see it, I can just open another pull request to adjust it to match 1.21 behaviour. # TODO (Maybe) - [x] The Aversion Obelisk does not support entity filters as of now, because Entity Filter Item is not present in Ender IO 1.20.1. I did not plan on implementing this since it's even controversial in 1.21 (doesn't have an item slot in the GUI) but if it is requested, I can implement it and write support for it in a couple of days. # Breaking Changes - No behaviour has changed but IFilterCapability has been changed to not extend from Predicate<T> This was done because of a double Predicate<T> extend caused by individual capabilities extending from Predicate<T> along with IFilterCapability. This was not a problem for Item and Fluid filters since they did not have 2 different test() methods. This change has literally no effect on any other filter.
❤️ 1
ferriarnus (Migrated from github.com) reviewed 2024-08-20 12:09:16 +00:00
krxdev-kaan commented 2024-08-23 21:34:12 +00:00 (Migrated from github.com)
Copy link

I have decided to also backport Entity Filters even though I was unsure if they were bound to changes in 1.21. So, the whole Aversion Obelisk backport is done. I believe it should be ready for a review :)

I have decided to also backport Entity Filters even though I was unsure if they were bound to changes in 1.21. So, the whole Aversion Obelisk backport is done. I believe it should be ready for a review :)
ferriarnus commented 2024-09-15 22:28:18 +00:00 (Migrated from github.com)
Copy link

Thank you for the PR, I'll try to look into it soon!

Thank you for the PR, I'll try to look into it soon!
krxdev-kaan commented 2024-09-20 21:11:05 +00:00 (Migrated from github.com)
Copy link

Cool, let me know if you need any changes!

Cool, let me know if you need any changes!
krxdev-kaan commented 2024-09-27 23:15:18 +00:00 (Migrated from github.com)
Copy link

Hey, I have realized that Rover656 has some updates for 1.20.1 which involved an update on FilterCapability which I was deriving from for the EntityFilterCapability class. So I pushed a small update to conform to the new changes made :) There should be no merging conflict now and I also once again tested everything just in case too. Just wanted to let you guys know so you won't have to review everything once again.

Hey, I have realized that Rover656 has some updates for 1.20.1 which involved an update on FilterCapability which I was deriving from for the EntityFilterCapability class. So I pushed a small update to conform to the new changes made :) There should be no merging conflict now and I also once again tested everything just in case too. Just wanted to let you guys know so you won't have to review everything once again.
krxdev-kaan commented 2024-09-28 23:21:44 +00:00 (Migrated from github.com)
Copy link

I have seen that ferriarnus also has updates for 1.20.1 today which involved updates on the base machine block entirely for performance optimizations. I will also make updates once again to conform with these changes but I will be doing it tomorrow. I will once again comment what updates I've made to conform with the changes tomorrow :)

I have seen that ferriarnus also has updates for 1.20.1 today which involved updates on the base machine block entirely for performance optimizations. I will also make updates once again to conform with these changes but I will be doing it tomorrow. I will once again comment what updates I've made to conform with the changes tomorrow :)
Rover656 commented 2024-09-28 23:51:10 +00:00 (Migrated from github.com)
Copy link

@ferriarnus Just to check, do you have a review of this PR in progress or would you like me to take a look, I'm keen to get this into the next 1.20.1 release :)

@krxdev-kaan thanks for all of your hard work on this!

@ferriarnus Just to check, do you have a review of this PR in progress or would you like me to take a look, I'm keen to get this into the next 1.20.1 release :) @krxdev-kaan thanks for all of your hard work on this!
ferriarnus (Migrated from github.com) reviewed 2024-09-29 11:23:33 +00:00
ferriarnus (Migrated from github.com) left a comment
Copy link

Some small remarks. I'll try to test it in game soon as well.

Some small remarks. I'll try to test it in game soon as well.
src/machines/java/com/enderio/machines/client/gui/widget/MessageWidget.java
ferriarnus (Migrated from github.com) commented 2024-09-25 23:36:00 +00:00
Copy link

Is this used? I personally wouldn't want to add new classes that aren't in 1.21. That being said, if something has an advantage, feel free to leave it and PR it to 1.21.

Is this used? I personally wouldn't want to add new classes that aren't in 1.21. That being said, if something has an advantage, feel free to leave it and PR it to 1.21.
src/machines/java/com/enderio/machines/common/blockentity/AversionObeliskBlockEntity.java
@ -0,0 +1,114 @@
package com.enderio.machines.common.blockentity;
ferriarnus (Migrated from github.com) commented 2024-09-25 23:34:57 +00:00
Copy link

Here the Reasoning is mobs in the filter are the ones that are blocked. So Whitelisted filtered mobs should be blocked.

Here the Reasoning is mobs in the filter are the ones that are blocked. So Whitelisted filtered mobs should be blocked.
src/main/java/com/enderio/base/common/menu/EntityFilterSlot.java
@ -0,0 +56,4 @@
return stack;
}
if (stack.getCapability(EIOCapabilities.ENTITY_STORAGE).isPresent()) {
ferriarnus (Migrated from github.com) commented 2024-09-25 23:59:46 +00:00
Copy link

I think if you do isPresent, you shouldn't use ifPresent but just use get() on it. It's a small thing but it's very slightly better for performance iirc.

I think if you do isPresent, you shouldn't use ifPresent but just use get() on it. It's a small thing but it's very slightly better for performance iirc.
krxdev-kaan commented 2024-09-29 11:32:58 +00:00 (Migrated from github.com)
Copy link

Hey, I was just making some commits to conform with the changes you made yesterday. I just changed the getInventoryLayout method to createInventoryLayout method in that commit. Wanted to note it here just in case :) I will now reply to your remarks in a sec.

Hey, I was just making some commits to conform with the changes you made yesterday. I just changed the getInventoryLayout method to createInventoryLayout method in that commit. Wanted to note it here just in case :) I will now reply to your remarks in a sec.
krxdev-kaan (Migrated from github.com) reviewed 2024-09-29 11:35:45 +00:00
src/machines/java/com/enderio/machines/common/blockentity/AversionObeliskBlockEntity.java
@ -0,0 +1,114 @@
package com.enderio.machines.common.blockentity;
krxdev-kaan (Migrated from github.com) commented 2024-09-29 11:35:45 +00:00
Copy link

Oh okay then I must've got it the wrong way in my head. Will be fixed in a minute.

Oh okay then I must've got it the wrong way in my head. Will be fixed in a minute.
krxdev-kaan (Migrated from github.com) reviewed 2024-09-29 11:41:36 +00:00
src/main/java/com/enderio/base/common/menu/EntityFilterSlot.java
@ -0,0 +56,4 @@
return stack;
}
if (stack.getCapability(EIOCapabilities.ENTITY_STORAGE).isPresent()) {
krxdev-kaan (Migrated from github.com) commented 2024-09-29 11:41:36 +00:00
Copy link

Well yeah that definitely looks unoptimized right away. Was I drunk or smth hahah. Fixing it in a minute also!

Well yeah that definitely looks unoptimized right away. Was I drunk or smth hahah. Fixing it in a minute also!
krxdev-kaan (Migrated from github.com) reviewed 2024-09-29 11:43:15 +00:00
src/machines/java/com/enderio/machines/client/gui/widget/MessageWidget.java
krxdev-kaan (Migrated from github.com) commented 2024-09-29 11:43:15 +00:00
Copy link

I once used it but then removed the use. I will explain and send you some screenshot in a bit, if you like it then I will PR it to 1.21 also and if you don't I will go ahead and remove it.

I once used it but then removed the use. I will explain and send you some screenshot in a bit, if you like it then I will PR it to 1.21 also and if you don't I will go ahead and remove it.
krxdev-kaan (Migrated from github.com) reviewed 2024-09-29 11:53:39 +00:00
src/machines/java/com/enderio/machines/common/blockentity/AversionObeliskBlockEntity.java
@ -0,0 +1,114 @@
package com.enderio.machines.common.blockentity;
krxdev-kaan (Migrated from github.com) commented 2024-09-29 11:53:39 +00:00
Copy link

I have pushed the fix for this. You can check it out if you want.

I have pushed the fix for this. You can check it out if you want.
krxdev-kaan (Migrated from github.com) reviewed 2024-09-29 12:01:32 +00:00
src/main/java/com/enderio/base/common/menu/EntityFilterSlot.java
@ -0,0 +56,4 @@
return stack;
}
if (stack.getCapability(EIOCapabilities.ENTITY_STORAGE).isPresent()) {
krxdev-kaan (Migrated from github.com) commented 2024-09-29 12:01:32 +00:00
Copy link

Okay I can now remember why I did that. This is due to the fact that the get() method is private within LazyOptional on 1.20.1 forge so I have to use orElseGet() or orElse() method which are both doing checkups once again, in the end making the optimization level exactly the same as this (if not slightly worse). However, if you'd like, I can make a version with orElse() for readability reasons with a warning added due to usage of null on a @NotNull annotated object.

Okay I can now remember why I did that. This is due to the fact that the get() method is private within LazyOptional on 1.20.1 forge so I have to use orElseGet() or orElse() method which are both doing checkups once again, in the end making the optimization level exactly the same as this (if not slightly worse). However, if you'd like, I can make a version with orElse() for readability reasons with a warning added due to usage of null on a @NotNull annotated object.
krxdev-kaan (Migrated from github.com) reviewed 2024-09-29 12:13:26 +00:00
src/machines/java/com/enderio/machines/client/gui/widget/MessageWidget.java
krxdev-kaan (Migrated from github.com) commented 2024-09-29 12:13:26 +00:00
Copy link

So in the first stages of this PR I did not implement Entity Filter Item but the Aversion Obelisk had the slot for it. So I wanted to be able to add a pop-up message anywhere in the GUI with a reusable approach. So I implemented this for that reason. The pop-up can be put anywhere like on a slot, on a button and/or on thin air. You just give the position and size constraints and the area is now a hoverable pop-up message. Here is a screenshot:
image
If you like it, I can PR it to 1.21 and leave it here also. However, please feel free to not like it hahah

So in the first stages of this PR I did not implement Entity Filter Item but the Aversion Obelisk had the slot for it. So I wanted to be able to add a pop-up message anywhere in the GUI with a reusable approach. So I implemented this for that reason. The pop-up can be put anywhere like on a slot, on a button and/or on thin air. You just give the position and size constraints and the area is now a hoverable pop-up message. Here is a screenshot: ![image](https://github.com/user-attachments/assets/8e210ad2-c1d8-414f-8583-2cceddb27a65) If you like it, I can PR it to 1.21 and leave it here also. However, please feel free to not like it hahah
krxdev-kaan (Migrated from github.com) reviewed 2024-09-29 12:32:19 +00:00
src/main/java/com/enderio/base/common/menu/EntityFilterSlot.java
@ -0,0 +56,4 @@
return stack;
}
if (stack.getCapability(EIOCapabilities.ENTITY_STORAGE).isPresent()) {
krxdev-kaan (Migrated from github.com) commented 2024-09-29 12:32:19 +00:00
Copy link

Yes I have thought about this for half an hour straight and every approach would be the same (if the others are not slightly worse) because of the LazyOptional's implementation on 1.20.1. Both orElse(), orElseGet() and resolve() are alternatives to get(). However, all of these make a couple of null and validity checks before returning the value. Therefore, making them almost on par with my isPresent()+ifPresent() approach. However, if you have any other idea, I am all ears.

Yes I have thought about this for half an hour straight and every approach would be the same (if the others are not slightly worse) because of the LazyOptional's implementation on 1.20.1. Both orElse(), orElseGet() and resolve() are alternatives to get(). However, all of these make a couple of null and validity checks before returning the value. Therefore, making them almost on par with my isPresent()+ifPresent() approach. However, if you have any other idea, I am all ears.
krxdev-kaan commented 2024-09-29 12:54:32 +00:00 (Migrated from github.com)
Copy link

@ferriarnus Just to check, do you have a review of this PR in progress or would you like me to take a look, I'm keen to get this into the next 1.20.1 release :)

@krxdev-kaan thanks for all of your hard work on this!

It is my pleasure!

I just saw your latest commits, which were made an hour ago. I will also merge them in a couple hours. Though there seems to be no merge conflicts so I probably will just merge it and leave it.

> @ferriarnus Just to check, do you have a review of this PR in progress or would you like me to take a look, I'm keen to get this into the next 1.20.1 release :) > > > > @krxdev-kaan thanks for all of your hard work on this! It is my pleasure! I just saw your latest commits, which were made an hour ago. I will also merge them in a couple hours. Though there seems to be no merge conflicts so I probably will just merge it and leave it.
krxdev-kaan commented 2024-09-29 22:51:41 +00:00 (Migrated from github.com)
Copy link

I have merged the latest changes once again, no merge conflicts or any issues arose so I am leaving everything as is. Waiting on the review approvals from now on :)

I have merged the latest changes once again, no merge conflicts or any issues arose so I am leaving everything as is. Waiting on the review approvals from now on :)
❤️ 1
Rover656 (Migrated from github.com) reviewed 2024-09-30 01:29:11 +00:00
src/machines/java/com/enderio/machines/client/gui/widget/MessageWidget.java
Rover656 (Migrated from github.com) commented 2024-09-30 01:29:11 +00:00
Copy link

I think it'd be fine to remove this widget for now personally :)

I think it'd be fine to remove this widget for now personally :)
krxdev-kaan (Migrated from github.com) reviewed 2024-09-30 07:48:59 +00:00
src/machines/java/com/enderio/machines/client/gui/widget/MessageWidget.java
krxdev-kaan (Migrated from github.com) commented 2024-09-30 07:48:59 +00:00
Copy link

Alright, I will be removing it in a couple hours :)

Alright, I will be removing it in a couple hours :)
krxdev-kaan (Migrated from github.com) reviewed 2024-09-30 09:49:06 +00:00
src/main/java/com/enderio/base/common/menu/EntityFilterSlot.java
@ -0,0 +56,4 @@
return stack;
}
if (stack.getCapability(EIOCapabilities.ENTITY_STORAGE).isPresent()) {
krxdev-kaan (Migrated from github.com) commented 2024-09-30 09:49:06 +00:00
Copy link

Tl;dr Found a better solution then isPresent+ifPresent but it will add 2 warnings, would that be a problem for you guys?

Well I have decided to make an accurate calculation by time analysis and here are the results:

Definitions:
n -> Time taken for a single comparison
m -> Time taken for any minor action on objects (the easy part)
k -> Time taken for getValue() inside an optional (the worst part)

Approaches:

  1. isPresent() + ifPresent() (current approach)
  2. resolve() + isEmpty() + get()
  3. orElse(null) + null check

Times taken:

  1. 5n+m+k
  2. 6n+2m+k
  3. 2n+k

Conclusion:
Second option and current approach is very close to each other with the current one being somewhat better. However, the third approach seems to be a much better option with a minor drawback. The third option will give out 2 warnings because of the usage of null in a Non-Null context, however it won't be a problem otherwise.

Side note: I know that this was an overkill analysis for, at most, a very slight performance optimization but I had nothing else to do hahah

Tl;dr Found a better solution then isPresent+ifPresent but it will add 2 warnings, would that be a problem for you guys? Well I have decided to make an accurate calculation by time analysis and here are the results: Definitions: n -> Time taken for a single comparison m -> Time taken for any minor action on objects (the easy part) k -> Time taken for getValue() inside an optional (the worst part) Approaches: 1. isPresent() + ifPresent() (current approach) 2. resolve() + isEmpty() + get() 3. orElse(null) + null check Times taken: 1. 5n+m+k 2. 6n+2m+k 3. 2n+k Conclusion: Second option and current approach is very close to each other with the current one being somewhat better. However, the third approach seems to be a much better option with a minor drawback. The third option will give out 2 warnings because of the usage of null in a Non-Null context, however it won't be a problem otherwise. Side note: I know that this was an overkill analysis for, at most, a very slight performance optimization but I had nothing else to do hahah
krxdev-kaan (Migrated from github.com) reviewed 2024-09-30 17:26:43 +00:00
src/machines/java/com/enderio/machines/client/gui/widget/MessageWidget.java
krxdev-kaan (Migrated from github.com) commented 2024-09-30 17:26:43 +00:00
Copy link

Done! I have removed the widget and pushed the commits, you can check it out if you'd like. Once ferriarnus or you answer my last comment on the other task, I will do that right away also :)

Done! I have removed the widget and pushed the commits, you can check it out if you'd like. Once ferriarnus or you answer my last comment on the other task, I will do that right away also :)
krxdev-kaan commented 2024-09-30 19:55:45 +00:00 (Migrated from github.com)
Copy link

I have pushed a fix for a very extreme case to crash the game with Aversion Obelisk. If a server closes at a tick where the next tick would have been a spawn event in the range of an obelisk, the next launch of the server would instantly crash it in the first tick for one time (next launch is successful). I was playing with my build for a month now and I have just came across this. This is also possible in 1.21 even though it is REALLY unlikely to happen. I have pushed a fix and I will most likely PR it to 1.21 also.

Explanation:
Aversion Obelisk handles spawn event only if the spawn event is occuring in the range of the obelisk so we call getAABB() while processing and check if AABB contains the event position. However, if this event is occuring in the very first tick of the server, then the obelisk is not loaded yet. Therefore making it's aabb null at the time. This really is a very extreme case but it happened.

Solution:
I simply added a null check for the getAABB() before using it.
I will PR this also to 1.21 because, even though it is for a single time and very unlikely, it can happen.

I have pushed a fix for a very extreme case to crash the game with Aversion Obelisk. If a server closes at a tick where the next tick would have been a spawn event in the range of an obelisk, the next launch of the server would instantly crash it in the first tick for one time (next launch is successful). I was playing with my build for a month now and I have just came across this. This is also possible in 1.21 even though it is REALLY unlikely to happen. I have pushed a fix and I will most likely PR it to 1.21 also. Explanation: Aversion Obelisk handles spawn event only if the spawn event is occuring in the range of the obelisk so we call getAABB() while processing and check if AABB contains the event position. However, if this event is occuring in the very first tick of the server, then the obelisk is not loaded yet. Therefore making it's aabb null at the time. This really is a very extreme case but it happened. Solution: I simply added a null check for the getAABB() before using it. I will PR this also to 1.21 because, even though it is for a single time and very unlikely, it can happen.
krxdev-kaan commented 2024-10-01 19:42:07 +00:00 (Migrated from github.com)
Copy link

I've seen that ferriarnus marked everything as resolved. So I am assuming you guys didn't want me to make a change about the last comment. If there is any changes left you would like me to do, please do tell :)

Edit: I have clicked re-review by mistake while I was checking out the changes I've made to make sure I haven't skipped anything. Sorry!

I've seen that ferriarnus marked everything as resolved. So I am assuming you guys didn't want me to make a change about the last comment. If there is any changes left you would like me to do, please do tell :) Edit: I have clicked re-review by mistake while I was checking out the changes I've made to make sure I haven't skipped anything. Sorry!
Rover656 (Migrated from github.com) approved these changes 2024-10-01 20:45:32 +00:00
Rover656 (Migrated from github.com) left a comment
Copy link

This looks good to me, don't worry about the EntityFilterSlot - I think it'll be fine (and when I come to backporting some JEI stuff from 1.21 I can always touch it up.

Thanks a lot for backporting these features!

This looks good to me, don't worry about the EntityFilterSlot - I think it'll be fine (and when I come to backporting some JEI stuff from 1.21 I can always touch it up. Thanks a lot for backporting these features!
krxdev-kaan commented 2024-10-01 20:50:43 +00:00 (Migrated from github.com)
Copy link

Cool! I have joined the discord with my main account also just now. I am really glad that I could be of help! Hoping to port the other obelisks in a couple weeks as soon as my workload gets a bit better :)

Cool! I have joined the discord with my main account also just now. I am really glad that I could be of help! Hoping to port the other obelisks in a couple weeks as soon as my workload gets a bit better :)
Sign in to join this conversation.
Reviewers
No reviewers
ferriarnus
Rover656
Labels
Clear labels   
Area-Assets

   
Area-Backend

Backend work not usually visible to players.

  
Area-Conduits

Everything involving conduits

  
Area-Datapacks

   
Area-Lang

   
Area-Mod Compat

   
Area-Parity

1.12.2 missing features

  
Area-Rendering

Rendering code, might be shaders specific or general.

  
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

High priority, crash/breaking.

  
P-1-Medium

Medium priority. Potentially deleting items or breaking functionality.

  
P-2-Low

Low priority. Not hurting anyone, just annoying.

  
Status-Awaiting Response

Waiting for OP to respond

  
Status-Behind-Flag

This change is available but is placed behind a feature flag.

  
Status-Blocked

Blocked by a specific issue or protocol.

  
Status-Cannot Reproduce

   
Status-Duplicate

This issue or pull request already exists

  
Status-Help Wanted

We need some help to try and track this thing down..

  
Status-Incomplete Report

   
Status-Invalid

This doesn't seem right

  
Status-Needs LTS Backport

Fixed in latest but requires LTS backport.

  
Status-Needs Updating

Needs updating to a newer Minecraft version.

  
Status-Stale

This may not be updated by the OP any further.

  
Status-To Implement

   
Status-Triage

A Triage Member should take a look at this

  
Status-Wontfix

This will not be worked on

  
Status-Wontmerge

This PR won't be merged, but is left now for reference of ongoing or future works.

  
Type-Backport

   
Type-Bug

There is a problem.

  
Type-Documentation

Improvements or additions to documentation

  
Type-Enhancement

New feature or enhancement to existing feature.

  
Type-Question

Further information is requested

  
Type-RFC

Request for comments.

  
Type-Suggestion
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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Team-EnderIO/EnderIO#777
No description provided.
Delete branch "lts/1.20.1"

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?