Jump to content

kOS Autopilot


erendrake

Recommended Posts

I would use vim with the syntax highlighting from Steven, but notepad++ works very well

My VIM syntax highlighting is a bit out of date because I have to manually update it every time the main kOS mod adds new keywords, new syntax, or new bound variable names or new suffixes. So it's a pain to keep it up to date. It would be nice to be able to query that sort of data from the mod directly so it's possible to update it automatically, but right now that's not the case.

Link to comment
Share on other sites

what is the syntax for using the new WARP feature of setting it on RAILS or PHYSICS? I haven't been able to figure this out.

PRINT WARPMODE.


SET WARPMODE TO "PHYSICS".
SET WARPMODE TO "RAILS".

Please post if that doesnt work.

Link to comment
Share on other sites

I've been trying to wrap my head around all this crazy, fun stuff (orbital mechanics, ballistics, Kerbals, etc...), and I have a couple of questions.

Being the neuro-atypical I am, I'm diving in over my head. I think I've launched two "stock" vessels, everything else has been with at least Ferram's and Deadly Reentry. What I'd like to do is automate/optimize my ascents and insertions with kOS, but I know that FAR twiddles with things like terminal velocity. I'd be willing to try my hand at setting up a dev environment if anyone can point me in the general direction of how to build out a module/addon that would get kOS to pull terminal velocity (and probably max drag) from FAR rather than the KSP "model"... I just did some quick dipping into the FARAPI code and the VesselUtils code, and I think I might be able to cobble something together.

Of course, if I'm missing out on something critical, like FAR integration already in kOS, or FAR hooking into the core system and transparently integrating, I'll crawl back under my rock in shame... :P

Edited by madlemur
Link to comment
Share on other sites

There's a current bug report for kOS about getting terminal velocity wrong when FAR is installed. kOS still tries using the stock game's terminal velocity, and the way FAR was implemented it doesn't alter the built-in stock values the API returns to all the other mods, but rather it creates a whole new API on the side that other mods have to call instead of the stock API calls. I strongly dislike this approach, since if more mods adopted that approach, it would render the task of making mods compatible with other mods into an enormous task with something on the order of O(n!) special cases in mod code (n being the number of mods that exist that use this type of design that renders the existing stock API incorrect). It seems quite anti-object-oriented design to expose a different API depending on what's present, instead of masking your special exception case behind the same universal API that everyone uses.

If you want to work on FAR integration in kOS, I don't think it's already there. I think it's an area that's open to being fixed.

Link to comment
Share on other sites

Of course, if I'm missing out on something critical, like FAR integration already in kOS, or FAR hooking into the core system and transparently integrating, I'll crawl back under my rock in shame... :P

No shame required :) please feel free to contribute to our little project in any way you like! We always have room for another.

Link to comment
Share on other sites

I agree that it's not the best solution. I'm not sure why ferram implemented it that way, but it's what's there. Maybe he was afraid of breaking something internal to KSP? Anyway, I'll clone the repository and set up a dev environment, and see if I can patch in some FAR support...

Is there a standardized dev environment for kOS? i.e., What compiler, IDE, Unity ver, etc should I be installing for greatest compatibility with the existing code?

Also, I'm going to need a fair amount of handholding as I get started. For example, should I add support via AddOns/FerramAerospaceResearch? How does one check for the existence of another mod? (I think I can guess at how to do it, but the details may be dim now. Something about walking the parts, looking for one of Ferram's modules...)

Edited by madlemur
More questions...
Link to comment
Share on other sites

I agree that it's not the best solution. I'm not sure why ferram implemented it that way, but it's what's there. Maybe he was afraid of breaking something internal to KSP? Anyway, I'll clone the repository and set up a dev environment, and see if I can patch in some FAR support...

Is there a standardized dev environment for kOS? i.e., What compiler, IDE, Unity ver, etc should I be installing for greatest compatibility with the existing code?

Also, I'm going to need a fair amount of handholding as I get started. For example, should I add support via AddOns/FerramAerospaceResearch? How does one check for the existence of another mod? (I think I can guess at how to do it, but the details may be dim now. Something about walking the parts, looking for one of Ferram's modules...)

we have a mixed bag for development, i use visual studio as the IDE and i use whatever unityengine DLL that is packed with KSP. I know that Steven uses SharpDevelop.

I am happy to help out, i am most responsive on google talk/hangouts but you can get me by email as well. [email protected]

Link to comment
Share on other sites

but I know that FAR twiddles with things like terminal velocity.

I just finished a conversation with ferram about this, turns out that chasing TermVel with FAR will likely get your craft torn apart. He posited that other variables like AoA and Current Q would be a better abet more complicated method.

Link to comment
Share on other sites

