kOS Autopilot

[erendrake]

NEW RELEASE v0.15.0

We have a huge new release with fun toys for you all to play with.

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

NEW FEATURES:

Please follow the links to see the full information on the new features.

* Added new kOS GUI panel to the KSP Applauncher system. With this you can alter config values, and open/close terminals from one common panel. Just click the little kOS logo button in either the editors (VAB/SPH) or in flight view.

* Added pilot input to flight controls which lets you read/write the users control state, you can use this to set the exit behavior for the mainthrottle.

* Several suffixes are now methods that you can call with arguments.

* eg before to add to a list it was SET LIST:ADD TO "FOO". Now it would be LIST:ADD("FOO").

* Suffix methods that perform an action do not need to be assigned to anything. No more having to say SET DUMMY TO MYLIST:CLEAR. You can now just say MYLIST:CLEAR. like it was a statement.

* Added suffixes to OBT for walking orbit conic patches

* ORB:HASNEXTPATCH - A boolean that shows the presence of a future patch

* ORB:NEXTPATCH - The next OBT patch

* Added better techniques for selecting the Part you want from a Vessel:

* Ability to give any part any name you like with the new nametag feature.

* Directly querying a vessel for parts, searching for nametags, or part names or part titles.

* SHIP: PARTSDUBBED(string)

* SHIP: PARTSNAMED(string)

* SHIP: PARTSTAGGED(string)

* SHIP: PARTSTITLED(string)

* SHIP: PARTSINGROUP(string)

* SHIP: MODULESNAMED(string)

* Walking the parts Tree:

* PART: CHILDREN - A ListValue of parts that are descendant from the current part

* PART: PARENT - A PART that is the ancestor of the current part

* PART: HASPARENT - A boolean that shows the presence of a Parent PART

* SHIP: ROOTPART - The first part of a ship. The start of the tree of parts. identical to SHIP: PARTS[0].

* SET MyList TO SHIP: PARTS. now does the same thing as LIST PARTS IN MyList.

* A new system lets you access the PartModules that the stock game and modders put on the various parts. Through this, you now have the ability to manipulate a lot of the things that are on the rightclick menus of parts:

* PART Suffixes:

* GETMODULE(string)

* ALLMODULES.

* PartModule Suffixes:

* GETFIELD(field_name) - read a value from a rightclick menu

* SETFIELD(field_name, new value) - change a value on a rightclick menu, if it would normally be adjustable via a tweakable control.

* DOACTION(name_of_action_) - cause one of the actions that would normally be available to action groups *even if it hasn't been assigned to an action group*.

* DOEVENT(event_name) - "presses a button" on the rightclick part menu.

* Several others..

* Lists are now saner to work with with no longer needing to use weird side effects to get things done, now that there's proper methods available:

* :ADD has changed:

* Old Way: SET MyList:ADD TO NewVal.

* New Way: MyList:ADD(NewVal).

* :REMOVE has changed:

* Old Way: SET MyList:REMOVE TO indexnumber.

* New Way: MyList:REMOVE(indexnumber).

* :CLEAR has changed:

* Old Way: SET Dummy to MyList:CLEAR.

* New Way: MyList:CLEAR().

* Added ENGINE:AVAILABLETHRUST suffix. A value that respects the thrust limiter

* Added SHIP:AVAILABLETHRUST suffix. A sum of all of the ship's thrust that respects thrust limiters

* Added a new experimental COMPILE command, for making smaller executable-only programs to put on your probes without punishing you for writing legible code with comments and indenting.

* Filename convention changes:

* Commands that deal with filenames will now allow any arbitrary expressions as the filename, except for the RUN command.

* *Exception*: The above does NOT apply to the ``

[code single]RUN

`` command. The run command requires that the filenames are known at compile time, and it cannot allow arbitrary expressions evaluated later at runtime.

* Program files are now called *.ks instead of *.txt. When you first run the new version, it will give you an option to rename your files to the new name for you as they are moved to the new location.

* Although the default script filenames use *.ks, you can override this and explicitly mention filename extensions in all the filename commands. What you can't do is have filenames with no extensions.

* Added support for CKAN

* Added config file so kOS will now show up in Automatic Version Checker (AVC)

CHANGES BREAKING OLD SCRIPTS:

* BREAKING: .txt files are now .ks files: The new assumed default file extension for files used by kOS is *.ks rather than *.txt. This may confuse old IDE's, or your computer's assumed file associations.

* BREAKING: VesselName: Removed previously deprecated term "VESSELNAME", use "SHIPNAME"

