Corporea Retainers do not respect current spark color when re-submitting
HipHopHuman opened this issue ยท 4 comments
I'm not sure if this is a bug, or the intended behavior. I asked for clarification on the Discord server to find out if I should open this issue or not, but my question wasn't answered.
I had a conversation with @Alwinfy in #build_showcase which led me to believe that Corporea Retainers should work this way, but they don't.
If this behavior is intended and it is not a bug, then feel free to ignore/close this issue.
Version Information
Forge version: 36.0.22
Botania version: 1.16.4-411
Further Information
Problem:
- Request X of an item by name on a redstone signal
- Only the Corporea Index can request by name
Facts:
- Corporea Index can store failed requests on retainers, it is even persisted between game starts
- Two retainers can be used for repeating the same request. When a retainer request fails, it is stored on the 2nd retainer.
This means retainers can be "ping-ponged" to continuously request an item, as long as the request always fails. - Corporea Sparks can be dyed automatically with paintslinger lenses
Theory:
"Forcing" a retainer signal to fail will allow infinite requests. One can "force" it to fail by temporarily swopping the network color.
Theory disproved:
A Retainer appears to remember the color of the network it's request was made on. This means that even if the attached Interceptor's color changes, the retainer will still submit the request on the original channel color. i.e. if a request was intercepted on a white channel, but then the interceptor spark is dyed orange, pulsing the retainer will submit the request to the white channel, despite the interceptor being dyed orange.
Steps:
- Set up a corporea index with a white spark
- Set up a chest with a white spark - make sure it is empty
- Set up a corporea interceptor with 3 retainers, and a white spark
- Set up two master sparks, one white (network), one orange (unused)
- Choose an item you want to request, and put it on the interceptor item frame
- Request the item from the interceptor
- The request should fail
- There should now be 3 held requests, one in each corporea retainer
- Pulse one of the retainers to make it "forget" it's request
- Fill the chest with a stock of items
- Dye the interceptor spark orange
- Pulse each of the remaining retainers
- Notice that all 3 retainers aren't holding a request
- Notice that the Index is spitting out items, even though retainer network color is different
A potential improvement:
When their Interceptor Spark color changes, Corporea Retainers should submit the request on the new color. This way, color-changing via Paintslinger lenses can be used to "transfer" a request from one network channel to another. This enables the use of the Corporea Index as a way to summon specific items to a location according to the item's name, something that is not possible via the Corporea Funnel. It will combine well with the Labellia.
Imo, this is okay - The request is a pair of item matcher and count. The request happened to be made over a network with a certain spark color, but that's not really a property of the request, its a property of the requestor. When you change the network the requestor was on, it makes sense that the retainer replays the request to the new network
I think that's the bug though -- it resubmits on the old network.
And yeah, this should be fixed. Resubmitting on the new network has lots of cool untapped potential, now that we have a way to switch networks dynamically.
Confirmed, but not sure how to fix yet. Basically the problem is the retainer saves the request + the position it was submitted at. The Retainer's contract is that the request is resubmitted at the same position that the original request was submitted from -- the interceptor's spark only matters to the code at interception/remembering time.