Dunbaratu
-
Posts
3,857 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Dunbaratu
-
-
LaserDist v1.4.0 for KSP 1.10x. and KSP 1.11.x
The only real change here is compiling against KSP 1.10.x DLLs and support for putting LaserDist parts inside the new KSP inventory system. The parts are defined to have a very small volume, in keeping with other very small parts in Stock that are about the same size.
The KSP 1.11.x updates added an EVA inventory system for parts and they
require parts have a new "ModuleCargoPart" section added to its
Part.cfg files to use it.This release also works on the previous KSP version, KSP 1.10.x too, but it
may cause a startup complaint (which it is safe to ignore) in the logs on
KSP 1.10.x when it sees the new "ModuleCargoPart" section in the config files. -
18 hours ago, SATNAV1122 said:
Hello,
Cool thing but can you send the earlier versions so i can use them with my 1.10.1 mods please?
Your sincearly,Nikodem K******ki
Go to the github page and see the "releases" link. It should have older versions there.
-
6 hours ago, Emilienj said:
Hello,
Firstly thanks for this beautiful mod.
i want to know if is it possible to have the same function as the function « at » does for « print » but for the function Hudtext ? If yes how can i do this ?thanks
Not automatically, but you could write your own wrapper function that does something like this:
function warn_message { parameter text, col, row. hudtext(text, 5, 2, 20, white, false). print text at (col, row). } -
I can't comment about the MFD, as I don't use Rasterprop monitor, and the kOSPropMonitor mod is done by someone else.
But I can answer this:
4 hours ago, stephm said:I trained to access the "kOSProcessor" module, but on the other hand when I look at the doc KOS there is this:
kOSProcessor is the type returned by the bound variable CORE.
So for example:
print "The core is currently " + CORE:MODE. print "The core's boot filename is currently " + CORE:BOOTFILENAME.
-
6 hours ago, JebIsDeadBaby said:
Hello again.
while docking two ships I get CTD with no error messages about one second after successful connection . These are the last entries in the log:
[LOG 17:08:55.939] 2/4/2021 5:08:55 PM,kOS-IRWrapper,Attempting to Grab IR Types... [LOG 17:08:55.952] [FAR v0.16.0.1]: Updating vessel voxel for Space Station-2 [LOG 17:08:56.360] [FAR v0.16.0.1]: Voxel Element CrossSection Area: 0.00980822366822485 Std dev for smoothing: 3 voxel total vol: 167.724347110611 filled vol: 32.2048617377845
If I remove FAR the last entry is kOS, I just wanted to show that kOS is not the last mod trying to do something on this newly merged ship. I can't remove kOS for further testing as there are kOS cores on merging ships. So I just want to ask you if in your opinion, whatever kOS is trying to do here, may be a cause for CTD?
I can't imagine how it could be. exceptions thrown in kOS tend to get caught and just ruin kOS, not the whole game. And even if they're not, the stock game itself tends to catch exceptions mods throw, in general. But it's impossible to prove where it crashed without a post-mortem crash file to load into a debugger, and try as I might i have *never ever* gotten debugging to work right with KSP. (As in, trying to look at the kOS code in the Visual Studio debugger.) There were some instructions how modders can attach the debugger to a running process of KSP, but following them led to ... nothing happening and no error messages explaining why so.... I just gave up. Meaning, I have a hard time proving anything about a crash that won't show any messages in the logs. Also look at KSP.log, as it may be more low level than player.log and might say something more.
-
While probably not related (since your thread spans several days you probably already did this by now) I found that in 1.11.0 (haven't tried 1.11.1 yet) all rover repair contracts required me to save and reload from the save before the rover would be controllable. Switching to the tracking center and back again would also fix it. Basically the scene had to be reloaded somehow to break out of the bug.
-
I wonder if it would be helpful, as a mandatory field in the bug tracker, to make people have to tell you *both* the KSP version they're playing on now *and* the KSP version their campaign started with. Some bugs may require going through the version upgrade path to exist, and don't exist on games newly created from scratch. Such bugs would be impossible for the devs to re-create (and thus impossible to solve) if the reporting user never mentioned the crucial fact that it happened on a game that spanned a version update.
-
23 hours ago, garwel said:
I removed the MandatoryRCS DLL, but I still have the oscillation. I think the problem arises when you have no or very weak reaction wheels: kOS can't stabilize the vessel only using RCS and the engine. Strangely, it worked reasonably well in the past (although sometimes it used too much monoprop for preventing roll).
I noticed that it gets better when I manually turn off RCS about halfway between towards the target orientation at every oscillation. Then I manage to reduce the amplitude and have the (more or less) needed orientation. So my idea is that the PID just keeps firing RCS thrusters for too long. It may cause any issues when you have strong reaction wheels, because they'll eventually stabilize the craft, but with weaker (and more realistic) RW, you are doomed to have this endless swinging.
I'm not very good with PID settings, so I'm wondering if this is something that can be addressed in scripts (other than using more stronger reaction wheels).
You have a zillion mods installed, if I remember.
Can you reproduce the problem on a stock install with just kOS and no other mods? It would make it a heck of a lot easier for me to look at.
I spent a heck of a long time with people who using all kinds of realism settings and play in RO/RP-1 to get the new steering to work for the case of heavy ships that only have RCS for rotation and they've reported much improvement over the old steering. You're the only one who said it got worse than it was before. There's got to be something different about your test case from what I was testing, and I need to find out what it is.
-
4 hours ago, klh1228 said:
Hey all - No idea how this happened but every time my game saves now, I am getting a console error:
https://1drv.ms/u/s!AnWBehSzp6LgmBrGGMzccURNQjt-?e=VEDXYB
The game seems to be saved OK, but the message appearing constantly is pretty distracting. I've tried various things, including uninstalling and reinstalling the KOS mod, to try to get it to go away, but with no luck. I can't figure out what the root cause (no pun intended) might be.
Any ideas on how to track this down, and eliminate it? Thanks!
Since it's talking about plugin configuration in XML format it's probably talking about having trouble loading this file:
GameData/kOS/Plugins/PluginData/kOS/config.xml
That file contains your global kOS settings that are not savegame-specific (mostly the stuff you see in the toolbar panel for kOS). There might be something corrupt in that file. Have a look at it. If you can't figure it out you might be able to just wipe that file with a new copy taken from the kOS ZIP file (it will lose your kOS settings but you should be able to put them back like you had them after that)
-
43 minutes ago, dok_377 said:
This one somehow didn't get a fix. I wonder if NAN and infinite orbits after the satellite separation are still a thing. Probably is. No point in updating then, it still has some critical bugs.
Oh, and by the way, please fix your bugtracker. I can't even update my own bugs anymore.That might be my fault, indirectly.
I complained about how a spambot was able to deface someone's issue (not just append a comment or make a new issue, but actually wipe out and replace someone else's existing issue report with an ad.) This turned out to be because ALL users had permission to edit ALL other user's issues, so any rando account a spambot makes could do it too. It seems they might have "fixed" it by making so that now NO users have permission to edit ANY issues, even their own.
-
1 hour ago, Gotmachine said:
@garwel@Dunbaratu
In the posted chain of events, there is no step 5 : the stock RW torque is never restored.
Therefore, the worst that can happen from the kOS POV is that it, in case the torque doesn't stay constant, the available torque that kOS uses for it's attitude control PID will be the one from the previous step.
With MandatoryRCS, this mainly happen if the stock SAS is active. From what I understand (am I wrong ?), kOS rely on it's own attitude controller and disable the stock SAS.
So I have some doubts that there is actually any torque change happening while kOS has the attitude control in its hands.
However, what will definitely happen is that while kOS is in control, the RW torque will be locked in the very heavily nerfed one, essentially providing next to no effect.
From some experimentation I did a while ago, I remember that most KSP attitude PID controllers (stock, kOS, mechjeb...) have a very hard time achieving stability with only RCS.
The PID parameters are often quite aggressive and that doesn't play well with RCS, which are always at least slightly unbalanced, which is especially an issue when the RCS available torque is high.
Which would explain why reducing artificially the PID aggressiveness by forcing it to see only 10% available torque get ride of the oscillation issue.
Easy way to test that : disable the RW nerf in MandatoryRCS settings, reload the craft, set all the craft RWs torque to zero through the stock PAW slider : does the craft also has trouble stabilizing ?
All this being said, as a general rule, MandatoryRCS doesn't play well with non-stock attitude controllers (kOS, MechJeb, TCA...), as the whole nerf is made to work in conjunction with the stock SAS state.
This has always been a major issue. And TBH, that plugin is in zero effort maintenance mode, and I have a very low motivation to work on it.
If I were to decide to work on it again, I would likely rewrite it from scratch (the overall code quality is... poor).
I have a few ideas that would make it work a bit differently, and would allow much better compatibility with other mods.Dangit I had a long reply but lost it because of the forum's editor. (It pulled focus out of the text area for some odd reason, changing the meaning of backspace to the browser's default "prev browser page" meaning instead of the textarea's "remove a letter" meaning.... grrr.)
Anyway, the gist of it is this - regardless of WHY, the fact is that when kOS queries the reaction wheels for what torque they are able to provide, the answer they get back is the stock value, and this is at the core of why kOS is steering all wrong in this case. Whatever MandatoryRCS is doing to change the reaction wheels' behavior, kOS isn't seeing it when it queries them.
I also turned on a feature in kOS that has the steeringmanager dump a lot of stats on the terminal screen while it steers (set steeringmanager:SHOWSTEERINGSTATS to true.) Using this I was able to prove that if I use a stock install without MandatoryRCS, and suppress the reaction wheels myself with the stock toggle button on the PAW, kOS is capable of steering with the RCS alone just fine, and the stats on screen correctly reflect that the reaction wheel torque is missing from the sum of all torque, with just the torque the RCS supplies remaining. But when using MandatoryRCS, and *it* suppresses the reaction wheels, that same stat shows the full stock value, even though when steering manually with WASD keys instead of with kOS, I can't make the vessel turn at all when RCS is off and I'm relying on the reaction wheel alone (conclusion, the reaction wheel actually provides zero torque, as one would expect MandatoryRCS to be doing, but the query kOS sees is still claiming it's working at full stock magnitude and is not disabled.)
(The reason a false reporting of how much torque the wheel is capable of providing causes kOS to steer all wrong is that kOS is predicting how many seconds it would take to stop rotating from this information. When the value is reported higher than it really is, kOS thinks the vessel is capable of stopping rotation quickly when it really isn't, so it keeps overshooting the target facing.)|
I should say that older versions of kOS *did* have the problem you mention where it was bad at steering with RCS alone. But the latest version is much better at it (because it now rolls its own GetPotentialTorque() like all the other autopilot mods had to resort to doing because the stock one is all wrong when it comes to RCS thrusters). With older versions, what you say would have been true (that even without MandatoryRCS, the kOS mod is just bad in general at steering by RCS alone), but with the latest release it's not anymore. Now it's only got problems when it's MandatoryRCS that's disabling the reaction wheel instead of doing so through stock means.I should also point out that the user who reported this to me was installing MandatoryRCS on a KSP 1.11 install even though MandatoryRCS is only *advertised* as being good up to KSP 1.8, so perhaps that has something to do with it? I don't know.
Do you know of anything I could query from kOS's side to discover whatever it is that MandatoryRCS does to suppress reaction wheels so I can report the proper number to myself when querying the torque? Our Torque calculation for reaction wheels is this: https://github.com/KSP-KOS/KOS/blob/d308fae5a92eaf834013fbfaf8259f4889fc9aab/src/kOS/Control/SteeringManager.cs#L733 -
3 hours ago, MacLuky said:
Hi. can i find the old docs somewhere? i am on ro/rss and using an older version of kos, lacking deltav info i discovered
Unfortunately the web server that github provides for gh-pages only really serves up the most recent version of the html, and doesn't have a means to automatically let you select an older version. But, you CAN get access to an older commit of the HTML files copied locally onto your own computer, and have your browser render the local HTML files using a local file:/// url.
First you have to be set up to be able to clone github repos (and that's a long topic in itself, but the information is freely available online for how to do that).
If you are set up to be able to clone git repos, and you have gitbash, do the commands below to get the docs for kOS 1.2.0.0, which I assume is what you want because that was the last documentation change before kOS stopped supporting KSP 1.8:git clone [email protected]:KSP-KOS/KOS_DOC.git cd KOS_DOC git checkout gh-pages git checkout af93a757
If you want to know where "af93a757" came from, it was from looking at the KOS_DOC commit history on this page and finding the commit that was labeled as being for that kOS version: https://github.com/KSP-KOS/KOS_DOC/commits/gh-pages
That *should* give you a local copy of the HTML files so you can just point your browser at the index.html and go from there.
-
2 hours ago, garwel said:
Personally, I never felt the need to return a value from a script (and I could do it with global variables anyway).
I also encounter the same problem as @JebIsDeadBaby: RCS keeps firing for too long, and the ship "swings" back and forth for a long time. In one case, when my vessel's CoM was a bit off, it used all the monopropellant (which was supposed to be enough for a long journey) and still failed to orient itself correctly. I also use MandatoryRCS, and KSP is 1.11.
Reading through the MandatoryRCS code on github, it appears that its nerfing of reaction wheels is done in a way that is problematic for other mods that also have an OnFlyByWire() pass like kOS.
I say this because the order of events seems to be this:
1 - In its Update(), kOS queries the sum of all torque capability provided by all parts (RCS, reaction wheel, engine gimbal, etc).
2 - In its OnFlyByWire(), kOS uses that value to choose how it should set the pitch/yaw/roll controls.
3 - In its OnFlyByWire(), MandatoryRCS nerfs the reaction wheel capability now that it's too late for kOS to see the change.
4 - Now the stock game physically affects the ship by applying the pitch/yaw/roll controls that kOS assigned in step 3 above.
5 - Now the stock game resets the reaction wheels' torque back to stock values for the next pass.
6 - Back to step 1.
This order of events makes the nerfing that MandatoryRCS does be invisible to kOS, since that nerfing only exists temporarily in between kOS's passes. By the time kOS queries the values again next pass, they're back to their stock settings again, and won't get re-nerfed until after kOS's OnFlyByWire() control settings have been locked in.
It might be possible to work around this by having kOS move its torque capability query to its OnFlyByWire() instead of its Update(), and also continually check the Delegate dispatch chain order of OnFlyByWire()s and if kOS's hook comes before MandatoryRCS's hook, have kOS move it's hook to the end of the chain to guarantee it lets MandatoryRCS go first (swapping the order of step (2) and step (3) in my above description.) But that's a weird ad-hoc fix to a problem I'm not really sure is kOS's fault.
At any rate, you can do as @JebIsDeadBabysuggested above, which tells kOS "pretend the torque is only 10% as powerful as it claims to be, and act accordingly". This is not an ideal solution (because it globally nerfs the measure of the SUM of all sources of torque, including RCS thrusters, rather than just nerfing the reading from the parts with the problem, which are the reaction wheels). -
18 hours ago, stephm said:
hi !
Installing this version to test, i use kOSPropMonitor. currently playing KSP 1.10.1
And there a bug in rasterprop mfd it's impossible to write something.
i have this error :
Posted issue with log file on github and here kOSPropMonitor , i 'm not sure if @dsonbill updates is mod yet...
steph.
I can give you access to a compiled kOS.DLL to test with to see if it fixes the problem. Send me a DM and I'll send it your way. If you report it fixes it I'll get the change into the next release.
The issue is that kOS added an additional parameter to a method that kOSPropMonitor is trying to call, and although kOS did make sure the additional parameter is optional with a default defined for backward compatibility, in C# that still requires a recompile of anyone calling it because of how default parameters in C# work. The experiment to see if it fixes it is that instead of one method with optional args, I now have two methods, one with and one without the optional arg. The code isn't really that different, but it changes things so that it should still work when combined with an older obsolete DLL trying to call it the old way.
-
@JonnyOThan - I have a user giving a github issue on kOS that I think you might be better qualified to answer, as it's about kOSPropMonitor, which I know nothing about:
https://github.com/KSP-KOS/KOS/issues/2861 -
19 minutes ago, Dunbaratu said:
I tried that and it literally had no effect. I also threw in setting bypassEffects to true and also ignoreListenerVolume to see if they made any difference and they don't either. The sound is still a lot quieter in vacuum than it is in atmosphere.
Never mind. It did work. I just was running the wrong version of my dll. (forgot I had it set to compile in Release mode not Debug mode, so I was copying the wrong DLL file.)
Thanks for the info.
-
10 hours ago, ensou04 said:
I'm currently working on a blacklist system for sound sources so other people don't have to change their mod but: What you could do is to make sure that your audiosources has "bypassListenerEffects" set to true so that it ignores all the effects from RSE. The blacklist system I'm going to implement pretty much behaves in the same way.
I tried that and it literally had no effect. I also threw in setting bypassEffects to true and also ignoreListenerVolume to see if they made any difference and they don't either. The sound is still a lot quieter in vacuum than it is in atmosphere.
-
10 minutes ago, Dunbaratu said:
give me about 10 minutes and I'll send you an invite.
Addendum - I can't DM you on Discord easily since I had no prev contact with you and you aren't in any servers I'm in. Instead I sent you the Discord link as a direct message here on the Kerbal Forums. Go check your user page to see it.
-
2 minutes ago, JebIsDeadBaby said:
Well, we can try. I've found an old webcam, so I have a mic, a bit crappy though. Still have to figure out how to stream. I think I know how start a stream but not how to see what is streaming.
give me about 10 minutes and I'll send you an invite.
-
1 minute ago, JebIsDeadBaby said:
Dunno, can you stream via website or do I have to install it (I'm on web Discord as JebIsDeadBaby#5004 right now)? Also I do not have a microphone attached to the PC, which may be a problem. Never streamed anything via Discord.
I'm not sure. Discord has some differences between the web client and the desktop client.
-
22 hours ago, JebIsDeadBaby said:
I'm u/Angel0a, since yesterday I use the patch you've just released. Can it be this patch introduced this (I don't recall having this problem before the patch frankly, although I finished only one flight in my campaign before I approached you with the bug on Reddit, so I might just missed it )? Anyway, my ship uses a few mods, I may test it on some simpler design tomorrow (it's close to midnight where I am).
EDIT: OK, I checked it. Mk1 + FL-R25 tank + CX4181 + 4x RV-105 RCS on the waist, so I guess all stock parts but I use Restock models (shouldn't matter I guess).
Important mods:
Real Fuels with RealFuels-Stock engine configs. RCS set to Hydrazine.
Mandatory RCS. I disable reaction wheels with this mod, but with reaction wheels enabled it's just as bad.
With *torquefactors set to default 1 this ship spins like crazy. When I set them to 0.1 it quickly orients itself correctly.
I'm having a hard time recreating what you're talking about here. I put Realfuels-stock and Mandatory RCS on, and while it puffs a bit much (because the stock RV-105 RCS blocks are a bit overpowered for such a small ship as in your example description), it doesn't look nearly as bad as what you're describing, and it settles in pretty quickly.
Also, I don't even have an option to adjust the reaction wheels in the Mk1 pod because there aren't any there. With these two mods installed it seems to remove ModuleReactionWheel from the MK1 pod entirely, so "with reaction wheels enabled" isn't even an option for me.
Do you have the capacity to use discord and broadcast your gameplay on it? I may have to witness what you're talking about with my own eyes to see what you're getting. I'm having a hard time re-creating it.
-
36 minutes ago, JebIsDeadBaby said:
I'm u/Angel0a, since yesterday I use the patch you've just released. Can it be this patch introduced this (I don't recall having this problem before the patch frankly, although I finished only one flight in my campaign before I approached you with the bug on Reddit, so I might just missed it )? Anyway, my ship uses a few mods, I may test it on some simpler design tomorrow (it's close to midnight where I am).
EDIT: OK, I checked it. Mk1 + FL-R25 tank + CX4181 + 4x RV-105 RCS on the waist, so I guess all stock parts but I use Restock models (shouldn't matter I guess).
Important mods:
Real Fuels with RealFuels-Stock engine configs. RCS set to Hydrazine.
Mandatory RCS. I disable reaction wheels with this mod, but with reaction wheels enabled it's just as bad.
With *torquefactors set to default 1 this ship spins like crazy. When I set them to 0.1 it quickly orients itself correctly.
My strong suspicion is Mandatory RCS is the culprit, but I'll be checking tomorrow to be sure and seeing if there's anything I can do about it.
The change in kOS that might be responsible is this:
This standard API call provided by KSP here was utterly broken and has been for years: https://kerbalspaceprogram.com/api/interface_i_torque_provider.html
The value returned by KSP in that method in the case of RCS modules is totally random nonsense and some modders have known this for a while but I didn't. But kOS was depending on that information to tune the steering, and that's why kOS steering was bad before. kOS v1.3.0.0 contained a replacement for that answer in the case of RCS modules, manually calculating it properly and ignoring what stock KSP says, with some suggestions borrowed from other mods about how to make homemade replacement code for it.
So there's a chance that the nerfing that MandatoryRCS is doing isn't being "seen" by kOS's homemade replacment for the broken stock GetPotentialTorque method. -
Minor patch update available:
v1.3.2.0: https://github.com/KSP-KOS/KOS/releases/tag/v1.3.2.0
A quick patch to v1.3.0.0 that fixes issue #2857 that would
zero controls for just a brief single physics frame if
raw control neutralize had been previously used or if a
reboot had occurred while raw controls were in use. Most
players won't notice a single physics frame of zeroed
controls, but if you're using realism mods with limited
engine ignitions, it would unfairly consume an engine
ignition when the throttle zeroed for an instant. (Which
was a disaster if the engine only gets to have one
ignition.)Normally one bug fix wouldn't warrant a release, but this
bug was caused by changes in v1.3.0.0, and the consumed
ignition was unfair.--- The following are DIFFERENT topics, but the KSP forums contain the silly misfeature of merging comments together unless I wait a really long time between them, and I don't know how to make it stop doing that. ---
-----------------------------------------------------------------------
1 hour ago, garwel said:As a big fan of kOS, I try to automate nearly everything in my vessels. But there is one little thing that keeps bothering me: exiting the program. I still can't find a simple way to tell kOS to stop the script. RETURN doesn't seem to do the trick, for example. So I have to either write long IF statements or keep temporary variables to check in the main loop.
So if I can make a feature request, I want to ask for a command that stops executing the current script.
Oh, and I have a question. What is the "Script Trigger" action in the Editor for kOS parts? I think it's new, but I didn't find anything in the changelog.
As far as an exit - yeah I know. It got stuck in limbo because I kept waffling on whether or not programs should have exit codes. But it should be dealt with.
As for "Script Trigger" - can you explain what you mean? That exact string appears nowhere in the kOS C# codebase. There was an action added called "Suppress" that you can assign to action groups, if that's what you mean. (It lets you activate the same thing as clicking the new button "suppress autopilot" in the kOS control panel, but with an action group so it's just a keypress away if you want it fast without clicking around.)
11 hours ago, JebIsDeadBaby said:The latest version seems to waaay overestimate available RCS torque. Steering manager keeps RCS firing until the desired angle is achieved, obviously overshoots, which results in an infinite loop of corrections. Reducing torque factors to 0.1 solves the problem for me.
Can you share your craft file (and mention any mods that it requires, if it does)? Almost everyone else has said the new steering is a massive improvement over the old, or at least a neutral lack of difference. You're the first to say it's worse. I'd like to see exactly what's going on, to see if it's design-dependent.
-
42 minutes ago, MacLuky said:
Small question: my lock throttle is lost after a stage.
PRINT "=========================================". PRINT " STRATOS B7". PRINT "=========================================". PRINT "Waiting for ship to unpack.". WAIT UNTIL ship:unpacked. PRINT "Ship is now unpacked.". PRINT "Locking throttle". SET throt TO 1.0. LOCK throttle TO throt. //set ship:control:pilotmainthrottle to 1. PRINT "Starting countdown:". FROM {local countdown is 5.} UNTIL countdown = 0 STEP {SET countdown to countdown - 1.} DO { PRINT "..." + countdown. WAIT 1. // pauses the script here for 1 second. } // Go PRINT "Igniting booster". STAGE. WAIT 2.9. PRINT "Igniting rocket". STAGE. WAIT 80. PRINT "Decoupling payload". STAGE.I had LOCK throttle TO 1 before made no difference. Throttle goes up but as soon as the booster gets ignited the throttle goes down. I maintain radio connection with the rocket and can use the terminal. It runs the rest of the program, but even if i repeat the statement its not pushing up the slider.
Running kOS 1:1.2.1.0 installed through CKAN on a 1.8.1 RSS/RO/RP-1 install.
Update: adding
SET ship:control:pilotmainthrottle to 1.did not resolve the issue.
Not enough information to tell, but if it's RP-1 is there a chance the decoupling makes you lose an avionics part and now you are over the avionics limit and so it's refusing to obey controls?
[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System
in KSP1 Mod Releases
Posted
Well, it sort of does... but ... the reference frame SHIP:RAW that all the velocities are returned in is the reference frame the main game uses, which is centered around the active vessel's current Sphere of Influence body.
In other words, if you are currently orbiting Kerbin, then you are getting Kerbin's velocity relative to itself, which is why it's zero.
If you want its velocity relative to the Sun, you can just not care what's the reference frame it's using and just explicitly subtract one velocity vector from the other, like so: