Czerky

Strange. In previous versions I've seen it work the way you describe (i.e. CoL marker would be right above CoM for capsules). Maybe it's because Iwas using FAR. Surprised this doesn't also work in stock.

Iran isn't landlocked...

I some questions about planet resource distribution. If SCANSAT shows that a spot has 1% water, what does that mean in terms of how many units of water can be expected there? And how large (area) are resource deposits? If I take everything from one spot, how far away is the next potential deposit?

Another question - what conversion factor are you using to determine power/EC values from real world analogues? I know some mods like Interstellar and RO use 1EC/s = 1kW. I'm asking because I'm playing around with different converters and want to make sure EC values line up.

Does Regolith ignore stock parts for it's on-rails EC calculations (i.e. probe core power drain)? Is on-rails EC consumption only factored in if it's being used in USI recipe? If so, I think I know why I'm not seeing on-rails consumption for my variable generator - I'm not using any power! EDIT: Nope. That wasn't it. If I set up two concurrent test converters on a craft like so: MODULE // variable EC production { name = REGO_ModuleResourceConverter ConverterName = Fuel Cell StartActionName = Start Fuel Cell StopActionName = Stop Fuel Cell RecipeInputs = Hydrogen, 1.0, Oxygen, 1.0 RecipeOutputs = ElectricCharge, 2.0, False } MODULE // constant 1 EC/s drain { name = REGO_ModuleResourceConverter ConverterName = Fuel producer StartActionName = Start Fuel production StopActionName = Stop Fuel production RecipeInputs = ElectricCharge, 1.0 RecipeOutputs = LiquidFuel, 1.0, True } RESULT: 50% fuel cell activity real-time, 0% on rails. And if I do this: MODULE // constant EC production { name = REGO_ModuleResourceConverter ConverterName = Fuel Cell StartActionName = Start Fuel Cell StopActionName = Stop Fuel Cell RecipeInputs = Hydrogen, 1.0, Oxygen, 1.0 RecipeOutputs = ElectricCharge, 2.0, True } MODULE // constant 1 EC/s drain { name = REGO_ModuleResourceConverter ConverterName = Fuel producer StartActionName = Start Fuel production StopActionName = Stop Fuel production RecipeInputs = ElectricCharge, 1.0 RecipeOutputs = LiquidFuel, 1.0, True } RESULT: 100% fuel cell activity real-time and on-rails. --- Results are same when ditching EC and using some other intermediary resource. Despite my initial confusion with how this is supposed to work, I still think there something weird going on with the dumpExcess logic (at least as far as on-rails is concerned). That, or I'm still confused as to how the mod works (very likely). Looking at the test modules I'm using, is there any reason why variable output wouldn't be working on-rails?

Sorry about the jumbled mess. I didn't realize I had the wrong idea about on-rails resource consumption until after I wrote the post. Ignore anything I said about looking at tracking center changes. Now that I know about the 'catch-up' system I've been doing proper testing (looking at resource changes when craft is reloaded after a time). Still some oddity with on-rails when dumpExcess = false. I'm trying to isolate variables. Want to make sure it's not something dumb on my end. Will keep posted. Update: I also tested the MKS PDU, which is essentially the part I am trying to duplicate (different module I know), and there's no on-rails consumption for that converter either. If I leave the generator on for a week at 10% load, EU/DU levels are the same when I reload the vessel. Update2: Setting the EC dumpExcess = true for the MKS PDU restores on-rails consumption. Appropriate EU/DU levels when vessel reloaded. Strange.

