Make OpenComputers world interactions non-blocking / reduce per-call tick latency

[Vinillia]

Your GTNH Discord Username

10110812111510597110

Your Pack Version

2.8.4

Your Proposal

Scanning an inventory via transposer.getStackInSlot() is extremely slow because it appears to wait ~1 server tick per call.
A 54-slot scan takes ~2.8s at 20 TPS. Please consider removing/reworking this delay

Test code

local function f1()
  local storageSize = runtime.grid.transposer.getInventorySize(runtime.grid.side)
  for i = 1, storageSize do
    runtime.grid.transposer.getStackInSlot(runtime.grid.side, i)
  end
end

local function f2()
  local storageSize = runtime.grid.transposer.getInventorySize(runtime.grid.side)
  for i = 1, storageSize do
    -- runtime.grid.transposer.getStackInSlot(runtime.grid.side, i)
  end
end

local function measure(fn)
  local t0 = computer.uptime()
  pcall(fn)
  return computer.uptime() - t0
end

local t1 = measure(f1)
local t2 = measure(f2)

print(string.format("f1: %f, f2: %f", t1, t2))

Your Goal

OpenComputers has a very high skill floor if you want to use it efficiently for automation, and it’s also significantly more expensive than other automation options.
For comparison, SFM is cheaper and easier to work with (lower skill floor), yet its operations don’t have a per-call tick delay. From a gameplay/balance perspective this feels inconsistent: OC requires more investment and expertise, but is penalized with additional latency for basic operations, which doesn’t make much sense.

Your Vision

At the very least, this looks like a balance issue; at best, improving it would unlock additional practical automation methods.

Final Checklist

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

[PLASMAchicken]

Isn't there also a getAllStacks which allows you to get all stacks in 1 tick?

[hinyb]

You can use getAllStacks instead, it is essentially the batched version of getStackInSlot.
In OpenComputers, Lua runs in a separate thread pool, so any world interaction must be synchronized with the Minecraft main thread.
This synchronization naturally incurs a 1 tick delay per call.

[Vinillia]

Isn't there also a getAllStacks which allows you to get all stacks in 1 tick?

This function lacks information about the slot of the item. You technically can count them yourself but this won't save you if you there are gaps in the storage

[PLASMAchicken]

Did you try it?

https://github.com/GTNewHorizons/OpenComputers/blob/9ca529cf2ad9639ec5686cffd662e4724905f91e/src/main/scala/li/cil/oc/integration/vanilla/DriverInventory.java#L155

Code looks like it would just handle gaps the same as currently

[Vinillia]

Did you try it?

https://github.com/GTNewHorizons/OpenComputers/blob/9ca529cf2ad9639ec5686cffd662e4724905f91e/src/main/scala/li/cil/oc/integration/vanilla/DriverInventory.java#L155

Code looks like it would just handle gaps the same as currently

I'm sorry. I didn't mean that getAllStacks will fail but the fact that you won't be able to transfer the item or handle information about it correctly

Take a look at my in game setup for the reactors as an example:
My chest works as a setup template for the reactors. Computer will ensure that all reactors will match the same setup if there are enough resources

---

Now if I remove one of the items, the change will be reflected in the corresponding slot.

---

And if I change the function to utilize getAllStacks, I won't be able to get the same result (assuming that the template hasn't changed)

[Vinillia]

After further investigation, I found that my test case was incorrect. The iterator does not skip slots.