Wake on LAN (and/or Redstone), Reboot after Power Failure, Reboot after Error

[Hotrian]

I am requesting these features I haven't seen discussed anywhere
Each of these features would either have to be enabled manually by lua script, in some manner similar to setting a BIOS flag; Or these options could physically exist in the BIOS code and require recrafting the EEPROM to change. An example of this might be computer.setBiosFlag( option, value), though I don't know if BIOS flags already exist. There should also exist a server config option to globally disable each of these, in which case attempting to use or set them would always return nil or false.

• Wake on LAN (and/or Redstone)
• Reboot after Power Failure
• Reboot after Error (Kernel Panic)

Wake on LAN and/or Wake on Redstone
The wikipedia explains this feature well. This is a typical feature of real computers.
This feature would allow one computer to remotely power on another computer, provided it has the exact and complete machine address, is connected via LAN, and the remote computer has been configured to do so. I'm not sure if this feature is technically possible with the current setup, or if it is even possible at all. Alternatively, Wake on Redstone would allow a computer to be remotely started when it receives a vanilla Redstone signal, provided it has been configured to do so. Both features would require their respective cards, either a Network Card (Not Wireless) or a Redstone Card (not sure which tier). Robots might be allowed to use these too if that fits the theme.

Reboot after Power Failure (Restore Power State after Power Restore)
This feature would allow a computer to reboot automatically when power is restored if it has been configured to do so. This is a typical feature of real computers. The manual for my motherboard explains the options well:

When set to [Power Off], the system goes into off state after an AC power loss. When set
to [Power On], the system will reboot after an AC power loss. When set to [Last State], the
system goes into either off or on state, whatever the system state was before the AC power
loss.
Configuration options: [Power Off] [Power On] [Last State]

Robots could be allowed to use this as they could run out of power next to a charger that doesn't have enough power, only to later be charged, or someone could build a charger line next to them.

Reboot after Error (Kernel Panic)
This feature would be similar to a Kernel Panic that features automatic rebooting. This is a typical feature of real computers. This would allow computers that have encountered a fatal error to automatically reboot and resume operation if they had been configured and programmed successfully to do so. Preferably, and unlike real computers, an alternate setting would cause all errors to be treated as fatal errors. If this setting was not enabled, a fatal error must be thrown to auto reboot. Regular errors would drop back to the shell as usual. If this feature is seen as too overpowered, perhaps the Kernel Panic could take a bit of time (as they often do), and/or energy. Non-fatal errors should take less time to recover/reboot from. Optionally they could dump a stacktrace and additional information as real Kernel Panic's often do. The reboot wouldn't fail if the disk drive was full, but it wouldn't generate a dump. Each Kernel Panic would set a flag that must be cleared by the OS that prevents a Kernel Panic from getting stuck rebooting the OS and failing forever. Alternatively, an automatic reboot cannot occur twice within some set period of time, say 30 seconds. Robots could use this feature if that wasn't seen as too overpowered.

Each of these features could be seen as overpowered depending on how they're used, but these are real features that exist in real computers. It may be possible to write these from the LUA side, but I haven't seen or heard of such.

Sorry if these features already exist or are available and I am just unaware.

[magik6k]

Well, all this stuff is already more-or-less doable.

• Wake on lan can be done through computer component(http://ocdoc.cil.li/component:computer)
• +1 To reboot after powerfail(at least let eeprom/init decide what to do).
• Reboot after kernel error can be coded into eeprom/init.lua, Doing it by default(i.e. by machine.lua) may be unsafe. I think that I can put this functionality into openloader loot disk if it isn't there already

[Hotrian]

Thanks, I will look into those. I would appreciate the openloader feature if it doesn't already exist and you feel like adding it.

[Hotrian]

Unless I'm mistaken, the computer component cannot be used for WakeOnLAN unless triggered by an adjacent computer. This would require a second computer to sit on standby to startup the primary computer when it received a certain network message. This more or less defeats the purpose (though could still be utilized to (re)boot a computer which isn't responding to network messages), because if the second computer went down for some reason, it would have to be manually restarted. This could only do what I was hoping for if all of my computers were placed adjacent to one another, and organized such that the primary computer could activate/deactivate all sub networks/programs from a full shut down scenario.

[fnuecke]

This kind of fell off the table after being put on the backburner due to people being satisfied when being told they can power on computers using Computronics + BC gates the last time this popped up.

I'm not too keen on having this in computers themselves, but I might add a new block to take on this functionality. "Power Controller"? "Power Manager"? Meh. Anyway, that block would be configurable via its component (blah.wakeOnLan('string it has to receive to trigger'), blah.wakeOnRedstone(requiredSignalStrengthToTrigger) and such).
Will have to find the motivation to do the textures, first, though >_>

[Hotrian]

Is it already possible to get the amount of energy a computer has used up? It seems like it would be possible to tap in by calling computer.energy() and keeping track, but it probably wouldn't be accurate. Maybe there is an API that tracks this already?

