Jump to content

[1.3] kOS Scriptable Autopilot System v1.1.3.0


erendrake

Recommended Posts

9 hours ago, Lookerksy said:

In next version, would you mind add part's temperature data (current temp & max temp) into right-mouse menu of the part?
Sometimes when my vessel flight at high speed, 
    my kOS program can't find any information to tell me how to do to avoid overheat explosion.

Thanks.

This has been requested, it's worth reading this: https://github.com/KSP-KOS/KOS/issues/1056

If you have a Github account, you could add a comment to that page.

Link to comment
Share on other sites

I just hit a hilarious bug. I'm controlling the throttle as such on my plane:

 

  lock throttle to targetThrottle.

  until false {

    ... (calculate v_desired^2 and v^2)

    set targetThrottle to max(min(targetThrottle * v_desired2 / v2, 1), 0).

  }

 
This is, of course, a horrible method: it oscillates ridiculously, particularly combined with the spool up/spool down time of a jet. I was about to hook it up to a PIDLoop to do better.
 
But then my thrust went to something that printed as zero. And then it got weird. My speed started increasing. I verified in-game that the thrust output was zero, and fuel flow was zero -- but my speed was increasing. At first it was slow, but then it crept up and up, my plane broke the sound barrier. This is a plane with a single juno as the power plant, and thrust is zero as per every display.
 
At that point, then the speed *really* increased -- until in a matter of less than a second it went from 500 m/s to 2386m/s. In that second there were structural failures, parts splashing down hard (at 9700m altitude?) and finally the cockpit overheated.
 
So clearly, setting the throttle to values very, very close to zero confuses KSP. Seems like a bug...
 
MowCoie.png
Edited by numerobis
Link to comment
Share on other sites

5 hours ago, numerobis said:
So clearly, setting the throttle to values very, very close to zero confuses KSP. Seems like a bug...

 

Have you got a scenario where this is reliably repeatable?  I tried making the problem happen from reading your description and I couldn't make it occur.

I tried making sure I had Juno engines, and I tried settings as small as 1E-15 up to 1.0.  I couldn't make it happen.  (Note, going smaller than 1E-15 is pointless because the value returned when you try that is just plain zero.)

I also tried scenarios where the throttle toggles from 1.0 to 0.0000000000001 back and forth very quickly (faster than 1 physics update), and I couldn't seem to trigger it that way either.   (Not that I'd expect it to make any difference that way, given that kOS will only pass your new throttle setting on to KSP once per physics update anyway no matter how often you change it in your code.)

 

Link to comment
Share on other sites

Replicable indeed. It takes a while though, from the saves I've got -- about 15 minutes of game time.

I have a quick save where the phantom force had just started; mainThrottle is about 1e-14, and I'm multiplying by about 0.97 at a frequency of about 10Hz ("wait 0.1"). I seem to need to be in 2x physics timewarp; at 1x it converges. Unfortunately, reloading the quick save doesn't reproduce the problem; you're back at needing to wait 15 minutes of game time.

I'm trying to simplify it...

Link to comment
Share on other sites

On 9/2/2016 at 3:31 PM, ColKlonk said:

Anybody else having a Cooked Control problem wrt engine gimbals ? (RSS/Realism Overhaul mods)

On KSP v105 the engine gimbals work OK.

With KSP113, with the 'same' KOS program.. the gimbals don't work with any Locked steering..etcEdt:

[... snip ...]

Adding to this.. how many straight assignment locks could one execute per physics tic.

[... snip ...]

Could you please explain what you mean by "the gimbals don't work"?  Do you mean that the gimbal behaves as if it is always locked, with no deflection of the exhaust trails?  Or do you mean that kOS doesn't seem to take gimbal into account properly?  All that kOS does is ask each engine for it's potential torque (which internally the engine checks the gimbal) and then it sets the control state, as if you had manually affected the controls.  RSS/RO dramatically change some of the physics characteristics of the game, so it's possible that they have changed something so that kOS doesn't get the proper information.  But as long as they implement `ITorqueProvider` properly and don't change the flight control interaction we should have no problem interacting with those controls.  The torque provider method was new with KSP 1.1, so it is possible that it is the root of issues.  It is also possible that kOS is actually interacting with the gimbal just fine, it simply does not appear so because the response is small.  I would need more information to know what is going on, preferably a video showing your observed behavior.

