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

[Bongotastic]

The download on CKAN for 1.8.1 is corrupted. Not sure if the maintainer for the CKAN package sees this thread. I’ll check git in case it makes sense to report there. 

[Corax]

FYI, the "download from CKAN" is just a pointer to the file it needs, in this case it is referencing one on Github. The CKAN is basically just a big database of where to find things to download and how to install them, it does not host any of the actual files.

[Dunbaratu]

4 hours ago, Bongotastic said:

The download on CKAN for 1.8.1 is corrupted. Not sure if the maintainer for the CKAN package sees this thread. I’ll check git in case it makes sense to report there. 

Define "corrupted". (can you show the exact error message you got and what step you were doing at the time?)

Edited May 26, 2020 by Steven Mading

[Bongotastic]

Seems to have a few bytes more than it should.

[Dunbaratu]

16 minutes ago, Bongotastic said:

Seems to have a few bytes more than it should.

Yes but what do you mean by"should"??

I updated the ZIP on github because kOS works fine on KSP 1.9.1 and I wanted the kOS.version file to say so so CKAN would allow it to install.  Mod writers are supposed to do that by updating the .version file - I did that and then remade the ZIP with the only difference being the change to the .version file that said max KSP version was  1 8 99 to saying 1 9 1 instead.  I have no idea why CKAN calls it invalid for the ZIP file to have changed size.  Of course it changed size.  Because I overwrote it with a new version.  I don;t understand why CKAN claims this is a fatal problem.  I thought it was supposed to read the ZIP file and obey what it said, not complain that I changed it.

I don;t understand CKAN sometimes.

[Bongotastic]

2 hours ago, Steven Mading said:

Yes but what do you mean by"should"??

Thanks, working now. Very much appreciate since CKAN simply refused to install kOS. 

My “should” was literal quoting from the error message.  A metadata thing, I guess. 

[kcs123]

CKAN bot is stupid. Filename of ZIP archive "kOS-v1.2.1.0.zip" was not changed from latest release in 2019, despite the fact that content is no longer same. CKAN have catched archive size from previous ZIP archive and didn't updated metadata file because bot didn't see change in filename. Additional check for filesize seems to be stupid in this situation, but it makes sense from security standpoint, if some "man in the middle" try to attach malicious piece of code in archive without knowledge of author or user.

Instead of just repacking existing archive, better aproach is to make new kOS version, even when actualy nothing was changed, not even recompiled. It is tupid, but CKAN bot is just ordinary piece of code without any kind of AI. Can't even blame CKAN staff on that one. Can't predict situation like that, and even if someone predicted it, it would cause unnecessary load on severs to check out content on each archive for each mod in database if something was changed in archive or not. Currently it checks only if filename of mod is different than previous release. In situation like this some edit from human might be necessary. @HebaruSan might be able to tell more details about it.

[Dunbaratu]

49 minutes ago, kcs123 said:

CKAN bot is stupid. Filename of ZIP archive "kOS-v1.2.1.0.zip" was not changed from latest release in 2019, despite the fact that content is no longer same. CKAN have catched archive size from previous ZIP archive and didn't updated metadata file because bot didn't see change in filename. Additional check for filesize seems to be stupid in this situation, but it makes sense from security standpoint, if some "man in the middle" try to attach malicious piece of code in archive without knowledge of author or user.

Instead of just repacking existing archive, better aproach is to make new kOS version, even when actualy nothing was changed, not even recompiled. It is tupid, but CKAN bot is just ordinary piece of code without any kind of AI. Can't even blame CKAN staff on that one. Can't predict situation like that, and even if someone predicted it, it would cause unnecessary load on severs to check out content on each archive for each mod in database if something was changed in archive or not. Currently it checks only if filename of mod is different than previous release. In situation like this some edit from human might be necessary. @HebaruSan might be able to tell more details about it.

So, the tl;dr - From now on, I need to know that any change to the ZIP file's contents requires also changing the ZIP's file's name. (i.e. "kOS-v1.2.1.0.zip" becoming "v1.2.1.0_b.zip" or whatever.)

I'll test a CKAN install of kOS today.  If it still doesn't work, I'll change the filename of the ZIP.  (Based on posts in the kOS subreddit, I think someone at CKAN might have gone in under the hood and massaged the data for kOS to give it the new checksum, which is why I should test first.).

Edited May 27, 2020 by Steven Mading

[HebaruSan]

On 5/25/2020 at 8:34 PM, Bongotastic said:

The download on CKAN for 1.8.1 is corrupted. Not sure if the maintainer for the CKAN package sees this thread. I’ll check git in case it makes sense to report there. 

Please do not bother mod authors with CKAN problems. There's a CKAN thread and a bugtracker for a reason.

