event to tell a computer that it is about to be unloaded

So a event would be fired when the chunk the computer is in will be unloaded or the server is being shut off.

This (or a similar version of this) has been suggested repeatedly. One of the major issues with the idea is that it breaks the fourth wall–computers in the world wouldn't have any concept of being "loaded" or "unloaded", as chunk loading is an aspect of Minecraft made necessary by technical limitations, and is only apparent to players, and would not be visible to the characters that inhabit the world.

How does an event like this break the fourth wall more than computers losing data because you walked away from them?

There are ways to preserve sensitive data on the computer. It really depends on what program you want to run. If it's just a door lock then you can put it as a startup file, which will run every time a computer starts.

Lyqyd, on 28 March 2015 - 04:55 AM said:

This (or a similar version of this) has been suggested repeatedly. One of the major issues with the idea is that it breaks the fourth wall–computers in the world wouldn't have any concept of being "loaded" or "unloaded", as chunk loading is an aspect of Minecraft made necessary by technical limitations, and is only apparent to players, and would not be visible to the characters that inhabit the world.

This seems quite silly to me. Wouldn't it make sense to add the feature in anyways?

This mod isn't about presenting stuff. It's about programming.

an event for when the computer is about to shutdown would work and not break the 4th wall, just get the event to fire a few seconds before the computer actually turns off/unloads

I did request this before, but it was not accepted

MKlegoman357, on 28 March 2015 - 04:12 PM said:

There are ways to preserve sensitive data on the computer. It really depends on what program you want to run. If it's just a door lock then you can put it as a startup file, which will run every time a computer starts.

Not really.

Writing to the HD is the only "good" way, and it a) hammers the HD (at least in a lot of cases), and B)/> isn't reliable. The world saves out of sync with the filesystem, so if you save that you've done something to the HD and then the world gets forcibly unloaded, you'll often find that the file saved but the world didn't. It's especially annoying with turtles.

There's also the whole "computers don't always start up until they get updated or opened" thing. Speaking of 4th wall breaking…

The Lone Wolfling, on 29 March 2015 - 11:43 PM said:

There's also the whole "computers don't always start up until they get updated or opened" thing. Speaking of 4th wall breaking…

…. which, sadly, is still a thing under 1.73.

The way I see it, warnings when unloads occur would be nice, but I don't see them as viable.

Sure, they'd break the fourth wall, but so does the lack of persistence. The ideal solution would be to implement persistence, but the ramifications of doing that would likely justify calling the result "ComputerCraft 2". So assuming persistence "isn't going to happen", an event would be the "next best thing".

The real issue is that the event just isn't likely to help. Let's say you've got a turtle moving along, and mid-movement, the event goes into its queue. Odds are the server's going to shut down before it gets a chance to catch it - assuming it doesn't just simply discard the event while searching for the "turtle_response" event indicating the movement is complete!

Granted, in the latter case it can be grabbed anyways with decent coroutine management, and to deal with the former it might be possible to have ComputerCraft delay server shutdowns in an attempt to get all its "last second processing" done. But that's still putting aside the point that the event might not ever get a chance to go into the queue in the first place, because MineCraft servers can crash. However you look at it, a script just isn't going to be able to rely on these events, and one which attempts to stands to backfire.

To my understanding, a turtle's fuel level can be relied upon no matter what happens. I gather code has already been written to take advantage of this.

Bomb Bloke, on 30 March 2015 - 12:28 AM said:

To my understanding, a turtle's fuel level can be relied upon no matter what happens. I gather code has already been written to take advantage of this.

Lama did/does this, the post is a bit old now, but I hope to be able to update it for my Hive project

Bomb Bloke, on 30 March 2015 - 12:28 AM said:

[stuff]

To my understanding, a turtle's fuel level can be relied upon no matter what happens. I gather code has already been written to take advantage of this.

Fuel level however, unfortunately, doesn't work for some cases. Namely: rotations and inventory management.

Now, there is actually a solution, and I've got it working, on my machine at least. Unfortunately, it requires a peripheral currently, although I believe it could be implemented without too much trouble into CC itself. The way it works is as follows: the peripheral exposes three methods: writeData, readData, and hasStateChanged. Write saving a string, read reading a string, hasStateChanged returning a boolean. When you call write, it saves the value to NBT. readData returns that data. When you call writeData, it also writes the turtle's current state to NBT. When the turtle is updated for the first time thereafter, or when you call hasStateChanged, it returns if the turtle's state has changed since when you called writeData.

So basically, you can get 90% reliable resyncs by doing the following: writing the current state in the program with writeData(str), then doing whatever. Repeat. On startup, call readData() to get the state, then call hasStateChanged() to see if the last action you were about to do went through.

