Elliptical Orbit

I had the ability to control the throttle with mechjeb enabled on an earlier version of KOS. I take it that this is broke at the moment?

The best results I had was back in 21.1 and using Mechjeb and KOS at the same time. Mechjeb did all the ascent guidance and KOS did all the mechanicals and it worked perfect. I would just setup my plan in to Mechjeb and manually engage the auto pilot, then go start my script in KOS sit back and watch the show. The one thing that I can’t get to work in this newest version is the ability to lock the throttle to positions I want the engines to have with Mechjeb engaged. It seems not to work in this version and I know that in the older version I have for 21.1 Kevin has had this issue before and fixed it. I want to say that those file versions was either 8.x or 9.x. So at the moment I have to engage Mechjeb after my vehicles leave the ground but I still have no throttle control using KOS. Wonder if this can be possibly looked at?

Don’t suppose we could use these really cool venting effects on other engines?

Those items do not ignite the engines. They are only meant to burn off excess hydrogen that has not been ignited internally inside either the combustion chamber or the gas generator. Ariane 5 does a pretty good job at it while the Delta IV does a modest job at best (hence the charred blackness on the sides of the cores that you see after it has lifted off). A nice view of this is on the most recent GPS launch. If you have not checked it out there is a picture on the Spaceflight Now website that is a good example. http://spaceflightnow.com/delta/d365/launch/ But then the amount of hydrogen the RS-68 pumping out is a lot more than the Vulcan, not to mention the SSME had all the gas generator exhaust going through the combustion chamber so all the excess was pretty much burning at engine start.

It already is, just add the module lines to your pods in the part cfg files. MODULE { name = ModuleSAS } MODULE { name = MechJebCore } MODULE { name = TelemachusDataLink } MODULE { name = kOSProcessor }

Wow I have not checked out all the new stuff in a very long time and have been away from KSP. I see things have become a bit more interesting and there is a lot of great work going on. Here is a spot that may help better than Wikipedia stuff that it seems everyone wants to go to for their info. http://heroicrelics.org/info/h-1/h-1-c-d.html Of course the H-1 did not begin life as the H-1. Also there were two types of H-1 on the Saturn 1’s. I will just let you check the site out. If it wasn’t for the government taking down the NTRS site and not placing back all the info that it had, you could find out a lot more.

If you are like me then I tend to change fuel/oxidizer amounts in tanks to more accurate volumes for their sizes (sometimes gallons, other in liters). Not to mention that I will change the burn ratios on engines to match those we use on earth. For that reason even if you were to put amounts for fuel and oxidizer that you think that will be used evenly in an engine, I tend to make my vehicles oxidizer deplete first depending on what I have set for ratios. So you may be reading your liquidfuel amounts with your line of code but running out of oxidizer first which the program never sees if you do not have a line for that as well. Here are a few lines of code I have that works perfect for me that sort of works like an oxidizer gauge. wait until stage:oxidizer < 650. print "Lox 5% Sensor". print "". wait until stage:oxidizer < 390. print "Lox 3% Sensor". print "". wait until stage:oxidizer < 300. lock throttle to 0.

Simple timer code: set t to 15. until t < 7 { print "T - 0:" + t. set t to t - 1. wait 1. }. clearscreen.

This may help some users about using volumes, unless I have missed something that has changed… You have two volumes to work with one is “0â€Â, which is the archive volume. This is the volume you need to be in to save (at least your first) program. And you tend not to use it unless you really want to after your first program. The other is “1†which is what I call the working volume. This is the default volume you are working in when you first start the terminal and it is the volume that I run my programs from. If you wish to program in the terminal then you switch to volume 0 with the switch to volume 0. command. Say the file I wish to create is named ls2. Switch to volume 0 and start with edit ls2. command to label the file and start coding the program. From there you can program your code and save the completed file by pressing F5 when you are done. Your files will be saved in the archive folder on your machines hard drive. Mine happen to be in C:\KSP 21.1 - Loaded\Plugins\PluginData\Archive. Not sure what steam users would be. As long as you have a single file there you can copy, paste and rename as many files in the directory, and they are technically stored on volume 0 for KOS. Once you have a working file then I switch back to volume 1 and load the file from volume 0 that I wish to run. switch to volume 1. Copy ls2 from 0. Run ls2. If you have a file already then all you need to do is copy the file over from volume 0. If I have another file that I have modified then all I do is load that file name since I am usually in volume 1 anyway, then run the program.

Great work with the latest version sir! Back in action again.

Well, don’t get the error on the terminal anymore but it will not execute the command. It will do everything up until that point.

I can confirm that the below line does not function anymore either. Unrecognized term: ‘stage’ error. wait until stage:oxidizer < 200.

Don’t suppose we could get a feature to lock the camera in a stationary position and have it follow an object with out moving with it?

Don’t suppose that we can get this to turn on/off parts of Mechjeb? Right now I got a pretty good ascent script using it to control the mechanical parts and Mechjeb to control guidance, but I have to manually turn on and off the Mechjeb ascent guidance for my vehicle to do what I want it to do. I prefer it more than trying to code that part right now, and it works wonderful. If it was not for that I could send a probe to Duna completely hands off! This mod is the best thing since sliced bread!

Is there a way to get back the ability to have your vessel keep a pro grade orientation rather than swapping ends for a retro grade one while on the coast up to AP during ascent? Or have the ability to toggle what you would like to happen after engine shutdown?

