kaesekuchen

Sadly, there is no KOS specific "shopping" list on what you need to get the dll compiling. However, in general for KSP plugins, you need to link against some dlls in the KSP_Data/Managed folder: UnityEngine.dll Assembly-CSharp.dll This usually does the trick and enables you to build the dll. If you could give a bit more details on your current state, errors and so on, it might enable us to give more specific advice to get it running.

You could do something like this: set g to 9.81. set t to ship:maxthrust. if t = 0 { set t to 0.001. } set w to ship:mass. if w = 0 { set w to 0.001. } set twr to t / (w * g ). set velocityDifferenceToTerminalVelocity to ship:termvelocity - ship:velocity:surface:mag. set accelerationPerSecond to twr * g. if velocityDifferenceToTerminalVelocity <= 0 { set velocityDifferenceToTerminalVelocity to 0. } set thrustLevel to velocityDifferenceToTerminalVelocity / (accelerationPerSecond *0.25 ). Not the best way to achieve it, but this keeps you roughly below terminal velocity. If you want a different velocity, you have to swap out ship:termvelocity for your desired velocity. And of course you have to lock the throttle to thrustLevel Hope this helps

You could go with Unity's Monodevelop or SharpDevelop as far as "free" C# IDEs are concerned. I haven't checked how exactly to use postbuild commands with these, but i'm certain that it's possible similar to Visual Studio. If you like, i could check that out later and post some examples of basic "autoload" implementations for KSP (It's very helpful to instantly load the last quicksave on KSP launch, without having to navigate through the menu every time)

I'm probably just pointing something out that already occured to you, but in the longer run you probably save time and effort if you take the time to setup a dev environment. Hunting said errors you are already knee deep in that terrain. With a properly set-up IDE and debug version of KSP you can utilize "autoload" to reduce loadtimes/overhead between iterations and you can use the KSP.IO functionality to create tailor-made debug messages. If for any reason whatsoever it's not an option for you to install a visual studio express or similar, just disregard this post.

I believe it's ship:obt:semimajoraxis , if i recall it correctly

Thanks to erendrake and marianoapp for the parser overhaul! After a "preliminary review" i have to say, that i like the changes. The threaded execution of scripts is a nice feature, so is the change to ship:facing actually returning useable values for all 3 axes of the vessel. Hopefully i'll have some time later on to give it a more indepth spin. Good work.

The problem with circularizing your orbit is, that in an ideal circular orbit periapsis and apoapsis would be interchangeable. So if your intention is to write a program, that is very flexible and efficient you have to take a look at quite a few cases. 1) your periapsis needs to be higher a) will the new periapsis be higher than the current apoapsis ? - burn at current apoapsis, until apoapsis is higher than desired altitude for periapsis will the new periapsis be smaller than the current apoapsis? - burn at current apoapsis, until periapsis is higher than desired altitude for periapsis 2) your apoapsis needs to be higher - burn at current periapsis, until apoapsis is higher than desired alt. for apoapsis 3) your periapsis needs to be smaller - burn at current apoapsis, until periapsis is smaller than desired alt. for periapsis 4) your apoapsis needs to be smaller a) will the new apoapsis be higher than the current periapsis? - burn at periapsis, until apoapsis is smaller than desired alt. for apoapsis will the new apoapsis be smaller than the current periapsis? - burn at periapsis, until periapsis is smaller than desired alt. for apoapsis These are the 4 cases you have to take into consideration. It's usually easier to implement it with a certain threshold, saying you want to circularize at 100km, you should first execute the burns, until your periapsis is between 99.5km and 100km and your apoapsis is between 100km and 100.5km. I hope this pseudocode helps, otherwise i can cleanup the circularizing script i wrote and post that.

The issue at hand is, that (usually) the roll of your ship does not affect your burn. So it wouldn't matter if we are "upside down" or 90 degree rolled to the right, as long as we point to our destination. What izandral is looking for (unless of course i'm mistaken) is a way to change your orientation while maintaining your current roll orientation and therefore avoiding any unnecessary change on your ship's roll axis.

I'm afraid that this is a bit trickier. With the current state of kOS i haven't got this working unless you go the distance and do your own vector calculations from the getgo and use that system instead of the "premade" vectors kOS supplies for landmark (retrograde, prograde etc.) navigation. Steven Mading spent some time on this and wrote quite a few posts on this and i'll be so blunt to refer you to them for further reading. The main issue at this moment is, that we can't retrieve the current vessel's roll.Marianoapp stated, that once the big merge has been done, we will have a way to retrieve it.

I encountered this behaviour as well. It is due to the fact, that in the "FlightControlManager.cs" Update function, the lockable control of throttle, wheelthrottle, steering and wheelsteering get detached from the current vessel, but the new one doesnt get attached to the updated vessel. tl;dr : Without recompiling the kos.dll yourself, you can only circumvent this by reloading the scene (i.e. switch to another vessel and back to your vessel or quicksaving and quickloading)

