Jump to content

[KSP 1.10.1 and 1.11] kOS v1.31.0 : kOS Scriptable Autopilot System


Recommended Posts

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.

Link to post
Share on other sites
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 by Steven Mading
Link to post
Share on other sites
16 minutes ago, Bongotastic said:

7ncC88G.png

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.

Link to post
Share on other sites
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. 

Link to post
Share on other sites

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.

Link to post
Share on other sites
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 by Steven Mading
Link to post
Share on other sites
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.

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 by HebaruSan
Link to post
Share on other sites

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 by ManEatingApe
Link to post
Share on other sites
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 by ElWanderer
Link to post
Share on other sites
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 by ManEatingApe
Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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:

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.

Link to post
Share on other sites
  • 2 weeks later...

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/?

Link to post
Share on other sites

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.

Link to post
Share on other sites

@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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...