* BREAKING: SHIP:ORB: PATCHES: Moved SHIP:ORB: PATCHES to SHIP: PATCHES and it now contains all orbit patches

* BREAKING: Lists: New syntax for using :ADD, and :REMOVE suffixes for lists requires old code to be altered. See features above for the new way.

* WARNING: Bundled ModuleManager: Because kOS now needs ModuleManager, and ModuleMangaer complains about being run on Windows 64bit, you now see a new warning message if you run kOS on Windows 64bit, but the message is ignorable and kOS still runs.

* BREAKING: identifiers as filenames: If you use the same name for a filename as the name of a variable, in a file command such as COPY, DELETE, etc, then kOS will no longer use the variable's name as the filename but will now use the variable's contents as the filename.

BUG FIXES:

* PartValue: POSITION not using ship-relative coords

* Boot file name is case sensitive

* Engine reports maxthrust on :ISP suffix

* LIST VOLUMES IN <list> makes an empty list.

* Parser doesn't understand THING[num]:THING[NUM] or thing[index]:suffix(arg)

* ship:obt: patches seems to be missing some of the patches (Note: in addition to fixing it, the patches list was moved to just ship: patches, which makes more sense).

* Compiler should throw exception on trying to put a WAIT in a trigger.

Edited November 17, 2014 by erendrake

[erendrake]

New Pre-Release v0.15.4

this is a shoot from the hip update that we put together in a few hours. it has almost no testing so please let us know if you have any trouble with it.

v0.15.4

0.90 took us by surprise so this has had very little testing. if you find an issue please let us know either here in the github issues or on the forums.

BREAKING CHANGES

Issue #431: SHIP:ANGULARMOMENTUM and SHIP:ANGULARVEL have been changed from directions to vectors to me more consistent with their nature

New Stuff:

Should now be compatible with KSP 0.90

Bug Fixes:

Issue #421: some local files are corrupt

Issue #423: its possible to create a file with no extension

Issue #424: additional bootfile suffix protection

Issue #429: files sent to persistence file no longer get truncated

On Github: Download

[Camacha]

I have found some behaviour that I think is intentional, but causes some issues:

- It is impossible to readout the throttle without the global throttle setting actually being modified. This means that reading a throttle setting and modifying it becomes troublesome, since the modified result will be influenced by the unmodified input. A workaround might be to use another axis for throttle input, like a translating axis, but I do not consider that ideal.

- Inversely, it is impossible to set the throttle through kOS without locking the user out completely.

In my mind, there would ideally be some way to disconnect the throttle setting and throttle input completely. That would allow reading the setting, modifying it and sending it on to the global setting. Hacking something together with the thrust limiters and some compensating mechanism to un-input the throttle is possible, but again, probably not ideal. I noticed the thrust limiters themselves can be set beyond a 100%, but that is actually a useful property as the engine does respond accordingly I might be overlooking some good reasons not to do this though, so I would love to hear your thoughts.

There has been some trouble with I think an old bug too. Whenever I quicksave a running kOS unit, reloading causes parts to fall off. More reloading or going to back and forth to the VAB causes a craft in limbo with flames all over.

Finally, I reproduced the kOS logo as a vector drawing for my fly-by-wire video, as I could not find any versions in a decent resolution. If you ever need it, you know where to find it.

[Dunbaratu]

First: a clarification about the "parts fall off" - what's actually happening is that ONE part is affected. It's not fallen off, but in fact is vanished entirely - the SCS part fails to be created at all. Then all the parts that are meant to be attached to the vessel via the SCS part are now attached to nothing, and that's what makes them "fall off". I noticed this once and took a mental note of it. It's really just the SCS part - everything else is a consequence of it being missing. I'll be willing to bet it's because of the code that makes an attempt to restore the varaible state. It was written totally wrongly and I'd like to see it entirely removed until a replacement can be found. It's a thousand times less bad for the program state to be forgotten when you switch scenes than for parts to fall off.

As for thrust limiting - I think it's wrong for it to be used to actually *increase* an engine's output past its maximum. That seems like a massive bug. It may be useful, but don't depend on it - it should be fixed.

As for locking the pilot out - you can read the pilot's inputs even while they are being locked out and ineffective (as I understand it), and thus use them as a suggestion your script can decide what to do with - sort of the Airbus style of control where the pilot's joystick has no hydrolic , mechanical, or electrical connection whatsoever to the control surfaces. It's just a digital input to the autopilot software and the software decides what it feels like doing with that information. (A method with both good and bad consequences. The good is that the autopilot can prevent the pilot from doing something wrong, but the downside being that the pilot is helpless to prevent the autopilot from doing something wrong.)