• https://forum.kerbalspaceprogram.com/index.php?/topic/154922-ckan-the-comprehensive-kerbal-archive-network-v1272-chandrasekhar/&tab=comments#comment-2919934
• https://github.com/KSP-CKAN/NetKAN/issues

On 5/26/2020 at 4:48 AM, Steven Mading said:

I updated the ZIP on github

Yup, and CKAN caught that update 3 days ago. Users just need to refresh.

https://github.com/KSP-CKAN/CKAN-meta/commit/c1dc9a2e99245130e6e8f8465d41c3682886bfeb#diff-b5afb310527a3ec216c7e3782104872d

Quote

because kOS works fine on KSP 1.9.1 and I wanted the kOS.version file to say so so CKAN would allow it to install.  Mod writers are supposed to do that by updating the .version file - I did that and then remade the ZIP with the only difference being the change to the .version file that said max KSP version was  1 8 99 to saying 1 9 1 instead.

Version files provide a way to do it without changing the download. The "URL" property points to a copy of the version file hosted on a server that can be checked for updates (and it looks like kOS has this correct already). In addition to looking for new releases, KSP-AVC and CKAN will check that copy and use it instead of the one in the download if the "VERSION" properties match. So if you keep "VERSION" the same and update "KSP_VERSION_MAX", that change should be reflected in CKAN within 4 hours, for the original download. I do this for my own mods.

Quote

I have no idea why CKAN calls it invalid for the ZIP file to have changed size.  Of course it changed size.  Because I overwrote it with a new version.  I don;t understand why CKAN claims this is a fatal problem.  I thought it was supposed to read the ZIP file and obey what it said, not complain that I changed it.

If a download host gives us a bad file, we need to detect it. So we use hashes to make sure the file we're installing is the same as the one the bot indexed. If the files change, the bot updates the hashes.

1 hour ago, kcs123 said:

Instead of just repacking existing archive, better aproach is to make new kOS version, even when actualy nothing was changed, not even recompiled. It is tupid, but CKAN bot is just ordinary piece of code without any kind of AI. Can't even blame CKAN staff on that one. Can't predict situation like that, and even if someone predicted it, it would cause unnecessary load on severs to check out content on each archive for each mod in database if something was changed in archive or not. Currently it checks only if filename of mod is different than previous release. In situation like this some edit from human might be necessary. @HebaruSan might be able to tell more details about it.

No, don't do this.

1 hour ago, Steven Mading said:

So, the tl;dr - From now on, I need to know that any change to the ZIP file's contents requires also changing the ZIP's file's name. (i.e. "kOS-v1.2.1.0.zip" becoming "v1.2.1.0_b.zip" or whatever.)

I'll test a CKAN install of kOS today.  If it still doesn't work, I'll change the filename of the ZIP. 

No, the filename doesn't matter at all. @kcs123, please do not start new urban legends that mislead and confuse people.

Edited May 27, 2020 by HebaruSan

[kcs123]

2 hours ago, HebaruSan said:

No, the filename doesn't matter at all. @kcs123, please do not start new urban legends that mislead and confuse people.

That is why I called you for confirmation or denial.

[Kingsboy]

Hi everyone,
I would like to land the boosters of my heavy falcon at the same time with the kos script mod like here:

https://www.youtube.com/watch?v=aPXzNDhz6p8

But I don't understand the kos mod ...
Can someone give me a script to use to land a booster on a specific target ???
Thank you in advance.

Edited May 28, 2020 by Kingsboy

[ColKlonk2]

Nothing like writing your own scripts 

Try looking at the examples in the GitHub repository.

Better still, write an ascent script and reverse it.

[ManEatingApe]

I'm trying to use the the POSITIONAT function to calculate the relative position of planets for transfer planning purposes.

When using it with planets the values returned are correct, however the values returned for moons seem a little wonky. I think I'm doing something silly but can't figure out what's going wrong. Any help would be appreciated!

Here's a minimal code sample to demonstrate (running on KSP 1.9.1 Mac, kOS 1.2.0, no other plugins).
I've tried moving the CPU vessel to various orbits with no effect.

Spoiler

// Pass: Prints constant 13599840256 as expected
relativeDistance(kerbin).
// Fail: Prints changing value e.g. 9337055 that is not 12000000
relativeDistance(mun).
// Pass: Print constant 21783187949 that seems plausible
relativeDistance(duna).
// Fail: Prints changing value e.g. 5489455 instead of 3200000
relativeDistance(ike).
// Pass: Print constant 65353911824 that seems plausible
relativeDistance(jool).
// Fail: Prints changing value e.g. 29352791 instead of 27184000
relativeDistance(laythe).
// Fail: Prints changing value e.g. 70651219 instead of 68500000
relativeDistance(tylo).