If not, perhaps you could add onto this block with power statistics that keep track of power usage during lifetime and session, could be disabled by default to reduce calls when it isn't being utilized by the user anyway. For this to work, the computer would instead pull energy from the "Power Controller" if one is attached (which should allow for them to be placed inline if the computer didn't need the cable connection except for power). Then with a call to blah.setPowerTracked(true), blah.getPowerLifetime() and blah.getPowerSession() would return the quantity of power that has been consumed. The Session value would be reset when the computer powers on with blah.setPowerSession(0) and blah.setPowerLifetime(value) would also be exposed if the user should want to (re)set the stats.

So such an API could look like
blah.setPowerTracked(bool)
blah.getPowerLifetime()
blah.getPowerSession()
blah.setPowerLifetime(value)
blah.setPowerSession(value)
Probably with better method names

You could then easily determine how much power was going through a given computer. It still wouldn't be 100% accurate at any given time, but without it I don't think you can reliably track how much energy has been used.

I suppose you could throw in a blah.getPowerTracked() just for consistency, but I don't think it would be needed.

[Vexatos]

@fnuecke How about a literal PSU you can place adjacent to a case to do this?

[Hotrian]

Also, it would be cool if it were a small tileentity instead of a full block, that could be attached between a cable and a case, and share the block with the cable. If it could also share the block with other PSUs like how you can place multiple torches in the same block, that would be awesome. Been playing since classic but only recently got into building mods, so not sure what exactly can be done. You'd attach it to the side of the case you wanted to control/monitor, and if there was a cable in that block already the cable end would move back to accommodate. I assume it's easier to determine which case it should be attached to that way.

Edit: If it were 8x8x4 or 6x6x4 pixels there would be just enough space for the cable ends, and it would be relatively easy to make textures for.

[Eunomiac]

(I feel like I've mentioned this before, so my apologies if I'm repeating myself, but I can't seem to find it.)

I'll second the request for a "Reboot after Error" feature, specifically: Server hiccups can cause "too long without yielding" errors in even simple programs, and currently the only remedy (of which I'm aware) is a manual restart. Among other things, this makes OC use in adventure map design a bit dicey---players are unable to access Creative Cases to trigger a reboot (and, even if they could, there's that whole immersion-breaking thing that it would be nice to avoid).

On another note, I'd be very happy to work on textures for new blocks; just let me know. (It'll make me feel better about the whole "not being able to program in Java" thing!)

[jpastuszek]

Reboot after Power Failure is a must have for microcontrolers IMHO and should default to Last State.

[fnuecke]

@Hotrian regarding power tracking, to make that possible every power node would have to track its energy input/output, which is more overhead than I'm comfortable with. Maybe at some point, when I refactor that system (read: maybe in 1.8).
Regarding non-full block: the way you describe it would need either a custom multi-part implementation or FMP. And I don't want that as a hard dependency. It'll also act like a cable anyway, since it won't be sided, and easier to implement as a full block because no custom rendering, so... that's what it'll be ;-)

@Vexatos "literal PSU" as in you need it to make the case work at all? Nah, too many steps involved to set one up already for that to be reasonable IMHO.

@Eunomiac if you have a particular design in mind, by all means! In case you didn't know already, this is where the PSDs with the raw data live. Basically just base it off an existing entry in blocks.psd.

The API as I'm currently imagining it would be:

• setWakeOnLan(enabled:boolean, key:string)
  Where key would be the string data that has to be received for it to trigger. This can be a simple "power" or a secret key.
• setWakeOnRedstone(enabled:boolean, threshold:int)
  Where this will require a pulse exceeding the specified threshold (i.e. redstone input has to spike from zero to threshold for it to trigger).
• setKeepalive(enabled:boolean, interval:number, erroredOnly:boolean)
  If enabled, checks in regular intervals (real-time seconds, has a minimum value to avoid abuse) if the machine is still running, powers it back on if not. If erroredOnly is true, will only do so if an error caused the shutdown (not enough energy, crash).

Which should cover everything mentioned above?

Btw, I don't think the block will get a GUI. Because one to make it fully configurable to that extent would be a pain to make :P (for me, anyway)

[Hotrian]

@fnuecke Those would be great, and that's what I had assumed about power tracking and multiblocks. They're not a big deal anyway, just trying to throw out some more ideas.

[Vexatos]

@fnuecke Rather an "Advanced Power Converter", similar to a Power Converter, plus the turn-on-or-off feature if placed adjacent to Cases.

[MyNameIsKodos]

What about wake on redstone being put in as a feature of T2 Redstone cards, and wake on LAN being a feature of Network cards

Also, having a PSU as an additional required component in computer cases might be interesting too, but would require a rework of the GUI.

[fnuecke]

@Vexatos Kind of a T2 Power Converter? Or rather a T2 Power Distributor? Hmm. Either that, or add the "keepalive" functionality to the existing Power Distributor/Converter block and move the other two to the cards as @Kodos-Atoz suggested - which would require some internal restructuring though (nothing too massive I think, though).