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.

I have opened up a new issue called "Steering Discussion" on the github here. This discussion is related to some of the observations and "research" i have done on orientation/steering. Initially inspired to do so by the request of retrieving the current "roll" value of the ship's facing. Comments are as always appreciated regards, kaesekuchen

As Camacha said, you could always check for fuel left in the current stage or the entire ship. (ship:liquidfuel / stage:liquidfuel). Keep in mind though, that checking for liquidfuel = 0 won't account the case, where you have 0.01 liquidfuel but no oxidizer left (happend to me once or twice). If you have an accelerator sensor on your vessel, you should be able to use that as well. (ship:sensors:acc:mag).

Without Nodes it would be difficult. With the help of nodes you could do something like this : if ship:obt:body:name = "Kerbin" { set target to body("mun"). set n to node(time:seconds+300,0,0,0). add n. until n:orbit:apoapsis >= target:orbit:apoapsis { set n:prograde to n:prograde+( target:orbit:apoapsis - n:orbit:apoapsis ) / 100000. } set encounterCondition to false. until encounterCondition { until encounter != "None" { set n:ETA to n:ETA+1. } until encounter == "None" OR encounterCondition { set encounterCondition to encounter:periapsis <= 100000. set n:ETA to n:ETA+10. } This would create a "dummy" node 300seconds from now, altering the orbit altitude to match the mun's orbit altitude and then "seek" for an encounter. Although very crude and inefficient, this worked in easily getting to the mun from kerbin. I hope that soon i'll find the time to continue writing scripts that actually leave LKO

The sensor suffix has been renamed to "sensors". So instead of "print ship:sensor:acc:mag" you have to use "print ship:sensors:acc:mag"

The "roll" component of print ship:facing will always return 0 because the ToString() returns this: "R(" + Math.Round(euler.x, 3) + "," + Math.Round(euler.y, 3) + "," + Math.Round(euler.z, 3) + ")"; You can test this yourself with this little debug kOS script: print "debug : ship:facing:roll range". set minRoll to 9999. set maxRoll to -9999. set rollSteer to 0. set sas to false. lock steering to r(0,0,0). wait 1. until rollSteer > 360 { lock steering to r(0,0,rollSteer). wait 0.5. set minRoll to min(minRoll,ship:facing:roll). set maxRoll to max(maxRoll,ship:facing:roll). set rollSteer to rollSteer+15. } print minRoll. print maxroll. This script should return 2 very small numbers that are > 0 or < 0. We probably have to look into this, to achieve that the roll component of the ship:facing direction will actually contain usable data for "lock steering to..." commands.

A big thanks to erendrake for his quick response to enhancement requests and the overall work on 0.11 I have finished up the script sources i made while playing with 0.10 and will now switch to the 0.11 rc. I'll hopefully be able to provide constructive feedback regarding the new 0.11 features during the next couple of days. keep up the good work regards, kaesekuchen

Hi, point taken, regarding the dynamic keyword. Guess it's better to have the "chain of failure" to start when the plugin won't compile than it happening during runtime When i asked about making those values available via GetSuffix, i was under the impression, that otherwise it wouldn't be possible to achieve things like rendevouz with other vessels in space. But i proved myself wrong, since i just finished a script that just takes a vessel object as parameter on the launchpad and puts the launching ship about 15meter from the target vessel with a relative Velocity of 0m/s. There is a lot of warping and semi-efficient guesswork involved, but it works But still, having information like ETA to apoapsis of any targetable vessel available would be a nice feature. On the aspect of actually docking via kOS, we probably need the functionality to have docking ports as targets and the ability to set the "Control From Here" option via script. Though, i haven't looked closer at the API what extensions would be necessary to achieve that functionality. At the current state, it's a lot of fun and outside the box thinking, to see what one can achieve with the given functionality regards kaesekuchen

from the top of my head: default situations, for example: 1) customizable orbits a) periapsis at X and apoapsis at Y. inclination at Z. c) periapsis/apoapsis at specific lon/lat d) fuel efficiency requirements ... 2) rendevouz a) achieving an intersect with a specific target. matching inclination at specific intersect c) maintaining specified relative velocity to the target for a certain period of time/proximity to the intersect d) docking 3) geosynchronous orbits a) reaching an exact geosync. orbit constant alignment with a specified ground station c) reaching an imperfect geosync. orbit and having automated correction burns to maintain the direct line of sight to the ground station during X orbits. (difficulty varies for example in minimum distance to geosync. orbit requested) more experimental situation, for example look at what SpaceX is doing, which comes close to your scenario regarding docking with a ground vehicle. a) launching, reaching specified alititude hover at said altitude c) land exactly on the launchpad or another specified location close to the launchpad to expand on this: d) launching, docking with ground vehicle close to launch site, ground vehicle driving back to the launch site and repeating the process. depending on difficulty minium repeat cycles requested and/or fuel limitations. guess the sky is (not) the limit, when it comes to thinking up scenarios for this purpose

