woodywood245

Sample code for first script: // script print "Main script running.". lock steering to up + R(0,0,180). lock throttle to 1. stage. wait 5. // blah blah blah // here's where you run your other script. run otherscript. print "Back to main script.". Sample code of second script print "Other script running.". // whatever other stuff Sample output: > run script. Main script running. Other script running. Back to main script.

Sure, I think that's doable.

Exactly. I have two games running, one is my "real world" game, and the other is a "simulator" where I test and debug my kOS code. I also use the simulator game to test my mods so I don't accidentally mess something up. I've been writing a large, generalized, modular flight control system that will work for all of my rockets over the last few weeks, so I haven't even touched my "real world" game in a while. But I'm learning a lot about the kOS system. I want to write an interplanetary guidance system, but even though the equations are readily available on another thread, the lack of explanation for the variables doesn't help me understand what's going on.

The thing that bothers me is that in the KSP API, there's a interface called ITargetable that represents objects that are targetable. The classes CelestialBody and Vessel both inherit from ITargetable, and as a result, they each have an OrbitDriver object, with which you can calculate headings, bearings, positions, phase angles, etc. Simply having a heading or bearing is enough to do the rest. So in the API itself, there's a common system for targetable objects, but kOS doesn't take advantage of that. I'm not sure why.

Okay, I've got one: why am I unable to get the bearing or heading to a body target? Am I losing it, or is this another kOS quirk? set target to mun. print target:heading. Suffix "target" not found on object. print target:bearing. Suffix "target" not found on object.

I tend to agree with you. Even "basic values" such as mass and radius of a body are things I don't look up in the wiki because I have techniques of acquiring them in game, and kOS gives me the opportunity to retrieve the variable values with much greater accuracy than other methods. All I need are a few numbers (one of them from a sensor, which is why I wrote Sensor Reporter), and I can calculate approximate body mass, radius, volume, and surface gravity. I can usually get values with less than 5% error for the large numbers. The way I look at the KSP solar system is what's the point of exploring if you already know everything? I like exploring the system and learning the physics and applying the math. At heart, I'm an engineer and a scientist. I design meticulously based upon a set of requirements. Before I land on the Mun, I need to send an orbital probe to determine the surface gravity, which I can do from orbit with a little math. I take pictures of the surface and map out the different areas to determine a good location to set down. I can then create a set of requirements to build my spacecraft based upon what I learned the last time. That's one reason why I haven't gotten very far in exploring the solar system. I do it meticulously, and while I might be using "seat-of-your-pants technology," I'm not using seat-of-your-pants techniques. As far as LOCK STEERING TO goes, that only points me in one direction, and that's pretty useless to me during takeoff. I use it during other maneuvers, but during takeoff, I use the derivative of a function to determine what direction I need to be pointed, and then use that information to calculate a vector that I apply to the east and north directions, with a separate vector determining how much to apply in each direction. I can shave off an awful lot of delta-v that way. The current rocket I'm working with can get into orbit with around 3100 m/s deltav. However, one problem I constantly encounter is the "MechJeb wobble." I'm working on something for kOS that will hopefully eliminate that from my rockets, but you essentially have to build your own guidance system from scratch to even know what direction you're pointed.

kOS is not compatible with RemoteTech at the moment, unfortunately.

I'm not sure what the cause of this is, but some operations won't finish before the program ends. The bandaid I use is to tack on a "wait 1." at the end of the program.

I can't be sure, but I think a lot of the comparison problems stem from the fact that the "var" type is used far too often. Ever since var was introduced in C#, people have been going crazy with it. C# is generally a strongly-typed language, which can do some limited implicit casting (about as much as C/C++ can). The var keyword breaks that, and when you use it for things it wasn't intended for (var was designed for implicit type assignment from LINQ statements, where you may not always know the output type), it can really mess things up.

I've noticed the same problems. The zero-based line numbers don't bother me so much as get on my nerves. I guess it's a pet peeve. "Array indices start at zero, line numbers start at 1," is how my brain thinks of it. I've been using C# as my primary language for a few years now. I switched from VB after I had to use C/C++ and Java in my classes, and I got to the point where I was accidentally writing C-like code in my VB programs. I'd like to communicate with Kevin before I introduce any code into his code base, because I consider him the lead developer. Until then, I'll just keep adding stuff to my little mod, and taking things out when they appear in kOS. As far as the SOI of a body, the field sphereOfInfluence is in the CelestialBody class. To get the SOI of the body you're orbiting, you can look at vessel.mainBody.sphereOfInfluence.

