kOS Autopilot

[erendrake]

Another pre-release! I think this is the last pre for the direct control and docking milestone

https://github.com/erendrake/KOS/releases/tag/v0.11.1RC

NEW STUFF

• Added to BODY:ATM:SEALEVELPRESSURE
  
• Added Ctrl+Shift+X hotkey to close the terminal window (jwvanderbeck)
  
• Added a DockingPort Part Type, You can access it by "LIST DOCKINGPORTS IN ..."
  
• Improved RemoteTech integration (jwvanderbeck)
  
• SHIP:CONTROL:NEUTRALIZE releases the ship from KOS direct control.
  
• Added PART:CONTROLFROM which centers the transform on that part.
  
• Power requirements are now directly tied to the active volume's size, the ARCHIVE's size is unlimited so it is capped at the equivalent of 50KB.
  

[Camacha]

Another pre-release!

A lot of useful stuff to get things working smoothly Two things stand out:

[*] Added to BODY:ATM:SEALEVELPRESSURE

I am not sure kOS should provide all kinds of numbers in what has been called a magic way. I much prefer kOS only providing numbers that are realistically provided by such a system (like thrust, sensor values et cetera). I am not sure that sealevel pressure is magic, but it does kind of feel like it is handed to you (instead of, for instance, having to send a probe).

[*] Power requirements are now directly tied to the active volume's size, the ARCHIVE's size is unlimited so it is capped at the equivalent of 50KB.

As a minor quabble I would say that volume size and power consumption are realistically not related - of course you could think of more chips using more power, but in general power consumption is of course dictated by clock speed. I understand this is a gameplay mechanic, though.

I really need to freshly install my computer so I can get cracking

[Dunbaratu]

Realistically I'd imagine that the power consumption for a storage device would actually be inversely proportional to its storage capacity simply because the smaller drives are older drives that aren't as streamlined. You can get a lot of storage on a modern smartphone and yet keep running it on battery alone for quite a few hours (and most of that battery is being drained by the display and CPU not memory). To store a tiny fraction as much permanent storage used to require a disk drive the size of a washing machine.

Camcha, you are operating on the false assumption that the probe is operating without anyone back at home having done any analysis beforehand. If you didn't know the stats of the body beforehand you couldn't even send the mission in the first place. NASA already knew, for example, the mass of Mars, its radius, and the atmospheric density at the ground, prior to sending the Curiosity probe there. If it didn't have that information, then the complex landing procedure of the probe would never have been possible to engineer.

A lot of the data provided by the body structure is data that was known before the space race even began. When the Soviets sent probes to Venus, they already knew perfectly well what sorts of high air pressures they were going to have to design the probes for. There's a lot that's learned from afar with telescopes and math and spectroscopy.

The stuff in the BODY structure is stuff a space agency has to know before it even begins work on designing the vessel for the mission. If you didn't know the body's radius and mass and atmosphere, you'd have no clue whether or not parachutes would work, how well they'd work, whether you should use them at all, and you'd have no idea how strong the effect of gravity would be so you don't know how powerful the engines have to be, how much fuel consumption to expect, and so on and so forth.

Edited February 24, 2014 by Steven Mading

[erendrake]

Realistically I'd imagine that the power consumption for a storage device would actually be inversely proportional to its storage capacity simply because the smaller drives are older drives that aren't as streamlined.

You are right about more advanced technology makes for bigger drives with less power usage, but we dont have advancement in tech yet in KOS so i am assuming you are using the same reel to reel tape from 500B to 500KB. I would really like to have tech tree integration and it is on my list and then all of this will make more sense.

The stuff in the BODY structure is stuff a space agency has to know before it even begins work on designing the vessel for the mission.

Some of these BODY numbers can be very well known simply by observing its orbit, others would require powerful telescopes. I am not sure you could get exact values without more direct observations? I was considering rounding some of these values and adding some kind of achievement/techtree mechanism to add the rest of the precision back over time.

I would really like to do some kind of tech tree thing for KOS can you tell

[Camacha]

Camcha, you are operating on the false assumption that the probe is operating without anyone back at home having done any analysis beforehand. If you didn't know the stats of the body beforehand you couldn't even send the mission in the first place. NASA already knew, for example, the mass of Mars, its radius, and the atmospheric density at the ground, prior to sending the Curiosity probe there. If it didn't have that information, then the complex landing procedure of the probe would never have been possible to engineer.

A lot of the data provided by the body structure is data that was known before the space race even began. When the Soviets sent probes to Venus, they already knew perfectly well what sorts of high air pressures they were going to have to design the probes for. There's a lot that's learned from afar with telescopes and math and spectroscopy.

