Feature requests for AE2

[Divran]

Your GTNH Discord Username

Divran

Your Pack Version

2.1.2.3qf

Your Proposal

This is a list of some features I've thought of over time. I don't expect all of them to be implemented. Some may be difficult, impossible, or not worth the effort. I understand this. I'm just throwing ideas. Basically just pick any you like. I posted this in a discord chat and boubou asked me to make a ticket.

• feature here
  • reason for feature here, if not self-explanatory

Crafting status screen

• [x] 100% tall crafting status screen
• [x] implement the new backported crafting status screen on the wireless crafting terminal (might already be done in a version newer than we have)
• [x] click any item (or a button near it) in crafting status and have it highlight the inventory
  • would save time because you wouldn't have to switch over to the interface terminal
• [ ] working time estimation (current time estimate is pretty much worthless)
  • I don't know how it's implemented currently but one way I've thought of that should work is to keep track of when an item is inserted into a machine and how long it takes until it's crafted. then keep a rolling average of that time for each item, in a shared lookup table (per ae controller, not per recipe). this would also help with the next point below.
  • also, currently if two crafts want to use the same recipes, it doesn't add the time of the other craft to the current one. whichever recipe happens to be crafted last should have the time of the recipe that's crafted first added to its total, since it needs to wait for it to finish.
• [ ] time estimation for every item in crafting status screen
• [ ] more detailed item status info,
  • why is it scheduled and not actively crafting?
  • is it blocked by a full inventory or does it just not have enough co-processors?
  • Is it blocked by an interface not pointing at an inventory (mistake during setup)? Or what?
• [ ] sort items in list by status, instead of whatever random sort it uses currently
  • so that green/yellow status items appear at the top of the list
  • maybe a button to toggle it
• [ ] sort the list of cpus to the left by crafting status,
  • so cpus that are currently crafting a player requested recipe will be sorted to the top, followed by crafting card requests and last, idle cpus.
  • maybe with a button to toggle back to sort by name or id or whatever it does currently
  • 100% tall ui would greatly reduce the usefulness of this sorting but depending on resolution it's entirely possible to still have the list be taller than the screen. At least for us, we have over 50 small cpus and a lot of crafting cards.
• [ ] button to set a currently crafting recipe as "max priority", meaning no other currently crafting recipe can use the same interfaces as this recipe until this recipe is finished
  • for when you have a craft going for a compressed fusion which will take 48+ hours to complete but you really just want that one zpm pump right now. ofc this won't be able to distinguish between different interfaces attached to the same multiblock machine so depending on how your base is set up it might not always work, but I expect there's nothing that can be done about that.
• [ ] option to toggle to a tree based crafting status screen (like logistics)
  • not needed if the other feature requests are implemented such as sorting by status, but would be nice
  • [x] done in calculation screen but not yet in status screen
• [x] Display the number of patterns it's about to request in addition to the number of items, see https://github.com/GTNewHorizons/GT-New-Horizons-Modpack/issues/14617

Crafting

• [x] for active crafts to use incoming/stocked items instead of having to request them when it reaches that particular item in the schedule
  • for example if a currently crafting recipe has 40k sodium or whatever scheduled but not actively crafting that particular item at that particular time, and then something else crafts 100k sodium and dumps it into ae and doesn't use it, it can just yoink some of that and skip having to craft it in the first place, this would literally save multiple hours spent crafting in many cases
• [ ] give patterns priorities, if you encode different recipes with the same output in two or more ways it will use one first until you run out of required resources and then switch to the next one
• [ ] give interfaces priorities, so if two or more interfaces have the same recipes, it will use one over the other while crafting.
  • potentially also use this priority for keeping stock.
