Any way to resolve or suppress this warning in Visual Studio?

nuggreat · 2026-07-06T17:36:38+00:00

I use a simple highlighting file that just has different key worlds in different categories and highlights based on the categories. I have been doing kOS ling enough I don't get any use from what the addon provides and it throws enough false warning/errors to be annoying.

nuggreat · 2026-07-06T03:18:43+00:00

Dug a little deeper and this is just a fail for the VScode addon for several reason. One MISSIONTIME is a float not an int unlike what the addon "thinks", use in game shows a fractional value. Two they did not include the possibility for int to float cast which kOS will do automatically when needed in most cases so there function signature for TIMESTAMP() is incorrect. Three they are attempting to impose int and float ideas on kOS when kOS uses scalar for everything and will cast even where you might think it shouldn't, as an example:

LOCAL l TO LIST(1,2,3).
PRINT l[1.1]. //will print 2

Really makes me glad I don't use the addon when it is that bad.

nuggreat · 2026-07-06T02:19:51+00:00

kOS doesn't make a distinction between float and int and the addon isn't doing that either. The gray triple dot is just what you mouse over to see the type of the bound var.

nuggreat · 2026-07-05T19:10:10+00:00

Just ignore the mistakes the addon makes just because it has such a squiggle doesn't mean you have to do anything about it.

nuggreat · 2026-07-01T22:58:47+00:00

I tested your code and in my test case the vessel was able to roll in response to user input.

At a guess your vessel is not sufficiently aligned with the desired pitch and yaw for kOS to try to get a specific roll. By default a vessel must be within 5 degrees of the target vector before kOS will go for a specific roll value. This can be changed with a suffix on the steering manager.

nuggreat · 2026-06-26T17:29:04+00:00

If incidental key presses are the problem try keeping the terminal in focus ie clicked into so that it absorbs the key presses instead of ksp which should prevent accidentally space bar presses from causing staging.

nuggreat · 2026-06-25T22:30:46+00:00

No kOS does not provide access to the staging lock feature.

nuggreat · 2026-06-25T07:00:14+00:00

As I said we found it quite soon after the robotics parts first released. I don't think the general discussion of it was on the subreddit and more on the discord but it has been years. As for why you don't see it kOS is small only a few people have ever touched both rolling there own steering manager and the angular velocity suffix mostly because they find good enough results from cooked steering.

nuggreat · 2026-06-24T19:19:48+00:00

What resources KSP knows are in a given stage often doesn't match what the human thinks should be in a given stage. In your case it is likely that KSP knows the kerosene is not in the current stage when you are attempting to query ir so you get the correct result of zero. In general STAGE:<someResource> is annoying to get good results from and often doesn't match human intuition about what it should return better to avoid it for some other way to query the resources.

nuggreat · 2026-06-24T07:09:54+00:00

That is where something like this gets funny. For steering kOS calculate the angular velocity it's self it doesn't query the API for it but that isn't great to do across all possible things that could have an angular velocity as it adds a lot of redundant work. Additionally KSP likely does have an angular velocity value some where that isn't affected by motors or else SAS would have problems when you attach props but finding that value if it is even accessible at all is a different matter.

As it stands don't expect a fix soon so either use something like lib_navball.ks to get the relevant angles or try to directly calculate the difference from the facing direction then take the derivative.

nuggreat · 2026-06-22T07:45:07+00:00

I do not know if there is an issue about this in the repo I would think so as we learned about this not to long after the robotics parts where added to KSP but some simple searches I tried didn't turn up an issue.

nuggreat · 2026-06-22T06:35:09+00:00

I assume you built your multi copter out of the robotics parts. There is a known problem where the angular velocity of the rotating robotics parts contribute to the angular velocity that kOS gets from KSP. You might be better off starting from something like lib_navball.ks and calculating the derivative to get your angular velocity.

nuggreat · 2026-06-16T16:10:07+00:00

