[1.3] kOS Scriptable Autopilot System v1.1.3.0

[hvacengi]

Announcement:

There have been 2 major breaking bugs reported for kOS-v0.19.0 (one regarding InfernalRobotics and another regarding renaming files).  We are looking at potentially making a quick maintenance release "tonight" (EST) March 4.  We are asking that any one who has found additional new major breaking bugs please try to make a github issue for them so that we can get them in to this release, instead of needing another rapid release in a couple of days.  Thanks!

[-ctn-]

The new HAL part seems to z-fight when surface attached. Anybody else have this issue?

[hvacengi]

I've been testing the KAL9000 part for well over a month at this point and haven't noticed anything that I would call z-fighting.  On some models where the collider is not flush with the texture I've seen the part hidden or partially obstructed by the texture.  Can you say what you mounted it to when you observed the z-fighting?  Do you observe it no matter what it is mounted to?

[-ctn-]

2 minutes ago, hvacengi said:

I've been testing the KAL9000 part for well over a month at this point and haven't noticed anything that I would call z-fighting.  On some models where the collider is not flush with the texture I've seen the part hidden or partially obstructed by the texture.  Can you say what you mounted it to when you observed the z-fighting?  Do you observe it no matter what it is mounted to?

sorry, wrong phrase. It does disappear into the part it's attached to. I tried to put it on the mk1-2 pod, the 1.25m and 2.5m fuel tanks and the octo probe core. Not a major deal, just slightly annoying. 

I typically use the stackable kOS parts anyway.

Edited March 4, 2016 by -ctn-

[hvacengi]

2 minutes ago, -ctn- said:

sorry, wrong phrase. It does disappear into the part it's attached to. I tried to put it on the mk1-2 pod, the 1.25m and 2.5m fuel tanks and the octo probe core. Not a major deal, just slightly annoying. 

Ah, in those instance we might be able to make some slight adjustments, but it's a pretty fine line when trying to surface mount a part that is as thin as the KAL9000.  That MK1-2 pod loves to eat parts, and the colliders on the 2.5m tanks tend to be funny too.  I'll mention it in our dev chat.

[BevoLJ]

Having a bit of trouble with my script since the update.  I have a when statement that runs my faring function.  It says it is taking to long to be done in a trigger. I have never had any issues with this when statement before so was hoping someone could take a look at my code and help me make it a bit faster.  I use this function for many other purposes, and trying to avoid adding faring specific code (not really much room left on my cpu) but do you think that is the only option?

Spoiler

FUNCTION Event_allparts { PARAMETER module,event. LOCAL Part_list is list(). LIST parts in Part_list. FOR p in Part_list {
    IF p:modules:contains(module) { LOCAL m is p:getmodule(module). m:doevent(event). }}}

WHEN alt:Radar > 30000 Then {Event_allparts("ProceduralFairingDecoupler","jettison").} 

 

[hvacengi]

8 minutes ago, BevoLJ said:

Having a bit of trouble with my script since the update.  I have a when statement that runs my faring function.  It says it is taking to long to be done in a trigger. I have never had any issues with this when statement before so was hoping someone could take a look at my code and help me make it a bit faster.  I use this function for many other purposes, and trying to avoid adding faring specific code (not really much room left on my cpu) but do you think that is the only option?

  Hide contents

FUNCTION Event_allparts { PARAMETER module,event. LOCAL Part_list is list(). LIST parts in Part_list. FOR p in Part_list {
    IF p:modules:contains(module) { LOCAL m is p:getmodule(module). m:doevent(event). }}}

WHEN alt:Radar > 30000 Then {Event_allparts("ProceduralFairingDecoupler","jettison").} 

 

Well the issue is you're essentially iterating over every single part in the vessel.  You're also creating the parts list in a verbose manor.  Here is my script for disarming parachutes:

function DisarmParachutes {
	local modList is ship:modulesnamed("ModuleParachute").
	for mod in modList {
		if mod:hasevent("Disarm") { mod:doevent("Disarm"). }
	}
}

You can modify that to use parameters if you would like:

function DoEvent {
    parameter module, event.
	local modList is ship:modulesnamed(module).
	for mod in modList {
		if mod:hasevent(event) { mod:doevent(event). }
	}
}

 

Edited March 4, 2016 by hvacengi

[BevoLJ]

Ah, I see. That makes a lot of sense.  Thanks! =)

 

Edit: Worked beautifully!

Edited March 4, 2016 by BevoLJ

[TJ179]

Hey, 

