Change how computers are unloaded/loaded

Alrighty. This suggestion is assuming I know my ComputerCraft well enough. I've heard that once a computer is unloaded it essentially shuts down. Since dan200 wants to keep the presentation correct, not break the fourth wall, and avoid having an unloading event, I have come up with an alternative solution.

Simple: When a computer is unloaded, have it suspend its running state. Then, when loaded, have the computer resume. (think virtual machine states here, it's a similar idea/concept).
EDIT: Apparently this would require massive backend changes.

Alternative Solution:

Hmm. Would it be possible to keep the computer running (only the program, not the block) and simply hold it, keeping it from running the next line of code? Therefore it still loads the computer, keeping its execution state, but it doesn't run anything?

This would produce a similar effect, and although the computers would still deactivate at server restart, it's slightly better than deactivating at every reload.

This way it behaves like you'd assume most things to behave in Minecraft: they pause when deloaded and resume when loaded. As well, this allows for a lot less confusion with new users. Finally, it allows for less things to break (as long as they are coded to accommodate the possibility of being paused and resumed later, i.e. time-based stuff).

This has (as far as I'm aware) been on the desired-features list for a very long time. Unfortunately, the way it is currently set up means that serializing the Lua state to make it resumable later isn't a simple task. From what I recall, making this change would mean no longer using LuaJ as the back end of things, which could be a massive amount of work.

Lyqyd, on 05 April 2015 - 05:35 PM said:

This has (as far as I'm aware) been on the desired-features list for a very long time. Unfortunately, the way it is currently set up means that serializing the Lua state to make it resumable later isn't a simple task. From what I recall, making this change would mean no longer using LuaJ as the back end of things, which could be a massive amount of work.

Hmm. Would it be possible to keep the computer running (only the program, not the block) and simply hold it, keeping it from running the next line of code? Therefore it still loads the computer, keeping its execution state, but it doesn't run anything?

This would produce a similar effect, and although the computers would still deactivate at server restart, it's slightly better than deactivating at every reload.

Apologies if this is impossible/very difficult as well.

cyanisaac, on 05 April 2015 - 05:45 PM said:

Would it be possible to keep the computer running

No idea in the viability of this option, but it will still have issues if the server shuts down.

Ignore me, I can't read.

cyanisaac, on 05 April 2015 - 05:45 PM said:

Would it be possible to keep the computer running (only the program, not the block)

Considering that scripts can interact with redstone states or peripherals at any time (which requires the computer to know what's around it, which requires a loaded chunk…), I'm doubting it. And then there are turtles, which frequently move around the world and interact with mobs / blocks / etc…

Bomb Bloke, on 05 April 2015 - 11:21 PM said:

cyanisaac, on 05 April 2015 - 05:45 PM said:

Would it be possible to keep the computer running (only the program, not the block)

Considering that scripts can interact with redstone states or peripherals at any time (which requires the computer to know what's around it, which requires a loaded chunk…), I'm doubting it. And then there are turtles, which frequently move around the world and interact with mobs / blocks / etc…

He was saying for the program to just stop at the line it was on when the block was unloaded and then resume when the computer is reloaded, so the code is not actually running when the chunk is unloaded.

It'd likely be possible to rig something up whereby events aren't passed to systems that're no longer in unloaded chunks, effectively pausing them. But one fairly major problem (and there's likely others; this is just the first that comes to mind) would be timer events - if these fire, they need to be passed, they can't just be discarded.

You could in theory create a buffer to store these timer events until such time as the computer is chunk loaded again, but it'd be a finicky business. You wouldn't be able to just dump them all into the system's queue as soon as it becomes possible to do so, as the system may be expecting delays between the events and could malfunction as a result.

Even assuming a system is implemented to track the gaps between these timer events and fire them at the correct pace… the whole thing still falls over when the server gets shut down, so nothing is really being achieved by all that work. Users still need to build their scripts to deal with unexpected restarts anyway.

this has been a common request in the past

to sum up past request results: true persistence requires CC2.0 so we will stick to the current system of recoverable shutdowns

the forums has some persistence stuff