Dunbaratu

I don't have BDarmory so I can't really test this out myself. But in general I could maybe give you live help by video conference if you want to arrange a time sometime today within the next 7 hours or so. I should be home today during that time. (remember to tell me your timezone too if you want this). I much prefer google hangouts for this, but I might be able to do it by skype, although I haven't fired up skype in over a year. Give me a PM with contact details if you want to do this. The partmodules thing was my baby (although erendrake revamped the suffix infrastructure, allowing method suffixes (suffixes with arguments), which was needed for it to work .. anyway that's another topic for another time) The point is that I like the system a lot and it pains me to see it being so hard to get working for some people. I admit that it's messy and confusing. Partly that's because the underlying implementation of things in KSP itself is a bit messy and it was hard to abstract all the mess away without introducing cases where the abstraction breaks, so I had to expose *some* of the messiness to kerboscript.

Not a bug. The problem is that the base game (and mechjeb) use the term "surface speed" to mean a 3D speed in a way that in no way is an actual surface speed. It's the speed in a reference frame that subtracts the rotation of the planet below you from your orbital speed, but is still a speed in 3D space, not a speed along the surface. In other words, it counts your vertical motion into the speed too, which isn't *really* a surface speed. It's just a poor choice of words in the main game that mechjeb inherited and kept using. I'd have called it planetary versus orbital or something like that. Anyway, if you actually do want the game's version of surface-reference-frame speed, then do this: print ship:velocity:surface:mag. Surfacespeed is the 2D projection of that, down into the horizontal plane.

The power drain code is very old code dating back to before we took things over, so it may just be a mistake that's always been in there. In general I've never been entirely happy with using Update() to run the CPU instructions in the first place, since that means that the same CONFIG:IPU setting means different things on different people's computers. I'm just a little afraid to move that code into FixedUpdate for fear of what might break. At any rate, I've made an issue for it on the github here: https://github.com/KSP-KOS/KOS/issues/526

Whoa seriously??? I didn't even realize that was possible. Basically that would have to mean that KSP still calls the Update()'s even when the game is paused, AND that it's acting as if time has passed even when paused. The mod calculates how much electricity was used each update by looking at how much time has passed in the physical world since the last update, using KSP's own reported value for it: Timewarp.fixedDeltaTime. But if that is passing even when paused, something weird is happening.

Are there Unity ports to consoles like PS4? They might try to get more money by doing a KSP port. Granted the game would have to be stripped down a little bit given the current state of consoles (that divert most of the selling price into paying for high end graphics cards and sound, at the expense of RAM and CPU speed.) RAM is probably the biggest limiting factor to getting KSP onto a console, but who knows what the next gen consoles will be like. It might be doable later. I'm thinking of something akin to the Minecraft XBOX 360 version. To make it fit in the memory limitations they did have to strip out a few things so Minecraft on console isn't as good as Minecraft on PC, but it still was a success anyway, sales wise, as there were enough people out there willing to play it on console even if it wasn't as good.

Well, you claim that "No maneuver nodes present!" is a message your own program put out, but if that's true then it's an incredibly unfortunate coincidence that you chose that exact phrasing because that happens to ALSO be the the exact phrasing used by the kOS code itself, here: if (vessel.patchedConicSolver.maneuverNodes.Count == 0) { throw new Exception("No maneuver nodes present!"); } So the complaint coming from kOS is the very condition you yourself also detected. You can't say nextNode:ETA when there isn't a nextNode. So when you see that there's no nextnode, you have to avoid calling nextNode:ETA.

Just so you know, the thing I'm currently working on on-and-off for the kOS project is the ability to enable a telnet server inside kOS (probably just to localhost 127.0.0.1 for safety since it's unencrypted telnet - if you want it remoted you can ssh tunnel it from 127.0.0.1 to a local ssh port to cause it to be more secure.) I actually already have it handling the thread fork that all tcp/ip servers need to work properly, and the telnet end of things follows most of the RFC's except for the one about terminal size (which I plan to add specifically for projects like this with hardware small displays). The part I'm in the middle of now is making the rest of kOS stop hardcoding the assumption that it's talking to a Unity GUI window. Anyway the point is that part of the motivation for this is projects like this one. In principle it should be possible to get the kOS terminal to appear on hardware displays provided the hardware implements a basic telnet client.