There still is a race condition, theoretically, but I have yet to encounter it. (If the turtle's NBT is in the middle of being saved when the server goes down. However, there's really no way around this. And on atomic filesystems it shouldn't be a problem anyways.)

(You need readData / writeData because the turtle's filesystem is not atomic with the chunk state.)

Rotations don't fail under any circumstances that I'm aware of, and inventory manipulation a can be checked behind the scenes beforehand to ensure success or failure before attempting the action.

Lyqyd, on 30 March 2015 - 04:37 PM said:

Rotations don't fail under any circumstances that I'm aware of, and inventory manipulation a can be checked behind the scenes beforehand to ensure success or failure before attempting the action.

Both of those are susceptible to race conditions. Not to mention that currently they both suffer from the whole "filesystem isn't synced with world state" thing.

Let's say you write the current rotation to a file, then rotate, then write the current rotation again. Even ignoring the second issue above, what can happen is that you write the rotation state to the file, then the chunk unloads. So you've written that you are about to take a rotation. But you have no idea if the rotation actually happened or not. Before you say "that won't happen often" - yeah, it does. Often enough that I gave up even trying with my quarry script. And just went to the peripheral-based system above.

Or let's say you are trying to put something in a chest. You check for space, it says there's space, then something else puts something into the chest. All of a sudden when you actually try to put things into the chest it doesn't work. Again: race condition. You cannot, in general, assume that just because you've checked something in advance that it will actually work when you actually go to do it.

Your second example is equivalent to saying that you don't need turtle.move() to return if it moved, because you can always check beforehand with turtle.detect(). And has the exact same flaw.

And with the second issue above these are even worse.

Now, if you've got a method that will reliably rotate, I'm all ears. But until/unless I see someone post a script that, say, rotates left 400 times and comes back to the starting position reliably through restarts / chunk unloads, without relying on external hacks (such as placing blocks or gps+movement or reserving 2 inventory spaces for keeping track of rotation. And the last is still susceptible to a race condition, and the first doesn't work in all cases. Ditto with the second.)…

Well, Lama somehow managed it. For inventory, getting a result and saving it for later use is of course a bad thing, because it's not just server restarts/chunk reloads that can cause a change in the inventory, so you just check the inventory right before you make actions with it. For rotation, you can first save the updated state and then rotate. For your 'file system is out of sync thing': I haven't came across this issue. I believe it is because turtle functions yield. So, if you start rotating (turtle.turnLeft for example) and after the first yield the chunk unloads then the code after turtle.turnLeft/Right will not be ran. That's why you have to first save the updated state and then do the movement.

MKlegoman357, on 30 March 2015 - 07:28 PM said:

Well, Lama somehow managed it.

Lama managed it for translational movement. For rotational movement, not so much. Again, race conditions.

MKlegoman357, on 30 March 2015 - 07:28 PM said:

For inventory, getting a result and saving it for later use is of course a bad thing, because it's not just server restarts/chunk reloads that can cause a change in the inventory, so you just check the inventory right before you make actions with it.

Again, that's still a race condition. You can minimize the window that way but you cannot eliminate it.

MKlegoman357, on 30 March 2015 - 07:28 PM said:

For rotation, you can first save the updated state and then rotate.

Again, again, still that's a race condition. As I have said multiple times, you can minimize the window that way but you cannot eliminate it.

MKlegoman357, on 30 March 2015 - 07:28 PM said:

For your 'file system is out of sync thing': I haven't came across this issue.

The reason you haven't come across it is that most of the time it only is an issue if there's something forcing an unload, as opposed to it saving normally. The most common cause of this being crashes.

The Lone Wolfling, on 30 March 2015 - 08:05 PM said:

MKlegoman357, on 30 March 2015 - 07:28 PM said:

For your 'file system is out of sync thing': I haven't came across this issue.

The reason you haven't come across it is that most of the time it only is an issue if there's something forcing an unload, as opposed to it saving normally. The most common cause of this being crashes.

Crashes or even closing the window instead of quit to menu seems to force an unload. If the turtle is mid-movement then NBT often isn't saved so you can end up getting one/two empty turtles where the original turtle was moving from. I just can't see this being implemented unless we get the entire persistence thing (and that will happen at the same time we upgrade to Lua 5.3 :P/>) and even then I can see issues with the world and the Lua state being out of sync.

SquidDev, on 30 March 2015 - 08:40 PM said:

we upgrade to Lua 5.3 :P/>)

Since when did Dan200 say he was going to which to Lua 5.3?

Edit: [/sarcasm]

Lupus590, on 31 March 2015 - 01:51 AM said:

Since when did Dan200 say he was going to which to Lua 5.3?

He didn't. That's the point.

I was aware, guess my sarcasm didn't go through the text.

One of the many times where you can realise that text is a very bad way at conversing.

A poor workman… ;)/>