[Camacha]

As for locking the pilot out - you can read the pilot's inputs even while they are being locked out and ineffective (as I understand it), and thus use them as a suggestion your script can decide what to do with - sort of the Airbus style of control where the pilot's joystick has no hydrolic , mechanical, or electrical connection whatsoever to the control surfaces. It's just a digital input to the autopilot software and the software decides what it feels like doing with that information. (A method with both good and bad consequences. The good is that the autopilot can prevent the pilot from doing something wrong, but the downside being that the pilot is helpless to prevent the autopilot from doing something wrong.)

That is indeed exactly my intention and in fact one of the real life examples I was thinking of. I took another look at the documentation and realized I completely missed the fact that you can now set and read the ship:control:mainthrottle. As far as I knew you still had to lock the throttle and obviously you are locking yourself out of control by doing that. However, I still seem to have trouble either just intercepting the pilot throttle without influencing the final throttle and vice versa, though at this point am not not too sure it is my lack of understanding kOS or actually a bug.

When I read or set the pilotmainthrottle, I can see the value change and the craft's engines respond appropriately (so throttle is influenced by player input):

clearscreen.
abort off.

set ship:control:pilotmainthrottle to 0.25.

until abort = true {
	print "Pilot throttle: " + round(ship:control:pilotmainthrottle, 2) + "     " at (0,5).
	print "Mainthrottle: " + round(ship:control:mainthrottle, 2) + "     " at (0,6).

	print "Pilot active :" + ship:control:pilotneutral + "     " at (0,8).
}.

set ship:control:neutralize to true.
unlock all.

However, when I try to set the throttle to anything else via kOS, I get locked out of setting or reading the throttle setting through the interface. Additionally, when I run the first script again, I am still locked out and I need to revert to launch to get it working again.

clearscreen.
abort off.

//changed this value from pilotmainthrottle to mainthrottle
set ship:control:mainthrottle to 0.25.

until abort = true {
	print "Pilot throttle: " + round(ship:control:pilotmainthrottle, 2) + "     " at (0,5).
	print "Mainthrottle: " + round(ship:control:mainthrottle, 2) + "     " at (0,6).

	print "Pilot active :" + ship:control:pilotneutral + "     " at (0,8).
}.

set ship:control:neutralize to true.
unlock all.

Am I overlooking or misunderstanding something? How should I intercept the throttle without the pilot setting influencing the actual throttle?

As for thrust limiting - I think it's wrong for it to be used to actually *increase* an engine's output past its maximum. That seems like a massive bug. It may be useful, but don't depend on it - it should be fixed.

You cannot really increase an engine's output past its maximum, you can only set the thrust limiter beyond 100%. The engine will only provide its maximum thrust regardless. When you set the throttle to 0.5 and the limiter to 200% you get full thrust (0.5 * 200% = 100%), but when you set the limiter to 300 you still only get a 100% thrust. It just tops out.

It is still not something you can normally do in KSP and that would be a fair reason to remove it, but the impact seems to be somewhat limited Of course, the impact of removing it is therefore limited too. I felt it was useful to deal with the issue of the locking command, but it appears that was not an issue that actually needed solving

Edited December 24, 2014 by Camacha

[Camacha]

Can I do a small feature request? Can :mass be added to the part properties? Or is that something that is not readily available?

[Dunbaratu]

Can I do a small feature request? Can :mass be added to the part properties? Or is that something that is not readily available?

That should be doable. In the underlying KSP API, a Part has both a mass value (The dry mass) and a GetResourceMass() method (which returns the sum of the masses of all the resource levels currently contained in the part, i.e. oxidizer+liquidfuel).

[erendrake]

Can I do a small feature request? Can :mass be added to the part properties? Or is that something that is not readily available?

Sounds good, mind adding the issue to github?

[Camacha]

Sounds good, mind adding the issue to github?

Done

In regards to my earlier post, might this issue be partially or fully related to it? I neglected to check GitHub before I posted the issue here, but it sounds like what I am dealing with. I cannot figure out a way of intercepting a control from the player and sending it on to KSP without the two either interfering with each other or having nothing work at all, though at this point I started seriously doubting myself.

Edit: I gave up for now and used the ship:control:pilottop axis instead of the official throttle. That works like it should.

Edited December 24, 2014 by Camacha

[hvacengi]