• [ ] sort items in request screen by status, instead of whatever random sort it uses currently
• [x] ability to use oredicts properly when requesting
  • for example if you encode a chest as using oak planks, but you have 0 planks of any kind, and you only have fir planks encoded, it should be able to request fir planks (currently it can't)
• [ ] allow interfaces with crafting cards to take unused items crafted by other sources
  • for example if two interfaces (with crafting cards) have let's say 64 each of the same item in keep stock, and the recipe they use is encoded to produce 256 of that item at a time, both interfaces will start a request, but they will only take items to use themselves once their own request is completed. but in this situation, the second interface could be filled much quicker if it used the excess items from the first craft.
• [ ] option on crafting cpu to only handle user-requested items. This way we could reserve the big cpus for personal projects. Crafting cards would only use cpus that are set to accept job from any sources.
• [ ] doing crafting calculations will often succeed, but with the start button unclickable. please fix this bug.
  • speeding up the calculations may help, otherwise reserving the items so nothing else can use them would likely solve the problem entirely.
• [ ] intent-based crafting
  • gt machines would no longer "guess" which recipe they should be crafting, and instead ae will directly tell them what to craft. this would not only instantly solve all recipe conflict issues, but would also significantly reduce server cpu load because gt machines would no longer need to check which items are in their inventories every tick and would also no longer need to loop through every item in their inventories and every recipe to check if those items make a valid recipe.
  • To know which recipe to use, if the user shift-clicks in the recipe from NEI then it's simple and there's only one. but if they construct the recipe themselves or otherwise modify the shift-clicked recipe, then ae could at the very least tell the gt machine which items it has in its input, and more importantly, which item(s) it expects to produce, which should narrow down the results to one single recipe basically all the time. after that, the gt machine could use the same inventory checking it already uses to see if it's being constantly filled with fluids or items in a different bus, but it'd still save server cpu time due to the fact that it wouldn't need to keep checking this over and over (only when ae tells it to check)
• [x] make the 2x button behave like middle click so that it uses the same slot up to 2b instead of only going up to just over 1 stack per slot
• [x] digital singularity sized crafting cpu

Other

• [ ] "keep stock" card for storage/export/import bus which would keep an amount of items stocked in the target inventory
  • in the case of the import bus it would leave the specified amount of items behind in the inventory
• [ ] "in/output exact amounts" card for storage/export/import (like chest buffer / super buffer)
• [ ] a terminal that can search for items stocked in interfaces, and export/storage/import bus configurations (edit: level maintainer configs too now that they exist)
  • not everyone plays solo single player. quite often, your team mates will build some stupid shit and you have to spend the next 40 minutes finding it (also sometimes that team mate is yourself...)
  • having it show which export buses or interfaces have crafting cards would be extremely helpful as well, to delete old setups to save tps
  • not saying it needs remote editing, although I wouldn't object to it. searching and "highlight block" would be enough for this to be very helpful
  • [x] Now exists for level maintainers, but not yet for everything else
• [x] don't move around items in terminals when shift clicking them, like refined storage
• [ ] working crafting request OC api, might already be fixed in later versions of gtnh's ae2, idk, but in the versions we've used it's extremely buggy
• [x] ability to charge wireless terminals with GT wireless chargers so we dont have to rely on EIO's shitty range. that, or charge it from armor, and then the armor will be charged by GT instead
  • universal terminal seems to work without requiring energy when placed in bauble slot (bug? or does it know you have a creative energy cell?)
• [x] dual interface p2p
• [ ] allow interface terminal to filter to all recipes that have oredict or substitution mode enabled
• [ ] don't sync the entire ae storage every time there's an update, just the visible part of the terminal window. would help prevent you from both ddosing yourself and deleting tps when your ae is inserting and pushing a lot of items per second (causing a lot of updates) while viewing a terminal
• [x] Add a button in all interfaces that allows you to multiply all recipes in the interface.
  • The most basic implementation of this feature would be to just have a 2x button that works the same way as the normal 2x button except it's applied to all recipes in the interface at once.
  • However, a more useful feature may be to have a text box where the user can type a number, after which the recipes will be multiplied such that the smallest output item count is at least that much, or any input or output becomes at least 2.14B, whichever comes first. For example, if I have a bunch of ingot -> rod extruder recipes and they are all different amounts, say one is 64 ingots -> 128 rods but the next 1k ingots -> 2k rods. And I want to unify the amounts into the same multiplier, I might type 10k into the box, which results in every single one being set to 5k input and 10k output (Or more, it should try to get as close as possible, while staying above the number you gave it, without breaking the ratios).

Your Goal

AE2 has always been missing a ton of features in my opinion. GTNH has done an excellent job so far with the changes to the interface terminal and oredicts and whatnot. But there's still a lot of possibilities left.

Your Vision

Improve AE2

Final Checklist

• [X] I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying I like this feature please reconsider adding it will prompt us to investigate and reopen it once we confirm your report.
• [X] I believe there is nothing similar in the pack already, or the existing solution isn't good enough.
• [X] I understand this change request may not attract enough attention and thus not be implemented.
• [X] I understand this change request may be rejected due to other community members thinking it's inappropriate.
• [X] I believe this feature would make the pack better.

[Divran]

I believe developers can edit the main post so if you do implement anything on this list it would be great if you could cross it off by making it strike-through. And link to the commit too, that'd be great.

[Alastors]

Yes, we can

[Divran]

Yes, we can

yeah someone else already edited it to have checkboxes since I completely forgot that feature existed

added the following item

• allow interfaces with crafting cards to take unused items crafted by other sources
• for example if two interfaces have let's say 64 each of the same item in keep stock, and the recipe they use is encoded to produce 256 of that item at a time, both interfaces will start a request, but they will only take items to use themselves once their own request is completed. but in this situation, the second interface could be filled much quicker if it used the excess items from the first craft.

[Szajkop]

Some thoughts:

• it would be nice to set a flag on a crafting cpu to only handle user-requested items. This way we could reserve the big cpus for personal projects. The Auto stockpiling and other actively requested stuff (by crafting cards) would only consume cps that are set to accept job from any sources.

• doing crafting pre-calculations sometimes return with ready to start status, but clicking the start button does not start the job. This may be that the storage has changed since the calculation started. Some fast re-evaluation of the already calculated required items would solve this issue imo.

[Divran]

Both excellent ideas. The latter one I've also had in the past but forgotten about (I've forgotten a shit ton of random ideas over the years). Will add them to the main list later when I'm not typing from my phone.

