Payload

Haha, if we get array handling who is going to be the first to make Pong? Tetris might fit nicely too. Why warp to that transfer orbit when you can play Tetris while you wait? I saw that video. Dude, that is all kinds of rad. I am already picturing a kerbal on a command chair perched on top of about four reaction wheels, running around on chicken walker legs. Automatic targeting of the chain gun.. No debris will survive.

Just doing some testing on the efficiency of limiting TWR below 10k with the stock game. Results: Orbital test. Parameters: 100k orbit alt. 0deg inclination. 6255m/s total 1927m/s left after orbital test 1. limit TWR to 2 until 10k. 1919m/s left after orbital test 2. limit TWR to 2 until 15k. 1801m/s left after orbital test 3. limit TWR to 1.5 until 10k. 1923m/s left after orbital test 4. no TWR limit. 1923m/s left after orbital test 5. limit TWR to 2.5 until 10k. So 2 is better than 2.5 and 2.5 was the same as not limiting it at all. That is with the stock gravity turn settings. Conclusion, if you are way over 2.0 TWR on launch you want to use the limit. If your rocket starts about 1.8 or 1.9 and gets no higher than 3. The limit might only help a little. 2.0 seems like the ideal setting for stock KSP. That might not be true if one changes the G-turn settings to rotate more slowly. More experimenting will have to be done. I think that is about optimal launch dV for the stock game. Someone might be able to get lower.

The thing is, I have been trying all day to build a rocket this thing can't fly. Unless I go really extreme on the bad moves, I can't do it. When I finally did build one that it couldn't fly, there was no way I could do it manually. I think there are some epic button mashers out there that have no idea how bad the rocket design is because of their epic button mashing. I applaud those epic button mashing skills. I don't have them. That is why I got Mechjeb and then kOS when it was available. I really am wanting to just throw Mechjeb away now, but I need it for it's information. It is really helping me debug and understand suitable behavior modes. I expect we will have far less failures now that people can read the comments. I also bet there are a few things I didn't think about. As far as testing goes. This thing should stage Asparagus, Parallel, and Serial as well. Someone needs to give that a work out. I have tried all of those and it works. I bet there is some configuration I haven't thought about yet though. That is what we need to do. Weed out the failure modes. There is no way I am going to attempt any landing code until I know this is working as well as it can be. One thing I need to explain. The prints in the loop are bad form. I know that. I have left them there for the time being for debugging. I really wish prints weren't that slow, but they are slow on every platform I have ever coded for. Nature of the beast. You can increase the loop speed by quite a large amount if you remove them. I never thought I would have to write code for something that is slower than my Amtel based Ardiuno clones. I thought wrong. This is an interesting learning experience. On a final note, WE NEED MODULES. Who is writing the landing script? We also need orbital correction modules. I can help. I think I might be able to muster the strength to do the calculations properly this time. We also need the standard orbital vector selects like mechjeb's SASS. We could use a standardized program that checks the current body. Now that examples of how to do that are available. We need it to set some variables. If you have some questions ask me and I'll get the info we need. It's not like it can't be amended. EDIT: Kalista, if you set tOrbit to 200k in the beginning that will set it's default value to 200k. Then all you have to do is hit 7. Have you tested the Jebpollo craft I posted? Or the official test craft? I think both of those are on the limit of this launch system.

I understand what you mean but the R() system never had to be this way. All he had to do was extract the values he called pitch and yaw and run it through the trig functions and use it to set the vector and use absolute roll to set roll. The problem was those weren't pitch and yaw. For instance, this works. set yaw to 90. set pitch to 90. set x to cos(yaw) * cos(pitch). set y to sin(yaw) * cos(pitch). set z to sin(pitch). lock steering to up + R(0,0,180) + V(x,y,z). There is no reason why those first two numbers couldn't have really been pitch and yaw and the trig done on them. (pitch,yaw,roll). Indeed I thought that was happening by looking at his code on Github. I think maybe he is using some other method to set z that causes gimbal lock. Either way, you only need pitch and yaw to set the correct vector. The gimbal lock is artificial in this case. That doesn't mean we don't need the V() structure because it is useful for other things, and the code above is effectively the same as the Q() system anyway.

kOS v0.61 is out. I have tested some new code and added comments so it is easier to follow. V0.61 compatible launch script is now up on the front page. Go update your kOS to .61 then you can have commented code!

