This is useful because proper shutdown routines can be programmed in based on the event. It also causes no problems because if a particular function runs too long, the computer errors and shuts down anyway. It's just a nice little utility. And I know you could program this manually by overwriting os.shutdown and os.reboot but that doesn't work for the keyboard shortcuts.
This is a read-only snapshot of the ComputerCraft forums,
taken in April 2020.
Shutdown Event.
Started by ElvishJerricco, 01 September 2013 - 03:27 PMPosted 01 September 2013 - 05:27 PM
This is another suggestion I have that I know has been denied before, but think that's only so because the right details weren't thought of. I think that whenever the computer is shutdown, a shutdown event should be fired, and then one coroutine cycle should be allowed. That is, push a shutdown event and whenever the coroutine yields, shutdown no matter what.
This is useful because proper shutdown routines can be programmed in based on the event. It also causes no problems because if a particular function runs too long, the computer errors and shuts down anyway. It's just a nice little utility. And I know you could program this manually by overwriting os.shutdown and os.reboot but that doesn't work for the keyboard shortcuts.
This is useful because proper shutdown routines can be programmed in based on the event. It also causes no problems because if a particular function runs too long, the computer errors and shuts down anyway. It's just a nice little utility. And I know you could program this manually by overwriting os.shutdown and os.reboot but that doesn't work for the keyboard shortcuts.
Posted 02 September 2013 - 02:21 AM
Yeah, this is good. I am making a "remote mount" program, which mounts remote files onto your local computer via rednet. If this was implemented, I would be able to stop people screwing up the program.
Posted 02 September 2013 - 06:50 PM
I agree, however, one coroutine cycle is a max of 5 seconds, so i think its last cycle should be atmost one second.
Posted 02 September 2013 - 07:12 PM
Posted 02 September 2013 - 10:20 PM
Please read the damn OP. I stated I think the reason it's been denied is because I don't think the right details have been thought of. The way I describe it, I think would be just fine and very helpful.
Posted 02 September 2013 - 11:13 PM
actually, i dont see it being denied anywherePlease read the damn OP. I stated I think the reason it's been denied is because I don't think the right details have been thought of. The way I describe it, I think would be just fine and very helpful.
all i see is positive comments
i dont see why its in that list .-. its a great idea
Posted 02 September 2013 - 11:35 PM
The only reason I can think of to deny this particular implementation of the idea is because if the game crashes, they probably can't fire shutdown events and wait for all their coroutine cycles A ) because that's to much to do in a crash scenario and B ) because crashes are likely (but not guaranteed IIRC) to give mods zero chance to do some game-close routines.
Posted 03 September 2013 - 12:01 AM
Most crashes are exactly that, a crash, even Minecraft doesn't get to cleanup, so mods definitely don't! The only crash that mods do (and I'm pretty sure they actually can) is when it's a handled crash and you get the proper crash screen. Even so, this would not be grounds to reject an idea. Otherwise if it was they could reject any idea based on problems when the game crashes :P/>-snip crash talk-
Posted 03 September 2013 - 01:39 AM
It's on the Do Not Suggest list because the developers wanted it there. While it would be nice, it wouldn't be reliable. Make sure you keep track of your state or keep your state clean at every yield and you won't have issues. Locked.