The stuff in the BODY structure is stuff a space agency has to know before it even begins work on designing the vessel for the mission. If you didn't know the body's radius and mass and atmosphere, you'd have no clue whether or not parachutes would work, how well they'd work, whether you should use them at all, and you'd have no idea how strong the effect of gravity would be so you don't know how powerful the engines have to be, how much fuel consumption to expect, and so on and so forth.

On the contrary - if you already know all the stats beforehand, you would not have to send a probe Of course, there is a lot to be learned from observation from afar. Yet history shows us this only gets you to a certain point. There comes a time you will only learn more by putting men or machines on the ground - or at least close by.

The examples you give illustrate that beautifully. Venera landers 3 through 6 were designed with a hull strength of 25 atm and subsequently, they all failed upon entering the atmosphere (although 5 and 6 were relabeled as atmospheric probes). It was not until the Mariner 5 probe did close up measurements that we realized that Venus has a surface pressure in the realm of 75-100 atm, a lot more than anyone expected. Not only did we learn about the circumstances on Venus by sending probes there, these first probes were in fact ill equipped to deal with the Venusian atmosphere. They were built to our best knowledge, which turned out to be not so good.

The same goes for the first Martian probes. We had some rough ideas what to expect, but a lot of it came down to an educated guess. It was not until we sent some probes there that we got a better idea of surface pressure and temperatures, water content and more basic stuff like that. You mention Curiosity, but that is of course a rover that has greatly benefited from previous missions. I doubt that such a complex undertaking would be possible without prior knowledge - and thus measurements - of local circumstances. Let us not forget that about 60% of Mars missions failed, most of which in the earlier years.

All this makes me feel that surface pressure is a magic number provided to the player. Let us not forget that we are dealing with an in-game universe similar to our 50's or 60's. In real life, our discoveries and knowledge were hard won and I feel it should be not different in the KSP universe.

Personally, I try to do all my measurements myself - even stuff like Kerbin weight and size - but I do very much understand that this is not for everyone. I think we have to make a decent assumption of what Kerbin scientist have been able to learn from afar and leave the rest for the player to discover. I would put surface pressure well within that rest category.

[Dunbaratu]

Personally, I try to do all my measurements myself - even stuff like Kerbin weight and size - but I do very much understand that this is not for everyone. I think we have to make a decent assumption of what Kerbin scientist have been able to learn from afar and leave the rest for the player to discover. I would put surface pressure well within that rest category.

What seems silly is that you had no complaint when the rest of the atmospheric numbers got added. The scale of the falloff rate of the pressure was already there in previous updates and you didn't complain about them. Knowing the scale for the change in pressure as you go up in altitude might as well not have been there if you want to have the pressure itself be unknown. I asked for sea level pressure to be added because the data that was already there had no meaning when it was missing. And wouldn't have been available if pressure wasn't already known. "Here's the rate of change of the thing we've never gotten any numbers for."

Furthermore the information you are talking about is already there in game for the human player. On the map screen. Even without kOS. All this does is let you write code thats not hardcoded and instead lets you use the current body as a lookup key to get to the atmosphere data that you clearly already have in the game as a human.

If you don't like knowing anything about the atmosphere pressure, asking kOS to pretend the player wasn't already given it by SQUAD is a bit late to be trying to change it.

[Camacha]

What seems silly is that you had no complaint when the rest of the atmospheric numbers got added. The scale of the falloff rate of the pressure was already there in previous updates and you didn't complain about them. Knowing the scale for the change in pressure as you go up in altitude might as well not have been there if you want to have the pressure itself be unknown. I asked for sea level pressure to be added because the data that was already there had no meaning when it was missing. And wouldn't have been available if pressure wasn't already known. "Here's the rate of change of the thing we've never gotten any numbers for."

I feel exactly the same about other atmospheric values, as well as any other magic numbers. I am sure I have voiced this on a number of occasions. Sea level pressure is just one of them. It is true that I am currently very busy, so I might very well have missed relevant changes and discussion in the past weeks.

If you don't like knowing anything about the atmosphere pressure, asking kOS to pretend the player wasn't already given it by SQUAD is a bit late to be trying to change it.

I think it is a good discussion to have, even if it is just to establish the general rules of engagement for things like this - especially since Nivekk (Kevin) and erendrake are both quite methodical in their approach. Which I like, I might add.

Personally I would like to push for only using numbers that could be conceivably measured, even if by unconventional methods, but I also recognize that the mod should appeal to a broad public with different wishes and play styles. There is obviously some tension between those viewpoints, but I do think there is a lot of common ground too.

[lijat]