local function relativeDistance {
    parameter planet.

    print planet:name + " " + round((positionat(planet, 0) - positionat(planet:orbit:body, 0)):mag).
}

To double check I wrote a Kepler's problem solver script in kOS that agrees quite closely with the planet values, but differs for the moon values. https://github.com/maneatingape/kos-miscellaneous-scripts/blob/master/kepler.ks

Edited June 16, 2020 by ManEatingApe

[ElWanderer]

11 hours ago, ManEatingApe said:

I'm trying to use the the POSITIONAT function to calculate the relative position of planets for transfer planning purposes.

When using it with planets the values returned are correct, however the values returned for moons seem a little wonky.

  Reveal hidden contents

// Pass: Prints constant 13599840256 as expected
relativeDistance(kerbin).
// Fail: Prints changing value e.g. 9337055 that is not 12000000
relativeDistance(mun).
// Pass: Print constant 21783187949 that seems plausible
relativeDistance(duna).
// Fail: Prints changing value e.g. 5489455 instead of 3200000
relativeDistance(ike).
// Pass: Print constant 65353911824 that seems plausible
relativeDistance(jool).
// Fail: Prints changing value e.g. 29352791 instead of 27184000
relativeDistance(laythe).
// Fail: Prints changing value e.g. 70651219 instead of 68500000
relativeDistance(tylo).

local function relativeDistance {
    parameter planet.

    print planet:name + " " + round((positionat(planet, 0) - positionat(planet:orbit:body, 0)):mag).
}