Alternator issue posted on Github. Very strange that on-rails isn't working. To test, I have the fuel cell, a probe core, and a bunch of lights. I put it in orbit and fire all the lights (load fluctuates around 15%). Go to tracking center and look at resources and fuel cell isn't being drained, but neither is EC. EDIT: Also tested by reloading on-rails converter vessels after significant time. Resource levels are still the same. However, if I get rid of the fuel cell and watch power consumption in tracking center, EC isn't being drained then either (and is still the same when I load the vessel). Is it because I was looking at it from the tracking center? Do you have to be in a flight scene for resource consumption to be tracked on vessels (even those on-rails)? Do you have to be within loading range of the vessel? EDIT: After setting the dumpExcess boolean back to true, on-rails consumption is working. After loading a vessel, 'consumed' resources are subtracted as normal. Strange. I don't know if it's a bug, or you need a high load % for on-rails consumption to register... or something else entirely. EDIT2: I tested dumpExcess = false with high loads of ~100% and it still didn't work on rails. At this point I'll try to see if there's anything in the resource converter code could be causing this. So far all I know is that dumpExcess = false --> no on-rails; dumpExcess = true --> working on-rails.

I've been trying to use the API to make a variable output fuel cell and ran into some issues. I'm using the resource converter module like so: MODULE { name = REGO_ModuleResourceConverter ConverterName = Fuel Cell StartActionName = Start Fuel Cell StopActionName = Stop Fuel Cell RecipeInputs = Hydrogen, 0.0647360000, Oxygen, 0.0323680000 RecipeOutputs = ElectricCharge, 1.5, False, Water, 0.0000520721, True } It works okay so far in that H2 and O2 are consumed in proportion to EC drain (probe cores register a 1.74% EC load - so far so good). However, when I attach an alternator-equipped engine part, load defaults to 100% - I'm guessing because the part is trying to fill the small EC container in the engine, even though they can't be filled by external charging. Potential bug? Another issue is that the conversion isn't working with craft on-rails. I don't know if Regolith conversions are even supposed to happen on-rails, and in the manner I'm trying to do it, so I thought I'd ask.

