HoneyFox

Good ghost cursors. Now i won't be worried about where i should turn to when that direction is behind me anymore.

Well my second suggestion was originally for an idea that: I can write a small plugin to register and provide a vector which combines the RVEL- vector and the TGT+ vector (this TGT+ vector will be scaled to the distance, meanwhile it has a maximum magnitude of 500m/s). This combined vector will be extremely useful when we rendezvous with a target that is several kilo-meters away (such distance is a bit too far for RCS so liquid engines are used).

Will there be docking indicators as well when in target mode? especially when user has picked a docking port as the target. Plus it would be good to provide a public interface which accept a vector (and maybe other information needed like referenced transform, icon name, icon size, in what modes will it show, etc.) and then display that on the nav-ball.

Hardest thing in KSP? Debug to make a plugin work correctly in game I guess... You know we cannot attach our debugger onto the KSP process so ... yeah it all relies on debugging console output... Second hardest thing in KSP? I guess it's playing aimlessly while actually waiting for the next update of KSP to be published. Huh... maybe this is even harder than the one I mentioned above.

Yes, a GUI editor for editing bezier curves in game will be very useful for this. (Also will be useful for another plugin written by me: TweakableParam, in which I am currently using a very primitive GUI to edit FloatCurve in game, too primitive that even I hate to use that... )

I'm glad to inform you of the up-coming new version (TweakableParam v3). It will be published soon. I'm still preparing the packaging + pushing source code to my GitHub, etc. New features (Well, just one new feature I have to admit ) Add support to FloatCurve replacement. Now you can replace these float curves (e.g. engines' Isp curve, solar panels' power output curve, etc.) by clicking the Replace Curve button in the "Add Parameters" window. The curve editing is still primitive though, you can add key+value pairs, and you can clear all entries. Also, I've found out that the Sarbian's Module Manager Extension plugin works perfectly with my plugin. The coming package will bring you with a small config file which will add the ModuleTweakbleParam to all your parts*. After that the Infuser Tool is no longer needed. * Only when you have MME plugin installed. MME is not included in the v3 package. You can get that from the link above and install that .dll to KSP/GameData/ folder.

I've written a plugin sometime earlier to control boosters' thrust either by time or by percentage of fuel left. I guess it's having similar functions as you are trying to implement ... This mod is a user of my plugin and BTW it's using fuel percentage curve mode: http://forum.kerbalspaceprogram.com/showthread.php/49598-o-21-x-Space-Shuttle-Solid-Rocket-Booster-1-1-Replica And another author has also used the plugin to implement a VTOL autopilot system. (though it has been out-dated) Actually I wrote that plugin with the initial intention to support adjustable-maximum-thrust-in-editor-and-during-flight capability, which i think is useful for both solid boosters and for liquid engines... Think of Delta IV Heavy's core booster, it has less throttle during flight until the two side-mounted boosters are decoupled. Think of some overpowered solid boosters, we can adjust its thrust to make it a medium-thrust long-burn booster which can be handy in some cases. Just want to inform you. It would be good if you can integrate some functions from that. Codes available on GitHub... but, uh... I haven't uploaded the latest code changes yet. https://github.com/HoneyFox/EngineThrustController

Oh... you fixed that. o_o Great! INSTA DL!

It seems like the record ends when my rocket reach a certain altitude. So I cannot record the entire ascent path of the rocket. Any clue?

Excellent, now aerobatics will turn to ACMI. Plus we can record a rocket's ascent path and then follow it when we want to launch the same rocket again.

Looks good, better with more shading so that it feels more 3D. Got several hand-drawn rockets with my own... Wait till i get back home and submit and let you see also.

This solid booster can send up to around 40tons of payload with an SSTO design. PS: At least give a small credit to me for that variable thrust plugin, OK?

line.SetPosition(..., ScaledSpace.LocalToScaledSpace(FlightGlobals.ActiveVessel.orbit.getPositionAtUT(time))); some code snippet from one of my plugins using ScaledSpace, with the lineRenderer (its useWorldSpace is true BTW).

Like this and hope that it can be viewed in map view. For the line width issue, if you can find a way to get the camera distance, you can multiply that as a coefficient with a constant value for the line width so that when you zoom the camera farther, the line width will increase accordingly and the line will appear with an almost constant width on the screen. Well, at least I've done that in some of my plugins before, though in map view.

The author can design a PartModule that are automatically inserted into all parts by using Sarbian's Module Manager's Extensions. That way, it can allow users to specify some special flag bits (or no flag at all if you don't want to do anything with the part) for each part. And by designing some new interfaces like: Invoke ActionName of Part(flag bits). We can then invoke the specified actions of those parts that matches the flag bits. Example: we've decided to use the third bit of the flag as the flag for all solar panels on the vessel. we then need to set all solar panels' flag bits so that their third bit is 1. then we need to write some script like: Invoke "Expand Panels" of Part(4). // Here 4 = 100(binary) so the third bit is 1.

Reason simple, these electric charge changes in steps (i.e. if it changes from 20.01 to 19.99, this statement will not run because it never equals to 20.00). Also, it's never been wise to make equality or inequality check for floating point numbers due to its inaccuracy nature. You should always use something like: if ( a >= b - e and a <= b + e) where the e should not be smaller than the step of the value change. EDIT: I don't know if the statement above works in this script language, but you can do that by nesting two if statements, though that will make the code look tedious...

I mean the phase angle, which seems to be the biggest problem. If the entire procedures are splitted into two parts: 1) get into LKO, 2) execute the transfer maneuver. and if we players can decide when to start these scripts, everything will be a lot easier. For me it's not easy to evaluate how much time / angle do i need to get into LKO... And i don't know if anyone knows how, or it's just some rough estimation.

Oh that's gonna be very tricky...

I think it should be quite easy for the author to implement that. Actually i really hope that the author can consider implementing some sort of interfaces so that other guys can implement more additional commands they want. Time warp for example... But the script language is not so command-based so i guess it won't be that easy. So it's just my suggestion.

At least we can approach to mun by using some special type of orbit: a circular orbit a litter lower than Mun's orbit. Then wait until body changed to Mun. Then do the de-orbit burn and land... Well, at least it's theoretically possible.

Always wanting MOD of Long March series... and now it comes! And that reminds me of the day when i found there's MOD for LM in the game Orbiter, on which day i did the same thing as today: INSTA-DL!

Because you never know how the global(world) coordinate system is. So you need some reference axes, which the UP is providing.

Terrific. This is gonna be better and better!

Useful. Agreed. And it will be more useful if it works for other types of resources like Oxygen from some life support plugins, etc...

That actually is a real big game-crasher for me. In order to get clear view i have to set to full res. But then my KSP can no longer start again because it will take over 3.6G memory during its loading phase. I don't know why this plugin need to use textures for characters. Can't we just use a simple text area for that?