Jump to content

[1.3] kOS Scriptable Autopilot System v1.1.3.0


erendrake

Recommended Posts

14 minutes ago, Geschosskopf said:

Option 2:  Write multiple copies of this script and give them all different names corresponding to the processor names on various existing ships, so they can be used as bootfiles by those ships.  Which seems impractical because I don't have any existing ships in the game where I'm just testing scripts.

You don't need to write multiple copies of the script with different names.  By default, if you have a file named "boot.ks" in the archive folder, it will be used as the boot file on new ships.  So you just need a single boot file that changes your settings.  Then, when you start to add more boot files you can either include the same text, or move the logic itself into an external script, or include it in one of your library files.  See that documentation here.

If you already have ships in the game, yes, you would need to copy the boot script to them manually.

But that brings me to option 3, use Telnet instead.  That way you can configure font size external to the game itself, and you don't even need to display the terminal in game.  See the documentation here: http://ksp-kos.github.io/KOS_DOC/general/telnet.html

It's highly unlikely we will make a universal boot file.  That is only a reasonable option when "start on the archive" is enabled.  And installing RemoteTech would kill the feature entirely.

Edited by hvacengi
Link to comment
Share on other sites

1 hour ago, Geschosskopf said:

So feature request:  why not just have a config file to save the user preferences? 

It's not a bad idea, but it's messy to add to the CONFIG object because it's getting kind of big now and having all the options fit on the UI screen is starting to get to be a problem.  Maybe it can be a field within the partmodule's config options - that way it would be possible to manipulate it via ModuleManager or editing the Part.cfg files.

 

Link to comment
Share on other sites

OK, new topic.....

With [ORBITABLE]:VELOCITY or even [ORBITABLE]:ORBIT:VELOCITY, (which are the same thing, apparently) you always get 2 vectors, orbital velocity and surface velocity.  How do I separate those vectors to perform operations on only the orbital velocity one?  And on top of that, how do I play with the individual components of one of them in isolation?

For example, if I do the following:

set OrbVel to SHIP:ORBIT:VELOCITY.
print OrbVel:X.

I get the error that this X is not gettable, then get a printout of both the orbital and surface velocities showing all their components.

So basically, how do I get my hands on SHIP:ORBIT:VELOCITY:X (and Y and Z)?

Link to comment
Share on other sites

I could not find anything about this:

I wrote a script to land a F9 first stage back at the KSC. It works fine if the root part is in the first stage, but I want to fly the rest of the rocket to orbit, and then jump back and land the first stage, or even do a falcon heavy like thing where three boosters separate at two different times, each having a script running. But when I switch to the first stage with FMRS the program is interrupted and has to be restarted.

Is there a way to

a) keep the program running

b) not delete the first stage, so it can land while I ascent

c) easily start a new program (with an action group etc.) and not having to type in "copy f9_1 from 0. run f9_1." So I can just activate a booster return script

 

I hope my question is understandable and not too annoying.

Thanks

Link to comment
Share on other sites

"Easy way" and possible only way to keep kOS program running is to keep craft inside physical range.

If you have already copied program in kOS CPU it should still be there, you only need to run it. I assume (haven't actualy tried it), that should be enough to write proper commands in boot script. See couple of posts back how you can do it.

 

You questions are understandable, we all want to create similar scripts, but some things are out of scope for kOS mod due to KSP game engine limits.
There could be a way to increase distance that influence if craft is "on rails" or inside physical range, 100 km instead of default 2-5 km (don't know exact value). But that would have serious impact on game performance.

All in all, there is no good advice for thing that you want to accomplish.

Link to comment
Share on other sites

1 hour ago, Kamik423 said:

a) keep the program running

b) not delete the first stage, so it can land while I ascent

13 minutes ago, kcs123 said:

