Config Options
solonovamax opened this issue ยท 3 comments
Describe the feature/addition!
It would be nice if there were config options for the following things:
- Max length of the number fields
- this limits the max count you're able to request. It may be desirable for some players to increase this.
- this would also be really useful for equations, as currently I've found myself in several instances where I want to put an equation but ran out of space so ended up calculating it on an external calculator.
height/width of the requester interfacelinks to source:currently, if you use numbers that are 7 digits long, they can sometimes have 1 digit cut off (idfk why???). and if you increased the max digit count to >7, the extra digits would definitely be cut off.
- config to specify rate limits on performing requests
- currently, if you have some item which cannot be requested, it will take a hit on the tps of the server, as it'll force ae2 to constantly recompute it, always resulting in the same calculation.
- smth like "take exponentially longer (with a max of like 30 mins or smth) before attempting to craft the item again, if it has failed several times in a row". of course, this would be off by default.
Why would like to see this feature/addition?
QOL
I'd be more than happy to implement the first two in a PR. for the second one, not sure where you'd want to do this as I'm not familiar with the codebase.
I'm always open to quality of life improvements and you've put a lot of thought into this.
I understand the point about the character limit in the input fields when you want to enter an equation. The background of this limitation was that it should not be possible to enter numbers that are not completely visible in the field. It would be possible to adapt the logic so that non-numeric expressions have no character limit and only the number itself has to be inside the box.
On the subject of the GUI size, unfortunately, I cannot understand exactly what problem you are describing here. Which number exactly is 7 characters long and what is cut off?
The size of the GUI is variable and can be changed using the button on the left-hand side of the terminal. This is the same logic as in Applied Energistics 2 itself. In fact, this logic has been completely taken over from the Pattern Access Terminal. Also in AE2 it is currently not possible to change the GUI width. But the height is variable. The overall size adjusts to the GUI scale value in your settings. So I don't see the problem here.
Can you prove your last assertion about the TPS problems with the requester using a profiler? That would surprise me because the requester has a stock change listener. It stores the known number of items in your network that you define in a requester slot and only when this number changes and is below the stock amount, an attempt is made to send another request. This means that new request operations are not started in every tick. Increasing the interval exponentially is therefore not a sensible approach here because the whole thing is event-based.
Last but not least, because you didn't specify the version you are speaking about, I would like to mention that there will be no more changes to old versions. These are not critical bugs. Changes will therefore only be made for version 1.20.4+ for NeoForge.
You are welcome to try implementing your wishes and I will take a look at the changes, but from the description, I can't really grasp what your goal is here.
I understand the point about the character limit in the input fields when you want to enter an equation. The background of this limitation was that it should not be possible to enter numbers that are not completely visible in the field. It would be possible to adapt the logic so that non-numeric expressions have no character limit and only the number itself has to be inside the box.
you could always check if the resulting number is greater than 9_999_999
(yuck, hardcoded value, ik, but idk any other good way to construct this, bc it's not a nice power of 2 or smth lol. ig maybe you could do pow(10, 7) - 1
or smth)
On the subject of the GUI size, unfortunately, I cannot understand exactly what problem you are describing here. Which number exactly is 7 characters long and what is cut off?
I'll grab a screenshot of this later, when I get home. (if I don't forgor)
however, I sometimes have numbers, such as 1048576
, in some scenarios (I have yet to figure out why), it will be shifted 1 digit over to show
048576
. (note: the space at the end. it has additional whitespace at the end, not present in the other inputs)
The size of the GUI is variable and can be changed using the button on the left-hand side of the terminal. This is the same logic as in Applied Energistics 2 itself. In fact, this logic has been completely taken over from the Pattern Access Terminal. Also in AE2 it is currently not possible to change the GUI width. But the height is variable. The overall size adjusts to the GUI scale value in your settings. So I don't see the problem here.
ah, that sucks that you can't change the width. oh well.
edited the issue to remove that.
Can you prove your last assertion about the TPS problems with the requester using a profiler? That would surprise me because the requester has a stock change listener. It stores the known number of items in your network that you define in a requester slot and only when this number changes and is below the stock amount, an attempt is made to send another request. This means that new request operations are not started in every tick. Increasing the interval exponentially is therefore not a sensible approach here because the whole thing is event-based.
I can't prove it using a profiler, however, I have made the following observation:
if you have ae2 request a recipe that cannot be completed with the items currently in the storage, after it fails, it will re-attempt to compute it. this is taxing on the tps, as it ensures that ae2 is always attempting to craft something. ae2 itself uses a decent amount of tps for large recipes, but this is expected. the issue is with how the requester will re-schedule another request if the first request fails. although, it may not be directly re-scheduling a request, if you have items that are flowing in & out, it could cause the same effect.
Last but not least, because you didn't specify the version you are speaking about, I would like to mention that there will be no more changes to old versions. These are not critical bugs. Changes will therefore only be made for version 1.20.4+ for NeoForge.
also, I am on 1.20.1 fabric, so sadly it seems I won't get in updates. rip.