Geschosskopf

Members
  • Content count

    5901
  • Joined

  • Last visited

Community Reputation

4101 Excellent

About Geschosskopf

  • Rank
    Director of Shanghaiing Operations

Profile Information

  • Location Lousy Anna's armpit
  1. -Gives hoses- :funds:

  2. Hey, I was wondering if I could use your ships and characters from SE-2 for my fanfic, Alien Skies(aka Newer Horizons),

  3. Surely SpaceX uses explosive bolts? I really don't know what they use to keep their boosters from hitting the core, but I'm sure it's some simple, light system that probably needs to be replaced after 1 use.
  4. Well, decouplers aren't reusable, either, so you can't reassemble the boosters back into a rocket whether you use Sepratrons or not. Especially if you park the boosters on the VAB roof That said, though, while no SRBs (including Sepratrons) are refuelable in stock, it's easy enough to change that with ModuleManager. You just have to patch the resources file so you can pump SolidFuel, then you can use large RSBs on refueling rovers the same as you use large LFO tanks.
  5. OK, the tweak of the line CF from 120% to 150% of the planet's radius seems to be what it needed. So, here's the script as it stands so far. I don't know if I'll ever do any more to it because it's no trouble to do the flying yourself. Be sure to read the "tips on usage" section for best results. // SatSpacer.ks by Bullethead // v 1.0 2016-12-04 // This script is an aid for evenly spacing 3 relay satellites in a circular orbit of arbitrary inclination // around any planet or moon with a reasonably large SOI. 3 relays evenly spaced and high enough to be able // to see each other past the planet will give 360^ coverage on the ground at that planet, but will have blind // spots at the poles. To cover them, send another group of 3 relays and put them at an inclination > 45^. // // Starting Conditions: // 1. A carrier vehicle (CV) carries all 3 relay satellites into a closed orbit at the target planet or moon. // 2. The relay satellites need enough dV to circularize. // 3. Run this script on the CV. // // What this script does: // The end result is that the CV will be in an elliptical orbit with Pe at the altitude of the relay satellites // and Ap set so that the CV's orbital period is 1/3 greater than a circular orbit at its Pe. This script calculates // and displays the Pe and Ap for the CV to accomplish this. It's then up to you to get the CV into this orbit, // either manually, with MJ, or writing your own script to fly it there. Whatever. This script is just a calculator. // // Tips on Usage: // Satisfy the starting conditions then maneuver the CV into the specified elliptical orbit. It's a good idea to set the // CV's Pe first, then its Ap. This way, the CV will be at Pe when you're done. At this point, turn the CV prograde and // release all 3 relays in succession, giving them just a few m/s to slowly drift apart. All 4 ships will now be flying in // formation. Switch to the 1st relay, adjust its Pe back to the desired value if required, then circularize it when it // gets back to Pe 1 orbit later. Determine its orbital period (use MJ, KER, etc.) and write this down. Switch to the 2nd // relay and repeat. After it circularizes, use RCS (with thrust limited down to like 2-3) to tweak its orbital period to // be within 0.1 seconds of the 1st relay's period. Then switch to the 3rd relay and repeat. Then deorbit the CV. Done. // Figuring out where we are, how big it is, and how high we need to be. // NOTE: All this is based on distance from center of planet. Must convert later to ASL altitude. CLEARSCREEN. SET OurPlanet TO SHIP:BODY. SET SLRad TO OurPlanet:RADIUS. IF (OurPlanet:ATM:EXISTS) { SET TotRad TO (SLRad + OurPlanet:ATM:HEIGHT). }. ELSE { SET TotRad TO SLRad. }. SET ClearRad TO (TotRad + (0.5 * TotRad)). // Gives a clearance of 50% for LOS between relays in same orbit // NOTE: ClearRad will be used later to dtermine commsat orbital altitude vis trig and geometry // Determining commsat orbital altitude in terms of distance from center of planet based on ClearRad // Imagine 3 commsats forming an equilateral triangle around the planet. ClearRad drawn from the // planet's center bisects one of the sides of the equilateral triangle at a right angle. Another // line drawn from the center of the planet to a vertex of the equilateral triangle thus creates // a 30-60-90 triangle with this second line as the hypotenuse. We need to find the length of // this line, which is ClearRad / sin30. SET DistFromCenter TO (ClearRad / SIN(30)). // Converting DistFromCenter to orbital altitude ASL to give where we want to park the commsats. // Then make sure it's considerably less than the planet's SOI radius. SET SatAlt TO (DistFromCenter - SLRad). IF SatAlt <= (0.75 * OurPlanet:SOIRADIUS) { PRINT "Commsat altitude: " + ROUND((SatAlt/1000),3) + " km". }. ELSE { PRINT "SOI not big enough. Need more satellites". END. }. // Determining commsat and carrier vehicle orbital periods SET GConst TO 0.00000000006673. SET PlanetMass TO OurPlanet:MASS. SET SatPer TO SQRT((4 * (CONSTANT:PI)^2 * (DistFromCenter^3))/(GConst * PlanetMass)). PRINT " ". PRINT "Commsat orbital period: " + ROUND(SatPer,2) + " seconds". SET CarPer TO SatPer * 1.3333. PRINT " ". PRINT "Carrier vehicle orbital period: " + ROUND(Carper,2) + " seconds". // Determining carrier vehicle Ap given its Pe and period // Step 1: Finding semi-major axis. Elliptical orbital period is same as for circular // orbit with radius = to SMA. SET CarSMA TO (((CarPer)^2 * GConst * PlanetMass) / (4 * (CONSTANT:PI)^2))^(1/3). PRINT " ". PRINT "Carrier SMA = " + ROUND((CarSMA/1000),3) + " km". // Step 2: Determining Ap distance from planet's center using SMA and Pe distance from center // (Ap DFC) = SMA + (SMA - (Pe DFC)) because the planet is one of the foci
  6. I have what is probably a stupid question.... Using 1.0.2-pre2, I did the traditional "copy scriptname from 0." and while this worked, I got a warning saying the syntax had changed. Now I'm supposed to do this: "copypath(0:/"scriptname") Egad, that's difficult to type quickly, requiring actual thought, which breaks the mood when I'm "in the zone" coding. Not a fan but I guess I'll have to live with it. HOWEVER, next time I ran kOS, I tried doing it the new way to get in the habit, and then I tried all permutations of quotes or not and their positions, and all sorts of other variations on the above theme, and NONE of them worked. So what am I doing wrong? Has this change not really taken effect yet? Or is there some trick to getting the proper syntax? Do you really need the quotes? Thanks.
  7. Add a few Sepratrons to kick the boosters further apart. Sepratrons are my favorite part in the whole game. Besides being useful for their intended purpose, they have countless amusing and entertaining uses That's good to know. Thanks. I'd always assumed that you had to design the whole rocket so that the initial boosters could be safely down before the rest of it got too far away, with obvious limits on overall efficiency.
  8. I'll have to keep that advice in mind
  9. Besides the 3 main points I listed in my 1st post, I should have added 2 more that are VERY important: DISABLE ENGINE GIMBAL and TWEAK CONTROL SURFACES.. Seriously, engine gimbal is total poison except in 2 very specific cases: Dogfighting and the bottom stage of a lifter that lacks tail fins. In all other cases, you're trying to go in an essentially straight line so don't want any off-axis thrust. As to control surfaces, they default to being active for all axes, which is usually quite inappropriate. So disable yaw for everything that's not a dedicated rudder, and disable roll for nearly everything else. You don't need (or want) very much aileron authority but you need a lot of pitch authority. Also, it helps to put rudders on the wingtips so they don't introduce unwanted roll when used, but this isn't critical. But anyway, build the plane so the CoM doesn't move, put the CoL right behind hit, and turn on SAS. Add extra SAS if necessary. Don't over-think this. KSP aerodynamics are a minimal rule set that only loosely approximate real life. Most of the things real airplane designers have to deal with simply don't exist in KSP, and trying to chase them usually causes more problems than it solves. Um, no. KSP is not real life. KSP wings produce lift regardless of AoA. They just produce more lift with a positive AoA. Think about it. If KSP wings required a positive AoA to produce lift, then as soon as your pitch inputs created an AoA of zero or less, the plane would fall like a brick because the wings would instantly quit working. --------------------------------- Anyway, back to @Spemble To illustrate the severe simplicity of KSP aerodynamics, consider the following aircraft, which I call the Bowtie. I actually designed this plane back in 0.24, LONG before the atmosphere changed in 0.9 and 1.x, It flew quite well then and, with the necessary adjustments for different parts, flies even better today. You can download it here: https://www.dropbox.com/s/yzth4xst2nyll42/Bowtie STOCK.craft?dl=0 (action group 2 works the ladders, 0 works the airbrakes). I built this plane simply to show how weird you could make things that still fly perfectly fine in KSP. It looks like this: Despite this weird shape (note also that the forward wings are upside down to get the forward sweep), it flies superbly because the CoM doesn't move and the CoL is right behind it. You can also see that the 4 rudders are on the wingtips symmetrically above and below the centerline, so don't produce unwanted roll. Finally, the CoM doesn't move. In the pic below, I tweaked the fuel out of one of the rear tanks, so the red full CoM" moved forward of the red "empty CoM" markers, as shown by the wonderful mod RCS Build Aid. With that tank full, the full and empty CoMs are in the same place, as shown in the pic above. Also note the extra SAS in the cargo bay. The torque of the cockpit alone is usually insufficient so all my planes have more.
  10. So, let me get this straight. Kelgee got the shakes, there are now 2 Tetrises, and Barbara teleported from the ship back to the station? Hmm. Yeah, that would probably give me a mental BSOD, too So, will they be able to talk to Jool?
  11. Bravo! Simultaneous landings side-by-side on the VAB roof for extra style points, too Very impressive. How big of an impediment is it to have to worry about the distance between the boosters and the rest of the rocket? Do the boosters have to get down safely before the rest of the rocket gets so far downrange that the game unloads the boosters?
  12. The Boffins have not been idle despite it having been a long time since the Circus did anything. No, they've been hard at work testing and tweaking stuff for the next chapter of the Glorious Kerbal Space Empire. Their current project is to develop a kOS script to facilitate the deployment of what they call "Moonsats". In the Circus concept of communications networks (see the link in my sig), there are 2 general species of commsats: Main Relays, which have huge antennae and are in highly eccentric polar orbits over the central body in each planetary system, and Moonsats, which are in moderately low circular orbits, usually but not necessarily around moons of the central body. There usually needs to be more than 1 of these latter per "moon", and they need to be spaced neatly, and that requires more math than the Boffins want to do manually. Thus, the goal was to make KAL9000 (actually the name of the computer part in kOS) do crunch the numbers for them . Anyway, the project has gone from the drawing board to partial implementation and successful completion of early milestones in the course of today. The Boffins are feeling a little proud of themselves so decided to show off what they've done so far. And here it is: Really, that's all it does right now, just calculate and display those 5 particular numbers, only 2 of which are really important at the moment. But that was the main challenge. The rest of the project should be somewhat simpler as it traverses known ground. Today the Boffins had to learn more about the "anomalous rectums" (actual technical term) of orbits than they ever wanted to know . There's a non-negligible amount of code and a lot of research behind this simple display. The idea of the whole project is as follows: A carrier vehicle (CV) with 3 moonsats aboard gets into an elliptical orbit at the desired inclination around the body the Circus wants to hang a network on. At this point, the kOS script is activated. The kOS script figures out a good altitude for the moonsats to orbit the body and adjusts the CV's Pe to that altitude. The kOS script determines the orbital period for a circular orbit at this altitude, then multiplies that by 1.33333 to get the desired orbital period of the CV. The kOS script calculates the Ap needed by the CV to have that orbital period and adjusts the CV's Ap as needed. Once so adjusted, the CV releases 1 moonsat per orbit, each of which then circularizes at the Pe of the elliptical CV orbit. Because the CV's orbital period is 1/3 longer than that of the moonsats, each time it or a released moonsat reaches Pe, it will be 1/3 of an orbit behind the previous moonsat, so they end up evenly spaced and able to see each other around the body. To accomplish this, the Boffins broke the project up into phases: Phase I: Develop the basic algorithms for computing the required orbital parameters, in such a way that the same script can be used at any body with a reasonably large SOI. Just print these numbers on the screen and test their validity by performing the necessary maneuvers manually. This is actually the only important phase because the system is workable at this point. The later phases are gravy. Phase II: Add the ability to deploy n >= 3 satellites, and add automation so the CV performs all maneuvers itself. Phase III. Write a separate program for the moonsats so they can tweak their own orbits automatically. Today, the Boffins are please to report that Phase I is complete! It's that output which appears in the pic above. The process starts by determining a "good" altitude for the moonsats. This has to be high enough that they can see the adjacent moonsats sharing the orbit without the planet in the way, plus have some margin of error for imprecise maneuvers getting there. For the 3-moonsat problem, this altitude is determined as follows: The desired quantities are the line CS (for calculation purposes) and also CS minus the radius of the planet (orbital altitude for maneuvering purposes). The length of the line CF is arbitrary, whatever you think gives enough clearance between the edge of the planet (and atmosphere, if present) and the LOS between adjacent moonsats. In Phase I, the Boffins chose 120% of the body's radius. This turned out to be just a tad too short in practice, so will be increased to 150% in the next round of testing. In any case, for the 3-moonsat problem, Triangle CFS is a 30-60-90 right triangle so with CF given, calculating the length CS is just 1 trig function away. The next step is to calculate the orbital period for a circular orbit of radius CS. Just plug the numbers into Kepler's 3rd Law: T = SQRT[(4 * π2 * R3) / (G * MP)] where T is the period, R is CS, G is 6.673 x 10-11, and MP is the mass of the body you're orbiting. Simply multiple this value by 1.3333 to get the period of the CV/s desired elliptical orbit. It was at this point that the Boffins started running into all the "anomalous rectums" and thought they were going to have to do a bunch more calculations using them to figure out the CV/s desire Ap by way of the semi-major axis. But fortunately, the Boffins figured out a shortcut after a chance reading of a footnote buried deep in dense pages of complex equations. That life-saving footnote said this: "A circular orbit with a radius equal to an elliptical orbit's semi-major axis has the same period as the elliptical orbit." The Boffins already now had the period of the elliptical orbit so could plug that back into Kepler's 3rd Law (above) rearranged to solve for R, which in this case would be the semi-major axis of the CV's elliptical orbit. R = [(T2 * G * MP) / (4 * π2)]^(1/3) Then, because the planet is at one focus of the ellipse, the altitude of the CV's desired Ap would simply be: Ap = [( 2 * SMA ) - CF] - the body's radius. Wow. That wasn't so hard, thanks to the shortcut Anyway, with all these numbers determined, the script simply printed them out as shown above. All this worked fine at Kerbin in an equatorial orbit but to really test Phase I, the Boffins sent a wad of 3 moonsats to Mun and had them arrive with a 60^ inclination. Here they all are still attached to the CV en route to Mun. And here they are being deployed, all being flown manually using the numbers calculated by KAL9000 using the script. You can see the CV is in a slightly elliptical orbit with the 1st moonsat in place and the next in-process. With all 3 moonsats in place, the Boffins de-orbited the CV. As it turns out, 2 of the moonsats can't quite see each other and the others are borderline due to their orbits being a shade too low. As mentioned above, fixing this is just tweaking 1 scalar value so really isn't important here. What is important is that the Boffins managed to code this script without any egregious logic errors, despite not knowing much about fancy orbital mechanics, and that the algorithms work well enough to provide good results even with substantial rounding errors (for clarity in the display of the numbers) and the imprecision of manual flying. So now the Boffins are celebrating with their traditional whiskey and wondering if it's even worth the trouble to go on with Phases II and III.
  13. Yeah, the "Aim Camera" tweakable does seem to have rather the same functionality.
  14. Yay! The heat changes sound very good and no more having to upgrade on the launchpad in sandbox Looking good on the command pod. I can tell I'll be putting a lot of miles on that thing.