I'm just going on the basis that most of the ships we send out to the planets have at least one DG or such like in tow, hey presto start cart on site

Could be done, but would be completely independent from the vessels actual functions. I.E. I could draw gigawatts from a DGIV that has its systems powered down. I'm not sure if I like the idea.
Rescue missions would always be possible with another IMS vessel, of course.

Also, the crew won't die of lack of electricity. They'll die on the implications of lack of electricity, which in space usually means freezing to death over the course of several weeks...

Will storages be providing resources without power?

As for gigawatts from DG - as far as I know we can transfer hundreds of tons of resources from the same DG

EDIT:

Oh wait, we can't - it works another way...

Thats what I thought you would say and logic tells me that a simple one liner in a config file cannot control the flow of juice, I.E put a maximum limit on it.

This is true but I'm guessing people would get into a rescue situation because they couldn't look after the first ship properly, let alone a second ship.

Yes yes your right, just throwing ideas about

It's kind of tricky, really. a power outage is a non-critical failure for most modules, nothing really gets damaged by it. In reality, the problems arise as a consequence of not having power, a power failure doesn't damage anything, as opposed to, say, a fire.

This is a problem in IMS, because the simulation for many module types isn't deep enough to really simulate those consequences. Habitats without power will inconvienience the crew, but since I don't have a crew simulation, that aspect is lost. Storage modules would loose refridgeration (if it even has refridgeration), but I don't have refridgeration I could loose. So a power failure can seem a bit inconcequential for some modules. I think taking habs out of temperature equalization (no ventilation) might be an incentive to power them up.
Damage will usually only result from overheating and undercooling. Which are conditions that will set in with certainty if there is no power at all (no cooling systems running, no heating, no life support working etc.), but modules who are not central to ships operation can be shut down individually with almost no ramifications.

Yup, exactly my point.

It's no problem at all to put a maximum output on it, but it won't be connected to the ships systems in any way. It can't actualy drain the other ships batteries or check if the other ship even is under power atm.

EDIT: just occured to me that by limit on flow of juice you coud have meant an energylimit, not a powerlimit. An energylimit would be rather complicated, that's true.

Well, as for storages - with the last update they have a working temperatures range of 10 K with optimal temp lying right in the middle, you can call it refrigeration. And they are temp.sensitive trusses now, so no air connection with habs. It is purely experimental, but if it will work - why not?

How fast will crew die? If temperature drops below minimum will they die instantly or will their pulse be slowing until death conditions arise?

No, I can't, because refrigeration would imply that the coolant has a higher temperature at the heat exchanger than what it's actually cooling. I.e. if those modules are refrigerated, they should be able to connect to radiators that are some Kelvins hotter than they are on the inside, but they can't...

Instantly. The problem is again a lack of depth: realistic would be a chance of injury, depending on how fast the buildup went, and regrouping in modules with better conditions. The crew would be a bit cramped, which will affect them in the long run, which I can't simulate. I don't have any provisions for injuries either, neither to cure them nor to affect performance of an injured crewmember. So, instant death on critical failure is the best option, even if not very realistic, because other options again result in a null-punishment.

Well, in that case I prefer to think of storage modules as a 'black box' refrigerators which takes power from IMS and returns heat from its own internal radiators dropping it into MCS. Temperature readings of IMS then stands for fridge radiator temp interfaced with MCS, having it out of working range results in fridge malfunction and hence losing consumables.

Well, it still doesn't change the fact that nothing happens if the power goes out

So far everything is working (or should I say failing) quite nicely, now I'm trying to streamline the incomprehensibly different nature of the command module into the other module routines, which is a bit tricky and might lead to some new bugs... let's see how this works out.

Well, to think of it, the worst thing that can happen with a fridge being cut from power is overheating... which will eventually cause the loss of resources.

The worst thing to happen is losing power to liefsupports. If the supply of stored consumables isn't big enough for a crew to survive a long period of time (and not to forget about decaying of stores kept in unpowered fridge) they're a bunch of dead UMMUs alright.

In which cases power cut situation may arise? Reactor overheat, manual disabling, anything else?

