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

[Dunbaratu]

2 minutes ago, infinite_monkey said:

With the latest update, the kOS icon is now a purple square

Playing on Linux with open source AMD drivers (Radeon RX 470)

Which icon?  There's a few different ones I can think of.

Also - just to be sure, wipe the entire GFX folder out, then re-install it from the ZIP - so we know if it's an issue in the actual project or just in how it got released.

[infinite_monkey]

I'm talking about the toolbar button, the rest seems to work normally. I tried refreshing the GFX folder, that didn't help though.

[Dunbaratu]

2 hours ago, infinite_monkey said:

I'm talking about the toolbar button, the rest seems to work normally. I tried refreshing the GFX folder, that didn't help though.

Dealing with this issue has been really frustrating - because whether the icon images work fine seems to be randomly varying depending on the user's exact setup, there's never an indication of anything being wrong on my end or any other people who work on the project, so it's impossible to tell what changes need to be made to fix it.

This all started because I was told that using PNG textures is bad and they need to be made DDS precisely to fix this kind of problem, and doing that actually made things worse.

I wish I could figure out what to do to fix this problem but I can't make it happen on my own computer.

Edited February 10, 2019 by Steven Mading

[funkheld]

Hi good afternoon.
can you start with kos two programs independently please?

Thank you.
greeting

 

program 1:

	until false 
{  
  PRINT ":".
  PRINT ROUND(SHIP:ALTITUDE,0).
  PRINT ":".
  PRINT ROUND(SHIP:APOAPSIS,0).
  PRINT ":".
  PRINT ROUND(SHIP:PERIAPSIS,0).
  PRINT ":".
  PRINT ROUND(SHIP:VELOCITY:SURFACE:MAG,1).
  PRINT ":".
  wait 0.1.
}
	

program 2:

	until false 
{  
  wait 0.1.
}
	

 

[ElWanderer]

14 minutes ago, funkheld said:

Hi good afternoon.
can you start with kos two programs independently please?

Thank you.
greeting

 

program 1:

 

	until false 
{  
  PRINT ":".
  PRINT ROUND(SHIP:ALTITUDE,0).
  PRINT ":".
  PRINT ROUND(SHIP:APOAPSIS,0).
  PRINT ":".
  PRINT ROUND(SHIP:PERIAPSIS,0).
  PRINT ":".
  PRINT ROUND(SHIP:VELOCITY:SURFACE:MAG,1).
  PRINT ":".
  wait 0.1.
}
	

 

program 2:

 

	until false 
{  
  wait 0.1.
}
	

 

 

You can have two separate CPU parts with two different boot scripts, yes. Each CPU would run its own program.

[funkheld]

Thanks for your help.
I can not do that with my 70 years.
Can you please help me with a little demo?

Many Thanks.
greeting

[Stone Blue]

Welp... looks like the GUI texture issues are on me. I failed to note an important detail about changes to the GUI textures in my PR on Github
At least its an easy fix

@Steven Mading Please see my reply on the PR

I profusely apologize to everyone for the inconvenience.

[Dunbaratu]

2 hours ago, Stone Blue said:

Welp... looks like the GUI texture issues are on me. I failed to note an important detail about changes to the GUI textures in my PR on Github
At least its an easy fix

@Steven Mading Please see my reply on the PR

I profusely apologize to everyone for the inconvenience.

Sadly the issue is a lot more messy and complex than that.  See my reply to your reply on the PR.

It appears to be an instance of the old file sizes *accidentally without our realization* avoiding a buggy step KSP does on loading them.  In the PR that "fixed" the file sizes but kept them as PNG, that made it possible for KSP to attempt its buggy conversion, when before the oddball file sizes meant it didn't try to invoke its buggy code that does the conversion, and left them alone.  The irony may be that the original old files worked better *because* they failed conversion.

Edited February 10, 2019 by Steven Mading

[infinite_monkey]

7 minutes ago, Steven Mading said:

Sadly the issue is a lot more messy and complex than that.  See my reply to your reply on the PR.

