EpicSpaceTroll139

How many tons is that? lol

I saw that. But atmospheric pressure only changes the TWR and Dv, not the burn time. Anyways, testing confirms the boosters burn for about a minute and a half while still reserving fuel for their own recovery, so no problems with the vehicle.

I finally downloaded 1.6.1. I must say I am happy for the basic information readouts to finally be stock. I question their accuracy on my shuttle however. Those boosters definitely burn longer than 50 seconds, so I have no idea what it is referring to. Note the TWR and delta-v for the 2nd to last stage (marked 1) are not accurate, as the SMEs are shut off after ET separation. I've also been attempting to record some nice testing clips for a mission video. KSP is not cooperating.

I do have Making History, but I figured out that I don't need as much thrust from the SMEs with the new boosters. The older shuttle used the-integrated-fuel-tank-engine-booster-things-I-don't-remember-the-name, and needed mainsail SMEs (it once had 3 actually) to lift its full 50 ton payload, but the new boosters allow it to do the same with vectors. (There are 3 Vectors on the main orbiter there) I guess this is actually good. The vectors are lighter than the original mainsails, which will help when taking the shuttle on the beyond-LKO missions which I have planned. I may need to make some tweaks to the aerodynamic surfaces though to account for the COM having shifted forward. Edit: Actually the new boosters don't have more thrust, they just stick with the shuttle longer and thus give it more oomph.

While I'll probably get back to dinosaurs sometime soon, for now I've been working on an upgrade to my old space shuttle. I am laughing (albeit a bit ruefully) at my own stupidity. I spent a bunch of time writing (well rewriting and integrating with a launch script) kOS code to control vernier actuated, claw-gimbaled Mainsails on the back of the shuttle... (see prototype here) and I just realized it was all pointless because they don't even fit with enough room to gimbal around. (Note the decouplers would not be there when it went to space.) I might be able to get away with lower-thrust vector engines on the orbiter though now that it has more powerful boosters.

From what I've read in the kOS documentation, Events include all things you can activate via the part right-click menu, whereas Actions only include those that can be assigned to an action group in the editor. Lock/unlock pivot is not available to be assigned to action groups, thus it is not available in Actions, but it is available in right click menu (if a part has been grappled), so it should be in the Events list. Atleast, that's my new understanding. I'll have to test this when I get home.

Unfortunately it appears that the pivot toggle cannot be added to an action group in the editor. Edit: In case you're interested, this video (less than a minute long) shows the prototype for the system I'm putting on the shuttle.

So, this may be a bit of a niche question, but is there any way to have kOS lock and unlock the pivot of a klaw? I did some testing and there does not appear any such an action amongst the various accessible modules of the claw part, but perhaps there's something I'm missing? I had a mini-script do For mod in part:allmodules {Log part:getmodule(mod:name):allactions to My_Log.txt.}. and it spat out the following, appearing to show that toggling the pivot is not an available action. I however know the claw to be a bit of an oddball part, so I wanted to check that this action isn't accessible from some different route? The reason I'm asking is because I've created an engine-gimbaling system that uses claws and small verniers to give high gimbal to mainsails, for use on a space shuttle. It would be ideal to allow the script to unlock them after timewarping to the launch window, and lock/unlock them for times during the launch when change in gimbal angle is not being requested (thus saving fuel on the verniers). UPDATE: I may have found a solution to my problem, using EVENT instead of ACTION. Will have to check when I get home

Not particularly sure how this somewhat memey song got into my head, but it's been running circles for the past couple days.

I made a thingymabobber that gimbals a Mainsail. It should be readily scalable to gimbal Rhinos and Mainsails. It only really needs 4 of those side engines, and I plan to reduce that to 3 this evening. Should be useful for large space shuttles. My apologies for the hiccup audio. I have no idea what happened there.

