Why ElectricCharge on Engines?

[DesTroy]

This is something I have been wondering for the longest time, as it causes so many issues.

Whenever an engine has this in it's cfg:

RESOURCE
{
    name = ElectricCharge
    amount = 0
    maxAmount = 0
}

It will cause a NaN bug to occur on the ElectricCharge tweakable if one right clicks the part... which then screws up the mass of the part, which affects things like fund costs, CoM marker from showing up, and all sorts of other calculations.

The fix is simple, remove that resource block from the cfg.

The question I have is.... why do modders KEEP ADDING THIS IN? It's completely useless, it's max charge is 0, so why even list it? I don't understand. Even some stock parts still have it? Why?

Some modders (And also some MM 'fixes') add "isTweakable = false" & "hideFlow = true" to the code block to negate this problem. But WHY? Why are you so insistant in keeping that block at all?

I always delete these code blocks.... Is there something I am not aware of? Is it needed for some crazy, unforeseen reason or bit of code that uses it? I have not noticed any ill affects thus far... Alternators still work on the engine too, so that's not an issue.

Can anyone answer these questions? I am interested to know the reason

If it is indeed unneeded (Which I totally suspect) Then let this be known to all modders... Stop wasting everyone's time, including your own, and just don't include this code block!

PS NOTE: I am not talking about the ModuleAlternator code block:

MODULE
{
    name = ModuleAlternator    
    RESOURCE
    {
        name = ElectricCharge
        rate = 5.0
    }
}

It is not the problem, and I don't mean to remove this.

Edited July 26, 2014 by DesTroy
Clarified about Alternator block vs. separate resource block

[Master Tao]

It's so that the engines can generate electricity, simulating an alternator. There's no storage, but when you're running most engines in the game, they provide electric charge.

[DesTroy]

Master Tao, sorry, but you are incorrect.

The code for generating electricity is the "ModuleAlternator" module block:

MODULE
{
    name = ModuleAlternator    
    RESOURCE
    {
        name = ElectricCharge
        rate = 5.0
    }
}

Which, as I stated in my first post, still works without the completely separate:

RESOURCE
{
    name = ElectricCharge
    amount = 0
    maxAmount = 0
}

That resource code seems, for all purposes, useless.

Edited July 26, 2014 by DesTroy

[RSF77]

This was bugging me on some spaceplane designs a while ago. If I can remember right you can adjust the resource slider from empty to full, it still stays 0.0 but resets the center of mass so you can see it and whatnot. I might be wrong about this because I haven't tried to make a spaceplane since .23 but I know there is a way to do it right there in the hangar and reset it, unless that itself has changed.

[DesTroy]

I heard you can do that to fix it, but it has never worked for me, because the slider doesn't always respond to tweaking..

It is ultimately besides the point, because the code block shouldn't be there in the first place.... remove it from offending parts, and you never have to worry about it.

[NathanKell]

My guess is that in early revisions of KSP, it didn't work without the RESOURCE node.

However, now, it is apparently unneeded.

[Clockwork_werewolf]

Actually Tao is right. The alternator generates electricity but without any storage this can't be used harvested. The Air intakes store a tiny amount of air for this reason and the flow of air is defined by their storage as much as how much air they have coming in. The electric storage is not needed on any engine without an alternator and any storage of 0 is also useless so I have no idea why it is in there.

[nli2work]

just tested it with squad's LV-T30 engine, one with EC resource, another without.

Engine without EC resources will still generate electricity for the vessel and recharge batteries. All that's necessary is the Alternator module.

[Clockwork_werewolf]

I stand corrected. It must have worked that way once but it's not like we can see the code behind all of this so maybe it changed.

The air intakes still need it but that could be because there are no other air stores on any ships.

[Master Tao]

It's useful in some Why on Kerbin would you do that? edge cases. To use electric charge, you (usually) need a buffer for 0.02s worth of charge. The game doesn't actually allow 0 EC in a module, so engines with alternators all end up with (I think) 0.10 EC storage.

As a practical example, try this bone-headed rover (SPH craft file):