Over the holiday weekend I tried to add support for the new built in autopilot features (just prograde and maneuver for the initial proof) and I ran into a weird complication. I added the abilities to the "toggleflybywire" function, and implemented them in the FlightControlManager. Through my first round of testing I only used the commands directly from the console, and both worked with no issues. Then I tried to run the command from within a script, and it failed. Through a bunch of debugging, I've found that it looks like the opcode has an extra pop, which is causing an error with the stack being queried out of range (it appears to be trying to pop at an index of -1, with the stack empty). Digging into the opcode is a little beyond my knowledge of kOS, so I thought I would bring it up here. I didn't want to make a pull request to bugged code, but you can see/clone my changes here: https://github.com/hvacengi/KOS/tree/Enable-builtin-autopilot

The script I am trying to run afterwards is pretty simple:

sas on.lock throttle to 1.
stage.
wait 5.
toggleflybywire("prograde", True).
wait 5.

I'm also attaching the error text:

[LOG 12:33:45.430] Code FragmentFile                 Line:Col IP   opcode operand
----                 ----:--- ---- --------------------- 
archive/testflybywire.ks    1:5   0152 push True 
archive/testflybywire.ks    1:5   0153 store 
archive/testflybywire.ks    2:1   0154 push $throttle* 
archive/testflybywire.ks    2:1   0155 push 132 
archive/testflybywire.ks    2:1   0156 store 
archive/testflybywire.ks    2:1   0157 push 134 
archive/testflybywire.ks    2:1   0158 addtrigger false 
archive/testflybywire.ks    2:1   0159 push throttle 
archive/testflybywire.ks    2:1   0160 push True 
archive/testflybywire.ks    2:1   0161 call toggleflybywire() 
archive/testflybywire.ks    3:1   0162 call stage() 
archive/testflybywire.ks    4:6   0163 push 5 
archive/testflybywire.ks    4:6   0164 wait 
archive/testflybywire.ks    5:17  0165 push prograde 
archive/testflybywire.ks    5:29  0166 push True 
archive/testflybywire.ks    5:29  0167 call toggleflybywire() 
archive/testflybywire.ks    5:29  0168 pop <<--INSTRUCTION POINTER--
archive/testflybywire.ks    6:6   0169 push 5 
archive/testflybywire.ks    6:6   0170 wait 
archive/testflybywire.ks    7:1   0171 push 138 
archive/testflybywire.ks    7:1   0172 addtrigger true 
                        0:0   0173 return 

[LOG 12:33:45.420] At testflybywire.ks on archive, line 5
toggleflybywire("prograde", True).
                            ^
Called from boot.ks on 1, line 23
run testflybywire.ks.
^
Called from boot on 1, line 1
clearscreen.
^