it is possible to calculate the True Anomaly, Mean Anomaly an Eccentricity Anomaly with kOS ? 

my goal is to wirte a program that can calculate the transfer window like http://forum.kerbalspaceprogram.com/index.php?/topic/84005-10x-transfer-window-planner-v1400-dec-3/.

 

i had tried a lot but nothing works right. One time i tried to copy the code from TransferWindowPlanner and convert it to kOS script. One other time i tried  to add kOS Code with some function like TrueAnomalyAtUT and so on...

 

can someone help me ?  

 

Sry for the very bad english 

[Dunbaratu]

 

3 hours ago, TJ179 said:

Hey, 

it is possible to calculate the True Anomaly, Mean Anomaly an Eccentricity Anomaly with kOS ? 

my goal is to wirte a program that can calculate the transfer window like http://forum.kerbalspaceprogram.com/index.php?/topic/84005-10x-transfer-window-planner-v1400-dec-3/.

 

i had tried a lot but nothing works right. One time i tried to copy the code from TransferWindowPlanner and convert it to kOS script. One other time i tried  to add kOS Code with some function like TrueAnomalyAtUT and so on...

 

can someone help me ?  

 

Sry for the very bad english 

Each moving object has an `:orbit` suffix with that kind of information on it.

 

For example: ship:orbit:trueanomaly.  There's more of them here:

http://ksp-kos.github.io/KOS_DOC/structures/orbits/orbit.html

The documentation 'search' bar works pretty well for stuff like this.  I jumped to this page literally by just typing 'true anomaly' into the search box on the upper left of the docs page.

 

[TJ179]

1 hour ago, Steven Mading said:

 

Each moving object has an `:orbit` suffix with that kind of information on it.

 

For example: ship:orbit:trueanomaly.  There's more of them here:

http://ksp-kos.github.io/KOS_DOC/structures/orbits/orbit.html

The documentation 'search' bar works pretty well for stuff like this.  I jumped to this page literally by just typing 'true anomaly' into the search box on the upper left of the docs page.

 

I knows that but i cant calculate the trueanomaly at a Time in the future... like orbit:trueanomaly(10 days in the future) 

 

Thats my Problem. 

[Riderfighter]

23 hours ago, Dr_Goddard said:

Looks about right

 

Lights and landing gear sometimes exhibit a bit of a glitch in my experience with a very slow computer. Sometimes they have to be activated twice to come on the first time.

 

Ok cool just wondering is that like an actual sensor by any chance?

[Dunbaratu]

1 hour ago, TJ179 said:

I knows that but i cant calculate the trueanomaly at a Time in the future... like orbit:trueanomaly(10 days in the future) 

 

Thats my Problem. 

Oh, THAT.

Predicting *how long* it takes to get to a particular point (which is really the same thing as predicting what point you will be at at a given time, just in the inverse) is a mathematically famously messy thing.

(NOTE: It's not messy for a perfectly circular orbit.  It only becomes messy when dealing with an orbit that has some eccentricity to it.)

It's one of those cases where intuition is telling you it *should* be a simple formula but it just isn't.  It's one of those that requires using a numerical approximation method that asymptotically *approaches* the right answer after looping several times.

This is what's happening inside the PositionAt function (which is why we provided it as a function.  It's an ugly one to do in kerboscript itself because fast loop iteration is important when doing numerical methods like that.)

What you might be able to do is use the built-in PositionAt(), and then once you have an XYZ position from that, it use it to work out the angle from there to the periapsis point (which is the definition of trueanomaly, of course).  I'd come up with some wacky vector angle calculation based on that, but that's because I like vectors.  There's probably other ways too.  (The vector solution involves getting the angle described by the 3 points: positionat(eta:periapsis), body:position, positionat(futuretime), which you can do with a VANG(), and  then figuring out if it's in the latter half of the orbit (so you'd need to subtract it from 360 to get the real trueanomaly since VANG can only report the 'nearest' angle, that is the one that's <= 180).)

Edited March 5, 2016 by Steven Mading

[TJ179]

5 hours ago, Steven Mading said:

Oh, THAT.

Predicting *how long* it takes to get to a particular point (which is really the same thing as predicting what point you will be at at a given time, just in the inverse) is a mathematically famously messy thing.

(NOTE: It's not messy for a perfectly circular orbit.  It only becomes messy when dealing with an orbit that has some eccentricity to it.)

It's one of those cases where intuition is telling you it *should* be a simple formula but it just isn't.  It's one of those that requires using a numerical approximation method that asymptotically *approaches* the right answer after looping several times.

This is what's happening inside the PositionAt function (which is why we provided it as a function.  It's an ugly one to do in kerboscript itself because fast loop iteration is important when doing numerical methods like that.)