All code in kOS, including steering locks, is limited by the `config:ipu` setting.  If your steering logic takes more than 2000 instructions it will run into the next tick before actually setting the value.  If you have multiple triggers that add up to more than 2000 instructions, it will run into the next tick.  The VM is configured to always run at least one main line instruction before returning to the beginning of the trigger code.  So it is very possible to observe windows where the value is not updated.  That being said, the internal steering code is not disabled for those "gap" ticks.  The steering manager logic will continue to steer towards the last value set until it is changed.  So as long as you aren't for some reason making very large changes in steering between ticks the delay will be legligable.  My best recommendation is to use a single function for the lock, and cache all of the values read from KSP at the beginning of the function.  That way you can try to ensure that all of your math is based on information from the same tick, even if that tick is no longer the current tick.  If it is off by one or two ticks, the error should remain small.  I also suggest simplifying the code as much as possible.  Calling a function takes multiple instructions (it has to push the parameters, and then call the function, and then actually execute the logic of the function) so encapsulating the steering logic itself into a single function will simplify code.  Using locks in place of functions can help, but it introduces a complication because you may be evaluating two separate locks that rely on the same data.  And calling cascading suffixes increases the instruction count (every call to a suffix has to push the suffix name, and then get the value).  My general rule of thumb is that any value that you need to access more than once will probably save time stored in a local variable.

Link to comment
Share on other sites

7 minutes ago, numerobis said:

Replicable indeed. It takes a while though, from the saves I've got -- about 15 minutes of game time.

I have a quick save where the phantom force had just started; mainThrottle is about 1e-14, and I'm multiplying by about 0.97 at a frequency of about 10Hz ("wait 0.1"). I seem to need to be in 2x physics timewarp; at 1x it converges. Unfortunately, reloading the quick save doesn't reproduce the problem; you're back at needing to wait 15 minutes of game time.

I'm trying to simplify it...

If it is not reproducible outside of physics warp, this sounds like a potential issue in the underlying KSP code.  Physics warp is notorious for having unexpected issues.

When you say it takes 15 minutes to show up, does that mean you start the 15 minutes at 1e-14, or do you start higher than that?  Without physics warp, do you run into issues between 30 and 45 minutes in?

Link to comment
Share on other sites

Indeed, I see nothing in your code that should cause this. You set the mainThrottle like any normal autopilot would, to a value that makes sense (after 300 ticks it should still be a normalized number, about 10^-15). And when I load from a save where the speed is such that I should hit this bug if it were your fault, I don't hit the bug. Must be something deeper.

Link to comment
Share on other sites

Hello.

Is there a way I could add a syntax check on Gedit or any GUI text editor in Linux? I have found several text editor with syntax highlighting but none compatible with a Linux distro so far, or no longer maintained. Also, is there someone who has modified the kOS terminal look? I think it needs a update in that sense. Why not use the same presentation as the game use, or like Mechjeb uses?

Link to comment
Share on other sites

23 minutes ago, Benoit Hage said:

Is there a way I could add a syntax check on Gedit or any GUI text editor in Linux?

Why GUI? There are extensions for nano and vim here.
Kode seems to work okay too, if you don't mind wine and un-dosifying the scripts.
Notepad++ also works in wine, and there's xml configs for KOS.
 

Edited by steve_v
Notepad++ works too.
Link to comment
Share on other sites

1 hour ago, Benoit Hage said:

Hello.

Is there a way I could add a syntax check on Gedit or any GUI text editor in Linux? I have found several text editor with syntax highlighting but none compatible with a Linux distro so far, or no longer maintained. Also, is there someone who has modified the kOS terminal look? I think it needs a update in that sense. Why not use the same presentation as the game use, or like Mechjeb uses?

Another option is Atom which also has a syntax highlight package for kOS.

Link to comment
Share on other sites

1 hour ago, Benoit Hage said:

Also, is there someone who has modified the kOS terminal look? I think it needs a update in that sense. Why not use the same presentation as the game use, or like Mechjeb uses?

To the best of my knowledge, no.

Also, it is unbelievably painful to use a terminal with a non-monospace font. It also breaks custom user inputs and displays.

Link to comment
Share on other sites

I am still trying to wrap my head around the reference frames in the game. so I don't even know if this is possible, but is there a way to like rotate two vectors so that one of there axis's points up. I am trying to get the distance between two parts as if they were 2d and you were looking at them from the top-down.

Edited by leviathan01
Link to comment
Share on other sites

is there any way of figuring out a craft's altitude apart from using that mod that adds laser distance sensors?

 

EDIT: nevermind, it's just been moved to the orbitable page in the documentation.

EDIT2: is there a way to get altitude above the ground though?

Edited by blub01
Link to comment
Share on other sites

LIST PARTS IN hoverEngines.
SET hoverEngines TO SHIP:PARTSTAGGED("hoverengine").


DECLARE refLimiter TO hoverEngines:PARTS:ENGINES:THRUSTLIMIT.

 

This is not working for some reason, anybody got an idea why?

EDIT: figured out how the whole suffix thing works.

UNTIL count > hoverEngines:LENGTH {
     thrustLim:ADD((tVel/10 + 9.81) * shipMass / (hoverEngines[count]:MAXTHRUST * refLimit[count])).
     SET count TO count + 1.
}

this says it return infinite for some reason though. the only way that would be possible is for hoverEngines[count]:MAXTHRUST * refLimit[count] to be 0 I believe, and it definitely isn't (maximum thrust should be 120kn or so, refLimit 100).

