Starwaster

It gets counted for each crewed part, so if you have a Mk1-2 pod and a Hitchhiker's pod then you're getting charged for both of them. Might have to lower power consumption a bit... I'd like to base it off real life, but ElectricCharge is harder than anything else to peg down as to what it represents. Realism Overhaul has a good redefinition where each EC is 1 KWh and things that add EC do so in joules. (or was it kilojoules?). So batteries tend to have high capacity ratings but generators and panels replenish it more slowly. Works reasonably well although batteries have no concept of max power output

Uploading new file. You can grab it here IoncrossCrewSupport-1.16.4.zip

Firstly, don't you dare apologize. I'd rather get bug reports and feedback then no bug reports and no feedback. Otherwise I'd only be doing this for myself and be less likely to expand it and work on it. Ok, cutting to the last few paragraphs here because we've got some math that looks interesting. This is the actual code that handles resource charges. (this is only for the part in the base config file we're talking about and only for the ION_SUPPORT_RESOURCE sections. The others are handled by collectors and generators which is separate code. [FONT=Menlo][COLOR=#444444]resourceRequest[/COLOR][COLOR=#444444] = ([/COLOR][COLOR=#444444]supportResource[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]RateBase[/COLOR][COLOR=#444444] * [/COLOR][COLOR=#444444]supportResource[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]RateBaseMod[/COLOR][COLOR=#444444] + [/COLOR][COLOR=#444444]supportResource[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]RatePerKerbal[/COLOR][COLOR=#444444] * [/COLOR][COLOR=#444444]supportResource[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]RatePerKerbalMod[/COLOR][COLOR=#444444] * [/COLOR][COLOR=#444444]crew[/COLOR][COLOR=#444444] + [/COLOR][COLOR=#444444]supportResource[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]RatePerCapacity[/COLOR][COLOR=#444444] * [/COLOR][COLOR=#444444]supportResource[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]RatePerCapacityMod[/COLOR][COLOR=#444444] * [/COLOR][COLOR=#444444]crewCapacity[/COLOR][COLOR=#444444]) * [/COLOR][COLOR=#444444]deltaTime[/COLOR][COLOR=#444444];[/COLOR] [/FONT] rateBase is consolidated with ratePerCapacity and ratePerKerbal (*Mod defaults to 1 and is unused in most parts. I think the hitchhiker pod uses 0.5 as do a few others but the Mk1 Pod defaults to full rate on everything). Standard rules of precedence are followed: multiplication first then addition. deltaTime is Timewarp.deltaTime and is the amount of time in seconds that has passed between frames. (it can be less than 1 second and will be when not timewarping.) And.... here is the problem... [FONT=Menlo][COLOR=#009695]protected [/COLOR][COLOR=#3363a4]double [/COLOR][COLOR=#444444]rateBaseMod[/COLOR][COLOR=#444444];[/COLOR] [COLOR=#009695]public [/COLOR][COLOR=#3363a4]double [/COLOR][COLOR=#444444]RateBaseMod[/COLOR][COLOR=#444444] { [/COLOR][COLOR=#009695]get[/COLOR][COLOR=#444444] { [/COLOR][COLOR=#009695]return [/COLOR][COLOR=#444444]rateBase[/COLOR][COLOR=#444444]; } }[/COLOR] [/FONT] If you don't understand programming, that says not to return the variables directly but instead to wrap them in a publicly accessible function that only gets and not sets. And instead of returning rateBaseMod it's returning rateBase. Do you see that? gorramit. Simple enough, I'll do a hot fix on it.

It's best to just think of it as a general multiplier rather than thinking of it as pressure at sea level, considering that all the planets in RSS with atmospheres have been (or will be) given custom pressure data per planet to match their real life counterparts. Just leave atmosphereMultiplier at 1. Changing it would involve decisions about changing the curve data or switching back to legacy model.

I'd be more suspicious of Action Group Extended than Real Chute.

hurrah! (ten chars)

They use raycasting to detect the fairings, or at least DREC and FAR both do. I assume NEAR does as well or fairings would be no good with it. (DREC will not do its own raycasting if it can detect and query FAR to determine shielded status)

It could do that if you're missing the textures for Kerbin. (Earth textures). If it does not find them then it will halt parsing of RSS' config file. That would explain why Minmus is still in its default orbit. Mun would also be in its default orbit unless maybe that's where parsing choked. You need to post your log file so someone can look at it: • Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log NOT ksp.log file. Especially not ever.

Romulan plasma bolt....

Please confirm, your code above is what you're trying to apply and it doesn't look like it's working? Those nodes are identical to what's already in the large battery bank config file. You didn't make any net changes. It's the same thing...

Unrelated, huh? Sure.....

Closing the books on any resource display issues. Maybe I can go back and improve things later, but I have to conclude right now that anything chrisl was seeing was just a display issue. Crewed (and other Ioncross parts) are consuming the correct amounts. However, the resource display can reflect net changes no matter what the source, including external non-Ioncross sources. It might not do it for all displayed data but it definitely does it for the base LSS modules (that is, non-generator / non-collector). I'll change the base configuration to use INPUT* where it makes sense instead of OUTPUT* Time to get back to actual development. (Clarification Edit: I shouldn't say it's just a display issue since it does reflect actual resource changes, but it doesn't represent incorrect resource drain/generation in the mod)