What you might be able to do is use the built-in PositionAt(), and then once you have an XYZ position from that, it use it to work out the angle from there to the periapsis point (which is the definition of trueanomaly, of course).  I'd come up with some wacky vector angle calculation based on that, but that's because I like vectors.  There's probably other ways too.  (The vector solution involves getting the angle described by the 3 points: positionat(eta:periapsis), body:position, positionat(futuretime), which you can do with a VANG(), and  then figuring out if it's in the latter half of the orbit (so you'd need to subtract it from 360 to get the real trueanomaly since VANG can only report the 'nearest' angle, that is the one that's <= 180).)

Thx for this info. 

Do you know how i can add in kos source a function with Parameter in a suffix structure? 

Maybe its the best  i try to implement from ksp the function trueanomalyatut () in Order to use it on kos Script. 

 

 

[BevoLJ]

EDIT: Nevermind!  After spending an hour on this I figured it out moments after asking for help on the forums! =D  For anyone wondering I just changed it to: 

local en is list().
	LIST ENGINES IN en. FOR ENGINE IN en { IF ( ENGINE:ignition ) { print "An engine exists with ISP = " + ENGINE:ISP.}}

_____________________________________________________________________________________________________________________________________________

 

Another question if you don't mind.  I am having trouble trying to find my engine stats for some calcs.  I have been through the documentation and seen many examples others use, but can't seem to get them to work (except for final stages).  The example engine code on the documentation (below): 

local en is list().
	LIST ENGINES IN en. FOR eng IN en {
		print "An engine exists with ISP = " + eng:ISP.
	}

gives me:

Quote

An engine exists with ISP = 0

An engine exists with ISP = 0

An engine exists with ISP = 320

An engine exists with ISP = 0

An engine exists with ISP = 0

An engine exists with ISP = 0

I have been searching around on Reddit and such seeing how folks pull the needed ISP from that and all the code I have found show they use en[0]:ISP.  But on my ship en[0]:ISP returns 0 rather than 320. Which is a problem since the calculation I am using ISP in is dividing by 0. However just doing en[2]:ISP works great for getting this particular stages info.  I however lack understanding on how the numbers in [] correlate to stages or engines on the ship.  I would like to just get the ISP of the engine on the current stage without needing a new function for each stage.  But as I understand if I use the en[2] my function probably wouldn't work for the previous and following stages and engines?  Any possible suggestions or examples on only pulling isp and thrust from current stage engines rather than en[0]:ISP/...?

Edited March 5, 2016 by BevoLJ

[hvacengi]

6 hours ago, TJ179 said:

Thx for this info. 

Do you know how i can add in kos source a function with Parameter in a suffix structure? 

Maybe its the best  i try to implement from ksp the function trueanomalyatut () in Order to use it on kos Script. 

I know that it's a bit of work, but the current implementation of kOS does provide enough information to calculate the anomaly parameters and to predict future true anomaly values based on time (without using `positionat`).  I have a script that does so (which is not in a decent enough condition to share at this point, sorry).  We have made a conscious decision so far to not expose some kind of "true anomaly at" function.  We never really finished that discussion on github (it was discussed internally with the dev team) but you can see that discussion here (including references on how to make it work): https://github.com/KSP-KOS/KOS/issues/153

[hvacengi]

2 hours ago, BevoLJ said:

I have been searching around on Reddit and such seeing how folks pull the needed ISP from that and all the code I have found show they use en[0]:ISP.  But on my ship en[0]:ISP returns 0 rather than 320. Which is a problem since the calculation I am using ISP in is dividing by 0. However just doing en[2]:ISP works great for getting this particular stages info.  I however lack understanding on how the numbers in [] correlate to stages or engines on the ship.  I would like to just get the ISP of the engine on the current stage without needing a new function for each stage.  But as I understand if I use the en[2] my function probably wouldn't work for the previous and following stages and engines?  Any possible suggestions or examples on only pulling isp and thrust from current stage engines rather than en[0]:ISP/...?

Engines also have `engine:ignition` and `engine:flameout` suffixes.  You could use those to find out if the engine is currently active.  Personally, I just ignore any engine that has an ISP of 0.

[-ctn-]

An engine with an ISP of 0? Wouldn't that just be an explosion?

[tajampi]

Is anyone here interested into making a real, kOS looking editor as a plugin?

