ElWanderer

This is correct. Anything under SHIP:SENSORS needs the relevant science part to be attached to work. https://ksp-kos.github.io/KOS/structures/vessels/vesselsensors.html

To add to infinite_monkey's answer: if you are running Realism Overhaul then you probably have no (or practically no) reaction wheel torque. The steering manager is known to struggle under such conditions. Also, are you locking to a particular vector or are you providing a direction with a sensible top vector? If you don't provide a top vector, it'll default something and quite possibly try to rotate the ship right around as well as hunt for the new forevector, which can result in a complete mess, though I think this has been improved relatively recently (only rotates once you're facing down the right vector), but I've lost all track of kOS version numbers!

Is it guaranteed that the kOS CPU part module will be at index 0? A safer way would be to find out what the module is called and replace getModuleByIndex(0) with getModule("module_name") As to how to find out what the module is called, I would try PRINT CORE:NAME. Sometimes I just put a ship on the launchpad and run a script to print out all the part names and their modules... PS thanks, I had missed getting the free space with a tag/part as the starting point from my own answer.

CORE gets you the CPU module which your script is running on. Modules that are a kOS CPU have a VOLUME suffix. So CORE:VOLUME:FREESPACE should get you the free space on the volume used by the CPU part module. If you want to check other volumes, it is a bit more awkward. If you have named a volume, you can use VOLUME(volume_name):FREESPACE. I think I found by default the name is unset, so my multi-CPU scripts name them all on start-up. You can loop through all volumes by looping through all the CPU part modules (e.g. LOCAL pl IS LIST(). LIST PROCESSORS IN pl.)

Looks like the window opens two minutes earlier (3:31 local time)

Same time tomorrow...?

Does LIST DOCKINGPORTS IN someListVariable work? That's all that page is talking about, I think, and will only get you the ports for the active vessel. To get the ports for another vessel, you can't use that format.