edit: added

[Divran]

Added feature request

• [ ] ability to charge wireless terminals with GT wireless chargers so we dont have to rely on EIO's shitty range. that, or charge it from armor, and then the armor will be charged by GT instead

[repo-alt]

Intrefaces do have priorities though, I don't understand why I keep seeing this request

[Divran]

Intrefaces do have priorities though, I don't understand why I keep seeing this request

I think I tested it the last time someone mentioned that they already had priorities, but I don't remember the results perfectly. I think that for encoded patterns the priority does nothing and that maybe it only affects the stocked items. But it was a while ago so I may be remembering wrong. I'm editing the original post to split up these two things into different checkboxes. If you would like to test it again and confirm the results then feel free to check the corresponding checkbox if the feature is already available.

[Divran]

New suggestion invented by a friend of mine: intent-based crafting so basically, gt machines would no longer "guess" which recipe they should be crafting, and instead ae will directly tell them what to craft. this would not only instantly solve all recipe conflict issues, but would also significantly reduce server cpu load because gt machines would no longer need to check which items are in their inventories every tick and would also no longer need to loop through every item in their inventories and every recipe to check if those items make a valid recipe.

To know which recipe to use, if the user shift-clicks in the recipe from NEI then it's simple and there's only one. but if they construct the recipe themselves or otherwise modify the shift-clicked recipe, then ae could at the very least tell the gt machine which items it has in its input, and more importantly, which item(s) it expects to produce, which should narrow down the results to one single recipe basically all the time. after that, the gt machine could use the same inventory checking it already uses to see if it's being constantly filled with fluids or items in a different bus, but it'd still save server cpu time due to the fact that it wouldn't need to keep checking this over and over (only when ae tells it to check)

[bizzlebazzle]

For the above, (I am the friend) this is more of a bilateral integration request as it would presumably involve GT code changes not just specifically AE2. It would also likely need machines to have a toggle that will let you chose if the machine applies this intent mode or uses the traditional method similar to bus isolation toggles- as if it strictly looked for pattern intents before commencing crafting then hand crafted recipes would obviously be broken. Or from an alternate perspective maybe a toggle that would let you specify the machine will only craft intent based recipes might be more logical?

I assume it would probably be a non-trivial change to implement but figured it made sense to suggest anyway, id try it myself but I have exactly zero knowledge of java.

[repo-alt]

https://github.com/GTNewHorizons/GT-New-Horizons-Modpack/issues/10968 ?

[Divran]

10968 ?

yes, definitely some similarities to that

[Divran]

Added

• dual interface p2p

[SweptWasTaken]

Don't move around items in terminals when shift clicking them, like refined storage.

I'm not sure if this is related or a bug, but when shift-clicking items in the terminal a lot of the time any view cells in the terminal will pop-out into your inventory, without even clicking on them. I think it might be something to do with mouse tweaks, but i'm unsure.

[Divran]

Crossed off the list due to being added:

• click any item (or a button near it) in crafting status and have it highlight the inventory
• ability to use oredicts properly when requesting

[chochem]

Hmm, can we slow down with the ae2 features a bit? Like focus on the most important stuff only maybe?

I mean I like them too, but AE2 features break the game a lot, are often very hard to debug, and delay stables forever. Case in point, the crafting status hightlight bricked autocrafting completely in the dev release it was added. And the substitution changes took months to resolve.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 3 days

[Divran]

Added the following

• [ ] Add a button in all interfaces that allows you to multiply all recipes in the interface.
• The most basic implementation of this feature would be to just have a 2x button that works the same way as the normal 2x button except it's applied to all recipes in the interface at once.
• However, a more useful feature may be to have a text box where the user can type a number, after which the recipes will be multiplied such that the smallest output item count is at least that much, or any input or output becomes at least 2.14B, whichever comes first. For example, if I have a bunch of ingot -> rod extruder recipes and they are all different amounts, say one is 64 ingots -> 128 rods but the next 1k ingots -> 2k rods. And I want to unify the amounts into the same multiplier, I might type 10k into the box, which results in every single one being set to 5k input and 10k output (Or more, it should try to get as close as possible, while staying above the number you gave it, without breaking the ratios).

[Divran]

Added

• [ ] digital singularity sized crafting cpu

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 3 days