Certainly. The only section modified was the Regolith module: MODULE { name = REGO_ModuleResourceConverter ConverterName = Fuel Cell StartActionName = Start Fuel Cell StopActionName = Stop Fuel Cell RecipeInputs = Hydrogen, 0.0647360000, Oxygen, 0.0323680000 RecipeOutputs = ElectricCharge, 1.5, False, Water, 0.0000520721, True } Only change was setting the ElectricCharge DumpExcess boolean to false (and output value on personal preference). With DumpExcess set to false, the converter will only consume reactants fast enough to 'top-up' EC. Works okay during time warp, but highest warp will tend to slow consumption (I'm guessing it messes up the Regolith time intervals?). However, a major hiccup is that conversions don't seem to occur with craft on-rails (don't know if this is because of the change I made or a limitation of REGO_ModuleResourceConverter). This limits the potential use of my modified part for deep-space missions. I'll need to do some more tests and get more information on the Regolith API before I come to any conclusions.

Right, but doesn't the rating of the Apollo fuel cell just refer to the maximum power output before saturation/voltage-drop/overheat? If I recall correctly, it was rated to 1.5kW, but the actual output during a mission varied between 500-1400W. Chem was a while ago, but as I understand, fuel cells don't consume reactants unless there is something bridging the terminals, and won't attain a certain current/power output (and hence reaction rate) unless there is a load connected to draw it (or they're short-circuited). Apologies if this sounds like whining. When I saw a load percentage value in the game, I just assumed you meant to model variable reactant consumption based on EC draw. Doing so would be a PIA I imagine, but I just wanted clarification as to your intentions for simulating fuel cell behavior. EDIT: I looked at the Regolith API and found out how to make the conversion rates dependent on load. Changed the fuel cell cfg to my tastes and it seems to work. Again, thanks for your work. This is just a minor issue I had with one part out of the many I use in your mod.

First off, thanks for making this mod. It's been very useful. I had a question about the Alkaline fuel cell. I was thinking of using it on some of my early low-tech spacecraft, but noticed that the current draw/power output defaults to 100% load (which is complete overkill). Is there a way to 'throttle down' the output to a lower, longer-lasting value? Is it perhaps supposed to throttle down automatically (to account for actual current load on the cell)? tl;dr fuel cell is spitting out 16 EC/s when I'm only using 0.3 EC/s.

All right. I went ahead and did exactly as you said. Results for 5x10m (d x h) cryogenic tank: Tank "dry cost" = 1.879065 <---- what I'm getting at 169 kL LH2 cost = 31.1 Right, so not zero. I just didn't expect such low values for the fuel tanks themselves. Is ~2 credits the correct (working as designed) value for an empty 5x10m fuel tank?

Are there any plans to add dynamic costs to the RF Procedural Parts tank? I noticed that the cost is always zero when they're added to a vessel/resized.

When attached to a vessel, the tank itself doesn't add anything to the VAB cost tally. I just found it strange as other procedural parts have a cost that's added after placement (and adjusted when resizing). With the Real Fuels tank, it is always zero.

Thanks for the update! Just a quick question - I'm playing with Real Fuels and I noticed that the procedural tank associated with that mod doesn't actually cost anything. Is this a bug or WAD?

Are you running Advanced Jet Engine by any chance? I had the same issue and removing AJE restored normal drag behavior. Why this worked I have no idea.

To verify my previous observation, I re-installed AJE, and the low drag issue reappeared. All tests were done with Mk1 Capsule + Mk16 Chute. In case it helps, the mods I'm using are: 6S Service Compartments AJE Antenna Range Chatterer Collision FX Deadly Reentry DMagic Science Docking Port Indicator Enhanced Navball FAR Final Frontier Firespitter Core KAC KER KJR MM PlanetShine Precise Node P.Fairings P.Parts RCS Build Aid Realchutes RLA Stockalike SCANsat Science Alert Simulate Revert Launch Toadicus Tools Toolbar (Everything but FAR installed via CKAN) It doesn't make sense to me either. I'd feel a lot better if anyone else experiencing this issue could chime in. For now I will just accept my luck and enjoy 0.90. Thank you for your hard work. Let me know if you need more info.

Update: Removing Advanced Jet Engine seems to have resolved the rapid descent issue for me. My capsules slow down to subsonic speeds as normal (drag coefficient values are now a lot higher - 0.65 near the surface instead of 0.09).

I haven't used any extra heat shields. I've also tried a manual re-installation. At this point I will try a process of elimination to see what else could be causing this issue.

Okay, so I decided to stop being lazy and test with a less crazy descent (~110x35). Variables are the same except my landing location ended up being about 600m ASL. Here are the results w/ FAR data: I haven't actually played with FAR in a while, so I'm not sure if these numbers are normal (I think they're ok?). Just FYI, I'm playing with stock Kerbin. Impact velocity at 600m ASL was 380m/s.

Edit: I'll try shallower re-entry angles. I know my trajectory was a little steep as I was doing a crude sub-orbital test. I just assumed that I could still slow down.

I'm wondering about the mechanism of ablative shields. Currently they will overheat and explode before using up their ablative shielding. I thought these shields vaporized outer layers in order to forestall heating of the bulk mass? I understand the need to tweak certain numbers to get things working, but is there possibly something odd going with upper atmosphere behavior?

I can confirm this with my Eve lander on DE + FAR. There's some kind of phantom torque on the craft that didn't happen until 5.3. It turns into a chaotic sideways spin further down in the atmosphere. I thought it might be lift, but there are no exposed parts on the craft that would explain the direction it happens in (FAR analysis also shows that the COL is inline with the COM). I've also noticed that heat shields don't shield other parts and don't ablate before exploding.

I went ahead and tested your latest code on the github repository for backwards (180 AoA) descents. Landings seem to fall consistently short by a tiny amount (~10km) (not using parachutes) but are still very close to initial prediction. It might just be piloting, but thought I'd share my result.

I've been playing around with your code, and was thinking about a quick way to get reverse (i.e. pod re-entry) descent predictions with FAR. In this section where you separate the Reference Transform (vessel steering orientation) into vectors used for the FAR simulation: Would it work if I just switch the forward and reverse vectors for the case of reverse descents? I set up code to do that via an extra GUI button and it seems to work for reverse descents (only tested for 0 AoA so far). I was basically just trying to emulate the backward probe core workaround that people are using.