Thanks for the reply, After posting my initial question, i realized as well that without changing/extending the language constructs, this would probably not be a simple addition. I've got another question regarding this part of the code: BindingsFlightStats.cs manager.AddGetter("ETA:APOAPSIS", cpu => cpu.Vessel.orbit.timeToAp); manager.AddGetter("ETA:PERIAPSIS", cpu => cpu.Vessel.orbit.timeToPe); Is there a reason, that the orbit.timeToAp variables are bound in the BindingsFlightStats.cs and not directly in the Orbit.cs ? when looking at the Orbit.cs GetSuffix function case "APOAPSIS": return orbitRef.ApA; case "PERIAPSIS": return orbitRef.PeA; case "BODY": return orbitRef.referenceBody.name; case "PERIOD": return orbitRef.period; It seems that the period gets returned from the orbitReference, couldn't we have an addition here to get: case "ETAAPOAPSIS": return orbitRef.timeToAp; case "ETAPERIAPSIS": return orbitRef.timeToPe; Maybe i've overlooked something, but since orbitRef.period is a simple double value returned, i don't see why this shouldn't be an simple addition to the GetSuffix function of Orbit.cs. This would make these ETA values accessible in every targetVessel without it needing to be the active ship. Before i add this to the github issues filed under enhancement requests, i wanted to check with you here first. Thanks for looking at it regards, kaesekuchen PS: I'm not too firm in c# myself, but isn't there a way to access a field of an object by "string" ? For example something like this: dynamic d = new { value1 = "some", value2 = "random", value3 = "value" }; d.GetType().GetProperty("value2").GetValue(d, null); (taken from here) This way, we could have every field accessible in the object, without having to add it specifically to the GetSuffix function. This would lower code readability to an extent, but would shorten the required amount of code lines without having to add a GetSuffix case for every single field in an object.

this is very far from perfect, but for throttle control during launch i use this "subroutine": calculateTWR.txt declare parameter desiredtwr. set g to 9.81. set t to ship:maxthrust. set w to ship:mass. set twr to t / (w * g ). //print "twr = " +twr. set thrustLevel to desiredtwr / twr. which currently gets called from here launch.txt declare parameter desiredAltitude,desiredtwr,desiredGravStart,desiredGravEnd,desiredAngle,interval. declare thrustLevel. declare desiredHeading. until ship:apoapsis > desiredAltitude { if stage:liquidfuel = 0 { stage. } run calculateTWR(desiredtwr). run calculateHeading(desiredGravStart,desiredGravEnd,desiredAngle). lock throttle to thrustLevel. lock steering to desiredHeading. if interval > 0 { wait interval. } for completness: calculateHeading.txt declare parameter dStart,dEnd,dAngle. if ship:altitude < dStart { set desiredHeading to Heading(90,90). } if ship:altitude > dStart AND ship:altitude < dEnd { set currentAltitude to ship:altitude. set currentAltitude to currentAltitude - dStart. set maximalAltitude to dEnd - dStart. set currentAngle to (currentAltitude / maximalAltitude) * dAngle. set desiredHeading to Heading(90 - currentAngle,90). } if ship:altitude > dEnd { set desiredHeading to Heading(90 - dAngle,90). } As i said far from perfect since results are very dependent on the 5 parameters you put in, but for my test launches it resulted in a very smooth throttle control. for example: switch to archive. //sets up a launch for an initial apoapsis above 100km, throttle control to always be at 1.5 TWR, grav turn starts at 7.5km and ends at 60km with a horizontal heading. recalculates course every ~2 seconds. launch(100000,1.5,7500,60000,90,2). hope this helps a bit