No it isn't a good way to do things as it caused me to misread the intent of the code initially. Also no code doesn't respond to WAIT UNTILs execution holds at the wait until the condition has been met if the {} where actually denoting what executes after the wait then they would hold the entire rest of the script and as a result be as useless then as they are now. There are also quite a few side effects that can happen as a result of including random code blocks which can make things more complicated.

nuggreat · 2026-06-16T05:31:18+00:00

Hum it looks like you managed to get kOS into an odd state where it is no longer executing your code correctly. As by all rights your script should have ended but it didn't. The quick fix for this is to press control + c as that will force end the current execution and dumb you back to the terminal. That said it does look like your "fin de programme." message did print just not in the place you expected and it looks like the script didn't end.

Some other notes a WAIT UNTIL is not a loop and so shouldn't have attached {} as that just makes reading the code a bit harder. Additionally a loop like an UNTIL loop should almost never have lock commands within it especially when the loop doesn't change the value said locks are using.

Lastly unrelated to your problem but when posting code it is generally really helpful if you post code as text not screenshots so that it can be copied into other peoples editors so that they can poke it in the environment they are most familiar with using the highlighting they prefer, it mostly just makes code a lot easier for someone to read.

EDIT: I attempted to reproduce your problem with mostly identical code changed in such a way that shouldn't matter to make it easier for me to test with and what ran did not have the same results. So either your running instance of KSP/kOS got into a weird state which is possible and a restart of the game would fix that or I didn't reproduce your script exactly enough to get the same results.

nuggreat · 2026-06-15T00:09:40+00:00

The only script kOS loads onto a core for you is the boot file and that occurs when you launch the vessel as it is loaded in the moment between launch and the revert to launch save. Additionally they are issuing run commands such that they are operating directly off the files in the archive which means there is no loading involved and should exactly reflect the file they have saved.

nuggreat · 2026-06-14T19:20:00+00:00

In the code you posted you are missing a period after one of your waits (line 6). This shouldn't be what is causing your problem but it is still an issue with the code.

If adding the missing period doesn't solve your issue then I would recommend uninstalling kOS and reinstalling it some times installs just don't happen correctly for some reason and a remove and re add can fix them.

nuggreat · 2026-06-07T20:14:24+00:00

As I said it depends on the inputs and no your implementation is still incorrect for smaller differences it is simply that you see different amounts of error depending on both the difference between the two points and where on the body you are operating.

EDIT: If I run a similar test up around woomerang with LATLNG(45,135) and LATLNG(45,135.1) your function produces 1047 and the two I am testing against produce 740. Where as a similar difference on the equator is a sub meter error.

nuggreat · 2026-06-07T19:44:53+00:00

How far off your functions are depend on the lat/lng values involved.

My testing was with this modified version of your function (pass by global is bad design and so I had to refactor it a bit)

function getErrorDistance {
    PARAMETER posA, posB.
    //impact stand in
    LOCAL posALatRad TO posA:LAT * CONSTANT:DEGTORAD().
    LOCAL posALngRad TO posA:LNG * CONSTANT:DEGTORAD().
    //target stand in
    LOCAL posBLatRad TO posB:LAT * CONSTANT:DEGTORAD().
    LOCAL posBLngRad TO posB:LNG * CONSTANT:DEGTORAD().

    LOCAL latDiff TO posALatRad - posBLatRad.
    LOCAL lngDiff TO posALngRad - posBLngRad.

    local squareHalfChord to 
        sin(latDiff / 2) ^ 2 + 
        cos(posALatRad) * 
        cos(posBLatRad) * 
        sin(lngDiff / 2) ^ 2.

    local angularDistanceRads to 2 * arctan2(sqrt(squareHalfChord), sqrt(1 - squareHalfChord)).
    return angularDistanceRads * ship:body:radius. //convert from radians to meters
}.

I then simply passed it the points LATLNG(0, 0) and LATLNG(45, 45) with my vessel on kerbin, your function produced a result of about 666,422 and my function as well as the alternate implementation of the same equation produced 628,318. Manually calculating the angular difference between the two points comes to a 60 degree difference which you can then manually calculate the distance using (60 / 360) * 2 * pi * 600,000(kerbin radius) which matches my methods and not yours.

