impyre

I like the idea of adding minerals/metals/resources that are unique to each planet (each planet could have its own), and obtaining samples of these would be needed to "discover" them and their special properties, thus allowing new technologies to be researched (and new parts!). The catch is that those new parts require the material that unlocked them in their construction. This would also give you a reason to visit all the planets (besides to just go look at them) since science usually doesn't last very long.

I don't think a snack generator would destroy it at all. It would give those of us who like to build bases and stations a way to keep them fed without having to run back to Kerbin for snacks. And in any case, as he mentioned it would probably require surface samples, that dependency really means that the main use would be to carry enough snacks to get to point A, make enough for the return trip on site, and then come back. For short trips like the mun and minmus, you'd probably save on weight just skipping the snackfactory and just packing a few extra treats for the trip back... but for trips to places like laythe, the usefulness of a snackfactory becomes much greater (without eliminating the point of snacks altogether.)

I see your point with time warp; however, it could be argued that it would warrant more thought in that case (planning ahead)... after all, must you not think ahead when it comes to electric charge also? Life support (i know that's separate, but still... in the line of "reality" i figured it bore worth mentioning)? Another thing is that I don't believe the game monitors dV in any way, just fuel levels... however, time is already kept by the game and would make adding this feature simpler. As far as intensity of operation, I'd vote rather for using time as the primary metric and maybe have g-force act like a "multiplier", creating excessive wear and tear. G-force has the added benefit of being another stat the game tracks already, and also has a more logical connection to something that might be considered to increase wear and tear on parts that aren't engines. It also has the effect of scaling damage with respect to what a vessel is doing. For example, nuke engines are built to last a long time... they have to be, having one wear out before it's depleted it's fuel on run #1 wouldn't make much sense, any high-dv/low-thrust engine is going to suffer a raw deal if dV is the measuring factor (and they already get a bad rap for usually being heavy with poor TWR). It doesn't seem right to punish them further. edit: g-force is also tied intrinsically to dV (as also with acceleration directly)... however, while dV is also tied to ISP and weight ratios, g-force is not. edit2: another thought I had, you could have bases/stations with repair bays set up to automatically perform routine maintenance as long as supplies are available to minimize the need for micromanaging and the danger of having things become inoperable during timewarp. A single interplanetary ship might not need a repair bay, but a flotilla might benefit from the presence of at least one amongst the fleet. (flotillas are my preferred method for interplanetary missions)

I think most people would want to see the snack levels listed by number of remaining days given the current crew using that snack box-shaped insular niche (Snack B.I.N.), lol. Is that possible? (knowing down to the last second is probably unnecessary)

I love this... this is the essence of Kerbal... should be stock imo. (I was always frustrated that a lone kerbal in a space suit could orbit for 40 years with zero consequences.)

yeah, the real problem is that if you're going too fast you skip the atmosphere entirely between physics ticks... by the time the game realizes you're in atmosphere... you've already found the ground. In any case, destruction is imminent. If you wanted to enforce some atmospheric effect occurring at speeds high enough to "skip" the atmosphere, just have the game check to see if you're "about to enter atmosphere" and if so, destroy your craft at the appropriate time.

A good way to avoid the "gaming" of the system by storing vehicles and parts you have no intent on using seems to be of no real benefit... you may as well introduce a "savings account". However, if you really wanted to prevent it, have vehicles cost upkeep to repair/maintain/resupply/etc. It would decrease the "budget" for each month by a little, and over time it would probably add up to costing more than the initial build. If you wanted to add a reality factor, have the cost of maintenance go up with time (perhaps up to a maximum maintenance cost)... this leads to "time to replace that aging space fleet for something new and shiny (and more reliable)" maintaining things can be expensive... maintaining old things can be really expensive. edit: the cost of maintenance should also be higher the further from KSC you are... and another thing, it would be good to be able to select which things you want to maintain and/or how much percentage of the maintenance cost you want to pay. (and maintenance should be impossible outside kerbin unless maintenance outposts are created) This would probably merge well with another suggestion in the suggestion forum about introducing maintenance into the game.

The easiest way is to just "minimize" the navball. Another way is to set an action group to shut off engines (if you choose toggle, be careful about toggling all engines because it will turn on engines that may not have been properly staged yet).

I really like this idea, but I think toggling it is unnecessary. Your idea would make it really easy to see every stage, so hovering would actually work just fine. Just over over the "show all stages" icon, and then all the lines and everything pops up, once you go to do something else it automatically vanishes (clicking could still be optional toggle though).

I love this suggestion, it adds a new level of depth to the game. I'd recommend using time as the key component instead of dV though, as accelerating doesn't really affect anything directly other than the engine itself... most parts just deteriorate with use (and many are used regardless of acceleration, take solar panels on a station for example) so using time as the degradation component could still be tweakable, but also allow for the degradation of bases/stations/etc. This also opens up whole new ideas, garages/hangars where players can store/refuel/maintain/repair vehicles, and maybe even a repair bay intended for use with stations (read: really heavy) where it could be used to make repairs to docked vessels and/or repair the station itself... though it should consume a "repair supplies" resource in the process.

Also consider the dead weight factor. While marginal, for large payloads it might make a difference. You could've added much more fuel for no additional tank weight penalty or tank cost, creating greater efficiency. Although with the scoring taking cost into account, I can see where the incentive is to deliver the cheaper of "fuel+oxidizer"... if the scoring had been fuel*oxidizer, it might've made more incentive to carry both... or even if the cost of payload fuel/oxidizer was subtracted from mission cost for purpose of scoring. I think the last one makes the most sense, as most of us only really care about the cost of the launching system, not the payload... as the payload just is what it is.

I love this mod. Great work, great update schedule, great direction. Awesome (and helps reduce the feeling of contracts all being the same). Thanks! Speaking of great update schedule... I just downloaded the .56 update like yesterday, noticed the inclination problem today, came in the forum to post and let you know... and it's already fixed?! Yah, that's awesome. Oh, and one more thing... I <3 the graphic representation for waypoints and required orbits.

My guess is low-flying asteroid. I put one in a low, nearly equatorial orbit once and it was very easy to see when it passed near the sun (as the face of the asteroid reflected the sun). That would also create the appearance of an elliptical shape.

I'd like to mention a couple things here. I use my main flaps for pitch control only, and use a smaller vertical tailfin to control yaw, and two small canards mounted near the front for pitch+roll. Edit: removed inaccurate info.

Assuming your center of lift, com, and structural integrity are good, (and especially if using "natural" gravity turns with aero mods like NEAR or FAR installed) it's probably thrust-related. When aerodynamics are working properly, essentially gravity pulls the nose down... but the effect is based upon the ratio between your vertical acceleration component and the acceleration due to gravity (obviously if you keep the nose straight up, it won't tip at all if it's aerodynamically stable). Basically, gravity pulls the same on every rocket... but the TWR of the rocket in question will describe its ability to fight back. I try to keep TWR around 2 during launch, but have had very successful launches with TWR as low as 1.5-1.6... if you go much lower than that, you'll need to wait until higher up before starting gravity turn (so as to build up more vertical velocity to compensate for the lack of thrust). This is a less efficient launch profile, and should be avoided. Clever staging can help manage TWR.

Has anyone been able to confirm that print throttle is broken? Also, is there any way to have the boot file open the terminal window automatically?

I really can't think of anything more helpful. You might try using raw control mode with a feedback loop to try to emulate human control. Just try to do it without kOS, pay attention to what you do with throttle, pitch, etc... then try to emulate that in a script. I use a script i call "datarecorder" to help with this, it logs all the relevant data (altitude, pitch, etc) at small time intervals. Unfortunately since print throttle doesn't produce output like it should, that doesn't help as much as it could.

The spooling makes this nearly impossible because controlling power output through pulse-width modulation is the easiest and most accurate method... however, spooling makes pulse-width modulation impossible (it relies on the existence of a well defined on/off threshold. The only way to get a jet to hover is by managing TWR to be close to 1. For a VTOL vehicle you don't need to hover really, just get the amount of thrust right for each vehicle. I use infernal robotics and create an osprey-like craft that tends to work pretty well if it's balanced properly.

I agree... bring on the quotes (but then again, I don't have a library of script I'd have to fix... of course, then again, if you've got a library of script to fix... you might write a script to fix it) Your problem is that you're trying to use an incorrect argument in the vang() function. It compares the angle of incidence between two vectors [vang(vector1,vector2)] but ship:velocity:surface:direction doesn't return a vector, it returns a euler direction in the form of r(yaw,pitch,roll). Simply swap ship:velocity:surface:direction for ship:velocity:surface:vector and that should fix it. As a side note, I believe (*though I could be mistaken*) that ship:velocity:surface is already stored as a vector, and can be used directly without the :vector structure tag.

I've been working with this for a bit and thought that we should have a page just to talk about kOS-related stuff. Right now it seems like you can't use for-loops to create a main program control loop that cycles through a list of installed subroutines. Even though it's a bit rough around the edges, I'm using this to get around that: boot file //boot file set ag9 to false. set halt to false. set ag8 to true. copy ctrl from 0. copy printtest from 0. //just testing to ensure that it works. set hasprinttest to true. run ctrl. main loop file //ctrl file delete boot from 1. until halt { wait .000001. //with such a short loop this keeps it from looking glitchy. print "main control loop running.". //testing purposes on ag9 { set halt to true. // action group 0 stops program. preserve. // later will add code to unlock steering/thrust to return control to user. } if ag8 //allow ag8 to toggle routines off and on. (can be used to put program to sleep temporarily) { if hasprinttest {run printtest.} //check if this subroutine is installed, if so then run it. } } print "Program ended!". Basically i'll flesh this out with all my short and simple subroutines, and then tack on a "management" subroutine at the end that will take care of any clean-up duties like reset variables that need to be reset, deleting unused programs to free up space, etc. I'm hoping to keep subroutines as short and simple as possible to give the software a sort-of multitasking capability.

apparently you can't do this. The for loop doesn't properly expand the variable before attempting to run the thing... so it's trying to run nothing each cycle. I tried to get around this by passing it to a sub-routine launcher script and then having that script launch the subroutines as declared variables... but that causes stack overflow error. Without the ability to build a solid control loop (without having to rewrite it every time i wanna change the program and taking up loads of unnecessary space) I'm not sure I can build anything useful.

Could you help me figure out why my control loop isn't working as planned? (from above-above post http://forum.kerbalspaceprogram.com/threads/68089-0-24-kOS-Scriptable-Autopilot-System-v0-13-1-2014-7-18?p=1355826&viewfull=1#post1355826)

I didn't mean solving for anything, I meant waiting until a certain altitude then attempt to keep the apoapsis in front of you but as close as possible with throttle management. Basically you wait until the apoapsis starts to move away (ETA:apoapsis will be getting larger) then you decrease throttle until it gets closer... so basically you hover around a certain value. I usually shoot for around 12 seconds (this is also the way some of the apollo missions performed certain burns in order to use fuel as efficiently as possible). edit: did you see the above edit about the control loop problem? as a side note, is there any forum dedicated to mod discussion/questions? if not... there should be (so we could use it instead of hijacking the mod's showcase thread) edit 2: nvm, i found the mod discussion thread... it just doesn't show up on the main forum index for whatever reason.

I used the method of ETA:apoapsis for awhile with apparently good results (and it is the easiest method of circularization as far as I can tell)... but it becomes difficult because the apoapsis will be closer at launch, then get further away... then get closer again. Still not sure what the mathematical relationship is. Edit: "print throttle." doesn't work for me. There's another problem I'm having, but it may be code-related. I'm trying to run a main control loop which runs through a list called subroutines. It uses "for routine in subroutines{ run routine. }" and is set up to loop until interrupted by action group. I want something that will let me re-configure on the fly by choosing what subroutines to run.

You didn't really include much detail about the program itself, but by what you've said... it seems extremely limited. I understand the difficulties associated with this type of calculation, but your post suggests that some things are optimal which are not optimal (by quite a wide margin in some cases). For example, you could use a lower angle than 45 degrees and less thrust on the second part (think 30 degrees and 2.5 g's), and just burn a little longer. Also, breaking this up into many more segments would increase its accuracy. I'm not trying to discourage you from doing further research, in fact I encourage it, I just want to also encourage you to be careful how you present things in this particular forum... as there may well be people looking for answers here that don't have the requisite knowledge to judge the efficacy of the method presented from an analytical standpoint.