That should be something like this: //target retrograde lock steering to target:velocity:orbit - ship:velocity:orbit. //target prograde lock steering to ship:velocity:orbit - target:velocity:orbit.

I've got a question related to the current state of the direct flight control and flight "orientation". Don't worry, i'm not asking "when the heck is it going to be released" I couldn't help myself and again played around with orientation,steering and so on. With the current implementation it is possible to directly command the vessel on the 3 rotation and 3 translation axes (Good job on this btw ) While testing around with this it occured to me, that we can apply these commands, but we are pretty much lost to reading out the actual results we achieve by this. Now, this might be something i missed, if so, disregard my inquiry. Let's look at this example: We want to align our vessel to a certain rotation, let's say the "target approach" indicator. With the automated steering we would simply "lock steering to direction", direction in this case being "(Target.GetWorldPos3D() - context.Vessel.GetWorldPos3D())". Now, if we would like to implement this with the direct steering controls, we need some orientation, since there are multiple ways of achieving the aforementioned direction. This brings me to my question: Do we have a way to readout our current difference on a certain axis towards the target direction? What i'm asking for, is something, that could be done on c# side like this: Quaternion q1; Quaternion q2; //our vessel's current rotation/orientation q1 = Target.transform.rotation; //our desired target rotation q2 = Quaternion.LookRotation((Target.GetWorldPos3D() - FlightGlobals.fetch.VesselTarget.GetVessel().GetWorldPos3D()) * -1) * Quaternion.Euler(90, 0, 0); float angleYawPitch = Vector3.Angle(q1 * Vector3.up, q2 * Vector3.up); float angleYaw = Vector3.Angle(Vector3.Exclude(Target.transform.forward, q1 * Vector3.up), Vector3.Exclude(Target.transform.forward, q2 * Vector3.up)); float anglePitch = Vector3.Angle(Vector3.Exclude(Target.transform.right, q1 * Vector3.up), Vector3.Exclude(Target.transform.right, q2 * Vector3.up)); float angleRoll = Vector3.Angle(Vector3.Exclude(Target.transform.up, q1 * Vector3.right), Vector3.Exclude(Target.transform.up, q2 * Vector3.right)); angleYawPitch is the angle between our current orientation and the target on the yaw and pitch axes combined, while the other 3 angles (angleYaw,anglePitch,angleRoll) give us the angle on the according single axis. So, to iterate on my question: at the current state, is it possible to achieve this in kOS? thanks for reading

Sounds like a good idea, you probably should open a feature request on the github's "issues" page for that. erendrake stated that kOS is currently in "feature stop" until the upcoming parser enhancements/rewrites will be implemented and merged, but if this is just a simple suffix made available via "ship:biome" your chances are good that he might sneak that in

I didn't mean to sound offensive, if i did, i apologize. My reply to this discussion was motivated by seeing it as an interesting thought, where to draw the line between "fun, gameplay enhancing feature" and simply "getting everything handed on a platter". But it is clear to me now, that your ideal scenario of kOS would be, that it just hands you generic tools and you have to assemble them into a working program The other day i was working with the kOS sources and scripts to create a program, that would analyze vessels in regard to multiple variables (thrust, isp, drag and so on) and i realized that i had to stop myself from putting too much logic in the c# sources, because it would have been possible to do this in kOS scripts as well.

Sorry to barge in on the conversation you two are having, but i felt the urge to comment myself on the "magic numbers" argument. In my oppinion, wheter or not it's considered cheating, would depend on the way you look at it (well, duh.) I think what this conversation is really about is, what is acceptable from a "roleplaying" point of view. For example, automated steering: You "tell" the ship, with a single command, to change the heading to a specific rotation and internally the "optimal path" to this rotation gets calculated and applied. Is this cheating in a broader sense? I think it's not, since you don't simply change the rotation in one step by telling the underlying engine to do so, but instead you use a multiude of commands on a higher level to achieve this rotation. Is this cheating in a "roleplaying" PoV ? Probably yes, unless you have a module on board, that adds a certain mass to your vessel, to account for the additional "hardware" your vessel requires to be able to achieve it. This basically comes down to balancing the tradeoffs one has to consider, when designing a vessel. Let's say you have a small probe, that just barely scratches the 1t mass. If you want the comfort of "automated steering", you have to add a module that masses 0.3t(arbitrary number) to it, which could make the vessel desing unfeasible. So instead of taking this module, you might consider using a "manual steering algorithm" to keep the mass low. So to sum it up, my oppinion is, that during the development process, "ethical" questions shouldn't be granted much merit. If there is a shortcut available, it should be made available. Later on, the gameplay tradeoffs can and should be considered. Be it via high cost, certain resource consumption, aerodynamical / design drawbacks or anything else that comes to mind.