Running various tests with different rate values on ION_SUPPORT_RESOURCE with no other EC set anywhere, I set rateBase to 1 (1 per second) and got exactly the results that I should have got. 1 per sec 60 per min 3600 per hour Then set rateBase = 1 ratePerKerbal = 1 ratePerCapacity = 1 resulting in triple the above reported rates. Will try tomorrow sticking some EC back in other areas

Read the title. Read the first post and release notes. Procedural costs are procedural. Go go into the game and slap a chute on something. Change chute stats. Watch Prices..

There is no equivalent for inputs. The impact is that your vents will suck CO2 out even if the outside air is full of CO2. (well not literally; KSP only knows oxygen or no oxygen. But the intent of the original configuration is that air vents are only useful on a planet that is moderately like Kerbin. Most likely, yes.

OUTPUT_RESOURCE_OXYGEN (Kerbin / Laythe) is used when the part is in an oxygen atmosphere. You can also use OUTPUT_RESOURCE_NO_OXYGEN (Duna, Eve, etc) for planets with no oxygen (or low oxygen. KSP has fields for the planets that determine whether they have oxygen or not. The collector extends Ioncross's version of the generator. There are other fields it has like requiresWater / requiresLand. I likewise had better results testing with INPUT_RESOURCE instead of OUTPUT_RESOURCE for things that were logically INPUTs. One difference between the two is that setting effectOnEfficency on an input affects the outputs which is as it should be. The problems seem to start because setting the same on an output affects ALL outputs which can effectively stop the generator from generating. effectOnEfficency is a multiplier for the generator when it can't process an input/output resource. It should probably not be less than 1 for an output. And it probably also adds up if it comes into play on multiple inputs. And, this next part would be really bad, but I think it might be cumulative between frames. One thing that you aren't seeing in your tests is the effect on the efficiency rating (hideEfficency = true). What I saw when I disabled that was that efficiency on the scrubbers never rose above 78% and was usually lower. Something similar might be happening on the base LSS section which might be why rateBase is so unusually low. I still don't know what the actual cause is though.

As for an explanation of "odd results", look at the four examples I included in my post from August 9th. I'll repost example 3 here. Example 3: Mk1-2 Command Pod on landing pad. Three kerbal capacity with one occupant. Scrubber turned off, ECR = 2.528/hr. Scrubber turned on, ECR = 2.775/hr. Add a 2nd kerbal and ECR goes up to 3.515/hr. Add a third and it's up to 4.75/hr. That means increases of 0.247, 0.987 and 2.222 respectively. Basically, instead of charging 1.667/occupant (so 5.0 in the above example) regardless of number of occupants (since I used ratePerCapacity), it's charging based on the number of kerbals present. And the amount charged per kerbal is odd..... 0.247 for one kerbal, +0.74 for the second and +1.235 for the third. And at no point is the full, expected 5.0 every charged. This may well be because of the 0.00 CO2 in storage, but it still seemed strange that more kerbals meant more electric charge when I'm using ratePerCapacity in my test config. 6. Going nuts as in fluctuating so much that I can't tell you exactly what value is being used. The fluctuation stops once CO2 in the tank goes above 0.01 so I know it's a calculation issue. I'll try to upload some screen shot fragments later if that would help. I'm not really seeing how, but it's possible that positive amounts of ElectricCharge are being generated. If that's so then the actual drain would be less than the expected drain. But that's an awful lot of net positive generation for that to be the case. In general I'm thinking the behavior you're seeing is interaction with the atmospheric vents and some of it is probably natural but there's too much that's unnatural in what you're describing. I'm going to plug that config in and see what I get. Some other general thoughts: ION_SUPPORT_RESOURCE nodes are ALWAYS inputs so to have drains there has to be negative values, so that's natural there. But the generators and collectors also accept INPUT_RESOURCE and I'm not sure why they were originally set up as OUTPUT_RESOURCE, all of them. To my way of thinking, CO2 should have been set up as an input, but it wasn't, and when I added the electric charge to the atmo vents, I just followed the example before me, and I'm not sure that was good. I should have looked into doing CO2 as an input and I should have investigated the full effect of 'effectOnEfficency'. Looking at the code, having CO2 with a value of 0 for that field on an OUTPUT_RESOURCE should kill all OUTPUT_RESOURCE for that generator. It should be 1 and probably should also be an INPUT (with a positive value instead of negative). So I'm going to try changing those and see what it does but I won't be able to for awhile, later today. Edit: Oh, also, make sure you only have one file with any of those configs in. For instance, either edit the original or delete it and replace with something else, but don't have two config files with the base settings in it because it will apply them all. Edit #2: Also, about the 'per Kerbal' charge; it's not that it's literally applying the charge per Kerbal because there is no such charge defined. It's what I mentioned above that the lack of CO2 is halting (or slowing) generation

Ka = kalcium, not karbon KO3.

You're probably seeing rateBase = 0.00277778. All resource modifications are rateBase + (ratePerKerbal * number of kerbals) + (ratePerCapacity * number of available crew slots). For a given part I'll look into it; last time I checked it was being applied... ... I don't think so currently; I'll have to look at the resource logic and see how and where that could get implemented. Probably not going to happen this round of updates. (unless I look at it and say "Oh of course, that's easy") Need to see your config and need more explanation of 'odd results' Same. Can't answer until I know how they're going nuts. Your configs would be useful to look at Does Tim Roth EVER play a nice / good guy?

Looks like an issue between TAC life support and tweakables. IMO.

A suspension of belief? Usually it's disbelief that requires suspending.... [/PEDANTRY]

Doesn't it have the capacity now to delete root nodes? I'd swear I saw somewhere we could do that.... If it's still the case that we cannot, sorry Nori, my bad. (You'd have to hide them in the editor and tech tree by changing their category / tech to something non-existent so that the game can't place them) @TechRequired = nonexistentTech @category = nonexistentCategory

Well it would definitely be a little wasteful in the corners, but you could make the inside round and leave the exterior hexagonal cause it does look kinda cool. (kinda like Discovery in 2001 actually. Sort of-not really) Or just ignore it.....

No it can't. And what do you mean about having to remember what parts you deleted when you update? Just re-use the cfg file you used to delete them. Unless there's something I'm not getting?

in spite of what that error says, it doesn't necessarily indicate a problem with the mesh. Other errors when the game is compiling the part/model can stop the mesh from compiling. Mod errors can do it as I've caused it to happen with coding mistakes myself.