Javascript is disabled. View full album

Launch, move Jeb from the lander can to the command chair, decouple the lander can, and try to move using rover controls. Nothing should happen because there's no batteries. Next, fire up the LV-T30s, and try moving again. The LV-T30s are generating 14 EC/s, which is plenty to run the wheels and lights, and it works.

Next, repeat the test after removing this section from the LV-T30 (liquidEngine1) cfg:

RESOURCE
{
    name = ElectricCharge
    amount = 0
    maxAmount = 0
    isTweakable = false
    hideFlow = true
}

Same procedure, but it won't move because there's no buffer for EC.

It's also possible to build a rover with no batteries and 4 of the medium rover wheels. As long as there are solar panels, it'll move slowly and the wheels will complain of insufficient EC.

[nli2work]

Ah.. I see. interesting. the issue is not really generating EC, but consuming it. If the vessle has 0 EC capacity, then no amount of generation from engines will do any good.

[Eric S]

Ah.. I see. interesting. the issue is not really generating EC, but consuming it. If the vessle has 0 EC capacity, then no amount of generation from engines will do any good.

Pretty much. Generated EC can only be stored, and only stored EC can be consumed. I'm assuming at some point a modder ran into this problem, found that he could get around it by adding a small amount of EC storage to the engine, and that "solution" got copied around between modders. I don't see any time where this would be an issue with any of my designs.

[DesTroy]

Ok, now it makes sense as to why it's there...

So it's still effectively useless . A band-aid solution for non-robust code.

They need to at least fix the code to allow for 0 EC on a module, to stop the NaN issue. This would remove this issue all together.

But they should also set it up properly so that devices can use ElectricCharge directly from power generators when operating. Instead of having to rely on the quick duct-tape fix of 'Every generator is also a tiny bit of storage, and devices can use THAT'

I can see an easy solution:

-Simply add a hidden buffer of 'charge'. This doesn't need to be a whole new resource. Just let it be a sum of all the EC/s being generated by active gens/alternators. When a device needs EC, it can look at the buffer and subtract EC/s depending on it's consumption. If it doesn't have enough power, or there is no active gens (and therefore no EC/s in the buffer), then look to EC storage. If neither has sufficient EC, then it doesn't run (Or turns on/off rapidly, runs slower, as some things do now)

But all in all... It is safe to delete the code block then (Or add the "isTweakable = false" & "hideFlow = true" fix).... Just add batteries if you want to use (and store) electric charge. Though every command pod includes EC storage anyway. Alternators and power generators are unaffected.

[Master Tao]

They need to at least fix the code to allow for 0 EC on a module, to stop the NaN issue. This would remove this issue all together.

But they should also set it up properly so that devices can use ElectricCharge directly from power generators when operating.

I believe this MM config is the standard solution to the NaN bug. It adds those to lines to any engines with alternators that don't have them (except maybe the B9 SABREs):

@PART
[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]]
{
    @RESOURCE[ElectricCharge]
    {
        %isTweakable = false
        %hideFlow = true
    }
}

AFAIK, the EC buffer is the result of a Unity limitation, so not something SQUAD can change. In any case, real circuits generally need buffers, too:

In the past, I've designed a controller which wouldn't allow providing power to the engine if the available power of the battery was below a given point. No battery was not an option.

This was not a bug, but a feature. The specification clearly stated that if the system was low on power, taking readings would be possible without draining the system even further (by turning the engine on while it's low on power).

Not all systems are designed like this, but think about a laptop for a while. It will not return from hibernate if the battery can't support an active state (at least, it shouldn't).

Although laptops are built to either run from battery or directly from the transformer, so those have a workaround. I do however suspect there is a certain buffer (at least a decent capacitor) in this as well (although not comparable to a battery in amount of charge).

[DesTroy]

AFAIK, the EC buffer is the result of a Unity limitation, so not something SQUAD can change. In any case, real circuits generally need buffers, too

I highly doubt it's a unity limitation... It's something easily extendable. Besides they can easily make it so that when the maxamount=0 it doesn't freak out and say NaN. Unity doesn't have a limitation to displaying 0.