One idea if one does not want the numbers to be magic is for KOS to keep track of measurements made, then the pressure can be known it a probe has been sent and provided by KOS in those cases (presumably in some database in KSC) if no measurement has been made KOS could return null or whatever error code might be suitable.

[Dunbaratu]

I think it is a good discussion to have, even if it is just to establish the general rules of engagement for things like this - especially since Nivekk (Kevin) and erendrake are both quite methodical in their approach. Which I like, I might add.

My take is this: When the human player was already given the data by SQUAD then trying to hide that data from kOS just means the human player writes less portable code. The script code will be better designed if that data that a human has learned is available in a cleaner way instead of being ad-hoc cobbled together differently by each player.

And even if it's something that wasn't already given by SQUAD like atmosphere is, think of what the code would look like *after* the player learns a thing about a body and uses it on their subsequent missions. If you're disallowing that information from being in BODY then you're having code that looks in two different places for BODY information. kOS script isn't sophisticated enough to let a player subclass the body database and add more to it themselves, so they'd be maintaining a separate independent body database in parallel to the one in the game.

Your false dichotomy assumes two viewpoints with people being on a line between them - on the one end people wanting kOS to be easy with broad appeal, and on the other end people wanting kOS to have even less information than the game gives a human being. My viewpoint is primarily about wanting not to have to write sucky code. And that means avoiding having two different parallel body databases - one that kOS built-in and a second one that I make on the side.

[Camacha]

think of what the code would look like *after* the player learns a thing about a body and uses it on their subsequent missions. If you're disallowing that information from being in BODY then you're having code that looks in two different places for BODY information. kOS script isn't sophisticated enough to let a player subclass the body database and add more to it themselves, so they'd be maintaining a separate independent body database in parallel to the one in the game.

I totally agree Forcing the player to maintain or use multiple databases is not very desirable. The multitude of purposes for a database, playstyles and wishes also means that it is nigh impossible to maintain a set of values that would be comprehensive and that also pleases everyone. It would therefore probably be best that kOS provides suitable tools, so that players can set up and maintain the databases they desire, leaving it to those users to fill them with appropiate values.

This also syncs wonderfully with the idea that kOS should provide tools and not solutions

[Dunbaratu]

I totally agree Forcing the player to maintain or use multiple databases is not very desirable. The multitude of purposes for a database, playstyles and wishes also means that it is nigh impossible to maintain a set of values that would be comprehensive and that also pleases everyone. It would therefore probably be best that kOS provides suitable tools, so that players can set up and maintain the databases they desire, leaving it to those users to fill them with appropiate values.

This also syncs wonderfully with the idea that kOS should provide tools and not solutions

This came about because I had my own body database in script form before and I'm trying to change my code to use the one in KOS instead. Either kOS should provide BODY information, or it shouldn't. All one or the other. What it should *not* do, is provide half the body information, which is what causes the need for two different parallel places to lookup body information, one provided by kOS and one I made up myself.

I'd favor supporting both play styles. Put the data there. Use it if you like, or ignore it if you like. That's identical to what already happens when playing the game manually under human control. You don't have to go pull up the info tab in the map view if you don't want to, but it's there for players that do want to.

The problem is that you're asking for everyone to have to play it your way. There is nothing about having the data there that stops you from playing it your way by just not using it. There IS something about insisting that it be removed that DOES prevent others from playing it their way.

I also don't agree with the idea that kOS should never incorporate any information from the later days of the space program, because Sandbox mode exists.

How would you feel about this idea:

In Sandbox mode, the body database has everything fully populated up front, because, hey, it's sandbox mode where the presumption is your space program has hit the top of the tech tree and knows everything already.