Sweet man thank you so much. I just took the time to comment my code anyway. It really needed it. So you did me a favor. LOL.

I don't see any syntax issues there right off. I do wonder what you are using surface speed for though. You also have to realize that if you cut your engines when you get an apoapsis of 69k you will never make it out of the atmosphere. You will still be in the atmosphere and your speed will reduce rapidly. Also 69k is still in the atmosphere. It doesn't end until 69500. I would be more apt to try. when altitude > setAlt then doSomething. Altitude works just fine. It's how the launch script on the front page works. Surface speed probably should too if you set it based on the rocket. I would suggest verticalspeed over surfacespeed though. Once you hit your target apoapsis and shut down, you will lose speed and the apopapsis will drop. You will need to goose the engine a bit to keep your apoapsis at the set height until you get out of the atmosphere. Say you were shooting for an apoapsis of 80k. You will need to do something like this. until altitude > 69500 { if apoapsis < 80000 { lock throttle to 0.1. }. if apoapsis > 80000 { lock throttle to 0. }. }. The loop will break when you get out of the atmosphere and then you can prepare for your circ burn. EDIT: OHH I think I know what your problem is. You still have power when you go to wait for apoapsis? I think you might be running out. Does the kOS screen go blank?

The problem is speed. It just isn't fast enough to do that and everything else it needs to do. Your steering would be all over the place.

I have kept a copy of them all since I started using it. The problem is the distribution rules. I haven't read them. I assume you can't redistribute.

It is definitely understeering now. It wasn't over steering before. It was experiencing Reset Windup and Derivative Kick. Reducing control force globally wont fix those problems globally. Only locally.

Well sadly we are going to have to revert to the older version of kOS now. I tried updating the script and that is not gonna work. The new PID changes to the steering have wrecked the ability of kOS to control even modest rockets. Though I can set a new heading. The craft wont hold it now anyway. Sorry guys. We are just going to have to use kOS 0.5 until this gets fixed. I'll make a notice on the front page.

Well it doesn't matter if I used the new system anyway. The steering is terrible now. It wont hold a heading even if you told it too. Reverting to the old version until this gets sorted out.

set tAngle to up + V(x,y,z) + R(0,0,roll). Yup. This worked yesterday. Now it's broken. I'm pretty sure that is not desired behavior. I really don't want to have to redo all my steering once again. The new method is nice. Though as Steven points out, we still need the old way to work also for various reasons.

Hmm seems to work here. I'll have a look. Maybe I fat fingered a key on the paste. Hold on I haven't tried the new update yet. I only installed it before I went to bed. Lets see. Yep it's broken now. Ugghh. I just redid the whole steering system. Looks like I'm going to have to do it again.

Roll control has now been added to the launch script.

Well anything about how the controls are handled I can't take credit for. I would have to give that credit to Kevin Laity. All I have done is tell the program what to do. How it handles that is squarely down to him. I know absolutely nothing about how Mechjeb works internally. It may have something to do with the way the PID is handled. Kevin's acts more like a traditional PID controller. I think it has a little bit of ringing compared to mechjeb but it seems to make course corrections in a much better way. In Kevin's blog he said he has fixed the ringing so I'm eager for the next release. We are getting surface prograde info so it's time for some fancy landing.

Though the video is not accurate as far as exactly how this would have to work. It is a really good idea. Imagine if you could just go to your car dealer and pick from a list of modular parts that all adhered to a standard. Imagine the market competition you get when anyone can build a part to those standards. Imagine how much further the auto industry would be progressed if they actually had to keep up with technology on a daily basis. Part of the reason these phones have progressed so far is the speed at which they can keep up with current tech. You do this, and that happens even faster. It's a marketeers wet dream and it is also nothing but good for the consumer. Win/Win.

I have a crazy trick for you to try. Try pulling prograde until you get 837ms of dV on the nav ball then adjust your node time by dragging it around. See if it doesn't give you a decent capture every time. That seems to always work for me. Still I remember the days when you just burned when you saw the moon on the horizon of your orbit. We used to just keep checking the map to make sure we didn't completely blow it.