It appears to be an instance of the old file sizes *accidentally without our realization* avoiding a buggy step KSP does on loading them.  In the PR that "fixed" the file sizes but kept them as PNG, that made it possible for KSP to attempt its buggy conversion, when before the oddball file sizes meant it didn't try to invoke its buggy code that does the conversion, and left them alone.  The irony may be that the original old files worked better *because* they failed conversion.

Are there other icons affected for some people or is it just the toolbar icon? kOS is not the only mod having an icon, so why does it work on other mods?

[infinite_monkey]

I think this worked before, so I guess I'm missing something:

SAS ON.
SET SASMODE TO "RETROGRADE".
		
WAIT 2.

SAS OFF.
LOCK STEERING TO SHIP:UP:FOREVECTOR.

WAIT 2.
UNLOCK STEERING.
SAS ON.
SET SASMODE TO "RADIALOUT".

While the first activation of SASMODE works, it doesn't work anymore after steering is locked to something. SAS is still activated, but only to stability mode. I tried setting SASMODE both before and after SAS ON.

 

EDIT: Got it. SASMODE has to be issued after SAS one, with a delay of at least one physics tick, if I understand correctly. On the other hand, one is not supposed to rely on any assumed value of a physics tick. So how do I make sure I wait long enough?

Edited February 11, 2019 by infinite_monkey

[Alchemist]

Yeah, there is the issue with SAS resetting its mode when you switch it on. (stock behavior)

wait 0. (same behavior with any number that happens to be less than a physics tick, like wait 0.001.) is sufficient to make the script skip exactly 1 update tick (wait command always skips at least 1 update, even if the condition is already met before that)

[infinite_monkey]

Hm, that's weird, I tried 0.01, and that was not enough. 0.1 seems to work.

[harits]

does anyone know how to use this mod?,
i'm not a programmer btw.

[Dunbaratu]

50 minutes ago, harits said:

does anyone know how to use this mod?,
i'm not a programmer btw.

That's kind of a generic open-ended question.

Yes.  There are people here who know how to use this mod.

Although I doubt that's really the answer you were looking for.

If you have specific questions, people here can help.  Do you need to get started?  There's a "know nothing" tutorial walk through here: http://ksp-kos.github.io/KOS_DOC/tutorials/quickstart.html

(although, reading that I just realized, we may need to update the .craft file it tells you to use.  That hasn't been changed in many KSP versions and I don't know if it still loads today.  At any rate, you can look at the screenshot of the rocket and just make one like it yourself.)

Edited February 11, 2019 by Steven Mading

[infinite_monkey]

50 minutes ago, harits said:

does anyone know how to use this mod?,
i'm not a programmer btw.

Do you have a specific question? Did you read the wiki, read some scripts other people made?

[Alchemist]

2 hours ago, infinite_monkey said:

Hm, that's weird, I tried 0.01, and that was not enough. 0.1 seems to work.

Weird, indeed. Last time I've tested it (when introducing the NAVMODE feature, because SASMODE is a bit useless without that) 1 frame delay seemed to be enough. Is it 2 now? maybe then using wait 0. wait 0. should do the trick.

[Dunbaratu]

3 minutes ago, Alchemist said:

Weird, indeed. Last time I've tested it (when introducing the NAVMODE feature, because SASMODE is a bit useless without that) 1 frame delay seemed to be enough. Is it 2 now? maybe then using wait 0. wait 0. should do the trick.

In working with KSP's API, we've found a number of places where it seems the low level calls only serve the needs of the user playing manually through the user interface, and not the needs of external programs trying to call them.  One very common problem is when you expect an API call to do something immediately but it turns out that what it really does is just schedule something to happen "soon enough" to keep the human player happy, but not "right away" as far as program code is concerned.  (i.e. "make this thing happen some time over the next physics tick".)  One difficulty is that sometimes an update to the UI will add additional delay that wasn't there before (i.e. it takes 2 physics updates to guarantee it happens now instead of 1), and we don't notice until someone tries using that one obscure feature.  This is a difficult thing to try to make a unit test for, since it requires the game be up and running and specific actions to be taken in-game.