During the 0.8x debacle, I seriously considered writing a competitor to kOS that was compatible with the kOS language, but had features that kOS lacked, had a simpler architecture with well-documented code, and actually worked. I have some experience writing scripting engines, so I figured it probably wouldn't be too terribly difficult as long as I could learn enough of the KSP API. I had even begun working on it, and got a good way in before 0.9 was released. Since the 0.9 release, I stopped working on it, but I am always ready to pick it up again when the mood strikes me because I documented almost everything I did. I love kOS, but there are times (especially when I'm looking at the source code), that the plugin makes me cringe. Examples: zero-based line numbers on error messages, lack of user-space exception handling, and the often-vague error messages that occur. And that's just a handful of things I would change. I momentarily thought about trying to fix the problems in kOS during the 0.8x thing, but the architecture is so complicated and full of anti-patterns that I'm not sure it's worth the effort.

There are a lot of things I've written that I'd love to see integrated directly into kOS (most of it being in the kOSExtensions portion of Sensor Reporter), and a few ideas I can't implement without changing the kOS source, but with Kevin away for a while, and final exams coming up, I haven't had an opportunity or urge to get in contact with him to see what we can do. Also, I've noticed that a lot of the code that gets written into the code base by people other than Kevin never see the light of day during release. Someone wrote the original Sensor Reporter code into the code base a while back (it wasn't me, and no one asked me), but it hasn't appeared in any releases.

It's taking me a little longer than originally planned to release this update because I have a few surprises in-store for you guys. I want to thoroughly test them before I release the update, though. However, I think you will like what I've done.

Coming Up in Sensor Reporter 1.5 - Bug fixes, including allowing you to add parts in any order without confusing Sensor Reporter regarding loading. - Compatibility with the Hot Beverage Inc. sensor mod. - A vessel!thrust() function, returning the current sum thrust output. Now the bad news: Until further notice, I HAVE NO PLANS TO MAKE Sensor Reporter compatible with Kethane. I have explored the possibility today, and there are too many technical problems and potential legal problems (the Kethane API is limited, and so is the license) to make it feasible at this time.

I'm always looking for new ideas for features, and I'm usually doing some kind of active development on this mod, so any suggestions are welcome. I'm currently working on the next version, which will include a couple bug fixes, and some new features. I will add this to the to-do list for that release.

No problem. I'm working on a 1.4.1 or 1.5 release (I'm not exactly sure how much I'm going to put into it yet) and I've coded a fix into Sensor Reporter that hopefully will make it so that it won't matter what order you place them in. I still have to test it though.

Ok, I think I figured out how this happens. In short, and without getting too technical, it has to do with the order that you put parts on. If you put kOS on first, then your sensors, everything is fine. If you do it in the opposite order (sensors, then kOS), your sensors will not be available in kOS. I might be able to create a workaround in Sensor Reporter, I'm not sure.

I'm pretty sure the problem is on the kOS end of things, and not on the Sensor Reporter end. The architecture of my mod is quite simple, but sometimes it has problems interfacing with kOS. I will dig into the kOS source and see if there's something wrong with the function registration code that is causing this problem. Unfortunately, the issue is intermittent, which makes it difficult to track down. Sometimes I've been able to fix it by reverting to launch, and sometimes by restarting KSP itself.

This kind of problem crops up occasionally for me, and I'm not entirely sure what the root cause is. But, to assist with figuring it out, what version of kOS are you using? Also, are you using the latest version of Sensor Reporter (v1.4)? And lastly, if you are, you can hit Alt+F2, and that will bring up the Debug Console. Sometime along the list after the vessel load, you should see a series of external function registrations. It will look like this: [LOG 17:14:57.845] stage manager starting... [LOG 17:14:57.845] all systems started [LOG 17:14:57.907] Adding math!pi [LOG 17:14:57.907] *** External Function Registration Succeeded [LOG 17:14:57.908] Adding math!log [LOG 17:14:57.908] *** External Function Registration Succeeded [LOG 17:14:57.908] Adding math!logbase [LOG 17:14:57.909] *** External Function Registration Succeeded [LOG 17:14:57.909] Adding math!ln [LOG 17:14:57.910] *** External Function Registration Succeeded [LOG 17:14:57.910] Adding math!e [LOG 17:14:57.911] *** External Function Registration Succeeded [LOG 17:14:57.911] Adding vessel!velocity [LOG 17:14:57.912] *** External Function Registration Succeeded [LOG 17:14:57.912] Adding vessel!gravconst [LOG 17:14:57.913] *** External Function Registration Succeeded [LOG 17:14:57.913] Adding vessel!isp [LOG 17:14:57.914] *** External Function Registration Succeeded Hopefully, somewhere in the log, it will say: [LOG 19:15:49.956] Adding sensor!grav [LOG 19:15:49.957] *** External Function Registration Succeeded [LOG 19:15:49.957] Adding sensor!grav!str [LOG 19:15:49.958] *** External Function Registration Succeeded [LOG 19:15:49.958] Adding sensor!grav!toggle [LOG 19:15:49.959] *** External Function Registration Succeeded [LOG 19:15:49.959] Adding sensor!grav!active [LOG 19:15:49.960] *** External Function Registration Succeeded If "Adding sensor!grav" does not show up, let me know. Alternately, you can send me the log (via email or something, you can PM me for that), and I can analyse it.