Man FAR is weird. Even with your TWR locked to 1.5 it is still getting up to speed pretty fast and it's hitting that dynamic pressure more than I expected. I'm glad it's working out for you. I hadn't specifically tested it against Mechjeb to see how fuel efficiency was compared and I never intended it to be used with far. I do know that it's inclination launches are more accurate than Mechjeb. I had assumed that the extra accuracy was costing me fuel. It's good to know that it isn't.

Throttle limits are a great idea and it can really help keep you from wasting fuel. I have setup a TWR hold in my script. It works better than I could have imagined. I say go for it. It will only help. It doesn't have to be very elaborate to get the job done.

You can't build a rocket like that. Straight up. It's common knowledge that things that are controllable by humans may not be by a computer. I'm just giving you hints here. Launch a wide variety of crafts it can do. It probably wont do so well launching a rocket that is built ignoring all physics like they don't matter. That is far worse than "less than optimal". I can't believe that thing actual did as well as it did. Another problem that is not your fault at all is the fact that deployed coms dishes like that have about FIVE times the drag of any normal part. They should just get ripped off, instead they have a ridiculous breaking strength and they are trying to pull the top of your rocket down. Because the bottom is unnecessarily heavy, that adds up to a combo that is not dynamically stable. That is like putting the fletching on the tip of the arrow instead of the end. It pretty easy to see if you have a good design or not. Watch the control indicators on the bottom left. If they are constantly swinging to the limit then you have an issue there that is beyond the control stability of the system. You can't just say that it failed to launch a poorly designed rocket properly. What do you expect me to be able to do about it? It doesn't launch rovers into space either. It wasn't designed for that. It is designed to be a starter script that you can tweak to launch your style of crafts. The default values are set to launch a reasonably large number of rockets perfectly fine. What you have here is a case that is far out from the norm. I do appreciate the feed back but saying that the program can't launch that rocket is like calling an auto manufacturer to complain that the coffee cup you bought doesn't fit into the cup holders. Certainly if they are fully adjustable cup holders that you just haven't taken the time to adjust, that seems a little wacky. First. Adjust the TWR limit. I noticed that your rocket has a TWR of 6.0 as it hits the edge of the atmosphere. You can stop the TWR limit from cutting out at 10k if you so desire. Look at line 190. See where it says "when altitude > turn1 then { set throttleLimit to 0. set tThr to 1. }." Delete the set throttleLimit to 0. line and the set tThr to 1 line. Then add set tTWR to 3. Then it will hold 2.0 TWR until you reach 10k and then increase it to 3. It may be that you need the control authority of full thrust all together. Try setting the throttle limit to off. It's not that I care about genuine criticism. But you are trying to launch one of the poorest rocket designs that I have seen in a while. I bet with some tweaking it can launch that rocket. Maybe not optimally, but hell the thing has very meager payload and you have it sitting on top of KSP equivalent to the Saturn 5. I'd say that is a pretty edge case. Yes roll control is not added in yet and that is causing some instabilities right of the bat. But the rocket did recover from that. It just didn't have the control authority to keep it going straight up or to make the G-turn. Average rockets have a TWR of 2.0 approaching 3-4. Not a TWR of 6 by the time you hit 20k. I'm asking if there is something you need to make your rocket easier to fly. Is there some setting that you need that is missing? Is there a part of the script that isn't functioning correctly? That is what I mean by feed back. Not this darned thing won't control my UNIQUE rocket because it's way out from norm and I haven't bothered to change one single setting. It is also not possible to launch into an orbit that is lower than 80k with my script unless you have changed the limits your self. I will say this one time and be done with it. This is not Mechjeb. It was never designed to be a MechJeb replacement. It is designed to be a framework that others can use to avoid having to write out an entire script when most things will just require a small change in settings. It is intended that you have some knowledge of this system and for you to be able to make changes where they are needed to fly any rocket to orbit. If you don't want to be bothered to take the time to learn how to use it. Then you need to use Mechjeb. I can handle building crappy rockets to test with my self. I built one with a TWR of 15 off the pad just to test my TWR hold. It still managed to orbit and steer that with perfect authority. Finally, I seem harsh because I'm Old. I have no time to mince words nor do I have any desire to do so. If the truth angers you so much then I am the wrong person to discuss it with.