Like the normal thrust it goes from 0.0 to 1.0 on the same scale. i.e 75% is 0.75

In my case my goal was to make a raw-steering (not LOCK STEERING) example of how to do docking from one weirdly aimed docking port to another, as a proof of concept of the new direction and position suffixes for parts, so because I was trying to do it with raw SHIP:CONTROL techniques the fact that LOCK STEERING didn't work right was of lesser priority to what I was trying to do. But yeah, that reminds me that I never did make the example video for that test case like I meant to. I really should. - - - Updated - - - Does this work for you? // Assumes that at this point of your script, // lat1, long1, and lat2, long2 are the latitude and longitude of the 2 points you're interested in. // SET geoPos1 to LATLNG(lat1,long1). SET geoPos2 to LATLNG(lat2,long2). print "Position vector of geoPos1 is " + geoPos1:POSITION. print "Position vector of geoPos2 is " + geoPos2:POSITION. print " --- ". set vector1To2 to (geoPos2:POSITION - geoPos1:POSITION). print "Straight line vector distance from pos1 to pos2, " print "(ignoring terrain and surface curvature)" print "is this: " + vector1To2:MAG.

Why limit the scope to just :GetField? Why not just allow a script to print whatever string it feels like to a PostScreenMessage, regardless of whether it's coming from a :GETFIELD or something else? Just implement it at the basic string level and you get :getfield for free that way, along with all sorts of other stuff.

