Cleric2145

I am, I installed it over the previous version. Is A.02b a fresh install? I will try a fresh folder the next time I'm around my home computer.

I apologize if this has been mentioned, I scanned a couple pages back: Many if not all the parts are just pure white with no textures, I'm using ATM but it shouldn't be causing totally white textures, right?

Mmm, lovely! So does the menu actually do anything? Do the settings change any of the debug options? I got exciting thinking it was a new feature and tapped 'Normal.'

Can I assume NEARFuels stands for "Not Exactly A Real Fuel?" :3

I'm not sure if this has been mentioned yet, I've scanned back several pages and didn't find and mention: The RT2 integration is *greatly* appreciated, but the Tantares Pack antennae are all rather overpowered compared to RT stock antennae. The Tantares antennae generally have 2-4x the range with 10x lower energy usage. I'm in love with the design of them, but I'm having to stick 6-8 of them around my craft to properly scale up the EC usage. c: I realize it's a simple tweak in the .cfg but that will get overwritten with every pack update, and doesn't fix it for the casual RT player that doesn't realize he's getting a bargain with the Tantares antennae. Thanks, love the mod!

Just to verify this doesn't suffer from the same issues as the other persistent momentum mod: have you solved the increase in momentum on a craft each time it comes out of warp? With the Time Warp Rotation Fix, if you let something rotate slightly, time warped, and then stopped time warp, the craft would be rotating slightly faster when coming out of warp without any control input. This would happen repeatedly until the craft was spinning wildly out of control so fast it changed its orbit.

I feel special. This post ended up being either strangely attuned to the developer's ideas, or got noticed. See Scott Manley's preview:

I like the red shading, I would just prefer it to fade/disappear after a period of time.

And a strapon liquid booster failing, sending the whole rocket sideways at Mach 1 isn't? c: But I understand why not--it's totally unrecoverable and is essentially a quick-load/revert situation.

I feel like if an SRB leaks, it as well as any parts it's attached to should explode.

On the contrary, I think it would be a great opportunity for alternate methods of fixing failures. Instead of linking all repairs to EVAs, allow locked thrusters/engines to be forcibly shutdown by closing all of the fuel valves and/or draining all of the fuel from the connected or nearest tank. This might even qualify more as a tank failure (pumps in the tank lock open and fail.) Potentially add more 'temporary' failures, such as a throttle sticking open, fixed by restarting the engines or cutting the throttle to zero and then back up. Engine ignition failures that simply require a remote restart. Just as in real life, not all failures should be critical and permanent. Variety is the spice of life and KSP has a tendency to link all actions to one system (e.g all experiments work instantly through dialogues, all repairs are made through EVA). Apologies for posting speculation outside of the Dev thread but it's pertinent to this thread's course. c:

One method of implementing "inspection" or maintenance (albeit a complicated way) might be to slowly lower the age of any part illuminated by EVA helmet lights, or within x meters of an EVA Kerbal. I'm sure this isn't very practical, but would be a nice way to differentiate actual preventative maintenance and simple visual/functional inspections.

MODULE { name = ModuleBatteryReliability MTBF = 8000 LifeTime = 100000 RepairCost = 1 Silent = false } And name = ModuleTankReliability MTBF = 24000 LifeTime = 100000 RepairCost = 1 MinTC = 60 MaxTC = 240 Silent = false I don't think the MTBF is the problem itself. The issue really is that MTBF is calculated for each part individually instead if all parts at once. This means everything could feasibly fail at once since failures are totally independant of each other (= no fun). What *I* think should happen--at least for probes--is that MTBF is calculated for the entire craft, then once the system decides to roll a failure on the craft, it draws from all the fail-able elements on the craft with each part's MTBF increasing or decreasing its likelihood of being drawn. Imagine having a bowl of tags, and each part has a tag. The lower the part's MTBF, the more 'tags' it has in the bowl. Find a method to determine a random drawing cycle (average of all MTBFs? Increasing freq with increase in parts/low tech parts?) .

Using 2.1 I'm still getting some silly rates on failures. I sent a probe off to Eve, and less than 24 hours after leaving Kerbin SoI, it had already suffered a fuel tank leak, reaction wheel fail and a battery short circuit. Now, I was time-warping on the active vessel, so this could very easily be fixed by time-warping from the Tracking Station, but that's more work on the player's end. I can work around a fuel leak, the reaction wheels aren't an issue, and the battery loss sucks, but by the time I reach Eve I don't know if I'll have a functioning part on the probe. :|