EDIT: should've probably the initial thrust limiter I read this from.. oops.

oh, and is there a way to check for any random key being pressed?

Edited by blub01
Link to comment
Share on other sites

I made a script that will adjust the thrust limiters of any engines with the tag "vtol" to balance the center of thrust under the center of mass. there by making a unstable craft, relatively stable.

https://github.com/leviathan01/KOS-vtol.git

this is just the first version, next I am going to make it work while in fight.

Link to comment
Share on other sites

I've just started playing with kOS - kudos on a huge undertaking.

Naturally the first thing I want to do is one of the things you cannot do - I just wanted to check if there is a better work around than the one I imagine.

I have made some maneuver node manipulation functions that I'd like be able to run from the terminal; e.g. deltaNodes( 200, 0, 0, 10 ) to eta+200 & p+10 all the nodes. It's to help do mission planning with low thrust vehicles; normally to get to the Mun you can drop a node and drag it around until it encounters the Mun - for a low thrust craft you might have 5 Pe Kicks that all need to be moved in synchrony. Being able to type commands from the terminal to interactively fiddle with the nodes would be great.

It looks like I'd need to make some NodeFunction.ks files and then run it from NodeCommand.ks. Then I'd use NodeCommand.ks as 'the terminal' - editing the file and typing 'run NodeCommand.ks' in the terminal.

Is there a better way to get the effect I want?

Link to comment
Share on other sites

3 minutes ago, DBowman said:

I've just started playing with kOS - kudos on a huge undertaking.

Naturally the first thing I want to do is one of the things you cannot do - I just wanted to check if there is a better work around than the one I imagine.

I have made some maneuver node manipulation functions that I'd like be able to run from the terminal; e.g. deltaNodes( 200, 0, 0, 10 ) to eta+200 & p+10 all the nodes. It's to help do mission planning with low thrust vehicles; normally to get to the Mun you can drop a node and drag it around until it encounters the Mun - for a low thrust craft you might have 5 Pe Kicks that all need to be moved in synchrony. Being able to type commands from the terminal to interactively fiddle with the nodes would be great.

It looks like I'd need to make some NodeFunction.ks files and then run it from NodeCommand.ks. Then I'd use NodeCommand.ks as 'the terminal' - editing the file and typing 'run NodeCommand.ks' in the terminal.

Is there a better way to get the effect I want?

idk about a kOS solution, but there are quite  a few mods out there that provide exactly what you want to do - mechjeb, for example, and I saw a mod that does only the finetuning of nodes a while ago on CKAN.

Link to comment
Share on other sites

@blub01 I use MechJeb quite a bit I don't think it can help with handling multiple nodes at once - I'll look again though because I am still finding 'new to me' things (e.g. in the maneuver planner recently). Were you thinking of Precise Node? I've not used that but it looks to include better time editing than MechJeb - but still not multiple node editing.

I also want to probably add things like 'split a node'; e.g. split Pe kickable part off from the rest, then split the rest into chunks, tweak magnitude and have the code translate that to a tweak of the components, specify the UT of the burn. Probably other stuff will come up as I start using it. Undo, Save As - so you can try a few different ideas and go back to the best one.

Link to comment
Share on other sites

6 hours ago, DBowman said:

I've just started playing with kOS - kudos on a huge undertaking.

Naturally the first thing I want to do is one of the things you cannot do - I just wanted to check if there is a better work around than the one I imagine.

I have made some maneuver node manipulation functions that I'd like be able to run from the terminal; e.g. deltaNodes( 200, 0, 0, 10 ) to eta+200 & p+10 all the nodes. It's to help do mission planning with low thrust vehicles; normally to get to the Mun you can drop a node and drag it around until it encounters the Mun - for a low thrust craft you might have 5 Pe Kicks that all need to be moved in synchrony. Being able to type commands from the terminal to interactively fiddle with the nodes would be great.

It looks like I'd need to make some NodeFunction.ks files and then run it from NodeCommand.ks. Then I'd use NodeCommand.ks as 'the terminal' - editing the file and typing 'run NodeCommand.ks' in the terminal.

Is there a better way to get the effect I want?

Is the basic problem that you just can't call a function from the interpreter?  Yeah there's ... reasons for that (the quick and dirty version is that because global variables live on past the end of program death, that means functions would too if they were allowed to, and then there'd be no way to clear the functions left behind by programs you ran other than to NEVER wipe those programs from memory, ever, until a reboot.)

So yeah, you end up having to run the function from a wrapper program.  You can, however, pass parameters to a program too just like you can to a function (with a comma-separated list of args in parentheses).

 

Link to comment
Share on other sites

37 minutes ago, Steven Mading said:

You can, however, pass parameters to a program too

oh so I can say in the terminal:

run someCmd( 2, 200, 400)

where I have a someCmd.ks file in the Scripts directory? thats 'as good as calling functions' from the terminal use experience, it just makes extra files...

Edited by DBowman
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...