What additional information do you get from 6 points in a plane that didn't already exist from just 3 points in plane? If you know they're all in a plane, once you have 3, any more are just gravy. If you don't know that they're all in a plane, then basically the concept of a "normal" vector to the not-plane doesn't make sense anyway. Or is the unspoken assumption in your math that you assume your points are not in a plane but are sort of close to being in a plane and you're trying to find the approximate average plane that runs through the cloud of them? (in KSP terms, since KSP terrain is made of flat polygons, that would mean the points are not all hitting the same polygon and you want the average plane between the angles of the different polygons you've hit.) I'd still go with the cross-product in that case, and just get the resulting vector from multiple tuples of 3 points, turning them into unit length vectors so as not to weight them, and then average them into one vector. i.e. if you have point A in the middle, and then points B,C,D,E, around A, then get the normals: AB X AC / |AB X AC|, AC X AD / |AC X AD|, AD X AE / |AD X AE|, AE X AB / |AE X AB|, and average their coordinates together, to get average slope around point A. It's good enough and it's a lot faster because you're allowing the underlying (very fast) 3D engine do the math, instead of doing it in the slow world of kOS script code. A cross product is normally a matrix operation with lots of components, but when you let the 3D engine do it for you, it's often translated into hardware instructions, as vector operators have to happen so often in graphics that a typical graphics card will provide you with the ability to do them itself. The 3D engine will abstract all that away so long as you use its function calls to do the operation and don't try to run all the steps yourself. But at any rate the whole point of kOS is to let you do it yourself and if you want to use the cloud method by all means go for it. I do agree that the lack of local variables and user-defined functions is rather severely limiting and could use fixing. It's on the long list of "stuff to get around to some day".

I noticed that too and reported it as issue number 397, but I didn't look into the cause because I was leaving the steering up to erendrake to deal with while I worked on other stuff, and I wasn't even sure it was real as I had a lot of other problems at the same time and it was hard to isolate one bug from another. If you're able to perfectly recreate it with a known craft and a known set of actions, it would be great if you could add your information to that bug report.

Getting a list of all laserdist modules on the ship (there should be one such module per laserdist part): set distModules to ship:modulesnamed("laserdistmodule"). For one such module (the zero-th one), turning it on, off (and making the laser visible): // Turning it on: distModules[0]:SETFIELD("ENABLED", true). distModules[0]:SETFIELD("VISIBLE", true). // Turning it off: distModules[0]:SETFIELD("ENABLED", false). distModules[0]:SETFIELD("VISIBLE", false). Getting the reading (only works when enabled = true): set metersDistance to distModules[0]:GETFIELD("DISTANCE"). kOS supports pretty much any module now in this way, provided the module gives the users a visible reading on the rightclick menu of the part. The names above ("ENABLED","VISIBLE", and "DISTANCE") are taken directly from the user interface GUI labels used on the right click menu. A more in depth explanation of how to get a kOS script to interact with other modules, using its generic partmodule system, is here: http://ksp-kos.github.io/KOS_DOC/general/parts_and_partmodules.html

Sorry, the problem is the origin position of the vector drawn on screen appears several meters away from the port:position that I set it to. I discovered, however, that if I set the magnitude to 1 (in the original code I was using from the github docs it was 5), then it appears exactly as I expect it to. I've attached screenshot below to show what I mean. This is with mag set to 1: http://i.imgur.com/PoScCGL.png This is with mag set to 5: http://i.imgur.com/OA4buTc.png It's not currently part of an overall program, I'm just trying to learn how everything works. Yeah thats the effect of the scale operator. It mulitplies both the offset start position and the vector itself. That may be silly. If nobody is using it that way i may remove the part about multiplying the start pos and just multiply the vector size only. In the mean time to get what you want just multiply 5 by the second argument only.

Your description is missing the most important bit: What is it about this that doesn't work? are you getting an error message? Is something not showing up on screen? - - - Updated - - - Your method seems to be doing an awful lot of extra work, given that kOS provides you with vector cross product operators already, which is what I suspect all your matrix math ends up doing anyway. The matrix operations behind a vector cross product are handled for you by the Unity engine, and we pass that on to you with a kOS function VCRS( vector1, vector2). You should be able to get a normal vector to a point on the ground using just 3 sample points, and a cross product. Once you've got the location of 3 points A,B,C, then you can do this: set ABvector to B - A. set ACvector to C - A. set AB_cross_AC to VCRS(ABvector,ACvector). // normal to the slope at that spot. set angle to VANG(AB_cross_AC, ship:UP). // slope angle (assuming that the impact // point is near enough in latitude/longitude to the // ship that the difference in UP between the ship location and the hit location is negligable).

The ship's raw position IS V(0,0,0) in kOS terminology. The weird contradictory coordinate system of underlying KSP is re-origined at the current ship's CoM for all position vectors in kOS (although it's not re-rotated to something sane - it stays at the underlying rotation). Oddly enough, it's still not origined at the vessel for VELOCITY purposes (which would zero your velocity if it was), but rather it reports the velocity at which the rest of the objects in the universe are passing you by.

I usually prefer to go with this logic: Whenever an engine flames out, start hitting the stage button repeatedly until no more flamed out engines are attached anymore and there is at least one working engine attached (Just like in manual piloting, hitting 'stage' doesn't always have an effect if you've hit 'stage' too recently. It has a cool down period. So what I do is usually hit 'stage' again and again until I see that mass has dropped as proof that it worked.) set numFlamedOut to 9999. // bogus start value forces loop to occur at least once. until numFlamedOut = 0 and ship:maxThrust >0 { // ship:maxthrust will zero if no engines are active. list engines in engs. for e in engs { if e:flameout { numFlamedOut = numFlamedOut + 1. }. }. if numFlamedOut > 0 or ship:maxthrust = 0 { stage. }. }.

That was a bug in one of the releases that has already been fixed in the most recent releases. Are you sure you have the most recent release? If you do, then something is weird about it because other people are able to do it without getting that error anymore.

All of it is in the "it would be nice" plans. We're well aware of them all. The chief problem is that kOS is really an enormous undertaking limited mostly by free time rather than by capability. They're all doable. But we have to think in terms of "triage". Some improvements aren't too hard but also aren't that useful, so they aren't high priority. Some improvements are quite useful but require quite a lot of work, so they aren't high priority as they'd prevent other stuff from getting done. The stuff in between those two extremes ends up getting done first. The telnet stuff I'm working on now would normally fall into that "but require quite a lot of work" category and therefore not be getting done, were it not for the fact that I view it as a pre-requisite for doing proper keyboard input to scripts, which is a big deal everyone wants. I view it as a pre-requisite for proper keyboard input simply because any code to deal with keyboard input would have to be rewritten later on once telnet becomes possible. The telnet isn't higher priority, but it affects the terminal infrastructure in such a way that I'd rather have it fleshed out before fiddling with the other stuff that uses that architecture, like keyboard input. By the way, erendrake is working on the gimbal thing you listed as #3.

You're probably trying to load a Vessel or a Craft file that you saved earlier before you made the change. When you save a ship design in the VAB, it saves a copy of the vessel that holds all vessel's settings for all the vessel's parts (so it can remember how you had your tweakables set.) When you launch the vessel on the launchpad, it clones that saved copy and all its saved part values. The part.cfg file affects the settings that are applied to *new* instances of the part that are created. It doesn't affect old instances of the part that already existed before you made the change. Try going into the VAB, pulling the ship apart and removing the SCS computer part and throwing it away, and then attaching a new copy of the SCS computer part to the vessel and reattaching the pieces as they were. Save that and it should now have the new setting.

I agree that it's ridiculous. It's been largely left alone for now because a future goal is to make multiple sized storage units and until that infrastrucure is in place any changes made now would just have to be changed again later. In the meantime you should be able to change it yourself by manually editing the Part.cfg file for the kOS part. Look at GameData/kOS/Parts/kOSMachine0m/ or GameData/kOS/Parts/kOSMachine1m/, depending on which part you want to change it for, and look for a file called Part.cfg in those folders. It should have a section like so: MODULE { name = kOSProcessor diskSpace = 5000 } Change the number for diskSpace, save the file, and re-run KSP. Be aware that your change will be reset each time you install an update of kOS and you'll have to edit it again. - - - Updated - - - I already was planning on not using port 23. This could be running on a computer that already has a real telnet server on it, and besides, the OS *should* be preventing a normal level user from running code that opens up a server on ports less than 1024. That's supposed to require root/admin privileges, which is another reason I'm not using 23. It would necessitate running KSP as root/admin. I may consider allowing the user to open it to known ranges, but that makes me a bit nervous. It would be easy for a kOS user to hear advice from someone saying "hey, doood, all you have to do is just type these numbers in there and it works everywhere - I know because I did it myself." I want a certain level of expertise on the part of the person opening this up so it puts the onus on them to know what they're doing and why. I may provide step by step instructions on how to set up an ssh tunnel. But the point is that an ssh tunnel then requires that there be some sort of existing means of logging in to the host machine already, thus the better security. - - - Updated - - - It opens up all the following use cases: Other mods, like telemachus, remotely hosting kOS terminals inside them. Support for the people who like to build funky hardware dashboards for KSP. Let's face it, we'll never end up making the in-game terminal as nice to look at as something like xterm or putty. In an external window, you can overlap the windows nicer, tile them, do what you want, without them getting in the way of the main game window. Supports people running the game on multi-headed monitor setups. They can put their kOS terminals on another screen away from their game screen. Multi-player coop Artemis-style missions such as envisioned by the Go At Throttle Up mod.

On a kOS Telnet server and security. I'm in the middle of trying to implement the ability to remote the kOS terminals from an application outside of KSP. Thus allowing you to, say, open Putty on Windows and connect it to the kOS computer and have your kOS script show up there. Or open an xterm on linux and connect into kOS from it. But this raises some security concerns, so I thought I'd ask the user community what they thought of my approach, as described below: It works by having a telnet server inside of KSP. I wanted ssh originally but had to abandon that plan due to the dearth of opensource ssh server implementations for C#, and my unwillingness to implement one from scratch as that would be a brand new months-long project in itself. Granted there weren't any telnet server projects I could find either, but the telnet protocol is a LOT easier to implement from scratch - at least just enough of the handshaking to make it switch from the default line-at-a-time mode to the char-at-a-time mode you need for proper terminal operations. The server will refuse to ever use any address other than loopback 127.0.0.1. It will make no attempt to resolve the hostname or find the 'real' address. This should prevent remote network connections. Because it's a false sense of security to even bother sending passwords over telnet, a different approach is needed for security entirely. Thus the loopback rule instead of bothering with names and passwords. Therefore users who do want to try to connect to the system from another host will have to be tech saavy enough to know how to set up their own ssh tunnel to do it. The security will therefore be the responsibility of the person setting up the ssh tunnel and not kOS. In keeping with the rules SQUAD imposes about not having KSP mods perform network traffic without the user's express understanding and opt-in permission, the mod will ship with the telnet option turned off by default, and unless you turn it on by changing a config option, there will be no telnet server running. The first time you turn it on, there will be an explanatory popup message about what it means. I'll do this even though, *technically*, since the server only talks to loopback 127.0.0.1, it's not *really* network traffic. It's local traffic that only lives in RAM and never reaches the hardware network interface. It is my hope that this will satisfy people's desire for some security. By only allowing it to be local 127.0.0.1, And being turned off until you say to turn in on, I hope to avoid the need for encryption and username/password checks. I can still see *one* potential problem being what might happen if you're running the game on a computer with multiple users on it at the same time, and another user wants to mess with you by telnetting to your KSP game. But that's the sort of thing that I think is less likely on a gaming machine on which you would run KSP, and more likely on a server machine. To do this someone *already* needs to have an account on your gaming machine and *already* have the ability to get to the command line on it. And if someone you don't trust has managed to do that much already, you've already lost your security entirely even before kOS enters into the picture.

On a side note - I see some people posting art where they've clearly got their hands on some rendering of the KSP parts inside some type of cad or diagramming tool, as in the recent post by Dr_Goddard. I might find such things useful in diagraming examples for docs. Where do you find the resources for those things. I'm assuming you didn't draw the parts yourself - they look too much like the rendered parts for that - I assume they were auto generated by somebody.

I had it wrong. it's the full word: ARCTAN2, not ATAN2. In lots of other languages it's atan2, so I remembered it wrong. That rambles a bit and is impossible to decipher what you're talking about. It is like building with lines and shapes in exactly the same way that math is like drawing. things like sine, cosine, tangent, functions, derivatives, etc all have meanings that do in fact map to visual representations, bu doing everything visually, while easier to follow, would be very slow. You can manipulate an equation faster than you can draw out graphically what those manipulations mean. Similarly you could program graphically, and there's been attempts to do so where you make the languages constructs into blocks and lines connecting them, but aside from proofs of concept they haven't really caught on, and for good reason. They may be easier to understand but they'er slower to work with once you do understand them. It's the common learning curve problem where usually the technique that's easier in the long run is harder in the short run. - - - Updated - - - It's too small in the picture to tell which way is right side up on that wafer thin part. Do this on the launchpad: set vd to vecdrawargs(v(0,0,0), 10*ship:up:vector, red, "ship:up vector", 1, true ). (I'm typing that from memory - I hope I have the arguments correct). If you have it mounted correctly, that should make an arrow pointing up. If you have it upside down, it will make an arrow pointed down through the launchpad.

This may be an obvious question but I'll ask it anyway just to be sure: Is your command core mounted upside down? The steering may literally think up is down when you do that. To test this case, have a careful look at the navball when you are on the launchpad. It should be showing the prograde marker in the center of the blue sky, rather than the retrograde X marker in the center of the blue sky. - - - Updated - - - Correct. If it didn't then the game wouldn't know when you press "A" whether that goes to the command line in the terminal or to the text file in the editor. - - - Updated - - - Incidentally, you're not actually showing us the relevant part of your script. What is buried inside the bit you described as: // more code here Because notice your screenshot is from an altitude of 593. And your script says WAIT UNTIL SHIP:ALTITUDE > 500. So... if you *just* started pitching over there ... then you've just hit the next part of the program after that - which we can't see.