arkie87

Not sure if i understood you... it seems like you are suggest the contract shows you the flightplan via maneuver nodes on screen i.e. the contract tells you how to get there/complete it?

So maybe thats my problem; i just never mess up Or maybe i'm just too liberal with the revert button...

I'm a bit surprised that more people dont want more imaginative/varied/realistic rescue missions. There are many possible improvements/variations to this one type of mission: (1) other planets/moons other than Kerbin; or orbiting kerbol (2) in orbit/on surface of planet/moon (3) in a EVA suit or a vehicle; vehicle is/isnt required to bring back to Kerbin via docking (gives a reason to learn how to make a targeted landing and/or perform a docking in orbit) To make the game more realistic, kerbals will never be stranded in EVA suite; they will always be in a vehicle with 0 deltaV/power such that they cannot be controlled and player must approach/dock with it. What do you you guys think?

Dont you mean higher i.e. they dont start working until initial airspeed is higher than it is now since now they work at 0 m/s?

I dont know if i agree with implementing KAC to stock with all of its features. I do think some sort of alarm clock will be necessary if the game is intended to be Kerbal space Program rather than Kerbal Space Simulator... though i also think the "program" part of KSP implies some sort of autopilot so that you can focus on sending and building/designing craft rather than flying them (once you've gotten the flying thing down pat) I also think that by default, the game should not let you time warp past a maneuver node... i dont know why that hasnt been implemented already

The way Unity physics engine works is by applying forces to individual parts, the equations of motion integrated with time which causes acceleration parts to displace and "pull" other parts along with them. I think increasing spring constants under time-acceleration should fix displacement problem. Alternatively, using implicit integration, rather than explicit, would fix the problem as well (though I dont think Unity can do this....) That said, I like your Time Control mod I used it to slow down time so i could crash into Kerbin at 150 km/s and see what happens

Why wouldn't/how couldnt SOI changes be calculated as you described (switch reference body and calculate resulting velocity by subtracting velocity vector from velocity vector between new and old reference bodies)? Anything else would violate conservation of energy i.e. give you free deltaV?

The same problem might happen if payload has landing gear or landing struts. Auto-action groups, like landing gear, can be edited in the action group window to exclude specific items, but the idea is default, a special action group should exist for solar panels. I agree with OP.

I dont really think you understand his suggestion. His suggestion will not increase physics load -- the number of calculations per second will remain the same. The only difference is normalizing by the time step such that forces/stresses are not multiplied by by time acceleration factor... (unless you are implying that adding one division will significant increase the load on a cpu, even if its operating at 60 calculations per second...) That said, i suggested this a while ago, but the way Unity physics engine works, merely dividing by the timestep is not possible/wont help because forces are applied where they are generated: for instance, if you have a spaceplane with engines located on the wing tips, unity applies forces on the engines, which then move forward after one timestep. The displacement creates a force on the wings (i assume a linear spring constant) and drag the wings and fuselage along with it. Thus, 4x acceleration will result in 4x displacement. However, one possible fix is to multiply everything else i.e. spring constants and stress/impact tolerances etc... by time acceleration factor so that displacement and stresses will not be affected. Also, ive noticed that intake air calculations increase by 4x under 4x time acceleration, which isnt correct...

Shouldnt the ultimate goal be to leave the Kerbol system (assuming the game doesnt go interstellar)?

I like #1 (though i'm pretty sure you can do this with PreciseNode, but i would favor a more integrated functionality to the current GUI). If you could specify ejection angle, deltaV, and number of orbits into the future, and the results displayed on the map view (as is done with a normal maneuver node), then this would be sufficient for finding transfer windows (though it would require you to already be in orbit, which restricts time acceleration and/or requires you to switch crafts to increase time warp factor). Perhaps, in the regular maneuver node GUI, there could be a button to toggle specification criteria i.e. from prograde-normal-radial to magnitude and angles. a button to tell maneuver node to predict what happens if maneuver is executed on the next orbit would be useful (though for window planning you might have to press "+1" 100's of times).

Very similar (basically the same) to the first idea i suggested in this thread: http://forum.kerbalspaceprogram.com/threads/99944-Best-Way-to-Integrate-Transfer-Windows-into-Existing-KSP-GUI-Environment The main complaint people have is that it makes it too easy, wont let people figure it out on their own, or only points out one kind of transfer. My second suggestion makes finding transfer windows easier for the player to do on his/her own. What do you think, OP?

With the current maneuver node system, you can draw one maneuver to just barely escape kerbin SOI, so as to minimize eccentricity (though an eccentricity will always be present); and then draw another one to find rough transfer window. But as mentioned before, this transfer window is less than optimal, since the plotted orbit always has an eccentricity. My suggestion allows to make just one maneuver node (thereby eliminating the need to finely tune a maneuver node to "just barely" escape kerbin SOI) using the actual orbit of Kerbin (no eccentricity), and will allow you to make this maneuver node from the launchpad, so you can time warp at 100,000x on the ground without having to switch to the space center/tracking station or another craft/satellite in a location that allows 100,000x time warp...

I agree with you. But i think one option is to improve maneuver node system to make it possible for players to find transfer window on their own, such as suggestion two posted here: http://forum.kerbalspaceprogram.com/threads/99944-Best-Way-to-Integrate-Transfer-Windows-into-Existing-KSP-GUI-Environment

Sure. That's a better idea, and it "integrates" into KSP theme perfectly.

Yes, you did. I think i quoted you and thanked you for giving me an idea of how to improve/integrate your idea to eliminate the need for a toggle button

This form is to compile suggestions i've come up with for integrating transfer windows into KSP GUI/Environment. I am a fan of intelligently integrating features into the current KSP GUI/Environment. The best example of a plugin that integrates perfectly into KSP GUI environment is a mod called "landing height." When landing, you obviously are more concerned with height above ground than height above sea level. However, in stock KSP, altimeter always shows height above sea level (in IVA mode, altimeter shows height above surface, but this view is less helpful when landing). You could use Kerbal Engineer (or numerous other plugins), which would display height above ground (in addition to height above sea level); however, a better approach to integrate better into the game is that when navball is in "surface mode" altitude displayed on altimeter is height above ground, whereas when navball is in "orbital" mode, altitude is above sea level, and the "landing height" plugin does this exactly ( http://forum.kerbalspaceprogram.com/threads/76320 ). So in keeping with the theme of "intelligently integrating features into KSP GUI/Environment, I have two suggestions for integrating transfer windows: For players who just want to be told the information (possibly enabled/disabled via difficulty settings): The transfer window should be shown in map view as a (purple?) dotted line. This functionality should be activated only when an applicable object is targeted using KSP targeting feature. Only showing one transfer window prevents clutter in map view and integrates nicely into existing KSP functionality. For players who prefer to have the tools needed to easily find the transfer window on their own: An automatic toggle in map view to switch the reference body used to draw the orbital trajectory should be created. For instance, if you are orbiting Kerbin, it shows you trajectory around Kerbin (and you can click on it to add maneuver nodes). When you zoom out far enough such that this trajectory is no longer visible, it automatically toggles to show your trajectory around Kerbol instead, and you can click on this trajectory and add maneuver nodes. You can then use maneuver nodes showing trajectory around Kerbol to find optimum transfer window on your own, since you can slide maneuver node along the orbit around kerbol. Note: I am aware that when displaying trajectory around Kerbol whilst orbiting Kerbin, the trajectory would technically be helical; however, for the purposes of the drawing and simplicity, it can just take the trajectory of the body it is orbiting i.e. Kerbin. Thought? Additional/Better Suggestions?

Yes, I am aware of KAC, but, like most people who post about things that already exist in mod form, I am a fan of using minimum amount of mods and/or intelligently integrating mods into KSP environment such that they dont feel like mods and/or clutter the game. The best example of a mod/plugin that integrates perfectly into KSP GUI environment is a mod called "landing height." When landing, you obviously are more concerned with height above ground than height above sea level. However, in stock KSP, altimeter always shows height above sea level (in IVA mode, altimeter shows height above surface, but this view is less helpful when landing). You could use Kerbal Engineer, which would display height above ground (in addition to height above sea level); however, a better approach to integrate better into the game is that when navball is in "surface mode" altitude displayed on altimeter is height above ground whereas when navball is in "orbital" mode, altitude is above sea level, and the "landing height" plugin does this exactly ( http://forum.kerbalspaceprogram.com/threads/76320 ). That said, I think integrating transfer window visually into the map view when a body is "targeted" integrates nicely into KSP GUI environment. Alternatively, an automatic toggle in map view to switch the reference body used to draw the orbital trajectory i.e. if you are orbiting Kerbin, it shows you trajectory around Kerbin (and you can click on it to add maneuver nodes). When you zoom out far enough such that this trajectory is no longer visible, it automatically toggles to show your trajectory around Kerbol instead, and you can click on this trajectory and add maneuver nodes. EDIT: I am aware that when displaying trajectory around Kerbol whilst orbiting Kerbin, the trajectory would technically be helical; however, for the purposes of the drawing and simplicity, it can just take the trajectory of the body it is orbiting i.e. Kerbin.

So you gave me an idea: instead of spamming all transfer windows in map view or making it toggle-able... why not integrate it into current KSP system: when you target a planet, it shows you the optimum transfer window on the map in map view.... This can probably be programmed into the game right now via a plugin --- is there a plugin that does this?

I think we all agree something is needed in game. But i always prefer tools to figure it out (easily) over being given the answer. Perhaps a simple GUI to draw tangent lines for the "munrise" technique would be accurate enough...

Putting a satallite into orbit ahead of Kerbin should work, but you have to remember to adjust orbit to remove eccentricity (requiring more dV), otherwise, it will rapidly become out of sync with Kerbin. Obviously i think we would all prefer if we didnt have to do that but could use some tool to find transfer windows (rather than than a tool that gives you transfer windows) without having to switch between crafts... EDIT: perhaps a contract to make the player do this would be useful?

Yes, we established this multiple times in the past 6 pages (sorry if i appear frustrated). Makes sense to refuel before departing Kerbin's SOI, as you could save about 3.3 km/s. Good idea! - - - Updated - - - Makes sense on both counts.

Is it more efficient to put the refueling base around minimus? I suppose it depends whether your goal is to refuel rockets leaving kerbin or returning to kerbin?

My rationalization/proof is as follows: (1): dKE(North-pole-->Jool) >= dKE(Kerbol-->Jool) (2): dKE(North-pole-->Kerbol,Kerbol-->Jool) = dKE(North-Pole-->Kerbol) + dKE(Kerbol-->Jool) Thus substituting (2) into (1): Wasted dV = dKE(North-pole-->Kerbol,Kerbol-->Jool) - dKE(North-pole-->Jool) <= dKE(North-Pole-->Kerbol)

That's what i thought and have been trying to clarify this entire time. I think the upper limit on the wasted energy/dV for the two burn rather than direct transfer is the amount of energy wasted transferring from north pole to Kerbol...