NathanKell

v0.47 for KSP 1.0.5. Thanks to winged7, Zarbizaure, NathanKell, nightingale, chirsl. Revise the RD-270 cost revision. Revise AIES probe core costs to be in line with the Cube core. Place/price SXT airbags. Move BNTR engines to more appropriate node. Sanify solid motor placement; at some point placement got very messed up. Pretty-print altitudes in km for various sounding rocket/x-plane contracts. Fix issue with Successful Reentry contract completing too early (return home didn't check other conditions had been completed). Update control locker plugin to check mass every second rather than only during staging. Less realistic, probably (to the extent tonnage-based limits have a real basis), but less annoying. Fix issue with station contracts. Fix longstanding issue with high-atmosphere X-Plane contract not loading. Add new later-game suborbital X-Plane contract. Standardize rewards among the three suborbital contracts. Up limit of available HSF contracts. Properly place 0.625m X-15-rated tanks. Move AJ10 Advanced to Tier 4 engines (mid 60s) since it now has the AJ10-138 (Transtage) config on it.

v10.9.6 for KSP 1.0.5. Thanks to A1Ch1, NathanKell, SirKeplan, Shadowmage, waerloga, stratochief66, PhineasFreak, mellon85, Agathorn, cytosine! Tweak Baby Sergeant and sep motor reliability given they burn for such short times. Fix gimbal response speed on RD-107/8 verniers (SSTU). Fix shielded proc tank description. Fix a typo with the RS-56-OBA TF config. Fix an issue where set temperatures were being overridden by the global config when they should not be. Fix FASA XLR11 engine max temps to match Taerobee model. Tweak tech transfer for early Soviet engine reliability. Fixes to various late RL10 configs, add reliability data when missing. Correct AJ10-104D burn time. SSTU solids fixes. Remove conflicting SSTU craft files pending re-add. Further RSB support and fixes. Fix an issue with Tantares parts and rescaling. Correct TR-201 ignitions. Add reliability for RD-0110. Fix up AIES plumes. Add missing AJ10-Advanced plume. Reduce weight of reduced flow/thrust failure, add new performance loss failure. Allow an engine to shut down/explode even if it has already had a minor failure. Fix issues with 0.625m tanks. Fix issues with node position on Squad service bays. Fix an issue where a config was stating :FOR[RemoteTech] when it should have been AFTER (this would make other mods think RT was installed even if it was not). Add RO support for the Wild Blue Industries Buffalo MMSEV.

You could try loading them in Photoshop and resaving them with nvidia's DDS Tools; all the prior textures were created that way/ No idea if that's related.

@Dman979 log is private

@komodo @FiiZzioN this stickied thread has a discussion of drag cubes that should answer the questions.

@sjsninetrys OSX has GPU/API issues with 8k textures last I heard. That it worked on your setup that long means you were very, very lucky. Unless there has been some massive change in both Unity and OSX, to the best of my knowledge there are still considerable issues. Further, those x64 hacks have questionable internal stability. That's why they are hacks and not, like, released versions. So that too might be having an influence; I just don't know.

@sjsninetrys please read the OP next time. It specifically states that 8k doesn't work on Mac.

Ok. This will now fire an event showing the old transform and the new transform. However due to how vessel stores the old transform, in the case where the old transform and new transform are on the same part, all you'll get will be two references to the new transform. You'll still know it's happening though.

@John FX post to the RF thread, and also tag taniwha.

On the contrary, _everything_ is set up with the assumption that recommended mods are being used. That's why they're recommended. If they were merely "choose, or choose not, up to you" then they wouldn't be recommended. Also (a) you're forgetting just how much higher entry costs (and building upgrades! Don't forget them) are compared to part costs. As I said, they are 20-40x what the unit cost of a part is. And (b) your LV is way, way overpowered and indeed your CSM is too. For a lunar-orbital mission, let alone a flyby, you don't need more than about 6 tons TLI. And you can manage that on a Saturn IB-Centaur. If you want to chuck 3 people, that only goes up to about 10 tons, again not that much LV required (compared to Saturn V's 45t TLI). Remember that Apollo 8 had a mass simulator instead of the LEM, and went with a fully-fueled ~30t CSM (double the delta V needed for LLO, let alone a flyby)

Another interesting approach would be Early Avionics only. I believe an LV could then be done for about 20 tonnes using tier 0 engines and tanks, but with the Early 1m instead of Starting, and the X-Ray core. That would, however, have a higher score than one might expect because the X-Ray core is ~8kg vs the 60kg of the sounding rocket core. Oh, also @John FX I suggest you clarify "required / recommended" to "recommended / suggested" since I think that is the intent. That is, the mods RP-0 should not be played without (but will not, say, _crash_ without) vs the mods that can be added but are not needed for the normal experience.

In the very, very special case where axes _are_ aligned, i.e. your example where roll is swapped with yaw, you can get away with doing things that way. And I can certainly add an event for reference transform switch.

It was an 'optional' part in Firespitter.

I (or anyone) could probably get the mass down to 37t, I think. As you saw from the shot there's probably 100-150m/s extra on that bird.

Apologies if this is already added and I missed it in the OP, but @Crzyrndm it'd be awesome if one of the autopilot modes was "hold AoA". That's very important for reentry, and reentry is one of the times least able to be human-controlled, and none of the existing modes will work for it as far as I can tell. Descent rate is also useful there, but sometimes what you want to do is hold an AoA within stress and thermal limits rather than target a descent rate (at any AoA).

Yep, exactly. I don't have any bright ideas either there, I'm sorry to say. And besides, if I added a flag to use vesselTransform instead of ReferenceTransfrom, then what you got when you hit pitch wouldn't actually be pitch if those transforms didn't align! (i.e. doing it without a rotation to the new space). The alternative (doing the rotation) would be as you say: actuate if the dot is >0, but then axis-limiting isn't doing you much good.

Ah, crap I thought I responded to you @PTNLemay. Sorry. I can't tell you why the mass is wrong without knowing all the parts on your craft; I do know there's a serious issue in RealChute (that I discussed with @stupid_chris but I'm not sure when he might get to fixing it) regarding mass, so if you have any chutes aboard that might be it. @stratochief66 the A-4 does actually have some thrust vector control; you're right the real engine doesn't gimbal, but it has carbon vanes in the exhaust to shape the thrust vector; in RO that's simulated as four mini thrust transforms and gimbal for all of them. So there should be some control authority. RP-0 only updates avionics status on staging (technically: when the part count changes), so if you start the stage locked you'll stay locked until you stage again and have fewer parts. So that's why it doesn't unlock. @chrisl I would tend to go for a ratio of at least 5:1 if not 10:1 for milestones and repeatables. This is because, as I explained in my last post, the milestone has to pay for all the entrycosts, where the repeatables just have to give you more money than you pay building the vessel for it. And entrycosts are anywhere from 20-100x the unit cost of parts. I'm not sure how I feel about crewed lunar orbital; it's not a real counterpart to the uncrewed missions because for uncrewed there's a clear distinction between a flyby probe and the orbital probe. However for crewed missions you will need to burn probably at least 400ms at perigee to make sure you get a return to Earth (because the usual periselene you'd have on a free return is too high for the contract to complete!). So we're already talking about a significant, although nonetheless much lower, investment in resources. A traditional ballistic lunar flyby almost certainly won't lead to a low enough periselene to let the contract complete (though any astrogators are welcome to prove me wrong).

Well, you'll notice that the Saturn IU's tonnage limitation is very, very high. However, the Saturn IU was notable for being pretty much the first digital guidance unit there was. So it's modeled as a very capable (but not infinitely capable) computer. Earlier guidance was generally analog, and based off stage-specific input. Then things are much more limited. In the end though, you're not wrong: tonnage is a proxy, and not a great proxy, for the difficulty of controlling a vessel. It was chosen because it's a very easy proxy for people to understand and for us to implement.

Yeah, we should switch to AFTER[RemoteTech]. EDIT: I looked through all RO and there is one patch that does it, everything else is sane. Fixed for next RO.

It's after dinner. Here's the result. Now, if I had managed to keep closer to 0 degrees pitch (probably more like -1 at burnout so during coast it would raise to 0), and precess slightly less, that would be a perigee closer to 160km than what it is. But I'll take it. Oh, and note: This is a risky LV. TestFlight will make something in it fail probably 50% of the time. But all engines are within their specified maximum burn times (or over by a half-second), and the air-lighting is workable even with TestFlight lowering air-light ignition chances (I tested). One other note: This could be made rather easier to fly by adding a tiny nitrogen tank and some nitrogen attitude thrusters to the core. As the final orbit proved (flown by 90m/s start, 80km end, 60% shape, and Limit AoA to 3 degrees) there is breathing room in terms of delta V, so decreasing the mass ratio of the core slightly by adding some nitrogen (in a heavy tank >.>) and some thrusters wouldn't prevent orbit. And it would make aligning for kick far less finicky.

I think you might have to add a module to it to handle EC anyway. Don't recall the link, just take a search of the forum?

Update: So, it took some tricky flying, but I did manage it. Crashed KSP tho. >.> Changes to the above rocket: 1. You have to light the core a couple seconds before booster burnout or drag will de-ullage you. That is at a survivable Q however if you use the MJ turn 90m/s start, 80km end, shape 60. 2. Added two small seps tot he lower of the two wac stages. 3. Modified upper staging sequence: Seps and decoupler/shrouds fire, then the lower wac stage lights. The upper wac stage lights and decouples at the same time (although you could light it a second early if you were being very careful). Also, the flying is a bit tricky, because by the end of the core burn you need to keep level with the horizon but also use the A-4's thrust vanes to spin up a bit to keep that attitude stabilized, because you'll coast for about a minute and thirty seconds before separation and apogee kick (50s to apogee, where apogee was 160km for me on that flight before kick). When I have a minute, after dinner, I'll refly it with a shot in orbit.

@John FX I suggest some sort of normalization for payload fraction. (Otherwise a tier 0 rocket that gets 60kg into orbit, since that's about the minimum payload, will not score more than a Vanguard that gets 8kg into orbit.) Now, a quick followup. Here's a remade "Mirak" that I haven't tested yet, but will probably work. There's a bit more I could shave off probably, and I also might need to add some solids to the upper for ullage--there may have to be a coast period. But at ~100m/s more than the prior version, and 1.2t to play with, it should be ok. This is with avionics per booster btw. All tier 0, AFAICT, so that should be the thing to beat.

That design will likely have its engines shut down/exploded/etc by TestFlight for going over the burn time limits (the core and the first WAC upper). However, slightly shrinking the core and switching to air-lighting might (might!) be possible, although the dynamic pressure at core ignition might be prohibitive. You would also have to go to 3 WAC stages to keep their burn time low enough. Increasing delta V would also be possible, perhaps, by having only 1 Starting guidance unit on the core and then 1 each on the boosters. More expensive but the savings in core dry mass might make up for it. It should be very possible to do by unlocking only 1 node, early avionics. That will lower the payload to orbit's dry mass (over the above example) enough to require a much smaller LV and perhaps only 1 WAC stage.

The stock code now is basically identical to my ModuleRCS fork if you want to dig into that. That said, I'm not sure I'm understanding the problem. The issue is that you want an RCS port to only fire along a fixed axis of actuation, regardless of whether that is pitch, yaw, or half-n-half at a given time (due to reference transform shifts)? That would need a completely different setup, and ask @ferram4 how hard it is to determine the main axis of a vessel.