The LIST ... IN form only works for a few, pre-programmed cases. Any ship object has a DOCKINGPORTS suffix that returns a list of ports. To loop through them, do something like: FOR p IN TARGET:DOCKINGPORTS { // do something with each p. }

CHAR(34), but you'll need to append it to the string. e.g. SET myString to "He said " + CHAR(34) + "no" + CHAR(34). That'll set myString to 'He said "no"'

A vector cross of the two vectors will give you an axis (as it'll be at 90 degrees to both input vectors) vector around which you can rotate (ANGLEAXIS function) va by X degrees towards vb. I have an example of this somewhere in my ascent code (to avoid straying too far from surface prograde) if you'd like code to look at. The hard part is working out which way around things are to avoid going the wrong way... partly as KSP/Unity's coordinates are left-handed. Edit to add a link: https://github.com/ElWanderer/kOS_scripts/blob/f5e22ce98925976497ee9acc5216c56c4f7d8372/scripts/lib_launch_common.ks#L345

"We're about to dock with the ISS" "Oooh, quick! To the piano!" *starts playing The Blue Danube, badly* "Oh well. Makes a change from Knees Up Mother Brown..."

@MaltYebisu I know that when I first started using kOS, when you did "RUN X" twice in a row (without rebooting in between), you'd get the same results even if you'd changed the contents of X in the meantime. It's as if the file is cached when the run command is issued. From memory, there was a technical explanation about how files are parsed and their symbols stored when run, but I can't remember the details. It's entirely possible that's still the case. One way around it is to vary the name of the file e.g. by appending a counter. That said, I'd echo @Pand5461's advice of checking the actual file contents first.

How are you "calling" it? Are you using the syntax from the kOS docs (bearing in mind that you get a list of parts from SHIP:PARTSTAGGED, so have to iterate) e.g. SET allSuchParts TO SHIP:PARTSTAGGED("my nametag here"). // Followed by using the list returned: FOR onePart IN allSuchParts { // do something with onePart here. } Copied from: https://ksp-kos.github.io/KOS/general/nametag.html#examples-of-using-the-name

This bit is quite expensive in terms of operations. You don't need to lock the steering continuously in a loop; just once. Take out the until apoapsis bit, and stick a wait until apoapsis > 75000 below the steering lock. Haha - totally beaten to it.

Does this only happen while the script is running? What is your kOS "instructions per second" / CONFIG:IPU set to? Can you share the script?

I think that'll be dwarfed by the drag from the extra capsules having an abrupt 0.625m to 1.25m transition (capsule top to decoupler) and an open 1.25m node (decoupler to nothing). Admittedly, I can only view the video at poor resolution on my mobile phone screen at the moment, so I'm somewhat guessing at the parts. Either way, I agree that the extra capsules slow down just in time because they have considerably more drag than the prime capsule. Solutions include making the prime capsule more draggy and/or lighter (if you have a heat shield, remove all the ablator... or even the entire part), adding chutes that open earlier (drogues) or pitch over more during ascent so that you have a flatter trajectory. The last one gives you more time to decelerate. I think these have all been mentioned already. I would add that this type of craft is inherently risky - if the individual capsules get too far away from each other, those outside the active craft's physics bubble will be deleted. Admittedly, that's something like 23km now, so you should be okay. My other advice would be to orient to normal before firing the decouplers. That brings everything down with a more similar periapsis, but on slightly diverging courses. That reduces the chance of running into your own dropped stages. That said, (argh, out of place quote follows, stupid mobile interface) this may not be appropriate for this particular craft if the extra pods have tourists and can't orient back to retrograde for reentry.

Hmmm, this information isn't displayed on the map beforehand, but it might be available in the save file (and therefore findable manually or via a mod)... unless the mission parameters aren't actually generated until you hit accept. That would be a pain. I'd be interested to know what the deal is.

Hmmm, a different possible answer: as you have clearly got quite a few mods that may have affected this, it's possible one of them has implemented the behaviour described in the junior docking port's flavour text i.e. that they're too small to transfer crew through. That's never been true of the stock game, though. In stock you don't need to have a 'route' between two modules to transfer crew, they just need to be on the same vessel.

Right (or possibly left?) click on the hatch of the part you want to transfer crew out of. You should get a list of occupants with options to transfer or EVA them. Docking ports have nothing to do with transferring crew, by the way; you can transfer crew between individual modules of a craft that has no ports.

Yes, that won't work as it doesn't exist. Vessels don't have a THRUST suffix; only engine parts do. Do you know how to get the list of engines and loop through them looking for those that are active? You can get the current thrust for each active engine and add them up. Alternatively, you could tag the engine(s) in the VAB and look for just parts with that tag in your code.

What exactly have you tried? MAXTHRUST and AVAILABLETHRUST are both vessel attributes, but from memory only MAXTHRUST has an alias that means you can leave off the vessel (defaults to SHIP) - hence you need to use SHIP:AVAILABLETHRUST. THRUST is a part/engine attribute, so you would need to have looked up the right part to use it.

I don't know what that is, but it sounds like the engines are a single part with mode switching (I think I've seen a SpaceY engine that did that). Sadly... I don't know how that would affect the values of MAXTHRUST and AVAILABLETHRUST. It shouldn't be too hard to test, though. If there is a single part involved, you could also get the current THRUST from it.

How have you "disabled" them? If you have set their throttle limiters to 0, that would not affect the value of MAXTHRUST. SHIP:AVAILABLETHRUST is better in that situation as it takes limiters into account.

How fast are you going horizontally when this begins? At orbital velocity, the gravity you are trying to cancel out is effectively zero. By the time you are hovering, you do have the full force of gravity to counter. I'll look up the calculation for 'effective' gravity... Edit: okay, so your orbital velocity sideways can be used to calculate a centripetal acceleration. You then need to subtract that from local gravity when trying to determine how much you need to accelerate upwards: LOCAL v_x2 IS VXCL(UP:VECTOR,VELOCITY:ORBIT):SQRMAGNITUDE. LOCAL cent_acc IS v_x2 / (BODY:RADIUS + ALTITUDE).

Yes, I use something based on what (Cheers) Kevin Gisi did in Kerbal Space Programming episode 42 or 43: Calculate three points on the ground (A, B, C) a couple of metres away from the target site, in different directions (forming an equilateral triangle in my case). I then take vectors A->B and A->C and cross them, to get a new vector that will point at 90 degrees to the apparent slope of the ground i.e. if the ground is flat, it'll point straight up. The vector angle between that resultant vector and the up vector at the target point gives you the slope angle. Excluding the up vector from the resultant vector gives you a horizontal vector that points down the slope, which is probably the best direction to go in to look for somewhere flatter. That said, I have some breakout code that jumps half a kilometre away if it looks like we've got stuck in a hole or something! Though a work in progress generally, I do seem to have the slope code in a finished (i.e. documented state!) https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_slope_readme.md https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_slope.ks