Which version of Unity should I get for use with KSP 0.24.2?

There is a UnityEngine.DLL that comes packaged with KSP itself that you're supposed to use. It's under (I think - this is from memory because I'm not on my Windows machine at the moment) KSP_Data/Managed/ (or KSP_Data_x64).

The only time you care about the version of unity beyond just "use the one KSP ships with" is when you want to run Unity yourself in order to do things like make meshes and parts. For that information, look at the start of the ouput_log.txt that KSP spits out whenever it runs. It begins with a dump of the Unity Version number.

Link to comment
Share on other sites

Given my (dis)ability when it comes to 3-D modelling and/or texturing, I'll just leave Unity alone for now. erendrake's helped me get things compiling on my system, so now I just need to figure out how to test for FAR, and hook into it for some of the flight variables.

Link to comment
Share on other sites

  • 4 weeks later...

OK, I've come to the painful conclusion that I don't have the time and knowledge to directly help or develop anything. It's a matter of time (mis)management, expectations (mis)management, and an overly exuberant and optimistic desire to fiddle with things (hence the interest in KSP to begin with).

Besides, I've found that there's no need for direct FAR/NEAR integration, and my thoughts on adding a kOS module to the Box Satellite were pre-empted by the addition of a kOS core to the probe core...

So instead, I'm going to pontificate and (with tongue firmly in cheek) grace you with my thoughts of how to improve kOS! :wink:

There are several topics I want to touch on, and I may have missed or jumbled up discussions of these topics in this and other threads. So bear with me...

1: Storage as a resource - I don't worry about it now. I never use the local volume, since I can always use the archive. This will be important later...

2: "Compiled" code - There's been talk of exposing a compiler for kOSript, and there is some monster potential there. If the current modules could only run compiled code, and code could only be compiled at the KSC or with a new compiler-grade module (perhaps a manned module that converts electricity into compiled code), then you'd have to plan a little bit more. Maybe even have differing grades of compilers that could handle different sized sources. (Balance issues that could be worked out later.)

3: Volume accessibility - I use RT2. I like the difficulty of trying to maintain contact with other objects. One of the reasons I like kOS is that I can set up maneuver nodes in blackout zones, but if I fire off exenode (from the toolkit), kOS will correctly run the script even in the absence of a connection to KSC. Sadly, I can always access the archive. :( Even if I enter a number of run XXX. commands while I'm in contact with KSC, my probe will gleefully load and run the scripts from the archive even if it's from the far side of the planet (or any other blackout zone). This begs the question "Why have storage be a resource?" See above...

4: RPM support - Along with compiled code, I'd love to see an integration with RPM's MFD. I was thinking an API to build menus to fire off specific scripts. It doesn't need to be a full terminal (maybe if there's a full keyboard prop), and input might be limited (although I could see some good applications of various selectors for targets, numeric entry, etc.), but something so the IVA can interact with the kOS module. Probably not the easiest thing in the world to do (the MFD itself isn't that hard, it's the new construct within kOS to create, display, and interact with the menus. Come to think of it, that could be useful even in the default terminal...

5: Science module - Not an extension of the current modules, but a separate module that is designed specifically to run experiments and gather/transmit data. Perhaps it reduces the penalty for transmitting experimental data, or can compress the data into fewer Mits. Or is integrated with the Science Alarm... :wink:

6: HDD/SAN - Modules that have no native processing ability, but can provide more local storage. Perhaps integrated directly with one or more modules on the vessel to extend the modules' internal storage (or a command suite available to do so).

7: Skynet Protocol - On second thought...

Just my mental regurgitation of things I was thinking about re: kOS. I was afraid if I didn't post them, I'd forget them. :)

Edited by madlemur
Link to comment
Share on other sites

@Steven Mading

r.e.: Major sweeping changes like would be required to implement such things throughout the C# code require buy-in from everyone ...

Here is my view of what the change would be:

In public abstract class SpecialValue change GetSuffix() to

        
public virtual object GetSuffix(String suffixName)
{
switch (suffixName)
{
case "INFO":
return "Suffix INFO not implemented on this structure";
}
return null;
}

For each class that is a subclass of SpecialValue and contains a GetSuffix() method add a case "INFO": clause. (I am using public class GeoCoordinates : SpecialValue as an example because it appears to be reasonably well documented and not overly long.)


public override object GetSuffix(string suffixName)
{
switch (suffixName)
{
case "LAT":
return Lat;
case "LNG":
return Lng;
case "BODY":
return new BodyTarget( Body, Shared );
case "TERRAINHEIGHT":
return GetTerrainAltitude();
case "DISTANCE":
return DistanceFrom();
case "HEADING":
return GetHeadingFrom();
case "BEARING":
return GetBearing();
case "INFO":
return "GeoPosition.LAT - the latitude\n" +
" .LNG - the longitude\n" +
" .BODY - the body\n" +
" .TERRAINHEIGHT - altitude above sea level\n" +
" .DISTANCE - straight line distance from CPU vessel\n" +
" .HEADING - compass heading from CPU vessel\n" +
" .BEARING - angle between vessel's heading and .HEADING\n" +
" .INFO - this information"
}

return base.GetSuffix(suffixName);
}

Implementing in this manner allows the code to continue to function while the changes are being made. In addition I believe that the changes are localized to the one method. Note that the returned string is only useful for the same purposes as the ToString() method (i.e., as the body of a PRINT, SET or LOG... TO statement).

skips

Link to comment
Share on other sites

Implementing in this manner allows the code to continue to function while the changes are being made. In addition I believe that the changes are localized to the one method. Note that the returned string is only useful for the same purposes as the ToString() method (i.e., as the body of a PRINT, SET or LOG... TO statement).

skips

I dont dislike the idea of a structure having a "manifest" or "info" choice that lets you see what is available. The biggest problem I have is that it shouldn't be something that has to be hand edited each time there is a change.

I agree with Steven when he talks about having a much broader change to the way we handle structures so they are queryable and something like this can be generalized.

Link to comment
Share on other sites

@Steven Mading

r.e.: Major sweeping changes like would be required to implement such things throughout the C# code require buy-in from everyone …

Your original post described many things. The ones I referred to with the phrase "major sweeping changes" wasn't this one.


public override object GetSuffix(string suffixName)
{
switch (suffixName)
{
case "LAT":
return Lat;
case "LNG":
return Lng;
case "BODY":
return new BodyTarget( Body, Shared );
case "TERRAINHEIGHT":
return GetTerrainAltitude();
case "DISTANCE":
return DistanceFrom();
case "HEADING":
return GetHeadingFrom();
case "BEARING":
return GetBearing();
case "INFO":
return "GeoPosition.LAT - the latitude\n" +
" .LNG - the longitude\n" +
" .BODY - the body\n" +
" .TERRAINHEIGHT - altitude above sea level\n" +
" .DISTANCE - straight line distance from CPU vessel\n" +
" .HEADING - compass heading from CPU vessel\n" +
" .BEARING - angle between vessel's heading and .HEADING\n" +
" .INFO - this information"
}

There are at least 3 different places where such information would be useful that I can think of:

- Autogenerated documentation online.

- Printing strings in the terminal as you describe.

- Making information available to IDE and text editor highlighters.

That requires a bit more sophistication than just this string, and could be done by one single system if it was carefully thought out. Basically, I'd like to see this inventing of hardcoded off-the-cuff suffixes in source code in an ad-hoc way to be replaced with having suffixed terms register their suffix names in some common registry of names, and then put the implementation of INFO there, globally. That's better than hardcoding it differently for each type, and helps to minimize the chance of new suffixes being added that fail to get documented.

The only difficulty is how to deal with cases where the suffix names aren't actually known at compile time because they truly are dynamically created, like the resource names LIQUIDFUEL, SOLIDFUEL, ELECTRICCHARGE, and so on.

Link to comment
Share on other sites

The only difficulty is how to deal with cases where the suffix names aren't actually known at compile time because they truly are dynamically created, like the resource names LIQUIDFUEL, SOLIDFUEL, ELECTRICCHARGE, and so on.

If C# supports "closures," there are a couple of elegant approaches to handling dynamically created resource names that are consistent with my original proposal.

skips

Link to comment
Share on other sites

Are there still plans for making the frame of reference coherent and, if so, what should I expect?

I've slowed down on pushing for adopting that because of the recent change that now allows any of the things kOS previously only gave out as Rotations to now be retrieved as Vectors. This has opened up a number of workarounds that were previously impossible. If you can convert rotations to vectors, then you can turn the cardinal directions of most interesting frames of direction into basis vectors of a reference frame. Once you have the 3 basis vectors of a reference frame, then you can see how any vector would be represented in that reference frame using those 3 basis vectors and dot products.

It's not an ideal solution. It's still just a workaround. But the existence of the workaround made it less of an immediate need. I've been putting my spare time into working out a way to store the compiled program as a "machine language file", so you don't have to send source code on remote probes. It's one of those things that looked a lot easier at first before all the ugly details were dived into so it's been sucking up all my kOS programming time.

Reference Frame - aware vectors is still a thing on the back of my mind, but of late, erendrake and I have had our minds more concentrated on the basic language features like better help, more organized OOP style features, and so on. We ran into a roadblock where many of the new end-user features we wanted to make all required things the language just couldn't do under the hood, so it was time to overhaul a bit of what's going on under the hood.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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