Moons are indeed weird (though I thought this was only the case when you are orbiting their parent). When you ask for their position vector, it is (I think) relative to the parent body (and so you just need to subtract the parent body's current position vector). This is my position vector function:

FUNCTION posAt

{

PARAMETER c, u_time.

LOCAL b IS ORBITAT(c,u_time):BODY.

LOCAL p IS POSITIONAT(c, u_time).

IF BODY <> SUN AND c = SHIP AND b:HASBODY AND b:BODY = BODY { SET p TO p - POSITIONAT(b,u_time). }

ELSE { SET p TO p - b:POSITION. }

RETURN p.

}

 

Now to see if I documented exactly why I have those checks.

Looks like I didn't. Bother. I do remember being wildly confused for quite a while before I got something that worked, mostly through trial and error.

Edited June 1, 2020 by ElWanderer

[ManEatingApe]

35 minutes ago, ElWanderer said:

Moons are indeed weird (though I thought this was only the case when you are orbiting their parent). When you ask for their position vector, it is (I think) relative to the parent body (and so you just need to subtract the parent body's current position vector).

Thanks @ElWanderer that did the job!

For anyone else reading: If you want the position of a planet at a specific time "t" relative to its parent body, then you must subtract the current position of the parent body, not the position of the parent body at time "t" as you might expect.

Reworking the code sample and randomizing the time offset from epoch gives more sensible values.

Spoiler

// Pass: Expected value 13599840256
relativeDistance(kerbin).
// Pass: Expected value 12000000
relativeDistance(mun).
// Pass: Print constant 21783187949 that seems plausible
relativeDistance(duna).
// Pass: Expected value ~3200000
relativeDistance(ike).
// Pass: Print constant 65353911824 that seems plausible
relativeDistance(jool).
// Pass: Expected value 27184000
relativeDistance(laythe).
// Pass: Expected value 68500000
relativeDistance(tylo).

local function relativeDistance {
    parameter planet.

    local time is round(random() * 100_000_000).
    // Subtract current parent position *not* position at "time"
    local relativePosition is positionat(planet, time) - planet:orbit:body:position.

    print planet:name + " " + round(relativePosition:mag).
}

 

Edited June 1, 2020 by ManEatingApe

[Dunbaratu]

2 hours ago, ManEatingApe said:

Thanks @ElWanderer that did the job!

For anyone else reading: If you want the position of a planet at a specific time "t" relative to its parent body, then you must subtract the current position of the parent body, not the position of the parent body at time "t" as you might expect.

Reworking the code sample and randomizing the time offset from epoch gives more sensible values.

  Reveal hidden contents

// Pass: Expected value 13599840256
relativeDistance(kerbin).
// Pass: Expected value 12000000
relativeDistance(mun).
// Pass: Print constant 21783187949 that seems plausible
relativeDistance(duna).
// Pass: Expected value ~3200000
relativeDistance(ike).
// Pass: Print constant 65353911824 that seems plausible
relativeDistance(jool).
// Pass: Expected value 27184000
relativeDistance(laythe).
// Pass: Expected value 68500000
relativeDistance(tylo).

local function relativeDistance {
    parameter planet.

    local time is round(random() * 100_000_000).
    // Subtract current parent position *not* position at "time"
    local relativePosition is positionat(planet, time) - planet:orbit:body:position.

    print planet:name + " " + round(relativePosition:mag).
}

 

Well dang.  That's not how it was meant to work.  But it's been this way long enough to break people's scripts that expect it to be this way.

[Jacke]

15 minutes ago, Steven Mading said:

Well dang.  That's not how it was meant to work.  But it's been this way long enough to break people's scripts that expect it to be this way.

Obligatory XKCD

https://www.explainxkcd.com/wiki/index.php/1172:_Workflow

[ElWanderer]

4 hours ago, Jacke said:

Obligatory XKCD

https://www.explainxkcd.com/wiki/index.php/1172:_Workflow

Is it sad that I am giggling at that even though I've not clicked on it?

Just add a config option to re-enable space-bar heating...

[ManEatingApe]

12 hours ago, Steven Mading said:

Well dang.  That's not how it was meant to work.  But it's been this way long enough to break people's scripts that expect it to be this way.

No worries! There's a straightforward solution and maintaining backwards compatibility is really important.

Kudos to you and the team for the effort and skill spent maintaining such an excellent mod. It works extraordinarily well and the quality of the documentation is outstanding.

[Dunbaratu]

3 hours ago, ManEatingApe said:

No worries! There's a straightforward solution and maintaining backwards compatibility is really important.

Kudos to you and the team for the effort and skill spent maintaining such an excellent mod. It works extraordinarily well and the quality of the documentation is outstanding.

 

15 hours ago, Jacke said:

Obligatory XKCD

https://www.explainxkcd.com/wiki/index.php/1172:_Workflow

Not the same thing.  Not at all.  Let me explain the difference.

The XKCD cartoon is talking about a user who is aware the bug is getting fixed, but prefers it and wants it to stay broken.

This is about people who *don't know* the bug is getting fixed, so they don't know they have to remove the offset they put into their code.  Their code becomes retroactively incorrect and that's not their own fault.

What may be better is to fix it but give it a new name.  The old name could be depricated but still work the same way.  People could still run out of date code using the old way, but it would spew warning messages on the screen.  The newly renamed function would do it the correct way.

[Tyoi]

Nevermind my question - Mods, please delete this post. 

Edited June 8, 2020 by Tyoi

[HebaruSan]

Is there an alternate folder for script file installation other than KSP/Ships/Script/? CKAN has received a request to index somebody's script pack, and it seems that they're expected to live in KSP/Ships/Script/, but CKAN is squeamish about installing to non-standard subfolders of KSP/Ships/, so we may not be able to do this. Is there another option somewhere else, perhaps somewhere under GameData/kOS/?

[kcs123]

I'm not sure if kOS scripts should be qualified as full mod at all. Sure, people crating quite complex stuff with kOS that almost look like a mod, but IMHO it much closer to KSP craft files (as some scripts may be even tied to specific craft files) than it is as full mod.

IIRC, regular gamedata folder is deliberately avoided to be used for script files, so on any update of mod or KSP itself users does not loose their personal scripts.

Btw, how CKAN handle other mods that ships craft files as well ? Like FAR, B9PW and similar (those are first that poped up on my mind). Maybe that user can create some dummy folder and dummy config file within gamedata folder and kOS scripts can be then in intended Ships/Script folder ?

Anyhow, each user should be extra careful with installing those, to not overwrite their own homemade script files by installing that mod. There is small probability that there is same script filenames that is shiped with that mod and that some user is already created for himself. Not that it will happen a lot, but it may be possible.

[HebaruSan]

@kcs123, thanks for the reply, but I'm really hoping for an answer to the question I asked rather than derailing this thread with a dozen side issues; suffice it to say that for the most part the things you said are based on misconceptions of one sort or another.

4 minutes ago, kcs123 said:

IIRC, regular gamedata folder is deliberately avoided to be used for script files, so on any update of mod or KSP itself users does not loose their personal scripts.

Is that actually true? It sounds dubious, since it's pretty easy to update mods and KSP without losing custom files in GameData.

[scimas]

10 minutes ago, kcs123 said:

I'm not sure if kOS scripts should be qualified as full mod at all.

Agreed. So many people have already made their scripts publicly on github. And if people want to contribute more general or utility like code, they are encouraged to contribute to KSLib - a standard library of sorts for kOS.

As for the location of the script files, technically they can be anywhere. A Ships/Script/ simlink can then be created. I manage my scripts this way so that updating / deleting a KSP installation doesn't get rid of my scripts. Of course this method has same problems that @kcs123 already described.