Dunbaratu

Yeah, you're right. I knew that "velocity of A relative to B" means subtracting B's velocity from A's, but forgot that the navball isn't showing you the target's velocity (relative to you) when in target mode. It's showing you your velocity (relative to target).

I think that's the target-relative prograde vector. If I'm right, you'd need to subtract it the other way around (or multiply it by -1) to get the retrograde version. EDIT: No, it was right the first time. Ignore me.

The problem is that the code needs to be run in order for I_SHOULD_STAGE to ever get set. The WAIT UNTIL line is going to sit there and never run the loop that looks for the stage condition. You could make it a function that returns a boolean value, then call that function in the WAIT statement. FUNCTION partlist_flameout { parameter part_list. // pass in a LIST() of parts to check. FOR P in part_list { if P:HASSUFFIX("FLAMEOUT") and P:FLAMEOUT { // Note the use of short-circuit boolean protection here. return true. } } return false. } // Then later when you try to use it: local boosters is SHIP:PARTSTAGGED("booster"). SET RUNMODE TO 2. WAIT UNTIL partlist_flameout(boosters). STAGE. The reason I suggested making it just operate on a LIST you pass in, is that it is a bit more efficient that way because it doesn't have to keep re-searching for the part tags - it only builds the list once. Also, this makes it generically re-usable with other part lists you might want to use it on later.

I'm sure you've noticed in building in the VAB how in reality the ship is a tree structure (with the exception that struts are allowed to link cousins and siblings and thus slightly violate that tree structure). Well, in kOS you could walk this structure because each part has a :PARENT suffix and a :CHILDREN suffix (PARENT is a single part, and CHILDREN is a LIST() of parts.) So using that you could figure out which parts are "closer to" the root part, and which parts would "fall off" when a decoupler is triggered.

> PRINT SHIP:PARTSTAGGED("booster"):SOLIDFUEL Two problems with that: 1. The :SOLIDFUEL suffix is only on the entire vessel level, not on the level of a single part. (It totally could be and maybe we should add that, but right now it's not). 2. PARTSTAGGED is plural for a reason - because you're allowed to give the same tag name to more than one part, the suffix is designed to return a LIST of parts, not a single part. If you want to look at the first part in the list, put a '[0]' at the end of it. If you want to look at all the parts it returns make a FOR loop like so: FOR P in SHIP:PARTSTAGGED("booster") { // do something with P here. } try this: local I_SHOULD_STAGE is False. FOR P in SHIP:PARTSTAGGED("booster") { if P:HASSUFFIX("FLAMEOUT") and P:FLAMEOUT { // Note the use of short-circuit boolean protection here. print "I have a flamed out booster, I will stage". set I_SHOULD_STAGE to False. } } if I_SHOULD_STAGE { stage. }

Can't tell from here. Nothing in the logs indicated any errors with it that I could see. Would it be normal for it to not have any power? You're describing it being power starved, but if you built it as shown it shouldn't be. I see you have realism overhaul - did you make sure it has an antenna connection active on launch? In the past there have been (supposedly fixed now) bugs in which lack of antenna connection in RT caused the wrong result in game (power starving instead of a message about the lack of RT connection, when config:arch is true).

I think you're thinking of FMRS:

Can this mod detect the amount of gravity pull from the gravioli detector, and trigger something when it switches from getting weaker to getting stronger? Hypothetically that should happen right at apopapsis, when you are no longer getting further from the center of the SOI and are now starting to get closer to it.

I don't know what the Neato is. But if you're asking if you can aim the laser in different directions at different times, there are multiple lasers it comes with, and the higher ones are capable of having you "bend" the laser as it emits from the end of the gun within a certain degree arc. If you want more bend than that, then you'd have to mount it on a moving arm, yes.

Yes. In fact that's its main purpose.

You could iterate over all the engines and look for which of them are currently ignited, with this suffix: http://ksp-kos.github.io/KOS_DOC/structures/vessels/engine.html?#attribute:ENGINE:IGNITION list engines in all_engines. local active_engines is LIST(). for e in all_engines { if e:ignition { active_engines.add(e). } } // Now active_engines is a list consisting of only those engines that are currently lit.

I've done tests where using a Quaternion to rotate a vector produces enormous errors if the vector has a large magnitude, but works fine if you try to rotate the unit-vector version of the vector instead, and then multiply the magnitude of the vector back to full size again afterward. When I found QuaternionD I was sort of hoping it would avoid me having to perform those extra steps but it really looks like QuaternionD is sort of half "not there" so this technique won't work well. It looks like I will have to resort to the normalize, rotate, denormalize technique. It's not impossible, but it's a big edit because of how many places we perform vector rotations that I will have to replace with calls to some wrapper method instead that does those steps.

I'm finding a suspiciously large number of these missing extern methods in QuaternionD. I've been trying to build our own replacements for them, but each time I implement one, that just makes me find another one is missing the next time I run. So far, all the following are ones I've had this problem with and I had to re-implement them myself: QuaternionD.LookRotation() QuaternionD.FromToRotation() QuaternionD.eulerAngles I'm starting to wonder if the real problem might be one of the following possibilities: 1 - QuaternionD is part of some refactor that never got completed and I shouldn't really be using it at all. 2 - QuaternionD depends on an additional DLL I'm meant to be compiling with that I'm neglecting to add to the build or runtime environment. 3 - QuaternionD is designed for KSP-only and modders aren't supposed to be using it. 4- QuaternionD is only used by KSP in just a few places here and there, and only the parts that were needed by SQUAD got implemented, with everything else left as an extern method because it was meant as a "TODO" for later if need-be. If it's any of the above, then I probably shouldn't be trying to implement my own versions of these missing methods. If it's 1, 3, or 4, then I shouldn't be using QuaternionD at all and I should just find ways to get by without it. If it's 2, then I should be trying to figure out what I'm missing from my build or runtime environment. (Note, despite being in the UnityEngine namespace, QuaternionD seems to actually be part of the KSPUtils DLL file, not the UnityEngine DLL file.)

Well, I was hoping I didn't have to do that (normalize, rotate, then un-normalize) but it looks like it's the only good way. I really don't want to re-implement Quaternions because....ugh....Complex Numbers.

I'm getting a weird thing where the *compiler* claims a method exists that at *runtime* it throws an exception on and says it does not exist. It's this: System.MissingMethodException: Cannot find the requested method. at (wrapper managed-to-native) UnityEngine.QuaternionD:INTERNAL_CALL_LookRotation (Vector3d&,Vector3d&) at UnityEngine.QuaternionD.LookRotation (Vector3d forward, Vector3d upwards) [0x00000] in <filename unknown>:0 at kOS.Function.FunctionHeading.Execute (kOS.SharedObjects shared) [0x00000] in <filename unknown>:0 at kOS.Function.FunctionBase.Execute (kOS.Safe.SafeSharedObjects shared) [0x00000] in <filename unknown>:0 at kOS.Safe.Function.FunctionManager.CallFunction (System.String functionName) [0x00000] in <filename unknown>:0 at kOS.Safe.Execution.CPU.CallBuiltinFunction (System.String functionName) [0x00000] in <filename unknown>:0 at kOS.Safe.Compilation.OpcodeCall.StaticExecute (ICpu cpu, Boolean direct, System.Object destination, Boolean calledFromKOSDelegateCall) [0x00000] in <filename unknown>:0 at kOS.Safe.Compilation.OpcodeCall.Execute (ICpu cpu) [0x00000] in <filename unknown>:0 at kOS.Safe.Execution.CPU.ExecuteInstruction (IProgramContext context, Boolean doProfiling) [0x00000] in <filename unknown>:0 According to the compiler, UnityEngine.QuaternionD.LookRotation emphatically does exist, with those exact arguments. But at runtime it does not. I'm not sure what "INTERNAL_CALL" means, but I'm guessing it means "this isn't implemented in the normal C# way" or something like that. (i.e. maybe it's dropping down into some other language for that part, or doing something implemented in raw machine language instead of in the MSIL's opcodes?) This came about because I was trying to replace all our Quaternion usages with QuaternionD's because when working with large vectors (i.e. the distance from Kerbin to Duna, for example), the 32-bit precision of Quaternion's was beginning to multiply into rather big errors after several operations of using them to rotate those big vectors. But it looks like not everything that was implemented for Quaternion got re-implemented for QuaterionD''s. Am I going to have to resort to running my own matrix multiplications to perform rotations or is there some other solution to this?

Is there a means to limit the mod to only draft viewers who have written a chat message within the time the draft-twitch-viewers mod has been watching the channel? I'd prefer to allow lurkers to continue lurking if they prefer, and not end up having this mod "call them out" by drawing attention to the fact that they're viewing.

V1.0.0 release is now official! (It is no longer pre-release.) Available on spacedock and github and curse in the usual places. I'll see if I can get @erendrake to change this thread's head post. About the name: kOS has been around long enough that we figured it was long overdue for us to stop calling it 0.something. Lots of people are using it, and we're worried about backward compatibility enough that we're not really treating it like a Beta anymore. This version contains mostly a few things that we knew might break backward compatibility so we'd been putting them off for a long time. A jump to 1.0 seems a good time to add those changes. Of course, it has lots of other changes for whatever else was being worked on since the last release. BREAKING CHANGES As always, if you use the compiler feature to make KSM files, you should recompile the KSM files when using a new release of kOS or results will be unpredictable. New Subdirectories ability has deprecated several filename commands such as delete, copy, and rename. They will still work, but will complain with a message every time you use them, as we may be removing them eventually. The new commands deletepath, copypath, and movepath described below are meant to replace them. When using a RemoteTech antenna that requires directional aiming, in the past you could aim it at mission control with SETFIELD("target", "mission-control") and now you have to say SETFIELD("target", "Mission Control") instead, due to changes in RT's naming schemes. Previously the Y and Z axes of SUN:VELOCITY:ORBIT were swapped. (#1764) This has been fixed so it is now the same as for any other body, however scripts might exist that had previously been swapping them back to compensate for this, and if there were they would now break since that swapping is no longer needed. NEW FEATURES Subdirectories: (http://ksp-kos.github.io/KOS_DOC/commands/files.html) You are now able to store subdirectories ("folders") in your volumes, both in the archive and in local volumes. To accomodate the new feature new versions of the file manipulation commands had to be made (please go over the documentation in the link given above). In the Archive, which is really your Ships/Script/ directory on your computer, these subdirectories are stored as actual directories in your computer filesystem. (For example, the file 0:/dir1/dir2/file.ks would be stored at Kerbal Space Program/Shipts/Script/dir1/dir2.file.ks on your real computer.) In local volumes, they are stored in the persistence.sfs savegame file like usual. (Pull Request discussion record: #1567) Boot subdirectory: (http://ksp-kos.github.io/KOS_DOC/general/volumes.html#special-handling-of-files-in-the-boot-directory) To go with Subdirectories, now you make a subdirectory in your archive called boot/, and put all the candidate boot files there. When selecting a boot file in the VAB or SPH, the selections are taken from there and need not contain the "boot_" prefix to the filename anymore. Old boot files will be grandfathered in that are named the old way, however. CORE:BOOTFILENAME is now a full path. i.e. boot/myfile.ks. PATH structure now allows you to get information about the new full subdirectories system from your scripts. (http://ksp-kos.github.io/KOS_DOC/structures/volumes_and_files/path.html) New RUNPATH command now allows any arbitrary string expression to be used as the name of the file to be run. i.e. set basename to "prog". set num to 1. runpath(basename+num, arg1). // same as run prog1(arg1). As part of the support for this, programs with a large number of RUN commands (or RUNPATH commands) should now take up a bit less of a memory footprint than they used to in their compiled form (and thus in KSM files too). (http://ksp-kos.github.io/KOS_DOC/commands/files.html#runpath-and-runoncepath) Communication between scripts on different CPUs of the same vessel or between different vessels. (http://ksp-kos.github.io/KOS_DOC/commands/communication.html) A new structure, the Message, contains some arbitrary piece of data you choose (a number, a string, a list collection, etc), and some header information kOS will add to it that describes where it came from, when it was sent, and so on. What you choose to do with these arbitrary chunks of data is up to you. kOS only lets you send them. You design your own protocol for what the data means. If RemoteTech is installed, a connection is needed to send a message to another vessel (but not to a CPU on the same vessel). And, the message won't actually show up in the other vessel's queue until the required lightspeed delay. To handle KSP's inability to have different vessels far away from each other both fully loaded and active, you do have to switch scenes back and forth between distant vessels if you want them to have a conversation back and forth. Messages that were meant to arrive on a vessel while it wasn't within active loading range will wait in the recever's vessel queue until you switch to it, so you don't have to hurry and switch "in time" to get the message. Added anonymous functions : (http://ksp-kos.github.io/KOS_DOC/language/anonymous.html) By placing arbitrary braces containing the body of a function anywhere within the script that an expression is expected, the compiler builds the function code right there and then returns a delegate of it as the value of the expression. New 3rd-party addon framework (https://github.com/KSP-KOS/KOS/tree/develop/src/kOS/AddOns/Addon%20Readme.md) allows authors of other KSP mods to add hooks into kOS so that kOS scripts can interface with their mods more directly, without kOS developers having to maintain that code themselves in the kOS repository. (Pull Request discussion record: #1667) allow scripted vessel launches KUNIVERSE:GETCRAFT(), KUNIVERSE:LAUNCHCRAFT(), KUNIVERSE:CRAFTLIST(), and KUNIVERSE:LAUNCHCRAFTFROM() allow you to script the changing of scenes and loading of vessels into those scenes. While this breaks the 4th wall quite a bit (how would an autopilot choose to manufacture an instance of the plane?), it's meant to help with script testing and scripts that try to repeatedly run the same mission unattended. (http://ksp-kos.github.io/KOS_DOC/structures/misc/kuniverse.html) eta to SOI change: Added SHIP:OBT:NEXTPATCHETA to get the time to the next orbit patch transition (SOI change). (http://ksp-kos.github.io/KOS_DOC/structures/orbits/orbit.html#attribute:ORBIT:NEXTPATCHETA) get control-from: Added SHIP:CONTROLPART to return the Part of the vessel that is currently set as its "control from here" part. (http://ksp-kos.github.io/KOS_DOC/structures/vessels/vessel.html#attribute:VESSEL:CONTROLPART) maneuver nodes as a list:( New ALLNODES bound variable that returns a list of all the currently planned manuever nodes (the nodes you could iterate through with NEXTNODE, but rendered into one list structure). (http://ksp-kos.github.io/KOS_DOC/bindings#allnodes) Several new pseudo-action-groups (akin to "panels on", that aren't action groups as far as stock KSP is concerned, but kOS treats them like action groups) were added. (http://ksp-kos.github.io/KOS_DOC/commands/flight/systems#kos-pseudo-action-groups) Ability to get/set the navball mode (surface, orbital, target) with the NAVMODE bound variable: i.e. SET NAVMODE TO "SURFACE".. UniqueSet structure. (http://ksp-kos.github.io/KOS_DOC/structures/collections/uniqueset.html) A collection intended for when all you care about is whether a equivalent object exists or doesn't exist yet in the collection, and everything else (order, etc) doesn't matter. BUG FIXES In some cases (#1661) the program wouldn't stop immediately when you execute a kuniverse command that reloads a save or switches scenes. It would instead finish out the remainder of the IPU instructions in the current physics tick. After the fix, causing a scene change (or reload) automatically stops the program right there since anything it does after that would be moot as the game is about to remove everything it's talking about from memory. If using "Start on archive", with Remote Tech, a misleading "power starved" error was thrown when you reboot a probe that's out of antenna range. (#1363) unchar("a") was apparently broken for a few months and we hadn't noticed. The root cause was that its implementation had to be edited to comply with the change that enforced the VM to only use kOS Structure types on the stack. The need for that change had been missed. (#1692) Previously Infernal Robotics allowed you to move servos that weren't even on your own vessel and you shouldn't have direct control over. This has been fixed. (#1540) Refactored previous non-working technique for quicksave/quickload to turn it into something that works. (#1372) There were cases where using CTRL-C to abort a program would cause some old cruft to still be leftover in the VM's stack. This made the system fail to clear out the names of functions that were no longer loaded in memory, making it act like they were still reachable and call-able. (#1610) Some types of Resource didn't contain the :DENSITY suffix like the documentation claimed they would. (#1623)

There's full documentation (not just a list of commands) here: http://ksp-kos.github.io/KOS_DOC/index.html We try to keep it up to date as much as possible. Right now it doesn't contain the new things in the pre-release candidate but that's deliberate. It won't contain those until the candidate becomes a full release.

I noticed the following is the default setting for distances while in orbit. I was trying to debug why kOS docking scripts were having such trouble controlling the non-active vessel and realized it happened when the vessel got a short distance away but was still visible and loaded and decided to print out these values: PhysicsGlobals.Instance.VesselRangesDefault.orbit.load : 2250m PhysicsGlobals.Instance.VesselRangesDefault.orbit.unload : 2500m PhysicsGlobals.Instance.VesselRangesDefault.orbit.pack : 350m PhysicsGlobals.Instance.VesselRangesDefault.orbit.unpack : 200m Does anyone know why the pack/unpack distances are so drastically small for orbit compared to the load/unload distances? I think I might understand the need for it with vessels landed on the ground, because as the active vessel moves away from a landed vessel, the ground terrain mesh might become more coarse, invoking Kraken-riffic intersections between vessel and the re-positioned ground polygons. But the pack/unpack distances are *also* very small for ships drifting in orbit, where presumably it's not so bad, and I assume even with single-precision floats you still don't get the Kraken at a mere 350 meters away. Is there a really good reason for the value to be that small, and am I inviting disaster if I set it higher? I'm not talking about setting it super high - just making it closer to the load/unload distances so people can presume "if I can see the vessel on screen and it's not just a single dot, that means the vessel is fully functional."

I'm confused by the description. What do you mean by "path() isn't updated until after the script has finished running" when combined with "without setting the path in script!". If the script isn't setting the path, then what's this "updated" you're talking about mean?

Just a note, what I wrote as "correct" is actualy not correct. The vector is inverted in the wrong direction. (in addition to not swapping the axes, it's *also* failing to invert the direction so it's the sun's velocity relative to kerbin instead of kerbin's velocity relative to the sun.) I'm seeing if I can get the fix into the v1.0.0 official release coming up soon, rather than making you have to wait even longer for the next release after that.

Not your fault. You've discovered a bug. I made an issue for it here, which you should have a look at to see the detailed description of the problem: https://github.com/KSP-KOS/KOS/issues/1764 If you need an immediate workaround, you can swap the Y and Z axes of the vector you get back from SUN:VELOCITY:ORBIT (but only that one, not the other body's velocities), as shown in the screenshot accompanying the bug report link above. If you do use that workaround, be aware that it's likely something we'll fix in a later release so be on the lookout for that in the release notes of future releases so you can un-swap them once it's fixed in the mod itself.

Velocities are given relative to the SOI body of the vessel running the code. Thus ship:body:velocity:orbit is always a zero vector. But in general the generic solution to any "I don't know the frame of reference that was used to obtain these two vectors, how do I get one relative to the other" is to just subtract the origin vector from the non-origin one. i.e. the position of A relative to B, if you assume both are in the same reference frame but you don't know which reference frame that is, is to just do the vector subtraction: set relPos to Apos - Bpos. Similarly, you can do the same with velocities: The velocity of Kerbin relative to the Sun should be: set relVel to Kerbin:velocity:orbit - Sun:velocity:orbit. Caveat: I haven't tested this.

I'd like to also point out that you could also make a simple kOS script that does nothing more than log values to a CSV style text file. While it might be a bit daunting to get into kOS just for this and this alone, it would let you dump the file to a spreadsheet with whatever fields in the columns you wanted it to have. Granted, if what you wanted was a *live* output, rather than a logged output you look at later on after the flight, then this won't help you.

I was with you until you said that insult. Plenty of people using MJ2 know perfectly well how to do all the things it's doing. It's *possible* to use it in the unrealistic way where you use it to do a thing your space agency (you) never learned how to do (unrealistic because then who the heck designed the autopilot?). But that doesn't mean that's the only way it gets used. The notion that it's primary purpose is to succeed at a thing you don't know how to succeed at yourself is kind of insulting to a lot of players who aren't using it that way. (and kOS still automates a lot for you. It just lets you assemble the building blocks it provides into the final finished product. It's akin to making rockets in the VAB - you don't have to know the engineering that goes into making the parts.) As one of the kOS devs, please don't use kOS to be an insulting jerk to everyone who uses MJ2. There's lots of different reasons people use it and you're presuming motivations with blanket statements. First off, not everyone uses it as a replacement for their own knowledge in the way you imply, and secondly, even if they were, there'd still be the "play the game how you like" argument. I mean, one could make the argument that KER is for babies because it lets people see the delta-V of their rocket designs regardless of whether or not they know the math themselves. As someone who *does* know it, I still use it because the tedium of writing down all the necessary numbers from the user interface onto a scratch paper, then running through the formula, each and every time I add or subtract something from the rocket design, isn't fun.