There could be a way to increase distance that influence if craft is "on rails" or inside physical range, 100 km instead of default 2-5 km (don't know exact value). But that would have serious impact on game performance.

You can modify the load/unload distance for vessels in flight.  Here's an explaination of kOS's load distance structure: http://ksp-kos.github.io/KOS_DOC/structures/misc/loaddistance.html  You should be very careful when adjusting load distances.  It will often have unexpected results, most notably due to the way that terrain is handled at a distance from the active vessel.  I do not recommend trying to use the feature to perform the actual landing.  You could however use it to allow you to decide when to make the 1st stage your active vessel.

On a related note, there is a bug in the current release (https://github.com/KSP-KOS/KOS/issues/1492) that makes this kind of thing complicated because of how KSP handles decoupling.  That bug will be fixed in the next release.

Using a boot file should be your best option.  I've never used FMRS, but assuming it loads vessels the "normal" way, the boot script should trigger when you select that stage to land.

Link to comment
Share on other sites

3 hours ago, hvacengi said:

You can modify the load/unload distance for vessels in flight.  Here's an explaination of kOS's load distance structure: http://ksp-kos.github.io/KOS_DOC/structures/misc/loaddistance.html  You should be very careful when adjusting load distances.  It will often have unexpected results, most notably due to the way that terrain is handled at a distance from the active vessel.  I do not recommend trying to use the feature to perform the actual landing.  You could however use it to allow you to decide when to make the 1st stage your active vessel.

On a related note, there is a bug in the current release (https://github.com/KSP-KOS/KOS/issues/1492) that makes this kind of thing complicated because of how KSP handles decoupling.  That bug will be fixed in the next release.

Using a boot file should be your best option.  I've never used FMRS, but assuming it loads vessels the "normal" way, the boot script should trigger when you select that stage to land.

FMRS is described here:

It basically splits the saved game into two savegame files when you stage.  Then you can fly each half separately, first using one of the saved games to fly the booster stage to landing, then going back to the other saved game and using it to fly the upper stage to orbit.  After you've done both, then the mod will let you "merge" the saves back together into one, which now has both the landed booster and the upper stage in orbit.

Link to comment
Share on other sites

I totally forgot FMRS. I recall that is mentioned a long time ago on monding mondays, I thought it will be nice mod, but I actualy never tried it due to memory limitation before KSP 1.1.x releases. Thanks for reminder.

Missed that info about reading loading distances too. Good to know. Currently I'm short with free time for KSP, probably I will profit with waiting until all of my favorite mods are updated :)

Link to comment
Share on other sites

I think the way I will deal with this is having the root part on the first stage so at the time of separation the active vessel is the first stage which then will flip, boost back and land all while being the active vessel. There would be a second kOS module on the upper stage and hopefully using the LoadDistance stuff could keep the upper stage in existence (and unpacked) long enough to have another script circularise its orbit, once that's done the upper stage is fine until you change back to it, it can just wait in orbit.

I have used FMRS but I'd REALLY like the ability to do these launch/landings without doing it that way, it has a much nicer feel if you can launch, and watch separation, then follow the landing while the upper stage coasts and eventually circularises. If you planned your flight path right you might even be able to switch to the upper stage and do the circularisation burn yourself, but keeping it from vanishing from existence still needs to be sorted, I don't think you need to increase the distances very much though, boostback and landing happen pretty quickly, I don't imagine the upper stage is TOO far downrange by touchdown, will do some tests later and see

Edit: Forgot to mention the method I'm talking about won't currently work as there's a bug with the steering manager that won't let you control steering of two different stages simultaneously, but it's my understanding that bug should be fixed in a future release, that + Trajectories integration will make for some awesome SpaceX style scripts!

Edited by bradleyjh
Link to comment
Share on other sites

I just upgraded to 1.1.2 and kOS 0.20 from 1.0.5 and kOS 0.19.2

Did the cooked controls change between kOS versions, or is it a change in KSP itself? I'm getting a lot of oscillation, which I didn't before -- it's as if I had a PI controller, not a PID. In my craft I'm able to diagnose changes in yaw; in pitch I also oscillate but that's under more complicated control.

Link to comment
Share on other sites

3 hours ago, numerobis said:

I just upgraded to 1.1.2 and kOS 0.20 from 1.0.5 and kOS 0.19.2

Did the cooked controls change between kOS versions, or is it a change in KSP itself? I'm getting a lot of oscillation, which I didn't before -- it's as if I had a PI controller, not a PID. In my craft I'm able to diagnose changes in yaw; in pitch I also oscillate but that's under more complicated control.

Did the craft change? PID tuning is a fickle business and any change in configuration can cause strange effects.

Link to comment
Share on other sites

6 hours ago, numerobis said:

I just upgraded to 1.1.2 and kOS 0.20 from 1.0.5 and kOS 0.19.2

Did the cooked controls change between kOS versions, or is it a change in KSP itself? I'm getting a lot of oscillation, which I didn't before -- it's as if I had a PI controller, not a PID. In my craft I'm able to diagnose changes in yaw; in pitch I also oscillate but that's under more complicated control.

I reported this on reddit and Hvacengi and I did some testing to figure out what was causing it, I discovered it was having a MechJeb module on the craft doing it and he then discovered that it only seemed to happen if the MechJeb module was located on a fuel tank.

At the time I was using a MechJeb module to have control of the vessel without needing a stacking remote control unit so if you have a MechJeb module try removing it and see if that fixes the issue, if it doesn't then there may be an additional issue here that needs to be reproduced and reported, I'll be happy to help with testing if the above doesn't fix the issue, just give me info and a craft file to test with :)

Edit: in case you wanted to see the original discussion for more information here is the reddit thread: https://www.reddit.com/r/Kos/comments/4g89n0/kos_goes_crazy_when_locking_steering_to_up_in_11/

Edited by bradleyjh
Link to comment
Share on other sites

v0.20.1 KSP 1.1.2 and bug repair

Github: https://github.com/KSP-KOS/KOS/releases/tag/v0.20.1

Spacedock: http://spacedock.info/mod/60/kOS:%20Scriptable%20Autopilot%20System

Curse: http://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files

The biggest reason for this release is to handle two game-breaking
problems caused by recent alterations in the API that kOS hadn't
adapted to correctly yet.

The "remit" of this release is purely to fix a few bugs, and patch up
a few things where KSP 1.1 had changes we didn't catch. Mostly,
that's cases where previously working code in kOS had now become a
bug, but it also includes a few other bug fixes not related to KSP 1.1.

But any new features (rather than bug fixes) in the pipeline not directly
related to that "remit" are not in this release.

BREAKING CHANGES

  • STEERINGMANAGER:SHOWRCSVECTORS and STEERINGMANAGER:SHOWENGINEVECTORS are now obsolete and will throw an error.

BUG FIXES

  • Infinitely growing mass: Realism Overhaul users could not use kOS anymore, because kOS was re-adding its small module mass to the part again and again each physics tick. Even though the mass of kOS is small, adding it to the part 25 times a second quickly made the vessel grow too massive to do anything with. The bug was not caught earlier because it only happened if kOS was added to parts other than the parts kOS ships with (i.e. by using ModuleManager), and those parts also had other mass-affecting modules on them. Although discovered in Realism Overhaul, the problem could have been affecting any users who used kOS in that same fashion. The cause was traced to an incorrect use of the new mass API by kOS and has been fixed. (#1644).
  • "SET TARGET TO FOO." while the terminal is open was failing. Now it works. (The kOS terminal locks out all other inputs so your keypresses don't affect the ship, but as of KSP 1.1 the "all" input lock it was using to do so also includes the ability to set target, which it didn't before.) (#1636)
  • Incorrect value for MeanAnomalyAtEpoch fixed. It was multiplying the value by the conversion factor for radians-to-degrees twice, rather than just once. (#1642)
  • GeoCoordinates were not serializing properly. Now they are. (#1615).
  • Finally fully obsoleted the years-old suffixes for trying to do antenna range the old way (before we just relied on Remote Tech to do antenna work for us). (#1607).
  • Bug fixes for catching a few more cases where staging or decoupling part of the craft away was still confusing SteeringManager into trying to lock out, or take control of, the wrong half of the craft. (#1544).

NEW FEATURES

  • KSP 1.1 now allows you to lock the gimbals for the three pitch/yaw/roll axes individually on engines, as 3 different settings, rather than just lock the whole gimbal for all directions. kOS now lets you access this ability (#1622).
Link to comment
Share on other sites

7 hours ago, numerobis said:

I just upgraded to 1.1.2 and kOS 0.20 from 1.0.5 and kOS 0.19.2

Did the cooked controls change between kOS versions, or is it a change in KSP itself? I'm getting a lot of oscillation, which I didn't before -- it's as if I had a PI controller, not a PID. In my craft I'm able to diagnose changes in yaw; in pitch I also oscillate but that's under more complicated control.

Up until tonight's release, nothing had changed with kOS's steering.  Tonight's update did make changes however.  I have not had the time to make sure that the MechJeb conflict mentioned by @bradleyjh above is fixed.  That will be a primary focus for v1.0.0 (our next anticipated release).  The steering changes release tonight have been in testing by me essentially since KSP release 1.1.0 (though the fixes for decoupling ships have been tested by me for over 6 months).  You should see better performance of steering when relying on control surfaces, as KSP now exposes a basic torque calculation for them.

Link to comment
Share on other sites

I've found it's a pretty easy problem to work around anyway, as I said I was only using MechJeb to avoid having to add a 500kg remote guidance unit (which also doesn't look pretty when using procedural tanks!) which has a decent reduction on the amount of fuel needed to land the first stage doing stage recovery, so if that is the issue you can fix it just by using a different way to control the vessel over a MechJeb unit or by putting MechJeb on something other than a fuel tank. So waiting for 1.0.0 shouldn't be a problem, hopefully that is what's causing the issue for @numerobis

Something else I thought of, are you open to making the kOS modules "Remote Control capable" without torque or anything of course, but so the vehicle can be remotely connected to and controlled by having a kOS module, and in regards to RemoteTech maybe have it its self only capable of 1km or something, just enough to start a script on the pad. I could look at making the changes to parts config and submitting them for review if it can be done just in config? If it's possible I think I'll be modifying my copy of the parts files in any case, seems like it should be simple

Link to comment
Share on other sites

10 hours ago, bradleyjh said:

Something else I thought of, are you open to making the kOS modules "Remote Control capable" without torque or anything of course, but so the vehicle can be remotely connected to and controlled by having a kOS module, and in regards to RemoteTech maybe have it its self only capable of 1km or something, just enough to start a script on the pad. I could look at making the changes to parts config and submitting them for review if it can be done just in config? If it's possible I think I'll be modifying my copy of the parts files in any case, seems like it should be simple

We have so far made a conscious decision not to integrate probe cores into our parts.  The idea is that this is just a plugin module that augments the existing abilities of probe cores/command pods.  There are also potential complications regarding the "reference transform" for our parts as a "control from" source.  I don't know what would happen if you were to try and use either of the radial parts as a control source. I think that it would make more sense for you to add the kOS module to existing probe cores.  We have discussed adding a RemoteTech signal processing unit to the parts, as currently RemoteTech breaks if you don't have a SPU and only probe cores have the SPU by default.  But we have no plans to integrate any kind of antenna to our parts, even as a tech perk.  The requirement that the ship has a probe core for RT to work makes this integration redundant (since all stock probe cores automatically have the tech perk already).

That all being said, we're open to discussion on most of the mods features.  If you feel strongly that there is a good reason to include the integration, please feel free to create an issue on the git issue tracker so that we can discuss the pros and cons directly.

If you do provide these features for yourself, I'd recommend writing it as a MM patch rather than editing the cfg files directly, since the next update would wipe out your changes unless you remember to copy them first.

Link to comment
Share on other sites

 

35 minutes ago, hvacengi said:

We have so far made a conscious decision not to integrate probe cores into our parts.  [...]  I don't know what would happen if you were to try and use either of the radial parts as a control source. I think that it would make more sense for you to add the kOS module to existing probe cores.  We have discussed adding a RemoteTech signal processing unit to the parts[...]

If you do provide these features for yourself, I'd recommend writing it as a MM patch rather than editing the cfg files directly, since the next update would wipe out your changes unless you remember to copy them first.

FWIW, one of the Mechjeb parts attaches radially and works fine as a control source.  As far as I can tell, all's the control source does is determines your reference point and direction for movement (and what section of a ship you retain control of when staging/undocking).

That said, I think it'd be make more sense from a balance perspective to add kOS to probe cores rather than the other way around -- they're already technically computers anyways.  The biggest difficulty would be balancing the MM .cfg against the tech tree progression (since kOS modules have an improving disk-space-to-mass ratio, but probe cores are so much more than just a computer).  I'd also love a "partless" kOS, and already run a MM .cfg for MJ/KER everywhere.

Edited by dewin
Link to comment
Share on other sites

40 minutes ago, dewin said:

FWIW, one of the Mechjeb parts attaches radially and works fine as a control source.  As far as I can tell, all's the control source does is determines your reference point and direction for movement (and what section of a ship you retain control of when staging/undocking).

MechJeb intentionally allows for control.  I presume that the part's model somehow determines the reference direction, but it could simply be based on the local coordinates of the part. There's just a chance that our radial parts could provide that reference the same way that a radially attached docking port would.  I just mean that since probe core control wasn't part of the plan when we designed the parts, it could be that using it as a probe core would cause the reference to stick out the side instead of the front.  Other complications could pop up if not installed flat, like on a rounded surface.

It may also just work.  I honestly don't know since I didn't create the parts.

20 minutes ago, lakilakigant said:

Will you add the ability to execute "if" or "when" statements at any time rather than in a linear fashion as it used to be?

"when" statements are not purely linear now, and they should not be treated as the same thing as "if" statements.  Both "when" and "on" are triggers, you can read the details of their execution here: http://ksp-kos.github.io/KOS_DOC/language/flow.html#when-then-statements-and-on-statements .  Be very careful when using triggers, as they can have unexpected results and will survive until the end of the main program.  Triggers are an advanced topic, and a large number of the support requests we have surrounding them are because people don't understand how they execute.

"If" statements will always be executed linearly.  A break from that function would completely change the concept of how an if statement works, and break from every other language I know of.

If you are meaning to ask if we will ever support executing "when" and "on" statements as if they are their own thread: it is unlikely that we will support any kind of user side threading any time soon.

Edited by hvacengi
Link to comment
Share on other sites

1 hour ago, dewin said:

That said, I think it'd be make more sense from a balance perspective to add kOS to probe cores rather than the other way around -- they're already technically computers anyways.  The biggest difficulty would be balancing the MM .cfg against the tech tree progression (since kOS modules have an improving disk-space-to-mass ratio, but probe cores are so much more than just a computer).  I'd also love a "partless" kOS, and already run a MM .cfg for MJ/KER everywhere.

Second this. I mostly use MJ for info purposes (dV, craft mass, current thrust etc.) and to create maneuver node, less often than before, but still it is essential when you overestimate self pilot skills and become short on dV when you neet to get back home.

That become handy when you build some craft and want to share with others that don't use MJ. Behaviour of craft is the same regardless if you have MJ ort not. Similar thing is with kOS. It will be nice to include it in probe cores, less parts to worry about trough design.

While we already speaking of MJ, it is integrated quite well in career too. You can't use some MJ modules (rover controls, docking for example) until you unlock it trough tech tree. It would not be too hard to do same with kOS.

Such MM patch could be shiped separately from kOS main mod for people who will use it. Also it will be better idea to have different price for storage space, different EC drain rates and similar, rather than changing part mass as you unlock certain kOS part in tech tree. Again, to avoid different craft behaviour if you want to share craft with someone that does not use kOS at all.

Increased EC drain will result in need for additional battery and solar panels that will increase overall craft weight, so result will be the same as you have increased part mass, but craft will behave the same with and without kOS installed.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...