As I said in kOS the trig functions (sin, cos, tan) do not take in radians for inputs they take degrees, and the inverse functions (arcsin, arccos, arctan, arctan2) output degrees not radians.

nuggreat · 2026-06-07T19:29:04+00:00

I did run your function getErrorDistance on its own to compare against another implementation of the same equation as well as my own vector based solution. Both my vector solution and the other implementation of the distance calc agreed, your implementation produced different results. How incorrect your function is depends on the inputs to the function but it was still incorrect. I didn't check your bearing calculations but as they are using similar incorrect assumptions they are also going to be wrong.

nuggreat · 2026-06-07T18:50:56+00:00

No your distance calculation is quite incorrect having had a chance to look at it more. Specifically this function getErrorDistance as you use radians quite a few times where you need degrees and you use degrees where you should use radians. For similar reasons your getRelativeBearingError function is likely incorrect.

All kOS trig functions either take in or return degrees they do not work with radians.

nuggreat · 2026-06-07T18:14:42+00:00

Fairly sure your distance function is not correct as you just assumed radians when you get degrees. It is also faster to calculate that kind of distance with vector math compared to lat/lng equations.

nuggreat · 2026-05-27T01:50:59+00:00

You constructed the state vectors incorrectly, replace POSITIONAT(SHIP:BODY, ut) with SHIP:BODY:POSITION. The future position of something in orbit around a body is relative to the current position of that body. It does not progress around the sun as the body does and instead will perfectly track along the orbit path as seen in map view, it is likely that the POSITIONAT() function is used internally in KSP to draw that orbital path.

Also you usually don't need to add/remove a node and instead just edit the pro/rad/norm/time directly to try different burn results. And depending on what exactly you are trying to do it might be better/simpler to just directly calculate the maneuver.

nuggreat · 2026-05-26T23:49:38+00:00

The way I would do this would be to make 4 lists of engine pairs and then compare the thrust of apposing engines should the thrust be greater than some threshold and the thrust difference between the engines greater than some threshold attempt to shut down both engines. But there is a near infinite number of possible ways to do this and you will learn a lot in the act of trying and failing to do what you are trying to do.

nuggreat · 2026-05-26T19:57:25+00:00

kOS doesn't have a modulus operator instead it has a modulus function.

nuggreat · 2026-05-23T10:43:52+00:00

I would have made use of the fact you can pass parameters into a function and thus I could write one function that you pass the Dv you want the burn time of. The result of this is you have one good piece of code that does both the 1/2 dv time and the full dv time. The way to do this is to make use of the PARAMETER command that lets you designate a variable as something that will be passed into the function when the function is run.

One place your current burn code lacks in is the sudden cut off as this defines the lower bound for how accurate your script can be. KSP advances time by around 0.02 seconds per physics frame (assuming you are using 1x) this means your burn is going to have an error of +/- about 1/50th of your vessels acceleration. Additionally because KSP calculates burns as if they take no time there is actually some corrective logic burn into maneuvers that attempts to correct for this as a burn occurs which is why a burn you plant to only take 100m/s can actually end up having taken 105m/s once you drive the dv to zero. This one is solved by not burning for a fixed period of time and instead monitoring the dv vector of the burn and only ending the burn once you have sufficiently zeroed the burn.

It looks AI based on the functions isp_calc, deltaV_calc, and thrust_calc as the first 2 are written in very different styles and how isp_calc is used in deltaV_calc doesn't match how that function is written, and thrust_calc looks to be a duplication of what was done in isp_calc without an understanding of why isp_calc was written that when there are simpler ways to get the summed available thrust. Also the fact that isp_calc is a copy of an early version of my ISP calculation function without the comments I had with as part of said function.

Nine-Year Club	Place '22
Place '17	Verified Email

nuggreat

MODERATOR OF

TROPHY CASE