Speaking of punishment, I can see why you want to make user to feel the pain, but having enough real-life experience of maintenance of different electrical and electronic systems myself I can tell you that all systems like that has a good deal of protection and backup circuits made specifically to prevent 'punishment' situations. That's why I don't see any reason why you need to worry about too little punishment, at least regarding power distribution. Our power system is completely closed-cycle (in all the cases except of external supply situation or using a solar array) and hence should be fully under our control. The cooling system is another matter since it's open-cycle with heat coming from and going to outside.
So much we have only two punishments for a no-power situation: no control over cooling/heating and no control over anything at all. I'd say it is well enogh. (Oh yeah, there's the third - no regeneration. Even better.)

Currently I see the following damage simulation scenarios:

1) Reactor is being overheated to a critical temperature because of a lack of connection to deployed radiators (human error) or radiators cold enough (too close to the Sun, or maybe it's connected to the same radiator as NTR). It results in automatic reactor shutdown and IMS being powered by batteries. If the reactor isn't being restarted prior to a full batteries discharge the general power fail occurs. Vessel lose control, lifesupports stops to regenerate consumables, MCS stops to deliver heat to radiators. The vessel is either being heated (too close to the sun) or being cooled (too far from the sun) by itself until different modules go out of their temperature range. I'm pretty sure that with the current configs storage modules will be first to fail, and with lifesupports offline it will result in a quick death of a crew. Maybe even too quick. If there's no storage capacity and no regeneration, will they die instantly in the moment it happens?

2) Overheating or undercooling of some separate modules except of a reactor.
What will happen if storages' temp is out of working range but lifesupport is still online? Will it be enough for crew to survive or is at least some little storage necessary?
Lifesupport fail is a clear case. As long as we have our storages in working range everything's OK.
Overheated radiators just stop to radiate heat and it causes a heat-rising avalanche which will result in a general fail pretty quick.
Habitats temperature fail. Sudden death.
Solars array overheat. Well, it's all the same as reactor fail except that they won't cool down by themselves when disabled, at least on the same orbit.
Anything I forgot?

Well, there's a CM of course. Unpowering it will cause the loss of control. Overheating it will result in the same. Some of them also have a crew capacity which will be affected too.

That's clear, but the punishment must be there to give the feature any meaning. If it doesn't matter wheather or not a module has power, you might as well just leave it unpowered, I.E. the power feature is not required because you're actually better of not powering a module: Drawbacks zero, Advantages are power saved and less heat produced. Of course, this is only really an issue currently for habitation and storage. Habitation has at least a bit of a drawback in that the module won't equalize temperature with other modules anymore, so you have at least a potential issue. For storage, on the other hand, there's no difference wheather or not they have power, so we might as well leave them unpowered...

Finished my streamlining, getting a ctd that should have absolutely nothing to do with the changes I made. Very annoying...

Yes I was refering to your point of drawing gigawatts from a delta glider, and the fact that for IMS to restrict how much you could get from a single docked ship isn't as easy as adding a single line to the config file.

gigawatts is a unit of power. It is absolutely no problem to declare a maximum power output in a config line. The problem is energy (for how long you can draw a certain amount of power, if you will, since power is energy per time). While no problem to declare in a config, measuring how much energy has been drawn is a pain, and saving it a major hack, as the other vessel can't keep track of it, unlike propellant, of which it can keep track just fine...

yeeessss
I think i'm getting my powers and energies mixed up

I think you get the idea of what I'm trying say

Well, the only reasonable way I see here is to prevent unpowered storage from active cooling or heating. It aslo means that storages should be temp.sensitive by default.

Ok here's a thought, whats to stop a ship docking with another ship or station, transfering all the resources of the source ship or station and killing all the crew onboard?
Is there anyway we can have a saftey net so that when the source ship gets to 25% of a given resource the transfer stops, unless its a cargo container?

A good point. Maybe a safeguard preventing from transferring the last drops of consumables when there's anyone on board. Also the safeguard needed to prevent transfer on a vessel that has no consumables left. This safeguard should be implemented on receiving vessel.

So far, nothing. Would be easy enough to implement a certain reserve for the current crew size (so you can at least empty it out if you transfer all crew), but for how long should that reserve be? a sensible limit might vary from vessel to vessel...

Could it be user configurable?