That is an excellent question. It says "sensor1grav()" instead of "sensor!grav()" on the output?

I believe it is the measured Isp. The number that comes out is the same as the one in the engine's context menu.

Sensor Reporter 1.4 is out! http://kerbalspaceprogram.com/sensor-reporter-kos/ As of version 1.4, kOS 0.7 is no longer being supported. All single-precision returning functions have been removed. Do not use sensor!____f() functions anymore; they won't work. On the upside, I've added four new math functions, and a new vessel function: math!log(number) - returns the base-10 logarithm of the given number. math!logb(number, base) - returns the logarithm of the given number of the given base. math!ln(number) - returns the natural logarithm of the given number. math!e() - returns the natural log base constant e. vessel!isp() - returns the sum of specific impulse of all active engines. Also, I've moved all non-sensor functions to a PartModule called kOSExtensions. These functions are available regardless of whether you have any sensors on the spacecraft. Sensor functions are still only available if you add the appropriate sensors.

Actually, calculating tilt is fairly simple with a little math. You can calculate the difference between two vectors using the geometric definition of dot product of vectors: A·B = |A||B|cosθ, where A and B are vectors and θ is the angle between them. Rewriting, the equation becomes (A·B)/|A||B|= cosθ. Solving for θ, you get θ = cos-1((A·B)/|A||B|). If a vector, V, is represented as V=<x,y,z>, then A and B can be represented as A=<x1,y1,z1> and B=<x2,y2,z2>. Therefore A·B = x1x2 + y1y2 + z1z2. Now, using the UP vector for A, and the FACING vector for B, we can translate this into: set a to up:vector. set b to facing:vector. set dotprod to (a:x * b:x) + (a:y * b:y) + (a:z * b:z). set tilt to arccos(dotprod / (a:mag * b:mag)). print tilt. Alternately, you can calculate the dot product by multiplying the two vectors together using the kOS component-wise multiplication, then adding the components together. set c to a * b. set dotprod to c:x + c:y + c:z. This runs under the assumption that pointing straight up is 0 degrees tilt, and pointing sideways is 90 degrees tilt. Tilt values over 90 degrees mean you're pointed towards the ground.

I would LOVE to be able to do those things, but unfortunately, I'm limited by kOS. In versions of Sensor Reporter prior to 1.3.2 (the kOS 0.9x compatibility release) all of the functions used colons, as it fit in with the kOS code well. However, the expression system for kOS was changed in version 0.9, and the colon became an operator for internal namespaces. As a result, kOS is unable to recognize that sensor:grav() is an external function (external functions are stored as strings). Instead, it looks for the namespace "sensor", and doesn't find it. Earlier versions didn't use this method, and so I was able to get away with using colons. // Using colons in kOS 0.8 and earlier. print sensor:grav(). > 9.80695477026689 // Using colons in kOS 0.9 print sensor:grav(). > Unrecognized term: 'sensor'. As far as the parentheses are concerned, all function calls require the use of parentheses. It's a convention of almost every programming language, and it's a technical requirement of kOS. Without the parentheses, kOS doesn't know that you're trying to make a function call, and thinks you're looking for a variable. print sensor!grav. > Unrecognized term: 'sensor!grav'. print sensor!grav(). > 9.80695477026689 One advantage of kOS is that the language is freeform, meaning that whitespace (usually) doesn't matter. As a result, if you're having too difficult a time working with complex formulas, you can try breaking them up onto separate lines. You may also consider using an editor that highlights matching braces as you type them in, such as Notepad++ (I use Notepad++ with a kOS syntax highlight definition I made). Lastly, you may want to enter sets of brackets together, then write their contents on the inside. Some programmers use that technique in C-like languages, where braces of all kinds are commonplace. For example, when I write an if-statement, I usually do this: if [condition] { } if [condition] { // now i write my code here } Maybe you could do a similar thing with parentheses? I don't know if I could (I'm accustomed to remembering how many I need and when), but maybe it's worth a shot. Another technique that I use when I can't tell for sure if all of my braces match is to count them on my fingers. I add a finger when I have an open brace, and remove one when I have a closing brace. If I get to the end of the statement or block and have zero braces, I know everything's closed. If I have an extra close brace, I know I'm missing an open, and if I have fingers up, I know I'm missing that many close braces.

Are you referring to the exclamation marks being used for namespaces? Or something else?