Apparently you didn't read about the time warp. The warp logic is already set to be sensible. I also can't fix the fact that the Physical warp kicks in if you have focus on the kOS window. The best I can do is close the display before it warps. That would have to be an action group that YOU set up. I can't do it for you. Your rocket can't roll fast enough so it's wobbling about. According to Kevin, that should be reduced in the new version that is coming "soon TM." I have no control over that. I think the major problem is coming from force roll on lift off. I have been able to successfully add roll control back in the test version. You will have to set it so that your rocket doesn't roll after take off. I have a few things to do this morning but I'll be back in a few hours and I can post the script with roll control. I bet that solves your take off wobbles. It is trying to roll to 0 right after take off. You just need to tell it not to. Just to be clear. I have no control over the PID for the steering. I can only tell it where to point. Reading Kevin's latest blog post has me pretty assured we wont have to suffer that problem much longer. OK just watched your whole video. That rocket is not stable because it is bottom heavy. It also looks like you have FAR installed. I cannot help with a dynamic pressure problem you have caused yourself. Try reducing the TWR limit until it's stable in lower atmosphere. Next time ask yourself why you think you need all that orange tank and mainsail to launch such a light payload. Look at it driving the steering controls to the limits! How is it supposed to be able to control the rocket if it is at it's limit? Lose that ridiculous lower stage for something about 30 tons lighter. You guys install all of these things to make flying rockets more real and then you complain to me that it is too real?

O.K. Guys. New updates on the front page. Heading is now set via yaw with the Variable tHeading. Inclination launches are now as easy as setting a heading. The further you stray from equatorial the more Your inclination will vary from heading. Worst is polar at around 84deg inclination. 45 deg heading was 44.6 inclination. YMMV. Rockets launched into inclination should now circularize much better. Pitch is set just like it used to be. Only with a better term and the numbers now correspond to the Nav Ball. Throttle limiting is in. You can currently limit your TWR directly via the variable tTWR. You can turn throttle limits off with the variable throttleLimit. Auto warp is in. If you have focus on the kOS window then the auto warp will default to Physical Warp for some reason. So make sure you don't. Hohmann transfer updated with warp script. In progress. Getting the menu systems updated to reflect the new features. Still waiting on EXIT AND RUN. Before that will function correctly. As all ways, The current settings should launch most reasonable rockets. With minor tweaking you should be able to launch just about any rocket. Any feedback and testing is welcome. Enjoy.

It's really easy. Just have your loop update the xyz values as shown. You may not need the limits for function. They are there for the print out. I haven't tested to see what happens when you go beyond the 360 limit. My program doesn't have limits. I assume most people will know that >360 and <0 are invalid. 90 degree yaw equates to North on the Nav Ball. I have wrapped my yaw value in a target heading. Which is just set yaw to 90 + tHeading. You can then set tHeading to whatever you wish and that corresponds to the Nav Ball heading. Pitch is 90 up so that works out. Pitch is set via heading. I set a heading of 45 at my first turn and ended up in an inclination of 44.6deg. I'd say that's not too bad. I have not tested adding roll into the mix as of yet. I feel it might be the only thing R(,,) is good for.

There has been a lot of discussion lately about how to control your rocket's angle in an acceptable manner. Had this simple information been included in the read me, we could have avoided all the problems from the very beginning. Of course now that I have a handle on it, I fully expect the new update will come as I write this post. If not, then here is an example of how to use the V(,,) instead of the R(,,) system. You can use this until the new update rolls out to gain full and accurate control of your rocket. I'm pretty sure there are a few people that actually knew this from the beginning. All I can say is shame on you. This took me five minutes once I actually found an accurate description of the formulas. set yaw to 0. set pitch to 90. set x to 0. set y to 0. set z to 0. set q to 0. set tAngle to up + V(x,y,z). lock steering to tAngle. clearscreen. until q = 1 { on ag9 set q to 1. set pitch to pitch + 5. set x to cos(yaw) * cos(pitch). set y to sin(yaw) * cos(pitch). set z to sin(pitch). wait 1. if pitch > 359 { set pitch to 0. }. if pitch < 0 { set pitch to 359. }. if yaw > 359 { set yaw to 0. }. if yaw < 0 { set yaw to 359. }. print "x " + x at (0,1). print "y " + y at (0,2). print "z " + z at (0,3). print "Yaw " + yaw at (0,5). print "Pitch " + pitch at (0,7). set tAngle to up + V(x,y,z). }.