marianoapp

I made a missile a while ago with 0.625 parts and FAR installed but used kOS to guide it

@the_bT - Running a program with parameters in another core is not yet supported, but I have it in my TODO list. - There's another feature in the works to add multi threading to the cores, so you can have several programs running at once on the same core (although I haven't work on that for a while). - Using variables as file/volume names is not yet supported but it will be eventually.

It's written in .NET so it should work in linux, although I haven't try it.

@Dr_Goddard: Please post the problem you're having in the kOS thread so we can take a look at it.

MechJeb used to have a way to select a landing point just by clicking the planet while in map view, and I think that it also showed the coordinates of the selected point.

Use "list engines to engineList" and then a FOR loop to iterate over the list. Each item of the list is one engine with the properties you need. Lists wiki

@people with errors - If you're using ModuleManager then try deleting the config file from the kOS folder. - If the problem persist then take the "output_log.txt" file (it's inside KSP_Data), upload it somewhere and post the link.

@MrOnak: I used the Skillful plugin (just the dll) that automatically expand the loading range of the vessels, that way you can switch between the plane and the launcher and have scripts running in different vessels at the same time.

Nice! (although I kept waiting for the SAM to appear behind a hill and blow the plane to pieces )

@MrOnak: Nice to see my missile inspired someone There's no simple way to convert a direction to heading and elevation, but can be done with some vector math: // this only change when you move on the surface set targetVector to targetVessel:direction:vector:normalized. set upVector to ship:up:vector:normalized. set shipFacing to ship:facing. set sinYawF to sin(shipFacing:yaw). set cosYawF to cos(shipFacing:yaw). set sinPitchF to sin(shipFacing:pitch). set cosPitchF to cos(shipFacing:pitch). set facingVector to V(sinYawF*cosPitchF, -sinPitchF, cosYawF*cosPitchF). set diffVector to facingVector - targetVector. // this returns a value where 0 is the horizon and 1 is looking directly up // can be multiplied by 90 to get degrees from the horizon set diffUp to vdot(diffVector, upVector) @Entropius: ModuleManager support is broken, but we accidentally left the patch in the download. We're working to fix it.

All the directions when on the surface/low altitude use a frame of reference that can be considered to be at the center of the planet, and the components of it are rotations around the axes. We know that that is completely unintuitive so we're working in adding some features to convert between the different reference frames.

Simple hover script with a PID controller clearscreen. set newThrottle to 0. lock throttle to newThrottle. set targetSpeed to 0. set speedStep to 0.5. on ag1 { set targetSpeed to targetSpeed - speedStep. preserve. } on ag2 { set targetSpeed to 0. preserve. } on ag3 { set targetSpeed to targetSpeed + speedStep. preserve. } // controller coefficients set kpT to 0.1. set kiT to 0.02. // controller accumulated error set errSumT to 0. until false { // speed error set deltams to targetSpeed - ship:verticalspeed. // predicted throttle for a TWR of 1 set predictedThrottle to ((ship:mass*9.82) / ship:maxthrust). // ----------------------------------------------- // PID (PI actually) controller code set tempThrottle to predictedThrottle + (kpT * deltams) + (kiT * errSumT). set errSumT to errSumT + deltams. // ----------------------------------------------- set newThrottle to tempThrottle. print targetSpeed + " " at (0, 0). wait 0.1. }. Uses action groups 1, 2 and 3 to decrease, set to zero and increase the speed, respectively.

You should make a fork of the github repo, commit your changes there and then create a pull request (how to create a pull request). BTW I like this change

"out of sync" is the Mono error for when a collection is modified while being iterated, so it's probably some kind of race condition. We would need the log files to track this problem down, so the next time it happens to someone, please, send them over

I wouldn't add it to the docs just yet, it still is very experimental and has its limitations (like not being able to pass parameters).

Actually the only thing that changed was the FACING suffix but the steering code was not modified. I'll add a ticket for that.

The program that ended is the one in the launcher, the missile is running a different program in its own core. The program in the missile is started by the launcher using the (still undocumented) "RUN ... ON ..." command that let you start a program in a different core. These are some of the links I used while developing this: Intro, Advanced, Way too advanced (and math heavy) Anyway most of real life complexities arise from errors in the measurements and in a bunch of others things that have to be compensated, and that we don't have to worry about .

Something I've been working lately, because developing kOS is fun but using it is even more fun!

Mmm that should work, I'll have to check it out. In the mean time you can use set target to "mun".

@baloan: I understand the advantages, but if you want to program in python and talk directly to kRPC then there's no need to use kOS. Our mod being more tightly integrated with KSP fills a different niche. kOS is a computer that is IN the ship, you pause the game and the computer pauses too, if you loose power the computer shuts down. With kRPC you loose that, but as I said before is just a matter of preference.

Not yet...

@Steven: Ah ok, now I understand what you mean. We could of course keep adding stuff to make our CIL more expressive/flexible as need arise. @airbus: kOS actually compiles the code under hood, from the user perspective there's no difference with an interpreted language.

@Steven: There are no stack manipulation instructions because the compiled code is a stack based CIL and not assembler, and therefore there's no need for them (the .NET CIL don't have stack manipulation instructions either). @baloan: Most of the language bugs are because we rewrote most of the kOS code and it was bound to have this kind of problems in the first release. In fact the change was so big that we considered changing the name of the project to something else but finally agree to leave it the same. The main difference between kOS and kRPC is that ours is a virtual machine that exists entirely inside KSP, and as such is more tightly integrated with the game and subject to its rules (e.g. if you revert to launch in kOS the execution is stopped and the variables erased, but I don't know how kRPC handles this kind of thing). Anyway it could be possible to integrate kOS and kRPC so our virtual machine sends instructions to it instead of interfacing with KSP itself, but it would be necessary to evaluate the pros and cons of doing that. After the rewrite kOS became pretty language agnostic so it shouldn't be difficult to write a compiler for another language if we ever choose to do it (I think it took me about two weeks to write the current one).

All the config options can be modified from the kOS console itself, just use "set config:[option] to [true|false]". Use "list config" to view all the available config options and their current value. Actually that's what the compiled code cache does (without the saving to a file part), so it wouldn't be difficult at all to implement this.

Also SAS needs to be off for LOCK STEERING to work.