Mode 2 probably shows the body where it will be upon exiting its SoI (as opposed to Mode 1 showing where it'll be upon entry).

Why not make it a resource, then? If it's possible to make a hidden resource. Although with the KSP Alternate Resource Panel you would be able to hide it permanently so that it doesn't clutter things up. Create a resource "WedgeHatch" that has a pretty high density, and has one capacity per wedge. Toggling the hatch covers off removes the resource. Another option might be to look into borrowing the plugin from the test weight mod that allows for tweakable mass. Having the hatches take up weight would be the main factor for going without them, at least for me.

What would be causing my chutes to be acting strangely? When I set up the settings in the editor window, and click "Apply to Symmetry" the other parts don't get changed, and usually have blank data entry boxes (Spare Chutes, Pre-Dep Alt, etc.). In addition, I can set my chutes to "Only deploy going down=False", but after hitting apply, a right-click, Show Info tells me it's still "Going Down=True", and in-game usage reinforces that. My chutes only open going down, making my LES quick-chutes rather ineffective. Is this just a conflict of an older version, or is there some mod conflict somewhere? I'm about due for a total reinstall anyways, but I figured I'd look into common solutions. EDIT: I'm reinstalling RealChutes to see if this fixes it, but I believe I was still at 1.0.x. I'll let you know what happens. EDIT2: So the mustGoDown will now 'stick' when set, and that was really the more aggravating of the two problems due to the lack of workarounds. The symmetry parts still have totally empty fields when I Apply to Symmetry, though.

Would it maybe be possible to add a tweakable to toggle the fairing base to act as a decoupler? That might require some plug-in work.

I was thumbing through my tech tree when I thought about realistic progression. Technology doesn't come in lumps and waves, it's tested out and gradually makes an appearance. I considered a system for testing prototypes of parts, randomly offered similarly to missions might be, in which you test the object in return for a reduction in points or in percent (to increase alternate tech tree compatibility) to research the level in which the part resides. Testing would work like so: Offer appears at the space center/R&D hub to test an item. Each item would have parameters defining where it might be tested with rewards for each level (e.g. Escape towers= 5%@LaunchPad, 8%@Atmosphere, 10%@LowOrbit; Landing Legs=10 Research@Launchpad, 15 Research@Landed, 25 Research@ForeignPlanet). If the offer is accepted, the player temporarily receives access to a locked item under the condition that it be tested. (Potentially only works in specified zones to prevent abuse?) Testing would involve 'using' or activating the object x number of times (potentially with a large bonus for vessel recovery). Launch escape towers would obviously need multiple launches to fully complete testing, whereas landing legs or thrusters might be tested multiple times in each biome in one flight. One time use items like SRBs might receive lower test requirements. Failing a test might result in a penalty or perhaps just losing access to the item or even just increasing the repetitions required. A system like this might help ease up situations where players are stuck in a rut without enough Research to unlock the equipment to achieve more research. I like the idea of setting up an unmanned pod with a probe body controller on the end of an SRB to test out the LES and gain research without endangering Jeb.

Hey Chris I just had a strange black screen today on a fresh Career start. I was building a probe with a 1.25m stack chute beneath it with a MechJeb core on top of the chute between the edge of the chute and the probe. I went into the action group editor and changed the sizes around a couple times and everything was fine. I went back in and changed the size again, and I notice my delta-V rates all drop to NaNm/s. Shuffling the size up and down didn't help. When I launched I got a black screen, but no "NaNNaN Mm" bug. I have a massive .log spam of "[LOG 16:29:45.279] Look rotation viewing vector is zero," a problem I traced back to nodes that were too large for the object. Restarting KSP and relaunching the craft resulted in the same problem. I can provide a .craft file if you'd like but I'm so loaded up on mods, it'd likely be a pain for you to load the file. Have you had any experiences with this kind of problem? It's vaguely similar to the problems StretchySRBs had before the last patch with the sea-level SRBS. I suspect I can just rebuild the craft and fix the problem, but I wanted to bring this to your attention, since it seems like a rare hitch between Realchute and something else. EDIT: The problem seems to be using a drag chute with "Use current mass" on an extremely large vessel. When clicking Apply Changes it tries to solve for a mass to large and the part mass returns to "NaN t"

This is something I've been wanting for a while! Any chance of built-in Real-fuel/Kethane support?

Any updates on this plugin? I'm very very eager to see the rotation increase from time warp getting fixed. It's the only real problem I have with this great plugin. I sent out some probes to Duna, and the rotation got so amplified, it actually caused a significant deviation in the path of just one of the probes. Enough to cause an course error so large I didn't have enough delta-v to fix it.

Might I suggest a better name for this plugin? I glanced over it several times, not being a developer, just because I didn't think it'd pertain to me until I saw Sirkut's post in the SceneJumper thread explaining what it actually does.

Is that at all related to all of my engines' top nodes being too far down? All of my SFJB engines sink up into the fuel tank a meter or two, looking terrible and causing trouble fun.

Your Kerbin commsats are targeting the active vessel only. When you switch to your spent stage the dishes target the omni antenna, which is out of the omni range. You'll need a couple commsats pointed permanently at Minmus or dedicated at pointing at the vessel in the lower orbit.