That looks absolutely fan-frickin-tastic… How many rounds does the gun have? Just yesterday I saw the best meme about the A-10 Anyways, now that I'm on Thanksgiving break, I've been taking some time to work on various projects. A dinosaur, ships for a grand tour with a special twist, and my latest idea: a KoS script to allow high gimbal from large engines. See prototype below. Basically the idea is to have small Vernier engines, which instead of directly steering the rocket, steer the main engine which is placed on a claw joint. Thus, the main engine gimbals, steering the rocket. I believe this will be very useful on large shuttles for which vectors are not ideally sized. I need to work a bit on stabilizing the control loop though. On startup it kind of flaps about until it gets stuck in this sort of whirly oscillation which feeds back on itself. It sits there going in a circle like a top after it's fallen down.

So I left the booster landing program running in the background while I watched a youtube video. I heard explosions and feared my landing script was back to the old problems. Sort of, but not quite Among other things, both of the landing pads glitched under the terrain and exploded in the ocean beneath. Still trying to figure out what else happened. I'm pretty sure the script didn't land the booster in the second screenshot where it appears to be now.

Well I've gotten the landing burn working again. I believe something changed that made the game slightly more laggy than it was before, and that was at random delaying kOS registering triggers during the landing sequence. I made some tweaks and slightly increased the Factor of Safety on the burn timing, and now the boosters do not slam into the ground. It is however a bit disconcerting to see a booster balance like this for a good 5 seconds before finally coming back down onto the legs Also sometimes this happens: which is no good if I'm going to get this landing on a barge again. Just want to fix these minor issues, and then both this thing and the side booster landing scripts should be good for release. Still don't have anything going on for the center core. That's a going bit more complicated because by the time it stages it's going fast enough that an entry burn is required to prevent parts of the leg hinges from burning up on reentry. Unfortunately at this point it looks like the math required for the entry burn will be subtly different from the math used for the boostback burn, resulting in it needing a new section of code. Then the real fun will come with getting an RO install up and running, and then trying to apply this stuff where everything is faster, hotter, laggier, and engines don't work down to 0% throttle.

Yah I was definitely thinking it needed to curve more into the head. Just kind of stuck that thing on there as a placeholder for now. It's a bit too... pointy as well. Bracho head is rather blocky/stubby. Anyways, perhaps I'll work on it tomorrow. Time for bed lol.

Progress The head on this thing is proving rather hard to make. Gonna be tough to make it actually look like something... might need to reshape the body too. Perhaps a thicker base to the neck? Anyone got any tips?

The rocket should be released Soon.TM Maybe I'll give some closeups of the working hinges this one has when I get back to my dorm.

I've finally gotten the new guidance loops debugged, but now I'm running into a new problem. Despite having changed nothing but variable names in the terminal descent / landing portion of the script, I am now getting inconsistent results with the landings. Sometimes a booster lands just fine. Other times it seems to start burning too late, or cuts off an on-time burn early, and just slams into the ground with the legs halfway deployed. WHABAM! In the picture above, one booster landed fine, the other did not. In this one, one booster landed with too much horizontal velocity and tipped over, the other did the WHABAM! thing.

Wow that's looking great. Out of curiosity... what would happen if you attempted reentry with the cargo bay doors unlocked? Bad things I assume? Edit: Also, can it maintain 38 degree angle of attack during part of reentry like the real thing?

I did an overhaul of the guidance scripts that control the return of the side cores of my Failcan Heavy, trying to make them easier to understand and use as well as perform better. Improvements include side core script consolidation, in that now there is just one script that controls either booster given a parameter n=1 or n=2, instead of a separate script for the port and starboard boosters. I hope to eventually make it so that the parameter is n=1, 2, or 3 and the script controls all 3 cores. Also, the guidance loops have been changed to focus more on glide, which should give a modest reduction to the amount of fuel needed for the boost-back burn. But really what this has meant is I've been doing debugging. Lots and lots of debugging By the way... Still not finished with that... Hopefully will have a landing tomorrow.

*Dies a little on the inside* Edit: It is now that I begin to realize just how tall this thing's neck is.

Maybe I should rephrase on the very close. It's close, but not that close. Think... bigger… Hint: "arm lizard"

Very close!

Getting closer! Edit: Any more guesses?

I'll give a hint... it doesn't didn't fly.

Finally, with Fall break in all of its glorious shortness about to start, I am getting time to work on something. Any guesses as to what I'm making?