Yea! Glad to see some Atlas stuff coming back. Have not seen much since the Jordancox IFE pack (Ares I, SLS and Atlas 400/500 series) back with v.13.

Wouldn’t mind seeing the expanded fairing bases have a secondary wall part that can be jettisoned. Something that leaves behind a part that looks like the standard payload adapters but using the expanded parts. It would give another cool look and the ability of having more parts being shed. Not that it is the same as but an example would be how the Altas V and its 5 meter fairing have the support rings for the centaur. Long Live KW Parts!

I have not had a chance to mess with .20 yet, are these issues .20 only related? I ask because some may not know about the way you use KW fairing system. You must start at the top first and work your way down. Not the other way around. Start with the nose first and then add your walls. After you have a complete faring then if you need to remove it to see what is inside you just click the bottom most part and it will remove the entire assembly for you. You can then place it back when you are done. As far as the rescale factor, is this something new as well? While I change a lot of the other settings for these parts, I have never had to change that before. I have only concentrated my efforts on only the 1.25 and 2.5 meter items but I have noticed that the unit of measure for certain items seem to change from mod to mod. So instead of using pounds of thrust think kN instead. Same goes for weight, ton and metric ton or volume, gallons vs. liters for tanks. The best way to keep track for me is to use a spread sheet that I have made to keep track of all the standard settings the mod has. I also place any changes I have made along side those setting so I can tell what I have changed. Now it reminds me that I need to go update it for 19.1 so I can move to .20.

Not so much of deploying one as some random crashes that did not happen in 18.2. Not sure if it is me with some of the addons or my crap OS or the hardware itself. But then I do have a 5 year old machine that does SETI 24/7 (inc the graphics card) and using XP 64 on it. It is not the best OS out there and would not have done it had I known that the drivers for the board I have are crap. So now I am just waiting for IB E5 Xeons to come out for a new machine.

I believe that the SRBs in the pack do need a few attachment changes for sure. I have tried to use them with some of the vehicles that I have created and they are not quite there. Messing with the cfg files does help a bit but, using them just becomes frustrating. Most of all they need a TVC systems of some sort to be more controllable. As far as the rest of the parts go, I seem to not have any problems with their liquid parts at all. And I have had more success at using them. But then I have done quite a bit of tweaking on the cfg files too, mostly on the small parts. I have a small test video I made so I could have proof of the ascent issue that mechjeb 2.07 has when it gets close to AP, that is known and will be fixed. File size is about 25 Meg. Please let me know what you think. Mike https://www.dropbox.com/s/bwhps7xwysljrzy/Test%201%20-%20Small.mp4

Reading about some of the issues that users are having with the instant on scanning and fitting of the part, I was thinking about some ideas about this mod. It needs to change the dish part in to something more like what they use on real satellites. Say like a sensor box or pod that has a door that can be opened when in use. This would keep the sat from scanning until you turned it on with an action key. A box would be used if you wanted to mount it directly to your probe body. Or use a round pod that can rotate 360 and tilt 180 as well a door that can be opened. You could mount this to a folding or telescoping arm that can be deployed after launch. Then use the box or pod and fill it with different sensors of your choosing. Want a visible light camera? Need a kethane scanner? Want to scan in infrared or any wavelength? Add any sensor you want when someone makes it. Make them in different sizes for adding more than one sensor to that pod or what your needs require. Heck, add more than one pod. Then go one step further, and have your sat keep the data until it is able to beam the images back to Kerbin before you can look at them using something similar to the RemoteTech mod. Just some ideas.

Not sure if this has been asked before or not but will there be a way to display more than one time at a time on a single page? And being able to pick the variables we want to be displayed on those items?

You are correct, not so much a bug but more of a nitpick. I don’t use the auto warp feature for ascents. I have been using it that way with the older versions and just prefer to have the vehicle turn slowly keeping itself always aligned until AP is reached. Is there a way that you can add a toggle to have it on or off? Like the autowarp feature? And by the way thank you for putting that back. Keep up the great work!

Something that I am seeing in 2.07 that I have not seen before and I searched the thread to see if anyone else has mentioned this about the ascent guidance… I use a normal looking ascent profile for my vehicles and usually set a max turn altitude at about 80-90km. On low Kerbin orbit flights (200-300km range) and depending on the performance of my vehicle I build, there are some upper stages that I sometimes end up chasing down the initial AP. In previous versions this initial established AP (not the set AP I want), I could sometimes either get near it or fly past it on my way to my set Altitude. Of course this usually becomes the PE on the first orbit until it is circularized. Now if my vehicle gets close to this initial AP Mechjeb will shut down the engine and/or make the throttle behave erratic (on /off) till it gets past AP and then carry on as if nothing happened. Also after establishing my set AP, my vehicle would sit in the prograde coast position until it reached it and then begin the circularization burn and shut off mechjeb when finished. Now it wants to immediately swap ends and point to it after upper stage engine shutdown to coast to it. I did still have problems with my vehicles not wanting to steer my planned ascent profile. But after I tweaked the gimbaled range from what I had changed it to this problem has gone away. I had the mind set that the less the engines would move the more stable the vehicle would be and less chance that it would go out of control. But I increased the settings back and wouldn’t you know.

It seems that it has a hard time keeping up with solids. Also automatic staging events seem to look like they have less force than if you were to do it manually. Will there be a way to disable the autowarp feature so that it does not do it unless you want it to? Still this is a great addition to the game, well done guys!