EpicSpaceTroll139

Been working on an RO space shuttle of sorts. It's only barely still a WIP, but I still have some tweaks to make to it and the launcher so I guess it fits. It's like a weird amalgamation of 3 different vehicles Size of the original Space Shuttle (actually it has a bigger payload capacity). Wing / controls configuration of the X-37B. Top-of-rocket-without-fairing mounting of the Dream Chaser. It also has a nose docking port like none of those vehicles, to improve cargo bay space. Simulated test flights have been interesting. For air-drop tests, the carrier plane gets spaghettified by the kraken on separation about 50% of the time. Also, launch simulations showed that there is no such thing as too many struts, as the cockpit inverted into the cargo bay near Max-Q. Nevertheless it has performed way beyond my expectations on these first tests, proving easily controllable to soft landings... ...taking launch g forces like a champ (navball is hidden but the g meter hits about 5g at SRB burnout)... ...and turning out perfectly balanced (as all things should be) on reentry the first try with a 40+ ton mass sim in the payload bay, using a tiny fraction of the RCS propellant I'd budgeted, and requiring zero propellant pumping between tanks. Mass savings, yay!!! I did find out a part near the wing root gets toasty if I stay rolled one direction too long and/or dip too low into the atmosphere at high speed, but nothing too hard to handle. I was honestly really surprised how well it all worked (aside from the inverting cockpit), because it's really been an age since I last did anything in RO / FAR. I was sure the thing would flip out of control and disintegrate, stall and crash, or just go full lawn dart at some point, but it didn't. Now I just need to do "real" test flights, instead of "simulated" ones . Also need to do a full orbital flight, because I've yet to do one straight from beginning to end). Unrelated I'd like to figure out what's bugging my proc wing textures out so no matter what I set them to in editor, they're all heat tiled on launch.

Hmmm... that might be it. I don't have many autostruts on there but the locked-to-heaviest-part ones on the shuttle's landing gear do go across the decoupler... I suppose I could go into the craft file and force-disable the autostruts on the landing gear, then see what happens. I'm not sure how the shuttle will fair on landing if I do that though.

I don't know if you're talking about separators as in decouplers or as in the separation motors, but neither was clipped at all. It turned out I was just getting lucky with the carrier plane not exploding after I removed the separation motors. It has returned to exploding. I tried offsetting the decoupler a little bit outward just in case it was clipped slightly for some reason, but that didn't help. If I can't solve this issue tonight I think I might just go ahead and make a report without landing the carrier plane. After all I'm doing this in sandbox and the STS-1T mission doesn't technically require landing the carrier. Edit: Looks like in this particular flight I forgot to throttle down the carrier engines before detach. Doesn't seem to have any effect on the exploding tho

Thanks for the link, I'll check it out. It's hard to see, but I also have my shuttle mounted at an angle. Small angles make a bigger difference in FAR, and I was wary of affecting the flight characteristics of the vehicles when they're attached to each-other, but I'm going to try tilting it a bit more. I also have been throttling the carrier plane back. I'll have to try the shallow dive technique though, haven't been doing that. Still gotta figure out what's causing the instant explosion on some occasions though. It's like the carrier just spaghettifies after separating. Edit: Using more a aggressive pitch mounting of the shuttle and an action group to trim the carrier aircraft down at separation, I've now got the shuttle detaching cleanly with (apparently) good reliability. It seems the separation motors were the source of the kraken attacks. No idea why.

I switched them over to being on the shuttle and it worked once. Except my shuttle dropped back into the carrier plane after separating by several meters. Somehow I went on to make a survivable "landing" afterwards despite scraping off the body flap in the collision. I adjusted the separation motors afterwards and now the carrier plane is back to exploding. Yes I've been doing that, though I have tested without. I think they help with separation a bit.

Hmm, I'll try that later this morning. I wanted to keep the shuttle clean of any features it wouldn't have in flight, but tbh they're probably too small to make a significant difference in how it flies. Even if they do, it's better than the other plane exploding right?

Yep. Those are the sort of black box thingies on the side of the fuselage of the big plane. I think it's some kind of Kraken issue that's getting me. It's not like the carrier and shuttle are crashing into each other after separation, the carrier just instantly explodes the moment it decouples. Might need to redo the combined vessel file or something.

