Jump to content

[1.3] kOS Scriptable Autopilot System v1.1.3.0

erendrake

By erendrake
in KSP1 Mod Releases

 Share

Recommended Posts

casper88

casper88

Posted
Posted

hi there, have a query. with kos remotetech integration; a pre running (by pre running, i mean either using a boot script or run when there was a signal) should be able to activate events irregardless of having a constant connection? however, this does not seem to be the case as when the signal dropped I suddenly got spammed with "no signal to send the command on" (the running script was running on the local core volume and not archive.)

is this correct or have i overlooked something??

thanks

casper

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted
hi there, have a query. with kos remotetech integration; a pre running (by pre running, i mean either using a boot script or run when there was a signal) should be able to activate events irregardless of having a constant connection? however, this does not seem to be the case as when the signal dropped I suddenly got spammed with "no signal to send the command on" (the running script was running on the local core volume and not archive.)

is this correct or have i overlooked something??

thanks

casper

First question, is the RT option turned on in the kOS config panel?

Link to comment
Share on other sites
casper88

casper88

Posted
Posted

yes its active. what i meant, while with a connection run a program on the local volume; that local volume should be able to control the actions/events (via partmodule:doevent) regardless of the connection state...it pilots the craft without the need for connection once the program is running, does it not?

cheers

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted
yes its active. what i meant, while with a connection run a program on the local volume; that local volume should be able to control the actions/events (via partmodule:doevent) regardless of the connection state...it pilots the craft without the need for connection once the program is running, does it not?

cheers

It's meant to, but there might be bugs.

Can you check to see if it's the same as this problem?

https://github.com/KSP-KOS/KOS/issues/906

Link to comment
Share on other sites
casper88

casper88

Posted
Posted (edited)