And it's not just the KSP API.  Sometimes its interfacing with other mods.  In my own scripts I've taken to adding a 2 second wait to the top of every boot file, because I'm using RemoteTech.  When loading a vessel by switching to it, if you start the boot program right away, then Remote Tech will claim there's no connection to home, even though a second later it will claim there is.  It just spreads out its initialization work across several updates, taking time to get fully set up after a vessel load.  For a human player, that's just fine.  It's not even noticeable.  But for a program, it definitely requires some special work to slow the program down so it acts more like the human player would.

 

[RizzoTheRat]

Hi folks,

Can anyone explain what I'm doing wrong here.  I'm working on a docking script and having issue targeting the port.

Set target to "Agena".
set PortList to target:modulesnamed("ModuleDockingNode").
for Ports in PortList {
	set port to Ports:PART.
	print port:name.
	set target to port.
 } 

The test ship has a single docking port, and the print line does print out it's name ("DockingPort3")

However when I try to use when I try to use

target:ship:velocity:orbit

it tells me that GET Suffix 'SHIP' not found on object VESSEL("Agena")

Which suggests it's targeting the ship not the port.  However if I change that line to

target:velocity:orbit

I get the error GET Suffix 'VELOCITY' not found on object PART(dockingPort3,tag=TgtDockPort)

Which suggests it is targeting the port, so now I'm confused.

 

I've also tried setting the target to "Agena" and then referring to  Target:PARTSDUBBED("TgtDockPort"):position but it that doesn't work, presumably because it's potentially a list not a single part?

Edited February 11, 2019 by RizzoTheRat

[Dunbaratu]

27 minutes ago, RizzoTheRat said:

Hi folks,

Can anyone explain what I'm doing wrong here.  I'm working on a docking script and having issue targeting the port.

Set target to "Agena".
set PortList to target:modulesnamed("ModuleDockingNode").
for Ports in PortList {
	set port to Ports:PART.
	print port:name.
	set target to port.
 } 

The test ship has a single docking port, and the print line does print out it's name ("DockingPort3")

However when I try to use when I try to use

target:ship:velocity:orbit

it tells me that GET Suffix 'SHIP' not found on object VESSEL("Agena")

Which suggests it's targeting the ship not the port.  However if I change that line to

target:velocity:orbit

I get the error GET Suffix 'VELOCITY' not found on object PART(dockingPort3,tag=TgtDockPort)

Which suggests it is targeting the port, so now I'm confused.

 

I've also tried setting the target to "Agena" and then referring to  Target:PARTSDUBBED("TgtDockPort"):position but it that doesn't work, presumably because it's potentially a list not a single part?

Huh?  That makes no sense.  Hmm.

Can you trim it down to two very basic example code snippets that differ only in saying target:ship:velocity:orbit in one versus has target:velocity:orbit in the other?  Either this is a bug in kOS, in which case the example will help diagnose it, or it's a problem in the script... in which case the example will help diagnose it.

Your posted code shows the part where target is set, but not the part where it gets used where you report the error.  I can't see what other code there is in between those two things, and that could be relevant.

Edited February 11, 2019 by Steven Mading

[RizzoTheRat]

Er...it appears to be inconsistent.  I've stripped my code down to a small segment and target:ship:velocity:orbit works fine. 

Set target to "Agena".

set PortList to target:modulesnamed("ModuleDockingNode").
for Ports in PortList {
	set port to Ports:PART.
	print port:name.
	set target to port.
 } 

Set shipheading to target:ship:velocity:orbit .
lock steering to shipheading.

 

Built the code back up a few lines at a time and it crashed, removed some lines it ran, put them back in and it still ran!

I am using Lock for about 6 variables, I seem to remember advice than you shouldn't use too many Locks, could that confuse it?  

 

Can I confirm that targeting the port as I did above and then calling target:ship:velocity:orbit is how it's supposed to work?

 

Just trimmed it down to this and it crashed, it's a bit messy as I'm still working out what I want to do

 