Ok, I can now confirm my shuttle flies, as a glider at least. A glider that flies marginally better than a brick, but that's to be expected. Now if I can only get past the issue that my carrier plane explodes with extreme violence (to the point of sometimes crashing my game) the moment my shuttle detaches from it, so I can make a half-decent video/report. (Also for some reason all my procedural wings look like they have heat tiles no matter what texture I set them to, but I figure that's relatively minor)

Hello. It's been an age since I last posted here, and was looking to get back onto these challenges, but with a different niche. I've been developing a shuttle for entering the challenge again, this time with Real Solar system, since I saw that's being accepted now (with a little ribbon thingy on the badges too). It's something of a cursed Frankenstein monster with characteristics of the original Space Shuttle, Dream Chaser, and X-37B. It's got a chonky booster being developed to go with it. (Yes those are AJ-260s being used as strap-on boosters) However, one thing it also has at the moment that I'm unsure on are RCS thrusters, engines, and tanks from RO. I know currently the rules state that engine stats should be roughly in line with stock, and it's occurred that the engines I have on this thing don't really fall into that. RO engines, being made of Earthling materials, have much higher TWR than the Kerbal engines, and tend to have somewhat higher ISP (particularly in the case of HydroLox, which is currently the core of my launcher). For example, RS-25 (SSME) has a vac Isp of 452 s and TWR of 73.1 while the equivalent stock engine, the Vector, only gets 315 vac Isp and has a TWR of about 25.5. So the performance of RO engines is much higher, but of course they have to do a lot more work too. Would it be allowed to use these? To me it just makes sense using them with the bigger solar system, where everything has to be much bigger and go way faster, all without melting your computer. Also, well, they're realistic (I say as I plan to send a shuttle to Mars). That being said, I'd understand if the answer is no, considering the last (and only) person I saw enter with RSS (@Entropian) used stock parts to do the whole thing (kudos!), and there's so many different things to juggle when moderating.

Didn't do anything too fancy today. I've been putting off working on my shuttle missions and relevant kOS scripts, and instead making progress in my new hard career. Latest mission was a science and flag planting run to Kerbin's North Pole. Yah I know it's pretty lame I put a picture of Kerbin on the pole. When I got back I discovered to my dismay that all 7 of active contracts had disappeared, the 3rd time it's happened so far (I really need to file a bug report), and my last quicksave ( keep those enabled to deal with glitches like this) was from before the flight. Thankfully the most important ones popped right back up as available again, so I didn't have to do the flight over.

It's like one of those "spot the differences" games that you find in magazines. Try to find all the changes without reading the answers!

Whoopsies! My bad!

Well, it took many, many debug flights and landings (sometimes in the middle of nowhere), but I finally got the ascent portion of my script working well enough to get to orbit. Some highlights: WHEEEEEEEEE. Max Q Having to keep the gear retracted until the last moment to reach the runway "100... 50... 40... 30... 20... 10... butter" "Where are we this time?" "No idea..." Orbit! With only fumes left in the tanks! I need to make some tweaks to the script though. The inclination wasn't quite on point and the gravity turn could be a bit more optimized. I might also try to let the script use the more-efficient OMS engines for the latter portion of the circularization burn, once there is no worry of falling back into the atmosphere. Oh, and of course it might be beneficial to tell the script to drop the external tank when it's empty.

No FAR installed. This looks exactly like the bug described in the report @Steven Mading referred to (thanks!). Guess I'll look through the GitHub issues more thoroughly next time before running here. @Steven

So I might just be missing something, but I've run into an error that's left me scratching my head Something I've done in the past was to adjust the authority limiters on control surfaces in my kOS scripts, and would do it with a sequence of code like this: set MySurfList to ship:partsdubbed("CtrlSurf"). for Surf in MySurfList { Surf:getmodule("ModuleControlSurface"):setfield("Authority Limiter", 30). }. I've found this especially useful for reusable boosters on which it is desirable to have the surface authority set positive during ascent and negative during descent, and I was hoping to use it in a shuttle reentry guidance script to throttle airbrake deployment. But now, possibly due to change of KSP or kOS version, this method doesn't seem to work anymore. Testing on a single surface shows the partmodule and field exist with the same name and types as they were before, but when I try to set the limiter, kOS claims it's not there. It doesn't matter if I call the field by name or by index, kOS just goes "nope." Anyone have any idea what's going on here? Could this be because I'm running KSP 1.9.1 and this version of kOS is labeled for 1.8.1? It's been running smoothly for me except for this one issue so I feel like I'm just missing some change to the required syntax.