[LOG 12:33:45.423] System.ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
  at System.Collections.Generic.List`1[System.Object].get_Item (Int32 index) [0x00000] in <filename unknown>:0 
  at kOS.Execution.Stack.Pop () [0x00000] in <filename unknown>:0 
  at kOS.Execution.CPU.PopStack () [0x00000] in <filename unknown>:0 
  at kOS.Execution.CPU.PopValue (Boolean barewordOkay) [0x00000] in <filename unknown>:0 
  at kOS.Safe.Compilation.OpcodePop.Execute (ICpu cpu) [0x00000] in <filename unknown>:0 
  at kOS.Execution.CPU.ExecuteInstruction (kOS.Execution.ProgramContext context) [0x00000] in <filename unknown>:0 
  at kOS.Execution.CPU.ContinueExecution () [0x00000] in <filename unknown>:0 
  at kOS.Execution.CPU.Update (Double deltaTime) [0x00000] in <filename unknown>:0 

I think this feature could be a really useful addition to kOS. Any help you can give with implementing it would be awesome!

[Dunbaratu]

The difference between this:

archive/testflybywire.ks    2:1   0158 addtrigger false 
archive/testflybywire.ks    2:1   0159 push throttle 
archive/testflybywire.ks    2:1   0160 push True 
archive/testflybywire.ks    2:1   0161 call toggleflybywire() 
archive/testflybywire.ks    3:1   0162 call stage() 

(no pop)

and this:

archive/testflybywire.ks    5:17  0165 push prograde 
archive/testflybywire.ks    5:29  0166 push True 
archive/testflybywire.ks    5:29  0167 call toggleflybywire() 
archive/testflybywire.ks    5:29  0168 pop <<--INSTRUCTION POINTER--

(has a pop).

May be how one was called indirectly by the code in kOS (i.e. in the first one the script never said "toggleflybywire" - the script said "lock throttle to 1" and the lock command itself chose to call toggleflybywire as a result) while the other was called directly as a function in kOS (the script said "toggleflybywire(...)").

It occurs to me this may be a bug in general with people calling built-in functions with the parenthesis syntax. When I made them interchangeable, not only does it mean you don't need parentheses to call MYLIST:CLEAR but it also meant you CAN add them to things like PRINT and so on, which never occurred to me. I suspect you'll get the same exact POP problem if you try to do PRINT("hello") as opposed to PRINT "hello".

I'll have a chance to look into this later today. In the meantime you can try that little test. Try these two things:

PRINT "one".
PRINT("two").

And see if you get the same POP error on the second one as you got with flybywire. It may have nothing to do with your change, and have everything to do with this.

[hvacengi]

Thanks Steven. I hadn't though about that being a potential issue. I'll give that a try and see what happens. I've run into a couple other complications with using the built in autopilot system, so I'm not sure how perfect it will be yet. I'll give it a shot tonight or some time tomorrow and report back.

[hvacengi]

Just to update, using parenthesis with the print command did not cause any errors. It proceeded to the next line without issue. As a temporary shim, I push the number 0 to the stack before returning toggleflybywire, which prevents the pop error. Without more testing though, that is a stack overflow error waiting to happen. I didn't try using toggleflybywire without the parenthesis while using a defined string variable (if I just used a string literal it threw a syntax error on compile without running).

Depending on the rocket design though, these built in maneuver snap seems to be more touchy than the built in stabilization (much less dampening and higher output spikes). I am going to experiment a bit with rocket design to see if it is related to rocket wobble, or to the ratio of torque to the mass and to the overall length. These are an issue when using the built in buttons as well as when using kOS, so I don't think it should prevent implementing the functionality.

So at this point there are two things I need to fix before it could be submitted to be included: find a stable fix to the pop bug; find out how to toggle the ui icons for the different modes as well.

[Camacha]

Did someone order a new kOS unit?

After my post in the other topic, I had a bit of fun with an assortment of programs. Obviously, a lot of work still needs to be done, but that is exactly why I post here. Before I sink more time into this, it might be prudent to discuss the how and where and whether there is actually any need for a new unit. I had some doubts whether I could be of use, but I am somewhat pleased with how my experiments turned out.

I was looking to make a kOS replacement unit, as the current one is rather basic and since kOS has grown, I figured the model could use an update too. My main goal would be to make a pretty kOS unit that is up to current modelling standards, with a believable look, engineering and layout and with a reasonable amount of polygons. I have given myself an budget of 2000 triangles, as people who know what they are talking about say that is a reasonable limit, and the current model uses 1522. I have optimized the model primarily for textures, as polygons are less of a problem than memory. That being said, despite the hours put into this, I do not think this is the final layout. The main components are there - a realistically constructed hull, latticework and a semi-open space, a big computer part, some form of cooling, wiring and cables and a battery. I would like to shuffle them around a bit to make more sense. Suggestions are more than welcome, and additional inspiration too. This version has largely been inspired by a Jupiter ICBM nose cone, the Saturn guidance computer (not the DSKY) and another Russian computer, but I felt I could really use some more material, as it is rather hard to find pictures of computers mounted inside of rockets. If you have of know any, I would love to see it.

A bigger question mark though, is whether kOS will use pretty much the same basic units it uses now. This is pretty much a pretty reproduction of what is there already, but I do not know whether that makes sense for kOS in the future too. It has been discussed a couple of times in the past, but I do not think it has been recently.

I am curious to hear what you think

Some very crude texturing tests I did earlier:

Edited January 4, 2015 by Camacha

[erendrake]

Did someone order a new kOS unit?

After my post in the other topic, I had a bit of fun with an assortment of programs. Obviously, a lot of work still needs to be done, but that is exactly why I post here. Before I sink more time into this, it might be prudent to discuss the how and where and whether there is actually any need for a new unit. I had some doubts whether I could be of use, but I am somewhat pleased with how my experiments turned out.

I was looking to make a kOS replacement unit, as the current one is rather basic and since kOS has grown, I figured the model could use an update too. My main goal would be to make a pretty kOS unit that is up to current modelling standards, with a believable look, engineering and layout and with a reasonable amount of polygons. I have given myself an budget of 2000 triangles, as people who know what they are talking about say that is a reasonable limit, and the current model uses 1522. I have optimized the model primarily for textures, as polygons are less of a problem than memory. That being said, despite the hours put into this, I do not think this is the final layout. The main components are there - a realistically constructed hull, latticework and a semi-open space, a big computer part, some form of cooling, wiring and cables and a battery. I would like to shuffle them around a bit to make more sense. Suggestions are more than welcome, and additional inspiration too. This version has largely been inspired by a Jupiter ICBM nose cone, the Saturn guidance computer (not the DSKY) and another Russian computer, but I felt I could really use some more material, as it is rather hard to find pictures of computers mounted inside of rockets. If you have of know any, I would love to see it.

A bigger question mark though, is whether kOS will use pretty much the same basic units it uses now. This is pretty much a pretty reproduction of what is there already, but I do not know whether that makes sense for kOS in the future too. It has been discussed a couple of times in the past, but I do not think it has been recently.

I am curious to hear what you think

http://tweakers.net/ext/f/MUvOlvP3sOp3gIpGCsbOhUMw/full.png

http://tweakers.net/ext/f/XWkhR62rc55CPAqkFRpkDJAA/full.png

http://tweakers.net/ext/f/oUzeSqYANW6dxv4cpxMBPaUh/full.png

Some very crude texturing tests I did earlier:

http://tweakers.net/ext/f/psiJTz9BWmd7m1Qvo7wky1g4/full.png

That is very cool, when you are ready to add it to the project, do you have any reluctance to having the sourcefiles live in the github repo and be licensed as GPL along with the rest of the code?

A i have a small feature request. the "new" small kos part has some lights on it that i would like to eventually be script controlled. So if you think you would like to have something cool like some 9 seqment displays or some simple lights on your part i think that could add something pretty cool to the part.

- - - Updated - - -

New updated thing on the forums is a bother. ^ that thing ^

Edited January 4, 2015 by erendrake

[Camacha]

That is very cool, when you are ready to add it to the project, do you have any reluctance to having the sourcefiles live in the github repo and be licensed as GPL along with the rest of the code?

I will need to check the exact conditions of the license, but the work was pretty much intended for public distribution alongside the kOS software. If it would become part of the project, that would be great. My main concern is that is remains freely available and that it is properly attributed. I would also prefer that others cannot charge money for the work, but a quick scan of the GPL license seems to cover all those bases.

What would be considered the sourcefiles in this case, the Blender files and textures?

A i have a small feature request. the "new" small kos part has some lights on it that i would like to eventually be script controlled. So if you think you would like to have something cool like some 9 seqment displays or some simple lights on your part i think that could add something pretty cool to the part.

If I can get that to work, I do not mind My KSP modelling skills are modest at best and I would need to find out how to make controllable lights, but it sounds like a fun project to look into. However, might it be an idea to create a separate 9 segment display part? That way people can add it whenever and wherever they want.

So reproducing the current kOS unit is the way to go?

Edited January 4, 2015 by Camacha

[erendrake]

The KSP 0.90 compatibility release.

(The full thematic following of KSP 0.90's new way of

thinking will come in a future version. This is just

to make sure everything works.)

On Github

On KerbalStuff

On Curseforge

[h=3]BREAKING CHANGES[/h]

• Now respects the limitations of 0.90 career mode upgrades, which may make a few features not work anymore in career mode until you get further progressed along in your building upgrades.
  

[h=3]New Stuff[/h]

• Thanks to a new dev team contributer Johann Goetz (@theodoregoetz on github), we have a new, much better and cleaner looking documentation site
  
• Better flight input handling to detect the pilot controls and keep them isolated.
  
• "plays nice" with other autopilots a bit better, using KSP 0.90's new autopiloting hooks.
  
• New suffixes to handle directions better as mentioned in
  
  
• Separate Dry Mass, Wet Mass, and Current Mass readings for parts and for the vessel as a whole (TODO: Link here, but the public gh-pages hasn't be regenned yet so I don't know the link yet)
  
• Added new WAYPOINT object to help with locations of some contracts.
  
• Added new :POSITION and :ALTITUDEPOSITION suffixes to Geocoordinates to obtain 3D vectors of their positions in ship-raw coordinate space.
  
• ADDED muliple new ways to deal with resources.
  
  • STAGE:RESOURCES, SHIP:RESOURCES and TARGET:RESOURCES will let you get a list of the resources for the craft, the difference being that SHIP: and TARGET: includes all resources and STAGE: includes only the resoures that are for "this stage". All three of these will let you get a list of :PARTS that can contain that resource.
    
  • Part resources now gives you access to the resource's tweakable :ENABLE and :TOGGLEABLE can let you remove add a resource to the normal resource flow.
    

[h=3]Bug Fixes[/h]

• Better handling of range checking and loading the boot file when remotetech is installed (thanks to hvacengi for this contribution)
  
• Boot file overwrite fix (thanks to pakrym)
  
• (For developers) fixed compile error on UNIX platforms that was due to filename case-sensitivity differences.
  
• LOG command to the Archive now appends to the file properly instead of rewriting the entire contents each time just to tack on one line. It is now possible to read its output from outside KSP using a tool like the UNIX "tail -f" program.
  
• Better calculations of stage resource values, using SQUAD'S provided API for it instead of trying to walk the tree ourselves (which broke in 0.90).
  
• Fixed lonstanding bug with geocoordinates:TERRAINHEIGHT
  

[h=3]Small maintenence issues[/h]

• Bundling a newer version of ModuleManager
  
• Better use of the "skin" system for the app panel. Should see no obvious effect on the surface.
  

[Camacha]

[*]Better flight input handling to detect the pilot controls and keep them isolated.

You guys are moving fast

[Dunbaratu]

Just to let people know: Several of the links in the release announcement lead to either 404 not found pages, or to pages that are out of date and fail to mention the new feature being talked about.

This will be fixed, probably Sunday. The documentation source file changes are written, but the pages hosted on the site weren't regenerated from the source yet when the announcement was made.

- - - Updated - - -

I love that new part models are being made, Camacha. That's great. We should have plenty of variety to work with that way. When we have multiple part models, it means we'll have to think about what computer features should really scale as you climb the tech tree and buy better versions of the part.

One comment on the artwork - putting the kOS identifying decal on the top or bottom of a stack-mounted part means that once it's part of a stack, you can't see it anymore. Maybe there should be an identifying decal on the outer cylinder wall of the stack-mounted part too.

I don't know if erendrake agrees, but one thing in general I thought might be kind of cool is if kOS parts followed the inverse of the usual part progression. Typically in KSP you start with the small lightweight diameter parts and then get big diameter parts as you get better tech. For engines that makes sense but for computers maybe it should go the other way around - you get the bulky heavy computers FIRST on the tech tree, and then graduate up to smaller, but more capable ones later. If we want to go with that, it might affect the artwork decisions which is why I put it out for discussion now. The way you'd want to make the large diameter vs small diameter parts look might change depending on which ones you're envisioning as being the 1960's tech versus the 1980's tech.

And a lot of people have been asking for a surface mounted computer too - maybe we can start giving those out high up the tech tree.

Anyway, thanks for the work. This will be cool.

Edited January 4, 2015 by Steven Mading

[Camacha]

Part variety is the main reason I posted and what I need your input for. I intend to make high quality parts (without going overboard), so there is a fairly natural limit to how many can be reasonably included. RAM space still is at a premium and, let us be honest, kOS is not played for its plethora of computer models. It is somewhat lucky that the control segment in the parts list is not used that much, so cluttering up the parts list is a limited issue, though I do not imagine that is an invitation to go crazy in any case.

What I would like to avoid is making extra parts just for the sake of the Tech Tree, especially if that means that newly unlocked parts supersede old ones in every way. In line with my tools, not solutions mantra I would like to come up with a set of parts that allows a user to employ kOS in a variety of situations, posing interesting engineering questions, imposing trade-offs and making sense as a whole in sandbox mode too. As KSP is a building game, I would like to challenge players to think about what unit they are going to use for what reasons. It is fine to take career mode into account while designing them, spreading them neatly across the spectrum, it is just that modelling the line-up after it does not seem like the way to go. I think all situations and types of players are accommodated that way.

It would certainly help the design and manufacture of these parts to have at least some idea of how that is going to be achieved. That way parts can reflect the properties they have, while at the same time providing further inspiration for their shape and form. It also allows me to address something that I have been looking at and and that Steven mentions in his post - making things recognizable, especially from the outside. Rocket design is, unfortunately, fairly limited when it comes to exteriors - they tend to be of a rather tubular disposition. I feel it is important parts fit neatly into a stack, so it is a matter of striking a balance between standing out and fitting in. How to do that I am really not too sure yet. I have been toying with the idea of maybe making subtle external (space) radiators a shared feature of all the parts (since the current internal heat sink looks pretty, but does not make a huge amount of sense), or using the current black with some white design as a basis. I would like to see parts that work well with both stock parts and the higher quality parts you typically see in RSS or other mods.

Current vague plans for parts include three of them:

- The current big computer.

- A replacement for the current small part, though bigger than it is now. I am not sure the capabilities should be different.

- A surface mounted model, about half or a third of a structural intake.

I could see room for something like a model that is cheap, simple and not too capable that you might use in disposable craft, or maybe that should be combined with the surface mounted model.

Finally, I think it is important to be clear about my level of commitment. After lining out the parts and identity I will at least make the part that comes closest to the current big kOS unit. What happens after that is dictated by how the process pans out and, more importantly, how much time I will have to work on this kind of stuff. I am starting a business in real life and that has to take precedent, and this project has a learning curve for me as I am new to this kind of modelling. Both are factors that will govern available time and actual production. Ideally I would create a small but useful set of kOS parts, as I am partial to the mod and love the idea of contributing to it myself

Edited January 5, 2015 by Camacha

[Camacha]

Quick sketch of the revision. Major change is the addition of space radiators to the outside, along with heatpipes from the computer to make that work. This should make the part more recognizable. I moved the battery from the side to the back, though I am a bit worried the symmetry will make the part a bit boring. The mounting brackets have been reshaped to theoretically allow the computer to slide out for maintenance. I feel everything makes a bit more sense now, though I am not too sure about the radiators yet.

I played a bit with actually modelling things in Blender today and it is starting to make sense. I also figured out how to pass files back and forth from my CAD program to Blender and vice versa. Even with my limited understanding of Blender, that expands the possibilities exponentially.

Sorry for spamming your thread, I hope you do not mind. Or should I make a separate development thread?

Edited January 5, 2015 by Camacha

[undercoveryankee]

I will need to check the exact conditions of the license, but the work was pretty much intended for public distribution alongside the kOS software. If it would become part of the project, that would be great. My main concern is that is remains freely available and that it is properly attributed. I would also prefer that others cannot charge money for the work, but a quick scan of the GPL license seems to cover all those bases.

What would be considered the sourcefiles in this case, the Blender files and textures?

Across a couple of different license versions, the GPL has defined "source" as "the preferred form of the Work for making modifications to it" or similar language. So geometry in a format that's easy to open in a modeling tool (Blender format if that's what you've been using is pretty easy; if you're like bac9 and do geometry in SketchUp before converting to a fancier tool for texturing, it wouldn't hurt to include the SketchUp files). Textures in whatever is your "master" format that you would go back to if you wanted to change something, which would be a PSD/XCF if you're using editor features like layers that are lost when you go to a simpler format.

[postalbyke]

On the kOS docs page, specifically

http://ksp-kos.github.io/KOS/bindings.html

I see the charts of bound variable names as a paragraph of text rather than as a table of variables. Respectfully request some attention be given to this matter.

Thank you very much for your hard work, and for the amazing update on the docs! You guys are awesome!

[Camacha]

Should the kOS unit have a battery? Elsewhere there it a similar discussion on RCS and whether it should be contained within the command pods. I think it should not, as KSP is a building game and parts should be as modular as possible. This logically means that kOS units also should not have batteries.

From a gameplay mechanics point of view there is one reason to add a little power and I suspect this is the reason the original ones do have it: when you launch a rocket you need a minimum of time to boot up the script you want to run, getting the engines running (and providing power). However, as most command modules do have a bit of power I feel this argument is moot, and one could always add a battery if needed.

Another question is whether the kOS unit speed is settable in the configuration. I know it can be done globally, but I do not see anything in the .cfg files. Is that right?

Edited January 7, 2015 by Camacha

[Dunbaratu]

Another question is whether the kOS unit speed is settable in the configuration. I know it can be done globally, but I do not see anything in the .cfg files. Is that right?

The speed is a global setting for all of kOS rather than being different per-part. This was mostly because it was pictured as being a matter of people tweaking kOS for their own gaming machine's capabilities. We can't easily settle on a number that works for everyone without having to really nerf it to be unnecessarily slow for the people with faster computers, so it became a config setting. Also it has a direct impact on animation framerate of the game, so there's also a matter of user preference - would you rather have a fast kOS CPU or a smooth animation experience? This makes it ironically that you might want to set it SLOWER on a faster computer, if your computer's speed is mostly due to GPU rather than CPU, otherwise it takes your otherwise fast GPU-bound framerate and turns it into a slower CPU-bound framerate as the framerate is held back by running so many kOS instructions per frame.

Maybe it should be moved to depending on each part... but.... I'm tempted to say that doing that will require a bit of an overhaul on how CONFIG:IPU even works in the first place.

It really should be tied to the universe's physical time more so than the animation framerate, if we want to simulate a slower or faster computer in the gameworld.

A CONFIG:IPU of 150 on a machine that's getting a framerate of 30FPS is *literally* running the kOS script half as fast as one with the same CONFIG:IPU of 150 on a machine getting a framerate of 60FPS.

I've been thinking about interesting ways to have lower tech CPUS that run slower, but the above problem would have to be addressed first. As it is already, not everyone is *really* getting the same speeds out of their kOS CPUs.