Robot (screen) freeze

[Pizzn]

When a chunk is unloaded (I logged out from a server to test this) any powered up robots get their screens frozen. Robot still powered on, last message is readable on screen, no blinking cursor. Upon first key press the HDD/disk sounds shortly, then nothing. The robot must be turned off and on again so that keyboard input is available again. Did additional testing with Forge 2254, where no native lua libs are available. With this setup the robots are simply turned off, screens black. Computers and computer screens work fine.

Setup: Mods: Tested with OpenComputers only OC 1.17.10 - 1.6.2.12 universal, Forge 1614 OC 1.8.9 - 1.6.2.12 universal, Forge 1902 OC 1.10.2 - 1.6.2.7, Forge 2185

[Pizzn]

Tested again with disablePersistence=true (OC 1.10.2 - 1.6.2.7, Forge 2185), got this error while reloading the chunk:

full log: http://pastebin.com/nKCpx9tg

[Server thread/ERROR] [OpenComputers/]: Unexpected error loading a state of computer at (684.5, 80.5, 109.5). State: Paused. Unless you're upgrading/downgrading across a major version, please report this! Thank you. java.lang.Exception: li.cil.repack.com.naef.jnlua.LuaRuntimeException: Invalid kernel. at li.cil.oc.server.machine.luac.NativeLuaArchitecture.load(NativeLuaArchitecture.scala:351) ~[NativeLuaArchitecture.class:?] at li.cil.oc.server.machine.Machine.liftedTree1$1(Machine.scala:740) [Machine.class:?] at li.cil.oc.server.machine.Machine.load(Machine.scala:739) [Machine.class:?] at li.cil.oc.common.tileentity.traits.Computer$class.readFromNBTForServer(Computer.scala:151) [Computer$class.class:?] at li.cil.oc.common.tileentity.RobotProxy.li$cil$oc$common$tileentity$traits$RotatableTile$$super$readFromNBTForServer(RobotProxy.scala:26) [RobotProxy.class:?] at li.cil.oc.common.tileentity.traits.RotatableTile$class.readFromNBTForServer(RotatableTile.scala:38) [RotatableTile$class.class:?] at li.cil.oc.common.tileentity.RobotProxy.readFromNBTForServer(RobotProxy.scala:137) [RobotProxy.class:?] at li.cil.oc.common.tileentity.traits.TileEntity$class.readFromNBT(TileEntity.scala:92) [TileEntity$class.class:?] at li.cil.oc.common.tileentity.RobotProxy.func_145839_a(RobotProxy.scala:26) [RobotProxy.class:?] at net.minecraft.tileentity.TileEntity.func_190200_a(TileEntity.java:123) [aqk.class:?] at net.minecraft.world.chunk.storage.AnvilChunkLoader.loadEntities(AnvilChunkLoader.java:486) [atj.class:?] at net.minecraftforge.common.chunkio.ChunkIOProvider.syncCallback(ChunkIOProvider.java:96) [ChunkIOProvider.class:?] at net.minecraftforge.common.chunkio.ChunkIOExecutor.tick(ChunkIOExecutor.java:150) [ChunkIOExecutor.class:?] at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:673) [MinecraftServer.class:?] at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:387) [ld.class:?] at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:613) [MinecraftServer.class:?] at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:471) [MinecraftServer.class:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121] Caused by: li.cil.repack.com.naef.jnlua.LuaRuntimeException: Invalid kernel. at li.cil.oc.server.machine.luac.NativeLuaArchitecture.load(NativeLuaArchitecture.scala:360) ~[NativeLuaArchitecture.class:?] ... 17 more

Edit: Used foreLuaJ=true, no errors. Computers and robots boot up upon reentering chunk.

[Fingercomp]

I've tested in MC 1.7.10 and MC 1.10.2, on different servers (Windows and Linux), on different modpacks (with OC only, or OC with many other mods; OC version 1.6.2). In all cases screens just freeze, displaying what they showed before the chunk was unloaded. The robot continues to execute the program but doesn't react at any user keyboard or screen input.

The bug also seems to happen with terminal servers.

I thought this would be fixed soon. But while it makes robots and terminal servers almost completely unusable, no one has even left a comment here, let alone has fixed this (somewhat critical in my opinion) bug. And it already happens for more than a month. :confused:

[sshilovsky]

I've found a possible cause and a workaround: rebinding gpu to the screen helps to keep screen working (didn't test the keyboard though).

Bug confirmed for:

• linux singleplayer
• MC 1.10.2
• OC 1.6.2.7
• forge 2281
• no other mods
• default config
• tested on Creatix in creative mode
• tested in OpenOS as well as with custom flash script
• to reproduce the bug it is sufficient to exit and reenter the world in singleplayer mode while a robot is on

Test script for OpenOS:

if component==nil then
  component=require('component')
end
screen=component.screen
gpu=component.gpu
computer=component.computer
local i = 0 
while true do
  -- gpu.bind(screen.address) -- <- this is the magic
  computer.beep()
  print(i)
  if os~=nil and os.sleep ~= nil then
    os.sleep(1)
  end
  i = i + 1
end

[exa-byte]

This is still a great issue, is there any way this could be fixed?

[sshilovsky]

To work around this issue in OpenOS, save the following to /boot/40_bug2302.lua on the hard drive of your robot:

-- workaround for #2302: https://github.com/MightyPirates/OpenComputers/issues/2302
local event = require('event')
local component = require('component')
local gpu = component.gpu
local screen_address = component.screen.address

local function rebind_screen()
    if gpu.getScreen() ~= screen_address then
        gpu.bind(screen_address, true)
    end
end

event.listen('key_down', rebind_screen)

event.listen() should probably be called for other input events also.

[payonel]

@Fingercomp this doesn't repro for me in 1.7.10 - are you SURE it repros in 1.7.10 for you?

[payonel]

okay, now it repro's on 1.7.10

[LemADEC]

Issue was only fixed for robots, computers still reproduce the issue.

[payonel]

@LemADEC comment on multiple issues if you are seeing multiple separate bugs repro. if you think this specific bug is still open, feel free to provide repro about this specific bug.