Regardless... I do agree that buffers are generally needed... Which is why I am telling everyone to remove the resource block in the first place. Make people need EC storage to power devices and receive charge from alternators. The Command pods already have a tiny EC storage anyway, so I see no point in keeping the code block at all.

[GDJ]

I've played with that bit of text for some time. At least for me, setting the charge to 1 and the maximum charge to 1 has done absolutely no harm to my game as far as I can tell.

Now, if removing that bit of code will improve the game, then I certainly will.

For me, if it ain't broke, it don't need fixing.

[DesTroy]

In all honesty, it probably won't make the slightest bit of significant difference if you choose to do what you did, or add the "isTweakable = false" & "hideFlow = true" fix, or if you delete the code block completely.

Though TECHNICALLY by removing it you are saving a tiny bit of memory as the game doesn't need to add that section to the part module... Even if it is just a few measly bytes...

[MisterFister]

Ok, now it makes sense as to why it's there...

So it's still effectively useless . A band-aid solution for non-robust code.

They need to at least fix the code to allow for 0 EC on a module, to stop the NaN issue. This would remove this issue all together.

But they should also set it up properly so that devices can use ElectricCharge directly from power generators when operating. Instead of having to rely on the quick duct-tape fix of 'Every generator is also a tiny bit of storage, and devices can use THAT'

I can see an easy solution:

-Simply add a hidden buffer of 'charge'. This doesn't need to be a whole new resource. Just let it be a sum of all the EC/s being generated by active gens/alternators. When a device needs EC, it can look at the buffer and subtract EC/s depending on it's consumption. If it doesn't have enough power, or there is no active gens (and therefore no EC/s in the buffer), then look to EC storage. If neither has sufficient EC, then it doesn't run (Or turns on/off rapidly, runs slower, as some things do now)

But all in all... It is safe to delete the code block then (Or add the "isTweakable = false" & "hideFlow = true" fix).... Just add batteries if you want to use (and store) electric charge. Though every command pod includes EC storage anyway. Alternators and power generators are unaffected.

Though TECHNICALLY by removing it you are saving a tiny bit of memory as the game doesn't need to add that section to the part module... Even if it is just a few measly bytes...

Surry dude, but you're wrong. ElectricCharge is a "fluid" resource -- it can be sloshed around between components, and routed in the same was as fuel or any other resource. It's a lot simpler to treat ElectricCharge in a way similar to all other resources than it would be to make two different systems in the code. This is the same reason Kethane refineries actually "draw" negative-amounts of Kethane, which makes for some counterintuitive piping schematics.

As someone explained previously in this thread, ModuleAlternator has to have a "repository" that will "accept" the ElectricCharge within the same part.cfg BEFORE it can be routed elsewhere (such as to a battery) as any other resource / fuel overflow would. The opposite also happens -- whenever an engine (or a light) draws a resource, the default fuel routing calls for the resource to be pulled from the most-distant part first (as defined by the .craft file's listing of the daisy chain of parts). This means that resources are drawn across crossfeed-enabled docking nodes, but not across dead-end nodes such as non-crossfeed panels and / or decouplers (even though resources can be manually pumped between them by rightclicks.) Resource GENERATION works the exact same way but in reverse -- it first goes to the NEAREST part, then so on as they fill. If the engine partfile has a ModuleAlternator, the ElectricCharge will be generated, but without a {RESOURCE} parameter, there's a dead end and the logic will "burn" (discard unused) that quantity of ElectricCharge.

[DesTroy]

ElectricCharge, like Monopropellant and XenonGas is available everywhere on a vessel. It doesn't need or respond to cross-feeds or lack thereof. It is not a fluid resource.

Place a command pod, remove all the EC from it, and then place a bunch of decouplers and other non cross-fed parts between it and an RTG.... The command pod will charge just fine.

You obviously didn't read the all the posts... The alternators work just fine without the 'repository' as you call it.

So..... "Surry dude, but you're wrong." {sic}