Not sure if this first bit counts as "in KSP," but I've been working on a "Unified Shuttle Guidance" script for use in some missions I plan to do in the near-future with my space shuttle. Things this script will be able to do is launch the shuttle into an inclined orbit around Kerbin (or in theory any other starting body), execute orbital maneuvers, and assist in docking and reentry. That's all great, but it's been meaning lots and lots of debugging. Kind of grindy. Might be a while before Jeb and company get to space. On the other hand, a buggy test launch went pretty much straight up, and I ended up using it as an opportunity to brush off the rust on my landing skills under unusual circumstances. I did the final approach and landing in IVA, and once again encountered the "extreme braking" phenomenon. Granted, KSP aero and my shuttle's large wing area do result in a rather low stall speed of 62ish meters per second (for this payload), but I still would not have expected it to come to a stop that quickly. Afterwards I discovered the payload came loose in the bay, but I believe that was my fault. I kind of stalled in the last second or so and ended up slamming down with something like 10 m/s vertical speed on all 3 gear at once. Definitely need more practice in IVA.

Didn' t do anything too exciting today. Decided to do some IVA piloting and tried to land a mid-heavy aircraft. Had to go around the first time because I came in kind of high. Made it the second time around, but I kind of Ryan Aired the landing. I kind of expected because I was flying a large, sluggish plane and it had been a while since I last tried landing planes from IVA. What I wasn't expecting was for the plane to decelerate to a stop so quickly that I didn't even have time to react and activate the thrust reversers. I decided try again from external view to figure out what was going on. This what I like to call "excessive braking." Yes that is a converted airliner balancing on its nosewheel. Trying to figure out what's causing that right now. May have to do with this craft having been made in an earlier version of KSP. Guess I can market the passenger version for shortfield operations with the stipulation that all passengers be trained for high g.

I just got back to KSP after a looongggg break. I made this

Which version of kOS do you have? I'm not sure I could find a solution, but I could at least look into it. That being said, in the past I also worked on a similar script, and I found that the Trajectories mod wasn't really necessary. Actually I didn't even need true orbital mechanics. The script just estimated the impact point with a basic zero-drag, constant-gravity parabolic trajectory assumption. When I originally implemented it, it was sort of a "for the giggles" thing, and I fully expected it to fail horribly. Imagine my surprise when my booster actually ended up somewhere near the target! I won't bore you with the details, but whether you use Trajectories or not, there will be errors in your trajectory on the way back. You're going to have to steer (mostly using aerodynamics) during the descent, no matter how precise your boostback burn is. That steering should* give you some good leeway in terms of how you predict your trajectory, so don't feel trapped into needing Trajectories.** *Just how much leeway may depend on how lifty/draggy your rocket is and if you're using Realism Overhaul, relatively small errors could cause big problems **If you can figure out the compatibility issue, by all means use it if you like. But keep in mind that it's one more thing that might break in your script with an update.

Had a little bit of spare time among all my studying, so I decided to fiddle with a new stock bearing design (well, new for me. Probably done before). Made one rotor with it, and it was working great. So I decided to test a tandem rotor system, hoping to put it on a new heavy-lift helicopter. Apparently having two of the rotors broke physics. The "aft" rotor shifted sideways out of the bearings after being uncoupled, then exploded. ...and the pieces just started floating as if gravity wasn't there Thought I might have left hack-grav on, but nope In other news, having watched the successful landing of all 3 boosters on the latest Falcon Heavy launch, I feel motivated to work on my booster guidance scripts again. Need to figure out what's causing the inconsistencies with booster landings, and work on center-core landing. Hoping to then test it on bigger rockets... then figure out how to work with laggy throttles in RO.

I'm just going to leave this here

Deorbit by crashing a heavy spacecraft into it at 500+ m/s?

Hey that's pretty good! I like the detail! Don't be too worried if the lander has a high part count. I recall from working on mine, that while I never finished the rest of the rocket, it became quite clear that the lander would be a large fraction of the part count. Stock leg secondary option isn't bad though. Out of curiosity, do you plan to add spherical helium tanks at the bottom of the S-IVB? (Sorry for the late reply... been busy getting back to college this week)

I think I have something that can theoretically do the job... if it doesn't shred the station while launching it due to stresses.

How many tons is that? lol