clearscreen.
set throttle to 0.
function drawvecs{
	Set TgtVec to VECDRAWARGS( V(0,0,0), target:position, blue, "Target", 1, true).
	set TgtForevec to VECDRAWARGS( target:position, ApproachDist*target:portfacing:vector, Green, "Port", 1, true).
	Set ReqPath to VECDRAWARGS( V(0,0,0), target:position + ApproachDist*target:portfacing:vector, Yellow, "Path", 1, true).

	Set UpVec to VECDRAWARGS( V(0,0,0), 10*UpVel, White, "Up", 1, true).
	Set ForVec to VECDRAWARGS( V(0,0,0), 10*ForVel, White, "Fore", 1, true).
	Set SideVec to VECDRAWARGS( V(0,0,0), 10*SideVel, White, "Side", 1, true).
}

Set ApproachDist to 20.

Set target to "Agena".

set PortList to target:modulesnamed("ModuleDockingNode").
for Ports in PortList {
	set port to Ports:PART.
	print port:name.
	set target to port.
 } 

Set shipheading to target:position + ApproachDist*target:portfacing:vector.
lock steering to shipheading.
wait 2.
set angle to vang(shipheading,target:position).
Set MissDist to target:position:mag * sin(angle).
print "Missdistance : " + MissDist.
print vang(target:position,-target:portfacing:vector).

Lock Vrel to ship:velocity:orbit-target:ship:velocity:orbit.

Lock Upvel to ship:facing:topvector*vdot(ship:facing:topvector,Vrel).
lock ForVel to ship:facing:forevector*vdot(ship:facing:forevector,Vrel).
Lock SideVel to ship:facing:starvector*vdot(ship:facing:starvector,Vrel).

drawvecs().

Falls over on the Print vang line, but if I comment that out it falls over on Set TgtForevec in the function called from the last line

 

I'll have a go at at tidying it up and removing the Locks tomorrow, and if that doesn't fix it try and get down to a couple of shorter examples.

Edited February 11, 2019 by RizzoTheRat

[Dunbaratu]

5 minutes ago, RizzoTheRat said:

Can I confirm that targeting the port as I did above and then calling target:ship:velocity:orbit is how it's supposed to work?

Falls over on the Print vang line, but if I comment that out it falls over on Set TgtForevec in the function called from the last line

It should work, yes.

The only thing I can think of is that target *must* be getting changed to something else somewhere, and that change is happening maybe from one physics tic to the next which is why it only happens when you have longer code (that allows a physics tic to happen between setting it and using it).

Maybe this test might help - put this statement between each line between the setting of target and the line that errors:

print "AAA: target type = " + print target:typename.

but change that AAA to BBB, and CCC, and DDD, etc on each subsequent line so you can tell the lines apart and tell which line of code printed which line of output.

At some point in there, the target has to be getting changed to another type, and discovering exactly when that happens might help.

Once you have that test set up, and you see where the type gets changed, then try this:  Leave the code alone, but change your config:IPU to other values and try again to see if the place where it changes ends up *moving* when you do that.  If changing the IPU causes the change to happen at a *different* line, then that would confirm that its something that happens when a new physics tic starts.

If it is something that happens when a new physics tic starts, then that might be a kOS bug, or it could still be a script problem if your script has any triggers like WHEN or ON, or LOCK STEERING, that might execute code between tics and cause Target to change to something else.  Either way, narrowing it down will help (either me if it's kOS, or you if it's the script) find the cause.

[SpinkAkron]

I have a script library I've been working on for a couple of years while playing unmanned careers.  They are my building blocks for creating missions for commSats, science gathering, docking, landers, etc.  They're not proper rocket science, just good enough for what I was doing.  My focus was on simplicity and clarity as I was learning.  I thought I might clean them up and release them like a mod, giving players new to kOS somewhere to start.  Is there any interest in seeing something like that released?

[Xd the great]

29 minutes ago, SpinkAkron said:

I have a script library I've been working on for a couple of years while playing unmanned careers.  They are my building blocks for creating missions for commSats, science gathering, docking, landers, etc.  They're not proper rocket science, just good enough for what I was doing.  My focus was on simplicity and clarity as I was learning.  I thought I might clean them up and release them like a mod, giving players new to kOS somewhere to start.  Is there any interest in seeing something like that released?

Yes definitely.

[Xd the great]

How do you lock prograde?

[infinite_monkey]

1 hour ago, Xd the great said:

How do you lock prograde?

Easiest way would be SAS with SASMODE prograde