But in Career mode, the body database masks off some of the data, but detects when it's been measured by you in game and flags something inside kOS to remember that you've already gotten the measurement for it already, and then allows it to become unlocked after that (*). Thus the code would work properly and cleanly, and represent that your space agency has updated the data in the database like they *would*, rather than stubbornly insisting that the database must be frozen and never be added to and any new information needs to be put in a new, second database, which makes for ridiculous code. If this was done, it would be ridiculous, and incorrect, to assume the space agency knows nothing about the mass of a body or its radius and its orbital parameters and position data before sending a probe. Those are learned BY watching the planet from afar - it's mass being deduced from the effect its gravity has on the motion of other things, it's radius being deduced from the angle in the field of vision it takes up at a known distance, and so on. Even the atmosphere IS known to some extent beforehand - just not precisely. (It's not like they were expecting Venus to be barren without air.) So to simulate this you have the data produced by the body atmosphere database be present but imprecise and "wiggly" until after the probe was sent.

The above may be too much work to implement, but if it is, then erring on the side of giving too much information is less ridiculous than erring on the side of hiding known information that the space agency already has.

(*) If this was done, perhaps the way to detect that the information is already learned is to just hook into the science experiment logs. The game already tracks whether or not you've done a particular experiment before and gotten information back about it, so you look for things like "obtained barometric pressure reading from Eve's surface" in the science logbook to decide whether or not that data is available in BODY:ATM or not.

That would satisfy your complaint without adding the annoying insistence that the BODY database must be implemented entirely out in the script language with each user having their own different set of function calls for doing it. See, I like sharing code, and I'd much rather be able to say "here's a neat program I want to show off, and it will run in sandbox mode, or in career mode if you have previously visited Eve and taken a pressure reading from its surface" than have to say "along with this program you must also get my own body database because there is no standard for how to do that so you need my body database too and even if you made your own it probably doesn't have the same interface as mine does so it won't work with my code."

Here is what I am 100% convinced would happen if you removed the BODY database from kOS: the user community would replace this lack by sharing their own community-made body database instead of each user making their own, putting things right back where they were before. Why am I convinced this would happen? Because I'd do it. I was on the verge of doing it before when Kevin went AWOL and I waited to see if kOS had a future before deciding to do it, and then erendrake's version clearly was heading toward having a fully populated BODY database so I stopped.

Edited February 25, 2014 by Steven Mading

[erendrake]

So im ready to release v0.11.1.

This release is mainly about Direct flight control, and enabling autonomous docking.

https://github.com/erendrake/KOS/releases/tag/v0.11.1

It will go up on spaceport soon.

[CaptainKipard]

I'm happy to see thrust limiters implemented.

WRT docking scripts, is there already a way of getting the relative situation of targeted docking ports?

[erendrake]

I'm happy to see thrust limiters implemented.

WRT docking scripts, is there already a way of getting the relative situation of targeted docking ports?

You can get the relative rotation now, the distance, and direction to the target. Im pretty sure you are talking about having the x/y/z meters to the docking port and im sure i will add them soon but for now you get to do a bit of trig to get them. Also i promised marianoapp i would stop adding features until we were able to bring in his amazing new parser.

[CaptainKipard]

Is this update meant to be game-breaking?

Edit

No I don't think so. This release isn't fit for purpose. Even with a new game any kind of loading from quicksave or persistence, makes everything disappear.

Edited March 1, 2014 by Cpt. Kipard

[erendrake]

Is this update meant to be game-breaking?

Edit

No I don't think so. This release isn't fit for purpose. Even with a new game any kind of loading from quicksave or persistence, makes everything disappear.

Do you have a KSP log for me to look at? I cannot make this happen on my machine but we should try and fix it. do you have any other mods installed?

[CaptainKipard]

Yes I have a LOT of mods. Where would I find the log? The game isn't crashing so there's no extra folders that I usually get when I run out of memory or something.

[erendrake]

Yes I have a LOT of mods. Where would I find the log? The game isn't crashing so there's no extra folders that I usually get when I run out of memory or something.

in the root KSP folder there will be a KSP.log file. if you upload it to someplace like gist https://gist.github.com/ and link it in here. ill see if i can find the trouble.

[CaptainKipard]

Here10char

[Camacha]

i will add them soon but for now you get to do a bit of trig to get them.

Is doing trig not half the fun? If you can readily calculate the values you need, I am not sure you also need a function that does it for you - unless it is some extensive calculation that will eat up half your script of course. On the other hand, most modern languages have these kinds of things and you could of course consider it a tool as well as a bit of a solution.

Edited March 1, 2014 by Camacha

[erendrake]

unless it is some extensive calculation that will eat up half your script of course.

That is what i was afraid of. I am actually just waiting for one of you to tell me that it is a huge pain and show me all of the crazy code it takes first if it turns out to be not a big deal i might just leave it as is.

[CaptainKipard]

Is doing trig not half the fun?

Yeah I agree with this. Doing calculations and making elaborate scripts is the whole reason I use this instead of Mechjeb, I'm not sure there's any sense going in that direction. The values you told me about seem to be sufficient. Maybe I'm missing something it's just more realistic this way.

Edited March 1, 2014 by Cpt. Kipard

[erendrake]

Yes I have a LOT of mods. Where would I find the log? The game isn't crashing so there's no extra folders that I usually get when I run out of memory or something.

I underestimated how many mods you had you overflowed gist. would you just email that file to [email protected] ?

[CaptainKipard]

If you click "view full file" you'll see the whole thing. There's nothing else in there.

[Boamere]

As an absolute noob to KOS (and DOS ) is there a way to point towards manoeuvre node without coding a massive amount?