hi there, the issue in that link is slightly different (any i haven't noticed that one myself). for clarity, here is the script im using...

// Fuel Cell toggle

set core:bootfilename to "fuelcell.ks".

// load cells into array

local cells is list().

local tParts is list().

local tpart to core:part.

local moduleName to "".

local module to core:part:getmodule("kOSProcessor").

local resref to 0.

LIST RESOURCES IN RESLIST.

FOR RES IN RESLIST {

if (res:name = "ELECTRICCHARGE"){

set resref to res.

}

}.

local function togglecell{

parameter _action.

FOR module in cells {

if module:HASEVENT(_action) {module:DoEVENT(_action).}

}

}

LIST PARTS IN tParts.

FOR tpart in tParts {

if (tpart:TITLE = "Universal Storage: Alkaline Fuel Cell"){

for moduleName in tpart:modules {

set module to tpart:getmodule(moduleName).

if module:name ="ModuleResourceConverter" and ( module:HASEVENT("Start Fuel Cell") or module:HASEVENT("Stop Fuel Cell") ){

cells:add(module).

}

}

}

}

print "Found " + cells:length + " fuel cell(s).".

if cells:LENGTH > 0 {

when (resref:amount > resref:CAPACITY * 0.90) then {

togglecell("Stop Fuel Cell").

preserve.

}

when (resref:amount < resref:CAPACITY * 0.50) then {

togglecell("Start Fuel Cell").

preserve.

}

}

wait until false.

while a running connection to ksc

copy fuelcell from 0. run fuelcell.

does it depend on the upgrade level of any of the buildings? (this is a new career save)

cheers

- - - Updated - - -

...using the universal storage fuel cell part

copy and run while having a connection...then the program waits for the triggers and starts/stops the fuel cell based on charge..the way i expected this to work once running, is that the fuel cell is toggled independent of RT connection.

Edited by casper88
Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted
hi there, the issue in that link is slightly different (any i haven't noticed that one myself). for clarity, here is the script im using...

These forums have a [ code ] ... [ /code ] tag you can use for posting text that won't mangle the indents like that.

- - - Updated - - -

hi there, the issue in that link is slightly different (any i haven't noticed that one myself). for clarity, here is the script im using...

copy and run while having a connection...then the program waits for the triggers and starts/stops the fuel cell based on charge..the way i expected this to work once running, is that the fuel cell is toggled independent of RT connection.

But, that *does* sound like exactly the same problem to me. The program doesn't keep working once the connection is lost.

- - - Updated - - -

can you verify what is happening by the following:

instead of "wait until false", do this:


until false {
  wait 5.
  print "I am still running.  Time = " + round(time:seconds,0).
}

It will prove whether or not the program is still running after signal loss.

If the program is still running, but not doing its job, then that means RT is still locking out some things despite kOS telling it to sanction its piloting as "not manual".

- - - Updated - - -

Okay, new information: This is a bug specifically with using the right-click menus (like the one you are trying to activate on the fuel cell), and it's an RT bug, not kOS. RT invasively denies the use of the controls to everyone *except* those other mods who register themselves as "RT sanctioned pilots" with an RT API call. But apparently RT still invasively takes over all the parts' right-click menus, even denying them to sanctioned pilot mods like kOS. It only works with the vanilla flight controls like WASD, Shift, ctrl, etc.

There seems to be a workaround but it's unpleasant. If you *NEVER* open up the user menu panels for the fuel cells, *EVER* during the life of the flight, then RT doesn't do its invasive replacement of all the features contained there. It's the act of opening the panel as a user that makes RT re-route all its controls through itself. If you never use the panel as a user, supposedly, it still can work via the kOS script.

- - - Updated - - -

Another workaround would be to bind what you are trying to do to an action group, and just control it via action groups alone, which I think RT still allows kOS to control.

Link to comment
Share on other sites
casper88

casper88

Posted
Posted (edited)

There seems to be a workaround but it's unpleasant. If you *NEVER* open up the user menu panels for the fuel cells, *EVER* during the life of the flight, then RT doesn't do its invasive replacement of all the features contained there. It's the act of opening the panel as a user that makes RT re-route all its controls through itself. If you never use the panel as a user, supposedly, it still can work via the kOS script.

yup this is correct - and doesn't matter if RT integration is active or not...:( ill try the action group stuff when i have access to it in career mode.

thinking about how to phrase this to the RT thread, any suggestions?

------

i opened ship manifest - it caused RT to do re routing without selecting the part :(...also ship manifest also bypasses RT for the antennas and solar panels...maybe do this with KOS for the events?

Edited by casper88
Link to comment
Share on other sites
tomek.piotrowski

tomek.piotrowski

Posted
Posted

Hi casper88,

me and a few other kOS developers had a discussion about your problem. The issue itself was actually already reported here: https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/437. Basically after 1.0 got released it caused a bug with RemoteTech that was particularly difficult to get rid of. The solution that was used by RT developers was quite invasive and broke the interaction between kOS and RT.

We will be submitting a workaround to RemoteTech in a day or so, but I don't know how much time it will take for a fixed version of RemoteTech to be released. It will require a minor change in kOS as well, so overall it may take some time for the bug to be resolved completely. For the time being, you will have to refrain from right clicking on parts that you will later want to access from your kOS script :(

Link to comment
Share on other sites
Drew Kerman

Drew Kerman

Posted
Posted

Just leaving this blog post here in case it turns up in any future searches by people looking to log data with time-stamp sequential entries:

Logging Data - Not as Simple as it seems

tl;dr I did not fully think through the implications of using a wait 1. command to pause execution before logging a new piece of data and expecting it to do so consistently each second of the game

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted
After a bout of non-kOS programming a question popped up in my mind: has anyone dared to conceive a x86/x64 compiler for something like Windows or Android for kOS yet?

Do you mean just to create a KSM file from a KS file and nothing more? You know... that may actually be possible. All the stuff the compiler is doing seems to be handled outside the main game engine. Now you've made me think.

Link to comment
Share on other sites
Camacha

Camacha

Posted
Posted
Do you mean just to create a KSM file from a KS file and nothing more? You know... that may actually be possible. All the stuff the compiler is doing seems to be handled outside the main game engine. Now you've made me think.

I was more thinking along the lines of being able to compile standalone .exe files for use with Windows (or other relevant files for another OS, of course). Of course, you would only be able to run command line programs and a lot of functionality would not be available. Anything having to do with parts or the environment (which is most of kOS) falls apart.

Having spent a week or so throwing various files around in various languages, the idea did not seem that far fetched any more. Though I imagine the usefulness is limited, people would probably be better off adding a 'real' language to their repertoire.

Compiling KSM files from KS files would certainly add to the feel that you are working with real programs and IDE's. From at least a role-playing point of view, that might be interesting.

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted (edited)

The reason an external KSM compiler might be handy would be because KSM files load very fast in-game compare to KS files which are parsed and compiled from text in-game and freeze the game. We actually know why this is but it's a PITA to fix. It's because the parser is using Regex rules for case-insensitivity, and KSP uses Unity with 100% compatibility mode turned on, which for some odd reason disables the use of pre-compiled regexes in the Mono DLLs it uses. Therefore we have to use regexes that recalculate on the fly, and that's slooow. After looking into this, the *only* Unity platform that can't do precompiled regexes is some older iPhones. Everyone else can do it, but because KSP has 100% lowest-common-denominator compatibility turned on, the ability to precompile regexes is disabled for the sake of the non-existant iPhone release of KSP.

And Unity doesn't seem to provide an option with enough fine-grain tuning to say "I want to be compatible with everything big like a PC, Mac, xbox one, etc, but I don't care about being compatible with mobile phones please".

Edited by Steven Mading
Link to comment
Share on other sites
jcd

jcd

Posted
Posted

I'm trying to detect the AOA and sideslip of my ship. I am taking the dot product of the prograde vector with other vectors based on SHIP:FACING:

CLEARSCREEN.

until false
{
	SET rightRotation TO SHIP:FACING * R(0,90,0).
	SET rightVec to rightRotation:VECTOR.
	SET otherUpVec to SHIP:UP:VECTOR.
	SET upRotation TO SHIP:FACING * R(90,0,0).
	SET upVec TO upRotation:VECTOR.
	set frontVec to SHIP:FACING:VECTOR.

	//SET bankAngle to VANG(rightVec,upVec).	//	does this work on the opposite side of the planet?

	set rightA to (rightVec * SHIP:PROGRADE:VECTOR).
	set upA to (otherUpVec * SHIP:PROGRADE:VECTOR).	//	this corresponds to prograde relative to the horizon
	set upB to (upVec * SHIP:PROGRADE:VECTOR).	//	this is nose relative to horizon

	print "        " at (1,1).
	print rightA at (1,1).

	print "        " at (10,3).
	print upB-upA at (10,3).
}

It seems to work okay when flying a 90 degree heading from KSC, but it breaks when I turn around. Also, I don't understand why upVec * prograde doesn't correlate to AOA by itself. I am trying to take the direction the ship is facing, rotate it so it's vertical, and get the projection of the prograde vector on that vector.

Link to comment
Share on other sites
Wercho

Wercho

Posted
Posted (edited)
I'm trying to detect the AOA and sideslip of my ship. I am taking the dot product of the prograde vector with other vectors based on SHIP:FACING:

CLEARSCREEN.

until false
{
	SET rightRotation TO SHIP:FACING * R(0,90,0).
	SET rightVec to rightRotation:VECTOR.
	SET otherUpVec to SHIP:UP:VECTOR.
	SET upRotation TO SHIP:FACING * R(90,0,0).
	SET upVec TO upRotation:VECTOR.
	set frontVec to SHIP:FACING:VECTOR.

	//SET bankAngle to VANG(rightVec,upVec).	//	does this work on the opposite side of the planet?

	set rightA to (rightVec * SHIP:PROGRADE:VECTOR).
	set upA to (otherUpVec * SHIP:PROGRADE:VECTOR).	//	this corresponds to prograde relative to the horizon
	set upB to (upVec * SHIP:PROGRADE:VECTOR).	//	this is nose relative to horizon

	print "        " at (1,1).
	print rightA at (1,1).

	print "        " at (10,3).
	print upB-upA at (10,3).
}

It seems to work okay when flying a 90 degree heading from KSC, but it breaks when I turn around. Also, I don't understand why upVec * prograde doesn't correlate to AOA by itself. I am trying to take the direction the ship is facing, rotate it so it's vertical, and get the projection of the prograde vector on that vector.

I haven't checked all this myself, but I see a couple of problems.

1. THe R(#,#,#) notation is really confusing, and a recipe for disaster because it's based on the raw coordinate frame (which isn't oriented based on anything in particular), not the ship relative coordinate frame. I suspect you're seeing some consistency when flying towards 90 deg east, because the raw coordinate frame seems to start out the same at launch time. Try these instead:

SET rightVec TO ship:facing:starvector.
SET upVec TO ship:facing:topvector.

Those will give you ship-relative vectors every time.

2. The dot product will give you a magnitude, which might serve well enough. If you actually want the angle of attack, you'll need to use trig to convert rightA, upA, and upB into angles.

EDIT for encouragement: This directional stuff is some of the most complicated kOS stuff to me, and it's taken me a lot of time to figure it out. Once you get it, you can do a lot of cool things though, so keep at it.

Edited by Wercho
Link to comment
Share on other sites
jcd

jcd

Posted
Posted (edited)

1. THe R(#,#,#) notation is really confusing, and a recipe for disaster because it's based on the raw coordinate frame (which isn't oriented based on anything in particular), not the ship relative coordinate frame. I suspect you're seeing some consistency when flying towards 90 deg east, because the raw coordinate frame seems to start out the same at launch time. Try these instead:

SET rightVec TO ship:facing:starvector.
SET upVec TO ship:facing:topvector.

Thanks for the help. It makes sense that I was rotating based on a coordinate system that didn't stay aligned to the ship. I was also unaware of the difference between topvector and upvector.

But the code here still varies with heading: the angle between topvector and prograde increases as I turn to the right after takeoff. Are the vectors ship:facing:topvector and ship:prograde not in the same reference frame?

CLEARSCREEN.

until false
{
	SET rightVec TO ship:facing:starvector.
	SET upVec TO ship:facing:topvector.
	set frontVec to SHIP:FACING:VECTOR.

	//SET bankAngle to VANG(rightVec,upVec).	//	does this work on the opposite side of the planet?

	set rightA to (rightVec * SHIP:PROGRADE:VECTOR).
	set upA to (upVec * SHIP:PROGRADE:VECTOR).	//	this is nose relative to horizon

	SET someAngle to VANG(upVec,SHIP:PROGRADE:VECTOR).	//	this is directly correlated with AOA?

	print "        " at (1,1).
	print rightA at (1,1).

	print "        " at (10,3).
	//print upA at (10,3).
	print someAngle at (10,3).
}

Edited by jcd
Link to comment
Share on other sites
Wercho

Wercho

Posted
Posted (edited)
But the code here still varies with heading: the angle between topvector and prograde increases as I turn to the right after takeoff. Are the vectors ship:facing:topvector and ship:prograde not in the same reference frame?

All vectors are in the same reference frame, I'm pretty positive about that.

Is this a plane or a rocket?

Is this a rocket or a plane? Unless you have some wierd control setup, the AOA should be the angle between ship:facing:forevector and ship:prograde:vector (note that the direction that counts as forward is based on the controlling part, and most are set up so that forward is the direction a rocket or plane would travel when that part is mounted sensibly.

OOOOOOh, I just realized that you should probably be using ship:srfprograde:vector. "Prograde" gives the orbital-frame prograde direction, while "srfprograde" gives the surface frame (like when the speed readout on the navball says "surface"). I suspect your readings thus far may have been coincidental if they were right, because when landed on the equator you actually have an orbital velocity directly east.

EDIT: Also, have you used the VECDRAW commands? They are invaluable for figuring out what is going wrong in these situations.

Edited by Wercho
Link to comment
Share on other sites
idPhobos

idPhobos

Posted
Posted

Having an issue reading surface speed I could use some help with.

As per http://ksp-kos.github.io/KOS_DOC/structures/vessels/vessel.html#attribute:VESSEL:SURFACESPEED I expected ship:surfacespeed to be a 2d speed equivalent to KER's Horizontal Speed readout. However, running the following test code reports my combined vertical and horizontal speed.

E.g. KER reports -10m/s vert and <very small number>mm/s horizontal but ship:surfacespeed returns ~-10m/s.

until false {
  print ship:surfacespeed.
  wait 0.1.
}

Link to comment
Share on other sites
Dunbaratu

Dunbaratu

Posted
Posted
Having an issue reading surface speed I could use some help with.

As per http://ksp-kos.github.io/KOS_DOC/structures/vessels/vessel.html#attribute:VESSEL:SURFACESPEED I expected ship:surfacespeed to be a 2d speed equivalent to KER's Horizontal Speed readout. However, running the following test code reports my combined vertical and horizontal speed.

E.g. KER reports -10m/s vert and <very small number>mm/s horizontal but ship:surfacespeed returns ~-10m/s.

until false {
  print ship:surfacespeed.
  wait 0.1.
}

Sadly, Squad goofed in KSP 1.0.4 and changed their surface speed calculation function in the API in a way that uses the wrong formula now.

kOS just passes it on directly to the script, and it used to work before KSP 1.0.4 goofed up the calculations for it.

The fix is in already in the development version of kOS (just calculating it ourselves and ignoring the official value, which is what KER is doing, by the way) but it's not released yet.

In the meantime you can do the fix manually yourself - just use VCXL(SHIP:VELOCITY:SURFACE, SHIP:UP:VECTOR) and it *should* work.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...