The editor that comes with kOS is not really good for programming, and alt-tabbing to another program is a bit unstable (specially with thousand of mods) and takes you away from the inmersion of KSP

 

I will start working on it, but i'm also working in EngineLight so some collaboration will be welcome!

 

Will post the github repo here if I get anything done  (and maybe create a thread?)

 

[Riderfighter]

@tajampi That sounds like an amazing idea, I would help though I have zero experience with ksp and plugins.

Edited March 5, 2016 by Riderfighter

[Dunbaratu]

1 hour ago, tajampi said:

Is anyone here interested into making a real, kOS looking editor as a plugin?

The editor that comes with kOS is not really good for programming, and alt-tabbing to another program is a bit unstable (specially with thousand of mods) and takes you away from the inmersion of KSP

 

I will start working on it, but i'm also working in EngineLight so some collaboration will be welcome!

 

Will post the github repo here if I get anything done  (and maybe create a thread?)

 

Hmm.  Many people have made syntax highlighters for other editors, and one person is trying to make an editor from scratch, but making it be an in-game editor opens up some interesting possibilities.   Because the editor and the kOS mod would live in the same process in memory, it may be possible to have your editor query the kOS mod to ask it things about syntax and the like.

This is intriguing.

[tajampi]

24 minutes ago, Steven Mading said:

Hmm.  Many people have made syntax highlighters for other editors, and one person is trying to make an editor from scratch, but making it be an in-game editor opens up some interesting possibilities.   Because the editor and the kOS mod would live in the same process in memory, it may be possible to have your editor query the kOS mod to ask it things about syntax and the like.

This is intriguing.

Hmm, wonder if kOS exposes any information over an API. The idea was to let the user open a file via a "browser", but if I could somehow hook into the "edit" command...

 

Also, as this is getting serious I will create a thread. It will be named kOS-Editor in the Addon Development forum. I hope there is no legal issue using the name, otherwise, tell me

[Dunbaratu]

3 minutes ago, tajampi said:

Hmm, wonder if kOS exposes any information over an API. The idea was to let the user open a file via a "browser", but if I could somehow hook into the "edit" command...

 

Also, as this is getting serious I will create a thread. It will be named kOS-Editor in the Addon Development forum. I hope there is no legal issue using the name, otherwise, tell me

I doubt there's a legal issue with the name, but I'm not *technically* the project owner.  Erendrake is, although he's been so busy lately most of the work on 0.19.0 was done by the rest of us and he just posts the final announcements.
Right now kOS doesn't expose that much to other mods, but it totally could if there was a good reason, and this sounds like a good reason to me.
Right now when we open the editor we just launch an entirely new instance of `kOS.Screen.KOSTextEditPopup` and give it the filename and it pulls that into one big string and works with it from there.  The rest of the mod ignores it until it is done and says to save the file.  So that could totally be shunted off into someone else's code instead.  Archetecturally it is doable.

 

[Riderfighter]

That is cool to know multiple people are working on this, if its ok to ask who is working on it?

[hvacengi]

New Release!  v0.19.1

Github: Download

Spacedock: Download

Curseforge: Download

ABOUT

This release is a patch to v0.19.0, fixing some things found by the user community in the two days shortly after v0.19.0 released.

It also happens to contain a few terminal window features that were being worked on before v0.19.0 but were not deemed ready yet when 0.19.0 was released.

NEW FEATURES

• PIDLoop tutorial section in the docs edited to mention new PIDLoop() function that did not exist back when that page was first written. (http://ksp-kos.github.io/KOS_DOC/tutorials/pidloops.html)
• New Terminal GUI doodads and widgets: A brightness slider, and the ability to zoom the character width and height. Also made the transparency and dimming of the 'non-active' terminals a bit less severe so you can still read them when un-focused. Also, these new features can be script controlled by new suffixes, however it is unclear if that feature (doing it from a script) will remain in the future so use it with care: (http://ksp-kos.github.io/KOS_DOC/structures/misc/terminal.html)

BUG FIXES

• Fixed file rename bug on local hard disks: (#1498)
• Fixed boot files can be larger than the local disk (#1094)
• Fixed a bug where Infernal Robotics would break when switching vessels or reverting. (#1501)
• Fixes problems with using PartModule's SetField(), and infernal Robotics which had been failing for all cases where the field was a "float". (#1503). There may have been other places this bug affected, but this is where it was noticed. Hypothetically, anywhere the stock game's library insists on only accepting a single-precision float and not a double would have had the problem.
• Improve steering when small control magnitudes are required. (#1512)