[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[kerboman25]

48 minutes ago, scimas said:

2 hours ago, ColKlonk2 said:

You might have not set time acceleration correctly ?

If you don't set 'Physics' mode, AFAIK you have no control.

What you have said is true, but OP never said anything about time warping.

6 hours ago, kerboman25 said:

After the separation the craft begins to tumble because the craft is not controlled anymore.

Even if time warp was involved, the craft wouldn't tumble if the mode wasn't PHYSICS, or a mod like PersistentRotation isn't installed.

there is no call for time acceleration anywhere in my program so the problem is not comming from that side. though there is crosfeed enabled might the problem be related to that?

Edited January 24, 2018 by kerboman25

[ElWanderer]

On 23/01/2018 at 10:35 AM, kerboman25 said:

i'm almost certain that it has something to do with the decoupling clamp on the side because i tested the program on a craft that does not use this and it works fine.

Is the craft that worked identical other than the type of decoupler, or are there other differences?

Does KSP remain focused on the shuttle when you stage/decouple, or does it follow the external tank instead?

Does your shuttle have a connection, control and the ability to steer once staged?

What versions of KSP and kOS are you running? I'm aware there have been problems in the past with the kOS steering manager going into a bad state when vessels are created and destroyed, particularly with craft docking and undocking.

As you can probably tell, I'm just throwing out things to check/investigate.

[kerboman25]

18 minutes ago, ElWanderer said:

Is the craft that worked identical other than the type of decoupler, or are there other differences?

Does KSP remain focused on the shuttle when you stage/decouple, or does it follow the external tank instead?

Does your shuttle have a connection, control and the ability to steer once staged?

What versions of KSP and kOS are you running? I'm aware there have been problems in the past with the kOS steering manager going into a bad state when vessels are created and destroyed, particularly with craft docking and undocking.

As you can probably tell, I'm just throwing out things to check/investigate.

-The craft that it worked on was just a regular rocket without anything attached on the side.

-Yes the craft stays focused on the shuttle itself and not on the booster.

-Yes the shuttle is able to connect to a geostationairy satelite constelation and is manned so it should work always thoug?

-running 1.2.1 and compatible 1.3.1 KOS version (via CKAN)

- i can even tell you that the code is still running when decoupled but it's not steering the shuttle anymore.

if you want i can give you the full code but im certain that it's not the code to blame.

 

Edited January 24, 2018 by kerboman25

[Dunbaratu]

18 minutes ago, kerboman25 said:

-running 1.2.1 and compatible 1.3.1 KOS version (via CKAN)

Running 1.2.1 of KSP and 1.3.1 of kOS?  That doesn't make sense.  kOS 1.3.1 isn't compatible with KSP 1.2.1.

Can you give the *exact* version numbers of both kOS and KSP?

If CKAN is claiming kOS 1.3.1 works with KSP 1.2.1, then the CKAN information may be wrong.

 

Edited January 24, 2018 by Steven Mading

[kerboman25]

1 minute ago, Steven Mading said:

Running 1.2.1 of KSP and 1.3.1 of kOS?  That doesn't make sense.  kOS 1.3.1 isn't compatible with KSP 1.2.1.

Can you give the *exact* version numbers of both kOS and KSP?

oh i didn't know that sorry. running ksp 1.2.2 ank kos 1.1.3.1

so i wil have to search the internet for the older version

[Dunbaratu]

1 minute ago, kerboman25 said:

oh i didn't know that sorry. running ksp 1.2.2 ank kos 1.1.3.1

so i wil have to search the internet for the older version

No that is fine.

Your original post said 1.3.1 of kOS.  That's not the same as 1.1.3.1 which you say now.  1.1.3.1 *IS* compatible with KSP 1.2.2 (but not necessarily KSP 1.2.1 like you originally said).

Those little numbers *matter*.  A lot.  When posting problems be sure to get them written exactly as you see them - and that's advice for reporting computer software issues in general, kOS or any other software.

The reason it mattered here is that I was looking through the record of changes trying to work out when some fixes to the staging system were made and whether you had them yet or not.

[kerboman25]

2 minutes ago, Steven Mading said:

No that is fine.

Your original post said 1.3.1 of kOS.  That's not the same as 1.1.3.1 which you say now.  1.1.3.1 *IS* compatible with KSP 1.2.2 (but not necessarily KSP 1.2.1 like you originally said).

okey thanks i was worried, didn't read the extra 1  wel i've tried the craft without the decoupler having fuel crossfeed enabled but it also didn't work.

[ColKlonk2]

1 hour ago, scimas said:

What you have said is true, but OP never said anything about time warping.

I know, just speculating the use of 'runmode = 4' which is outside 'Physics' mode parameters, offering options of ellimination.

OP was providing minimal info.

[ElWanderer]

11 hours ago, kerboman25 said:

The craft that it worked on was just a regular rocket without anything attached on the side.

I am speculating somewhat wildly on a small amount of information, for which I apologise in advance, but I'm just wondering if it's gone a bit weird due to staging off the root part.

i.e. Did you build your shuttle in the SPH then attach it to the stack in the VAB? If so, is the root part on the stack, not the shuttle? If so, does changing the root part to be the shuttle's cockpit do anything to avoid the issue?

Edit: the other question I meant to ask is whether you can control the shuttle manually after staging (both if you fly the whole ascent manually, and if you run kOS then kill the script post staging). That might help narrow down the cause as to whether it is KSP itself or kOS that is being weird.

Edited January 25, 2018 by ElWanderer

[scimas]

2 hours ago, ColKlonk2 said:

I know, just speculating the use of 'runmode = 4'

People usually use 'runmodes' to separate different functionalities of a script during a loop. For example, in my own general purpose script, runmodes 1 to 4 belong to various stages of launching and achieving orbit, and rumodes 5 to 9 belong to various stages of landing. 

[Abpilot]

hey guys im having trouble launching a Buran replica (non RSS) and i have tried everything and it flys like a madman on steroids is there anywhere i can find a NON rss buran script

[kerboman25]

13 hours ago, ElWanderer said:

i.e. Did you build your shuttle in the SPH then attach it to the stack in the VAB? If so, is the root part on the stack, not the shuttle? If so, does changing the root part to be the shuttle's cockpit do anything to avoid the issue?

Edit: the other question I meant to ask is whether you can control the shuttle manually after staging (both if you fly the whole ascent manually, and if you run kOS then kill the script post staging). That might help narrow down the cause as to whether it is KSP itself or kOS that is being weird.

- yes i build the shuttle in the SPH and attached it to the fuel tank in the VAB. The root part was always on the cocpit of the shuttle. I rerouted the root part to the tank to change it again to the cocpit to make sure it is routed correctly.

-after the decoupling i'm able to control the craft myself via SAS but that's not what i intend to do with the program. I want to make orbit without doing any inputs to the craft control.

[ElWanderer]

On 25/01/2018 at 11:14 AM, kerboman25 said:

- yes i build the shuttle in the SPH and attached it to the fuel tank in the VAB. The root part was always on the cocpit of the shuttle. I rerouted the root part to the tank to change it again to the cocpit to make sure it is routed correctly.

-after the decoupling i'm able to control the craft myself via SAS but that's not what i intend to do with the program. I want to make orbit without doing any inputs to the craft control.

I'm afraid I'm out of ideas of things to check/try. Oh, other than...

...did you know there has recently been a KSP v1.2.2-compatible release of the latest kOS (v1.1.5.1)? https://github.com/KSP-KOS/KOS/releases/tag/v1.1.5.1

[kerboman25]

22 hours ago, ElWanderer said:

I'm afraid I'm out of ideas of things to check/try. Oh, other than...

...did you know there has recently been a KSP v1.2.2-compatible release of the latest kOS (v1.1.5.1)? https://github.com/KSP-KOS/KOS/releases/tag/v1.1.5.1

i always try to get my mods via CKAN and i just noticed that there is an update available i wil be downloading it soon and trying it out.

i wil already thank you for the help you gave me

[ColKlonk2]

Mr Mading:-

Any chance of a Cubed Root function (or n'th root). I'll try an exponent X^(1/3), but not sure on how the speed compares between the two.  

[meyerweb]

3 minutes ago, ColKlonk2 said:

Any chance of a Cubed Root function (or n'th root). I'll try an exponent X^(1/3), but not sure on how the speed compares between the two.  

Oooh, if we’re taking feature requests here, I’d really love a TERRAINSLOPE to go with TERRAINHEIGHT in the GeoPosition structure.  I’m calculating slopes by sampling points and doing vector math, but a built-in would make the results more precise and landing scripts ever so much simpler.

[Dunbaratu]

12 hours ago, ColKlonk2 said:

Mr Mading:-

Any chance of a Cubed Root function (or n'th root). I'll try an exponent X^(1/3), but not sure on how the speed compares between the two.  

The underlying math libraries in C# have a square root but I'm not sure they have a cube root.  I looked and didn't find one.  sqrt() is indeed faster than ^(0.5) because there are some known shortcuts that algorithm can take, but I don't think the same effort has been done for cube root.  Sqrt() gets its own function because of how common it is.  But they can't do that for every power without it getting silly.

[Dunbaratu]

12 hours ago, meyerweb said:

Oooh, if we’re taking feature requests here, I’d really love a TERRAINSLOPE to go with TERRAINHEIGHT in the GeoPosition structure.  I’m calculating slopes by sampling points and doing vector math, but a built-in would make the results more precise and landing scripts ever so much simpler.

It's not that simple.  Under the hood, kOS is doing some fancy footwork to make TERRAINHEIGHT work because of the fact that the game doesn't load the actual physical (collider) polygons for the terrain until you are very close to it.  Most of the terrain you are looking at on the screen is a "hologram" so to speak - it has visual appearance but no physics interactions.  As you move across the terrain, the game populates the terrain colliders in front of you as you move, and despawns them as you leave them behind you.  Anything more than about 6 or 7 km away from you isn't "really there".  At least it isn't "really there" as far as the Unity's raycast call is concerned, and that's what matters here.

When you query for TERRAINHEIGHT of nearby terrain that is fully loaded, kOS just asks Unity for a raycast that will get the precise length of that ray from body center up to that one terrain polygon it hit.  It could query from Unity (but it doesn't) the normal of that polygon to get its slope.  This is a pinpoint accurate answer but it only works with nearby terrain that has its colliders loaded.

When the terrain is far away, kOS is using samples from the terrain generation formula KSP uses (and how that works is a mystery black box as far as kOS sees).  kOS asks KSP, "If I was about to populate some terrain polygons in which one vertex of the terrain was at this exact latlng, what coordinate should I use for that vertex?"  This idealized answer (which won't be 100% the same as what you will find when you get there and the game fills in its chunky polygon approximation of the ideal) is what it feeds back to your script if the terrain is too far away to "really exist". The terrain generation system doesn't tell us the slope - just the terrain height at the spot we asked for.  To get slope we have to ask for the height at several nearby spots and compare them.

In other words, kOS would just be doing the same exact thing your script is doing - sampling several nearby points and working out the slope from that.

Besides, in a 3D world, slope isn't just a scalar.  It's a vector pointing normal to the surface at that spot.

[Puggonaut]

I'd like to learn how to use this program . I have downloaded v1.1.5.0 for KSP 1.3.1 .

Apart from ModuleManager is there anything else i need to do prior to installing this in my GameData Folder ?

EDIT

So I have installed 1.15.0 into my GameData Folder

First thing I got with a new save was this ,

So I chose PermitAll ??

Looked on github for a simple tutorial and erm this happened

Any idea's what I am doing wrong here please ?

Edited February 10, 2018 by Puggonaut 2
Added more information

[ElWanderer]

28 minutes ago, Puggonaut said:

Any idea's what I am doing wrong here please ?

Looks like you missed the statement terminator off the end of the PRINT command (or in simpler words, stick a dot/period/. on the end).

[Puggonaut]

38 minutes ago, ElWanderer said:

Looks like you missed the statement terminator off the end of the PRINT command (or in simpler words, stick a dot/period/. on the end).

D'oh...........dammit just added the dot/period/. and it worked

Steep learning curve ahead for me then lol

Thanks for the reply .

Edited February 10, 2018 by Puggonaut 2

[RagnarDa]

Hi! What are SHIP:Q actually supposed to be?

I have ship that is at altitude 290 m travelling at 89m/s airspeed. The density should be around 1.18 according to the wiki. I've calculated the Q to 4737 using the formula 1.18* 0.5 * SHIP:AIRSPEED * SHIP:AIRSPEED and that makes sense to me. The SHIP:Q on the other hand is 0.04116 and SHIP:Q*constant:AtmToKpa is 4.1711. If I reverse the calculation the first Q would yield a density of 0.00104 and the second 1.03110E-05.

Is it bugged or am I missing something?

.

Btw, thanks for a awesome software I spent countless hours with.

[Pand5461]

@RagnarDa

Q is dynamic pressure measured in atmospheres.

To convert between the units, you need to know in what units you calculate everything. In your case, density of 1.18 is in kilograms per cubic meter, so 4737 is in (kg / m³) * (m² / s²) = pascals (Pa).

0.04116 is in atmospheres, 1 atmosphere is 101325 Pa or 101.325 kPa (1 kPa = 1000 Pa). So, the value you get from kOS is 4171.1 Pa, pretty consistent with 4737 Pa from your first estimate.

[RagnarDa]

Wow quick answer! That explains it! Glad both that it wasnt a bug and my estimate was also correct. Thanks!

[RagnarDa]

Btw, do you know how faithful KSP is to real-world aerodynamics? Things like this: https://www.grc.nasa.gov/www/k-12/airplane/flteqs.html

I am testing it a bit and having mixed results. Want to know if it is something I did, some simplifications I did or that KSP just doesnt follow those types of equations.