[1.3] kOS Scriptable Autopilot System v1.1.3.0

[hvacengi]

57 minutes ago, EmbersArc said:

@kcs123, @hvacengi thanks! I'm trying to make a script to use differential throttling to control a Dragon v2 capsule for a point landing. I thought there might be a way to just tune the steering manager and use its output to adjust the thrust limit on the individual engines. Access to the output might or might not be helpful for that, just thought I'd try that first. It even somewhat works with the output from the rotational velocity PID but it's not very elegant. It looks like the best way is to make it from scratch after all.

You should check out some of the scripts by @Ozin, I think that's how he does his quadracopter script, and I'm pretty sure he did another one using rocket engines themselves. https://www.youtube.com/user/Ozin370/feed

I'm not sure what the steering manager would do with asymetric thrust like that, but you could try adjusting the thrust limiter based purely on the pitch and yaw error suffixes on steering manager.  I don't recall if those errors are signed however.

[hvacengi]

v1.0.2 Make A Little Noise!

 

DOWNLOADS

• Github
• Spacedock
• Curse
• Also available via CKAN

BREAKING CHANGES

• As always, if you use the compiler feature to make KSM files, you should recompile the KSM files when using a new release of kOS or results will be unpredictable.
• Most in game settings are now integrated with KSP's difficulty settings window. You will be prompted to migrate existing settings when you load your save game. Telnet settings are still stored in the old config file, but everything else is now stored within the save file. pull request | documentation
• Calls to resource suffixes on the stage bound variable are no longer rounded to 2 decimal places. Previously they were rounded to assist in detecting "zero" fuel, but they cause inequality issues when comparing to the newer stage:resources list or stage:resourceslex values.
• The behavior of the resource suffixes on the stage bound variable has changed with regard to asparagus staging. If you have smaller tanks that can be staged, stage:liquidfuel will return 0even if you still have an engine firing. This is a break from previous versions of kOS, but is aligned with the current UI design. Previous versions also aligned with the KSP UI, but the UI mechanic was updated with KSP 1.2.x

NEW FEATURES

• Official release for KSP version 1.2.1!
• kOS now has a procedural sound system! You can use it to play customized error tones or make your own musical notes. pull request | documentation
• Support for CommNet and modifications to make RemoteTech and CommNet use similar systems.pull request | documentation
• Trajectories integration enabled via new ADDONS:TR pull request | documentation
• Added new setting for default terminal brightnes, and updated default value to 70% pull request | documentation
• Added VELOCITY and ALTITUDEVELOCITY suffixes to `geocoordinates pull request | documentation
• Added TONUMBER and TOSCALAR suffixes to string values for parsing numerical values pull request | documentation
• New steeringmanager suffix ROLLCONTROLANGLERANGE to dictate the maximum value of ANGLEERRORfor which the manager will attempt to control roll commit | documentation
• KSM files are now gzip compressed internally, dramatically reducing the file size. Existing KSM files should still load, but see above for the recommendation to recompile all KSM files. pull request

BUG FIXES

• Fix for throwing errors when another mod uses dynamic assembly pull request
• Update Blizzy toolbar wrapper to the most recent version pull request
• Fix for local kOS hard disks breaking when loading with 4 byte long files pull request
• kOS no longer uses a write-only lock when writing to the archive, preventing an error when accessing a file opened for reading by another program pull request
• Fix for duplicate functions/locks breaking ksm files pull request
• Fix for null ref error when editing node suffixes on KSP 1.2.1 pull request
• Fix for issue where a body with the same name as one of our bound variables would block access to said variable (specifically Eta in Galileo's Planet Pack blocked the eta bound variable) pull request
• Fix for getting the science value and transmit value in sandbox mode pull request
• Fix error where unlock all inside a trigger will try to unlock functions too pull request

Edited December 7, 2016 by hvacengi

[hvacengi]

Go figure, they updated KSP between me creating the archive and finishing tests so I could click publish... I'm working on testing for KSP 1.2.2 and will post another update quickly if we need to recompile against the new version.

[hvacengi]

v1.0.3 (for KSP 1.2.2) Make a little noise! (Part Deux)

 

Downloads

• Github
• Spacedock
• Curse
• Also available via CKAN

Summary

This release is nearly identical to v1.0.2, except that it was compiled against
binaries from KSP v1.2.2 (released just before we published) and the version numbers
have been advanced. While it appears that kOS v1.0.2 is compatible with KSP v1.2.2,
we wanted to err on the side of caution and provide an explicitly compatible release.
Please review the changelog for v1.0.2 if you are upgrading from an earlier version

[kcs123]

On 03.12.2016. at 7:18 AM, Waz said:

Alpha8 of the GUI is up. I've been slowly tweaking the API for best usability, but still keen to here anything you feel is awkward or strange.

Specifically, STYLE:BG_FOCUSED is now STYLE:FOCUSED:BG and there is also STYLE:FOCUSED:TEXTCOLOR (and the same for ACTIVE, NORMAL, HOVER, etc.).

This release also includes a tutorial on making a self-contained TabWidget (see the GameData/kOS/html directory), and minor bugfixes for radiobuttons over comm delay.

https://github.com/WazWaz/KOS/releases/

@Waz, seems that alpha 7 or alpha 8 broke some of widget features. This kind of GUI no longer works properly:

To be more specific, Radio buttons on Picture in horisontal box with labels "Vel.Hover" and "Alt.Hover" no longer can be created like on above picture. Commands for set style no longer works. Here is how it is created previously(only important part for discussion):

// Creating GUI
set Hover_GUI to GUI(280,400). // (width,height)
set Hover_GUI:x to 515. // set GUI window position to X
set Hover_GUI:y to 60. // set GUI window position to Y

// Elements of GUI
set HoveringModeBox to Hover_GUI:ADDVBOX.
set HoveringChoiceBox to HoveringModeBox:ADDHBOX. // horizontal box for 2 RB
set HoveringChoiceRB_Velocity to HoveringChoiceBox:ADDRADIOBUTTON("Vel.Hover",true).
set HoveringChoiceRB_Velocity:STYLE:HMARGIN to 20. // create some space for next RB widget // in alpha8 produce error
  
set HoveringChoiceRB_Altitude to HoveringChoiceBox:ADDRADIOBUTTON("Alt.Hover",false).
set HoveringChoiceRB_Altitude:STYLE:HMARGIN to 100. // in alpha8 produce error
set HoveringChoiceRB_Altitude:STYLE:ALIGN to "RIGHT". // in alpha8 produce error

Previously, before STYLE introduction, I was using directly HMARGIN and ALIGN suffix, but that create error too.
Maybe it is still possible to arange two radio buttons horisontaly in one box, but I could not figure out yet.

I'm trying to create minimum sized GUI (in width/height used) with all needed commands and needed feedback for user. That I wanted to use one horisontal box with 2 RB instead of same thing with vertical box.

I will stick with KSP 1.2.1. for a while until other moders catch up with everything, so no need to rush with next update, just wanted to notify it.
Let me know if you need more details about it.

It is hard to tell in front what else could possible be needed regarding GUI. That is why I'm trying to bind existing scripts with GUI, to be able to perovide more quality feedback.

[MaxRebo]

Does nobody around here actually use Blizzy Toolbar integration? The Blizzy Toolbar button has been horribly broken every since I started with kOS in 1.1.3 (and probably way, way longer than that), way before that whole Contract Configurator affair. I'm not asking for a fix or anything; I'm fine with using app launcher (for kOS at least), if a bit reluctantly. Just found it strange that no one ever bothered to report it in all that time...

[kcs123]

25 minutes ago, MaxRebo said:

Does nobody around here actually use Blizzy Toolbar integration? The Blizzy Toolbar button has been horribly broken every since I started with kOS in 1.1.3 (and probably way, way longer than that), way before that whole Contract Configurator affair. I'm not asking for a fix or anything; I'm fine with using app launcher (for kOS at least), if a bit reluctantly. Just found it strange that no one ever bothered to report it in all that time...

Actualy, I reported it. @hvacengi have included some fix for it, but it still broken. Just in a few pages back it was stated that Blizzy Toolbar may be considered as unsuported until further notice. At least some progress is made with it. At the time I reported it, it was not possible to use stock toolbar for kOS either. So, for now you can at least use Blizzy Toolbar for other mods and stock toolbar for kOS until proper fix is provided.

You may also need to check new options for kOS under difficulty settings screen.

[sebseb7]

On 30.11.2016 at 3:53 PM, Waz said:

I've no idea what limitations RPM has, but probably the GUI will appear as normal GUI elements in IVA. Of course, nothing says you *have* to use a GUI when you write your scripts, and indeed, I suspect RPM enthusiasts would rather use a command line or text boxy ui (which you can build with the existing TTY interface).

RPM enthusiasts also like buttons and switches, and the display is not strictly text, there is a navball, a map, camera view. etc. It is the whole IVE experience that matters.
RPM tries not to limit anything. As far as I can see it would be possible to implement an prop where the GUI elements appear IVA on a "touchscreen" like in dragon v2. As long as you can intercept the draw calls and implement your own compatible display. maybe "gui" is build on top of "screen", and screen is exchangeable. It would be nice if one could implement its own display via a kosaddon. At some point it also would be interesting to draw the IVA navball using kos. same to to all IVA switches and status/warning lamps. 

Basically the most interesting unimplemented feature I can image, is to have something like this Apollo Panel as the "GUI" for kos: (all the gauges and switches should be kos controllable), "LOCK gauge1 TO altitude. / ON switch17 ...."  and the AGC-DSKY of corse! This sure could be done using a kosaddon communicating with RPM. And one should it design in a way that someday you could use a "gui-builder" to arrange the gauges and switches mission-dependend, like widgets. The only current connection between cockpit and IVA is 10 Actiongroup Buttons and the text screen. 




instead of mechjeb buttons, I would like to place my own buttons there and connect them to my own spacecraft control-system
(same for status/error lamps)

[kcs123]

I don't think that it is something easy to do with current RPM. Some of other moders that actualy create parts, more specific, cockpits and IVA for them may provide better info on this topic. But as much I was able to figure it out, you will need to do custom GUI for each specific cockpit. Meaning, you will need to alter cockpit meshes/recompile against RPM each time you want to change something with your own personal GUI.

Even advanced moders postpone doing IVAs for cockpits until final release due to amount of re-work IVA require.

kOS terminal, on the other hand is much less demanding, it only display data on one of RPM monitors, without or limited interactions. All interactions are mostly done trough AGs.

New GUI under development could in theory integrate within RPM monitor in similar way as kOS terminal. I say "in theory". In practice, I don't know how much of this is feasible, as that new GUI is just existing unity game engine GUI. First, it be user responsibility to create GUI small enough that could possible fit within RPM monitor. Second, I don't know if it would be possible to create 3D GUI with built in unity game engine GUI.

Meaning, if someone found a way how to display custom GUI on RPM monitor, it also need to take care how it would behave when you turn head around while siting in IVA. How GUI will be drawn on RPM monitor when you look at it from 30 or 60 degree angle instead of looking straight to RPM monitor at 90 degree angle ? Does built in unity game engine GUI is capable doing this ?

Quite a lot of question and uncertain answers. Quite a lot effort have to be made to do even most simple RPM integration. All that for most probably limited GUI features. Don't get me wrong, I'm sure that many players would like to see something like this in game, but let @Waz to get current system out of alpha phase first. Once it is at least in beta stage of development and integrated with official kOS release it will be more sense to discuss about RPM integration further. Maybe someone who is more familiar with RPM could possible do something about it in future, who knows.

I'm grateful already with overall kOS development how currently it is. Asking more from kOS development team, just not sound right, at least to me.

[sebseb7]

1 hour ago, kcs123 said:

I don't think that it is something easy to do with current RPM. Some of other moders that actualy create parts, more specific, cockpits and IVA for them may provide better info on this topic. But as much I was able to figure it out, you will need to do custom GUI for each specific cockpit. Meaning, you will need to alter cockpit meshes/recompile against RPM each time you want to change something with your own personal GUI.

Even advanced moders postpone doing IVAs for cockpits until final release due to amount of re-work IVA require.

kOS terminal, on the other hand is much less demanding, it only display data on one of RPM monitors, without or limited interactions. All interactions are mostly done trough AGs.

New GUI under development could in theory integrate within RPM monitor in similar way as kOS terminal. I say "in theory". In practice, I don't know how much of this is feasible, as that new GUI is just existing unity game engine GUI. First, it be user responsibility to create GUI small enough that could possible fit within RPM monitor. Second, I don't know if it would be possible to create 3D GUI with built in unity game engine GUI.

Meaning, if someone found a way how to display custom GUI on RPM monitor, it also need to take care how it would behave when you turn head around while siting in IVA. How GUI will be drawn on RPM monitor when you look at it from 30 or 60 degree angle instead of looking straight to RPM monitor at 90 degree angle ? Does built in unity game engine GUI is capable doing this ?

Quite a lot of question and uncertain answers. Quite a lot effort have to be made to do even most simple RPM integration. All that for most probably limited GUI features. Don't get me wrong, I'm sure that many players would like to see something like this in game, but let @Waz to get current system out of alpha phase first. Once it is at least in beta stage of development and integrated with official kOS release it will be more sense to discuss about RPM integration further. Maybe someone who is more familiar with RPM could possible do something about it in future, who knows.

I'm grateful already with overall kOS development how currently it is. Asking more from kOS development team, just not sound right, at least to me.

some cockpit components are shared between cockpits (for example the multifunctional displays aka. RPM). The gui does not need to be 3D, so differend angle does not matter. The RPM navball is an example for this. A touchdisplay is not 3 dimensional. I don't push for new functionality right now. I just want to point out that the basic design should be able to handle future extensions. As long as you can intercept the draw calls, RPM integration would be easy. 

[MaxRebo]

4 hours ago, kcs123 said:

@hvacengi have included some fix for it, but it still broken. [...] At the time I reported it, it was not possible to use stock toolbar for kOS either.

Do you mean this? I was aware of that (and the eventual fix), and I don't think it's the same issue - that's something that came with the new 1.2 custom difficulty settings. This:

On 25.11.2016 at 5:47 PM, kcs123 said:

I can even put kOS icon on Blizzy toolbar, but if I try to click on it to show kOS UI, it throw null object refernce error

seems to be an entirely unrelated bug. True, you reported it 2 weeks ago and that actually slipped by me when I double-checked. But yours seems to be the only mention of the issue in what basically amounts to at least 8 months of continuously broken Blizzy support... I can only conclude that virtually no one actually uses it?

[kcs123]

7 minutes ago, MaxRebo said:

Do you mean this? I was aware of that (and the eventual fix), and I don't think it's the same issue - that's something that came with the new 1.2 custom difficulty settings.

Nope. That one is related due to changes in Blizzy's code. Nightingale found it trough KSP 1.2. prerelease that contract configurator triggers bug within Blizzy's Toolbar. He provided PR for toolbar and all other mods that use toolbar need to update wraper to avoid that nasty bug.

Issue that I reported first time is on official kOS pre-release. It suppose to be fixed, but later on I was using kOS fork from Waz, so my later reports might not match with latest official releases. I will probably stick with current release until more of mods that I regulary use catch up with latest KSP update.

Final frontier, alarm clock, SCANsat seems to work just fine with Blizzy's toolbar. Infernal robotics seems to be broken too. I haven't try MJ in latest moded playtrough and several other mods that I used in past. I having limited free time for KSP lately, so I was unable to find stable set of mods for decent career game.

[MaxRebo]

14 minutes ago, kcs123 said:

Nope. That one is related due to changes in Blizzy's code. Nightingale found it trough KSP 1.2. prerelease that contract configurator triggers bug within Blizzy's Toolbar. He provided PR for toolbar and all other mods that use toolbar need to update wraper to avoid that nasty bug.

Well, we're certainly not dealing with the CC issue here. The null-reference exception when clicking the kOS Blizzy button has been there since at least KSP 1.1.3 / kOS 1.0.1 (I wouldn't be surprised if it was already present as far back as KSP 1.0). The CC bug prevented toolbar buttons from affected mods from showing up in the first place, as opposed to merely making them unclickable... and not all mods were affected by it either - those that used custom toolbar wrappers were mostly safe.

Infernal Robotics, btw, works just fine with Blizzy for me, even in 1.2.2...

[hvacengi]

I'm just gonna throw the first quotes in a spoiler tag, cause I'm not going to address them specifically, I just want to provide a reference to the paragraph that follows.  I had a more in-depth specific reply prepared addressing each point individually, but the forum ate it and I don't feel like writing the whole thing again.

Spoiler

7 hours ago, MaxRebo said:

Does nobody around here actually use Blizzy Toolbar integration? The Blizzy Toolbar button has been horribly broken every since I started with kOS in 1.1.3 (and probably way, way longer than that), way before that whole Contract Configurator affair. I'm not asking for a fix or anything; I'm fine with using app launcher (for kOS at least), if a bit reluctantly. Just found it strange that no one ever bothered to report it in all that time...

7 hours ago, kcs123 said:

Actualy, I reported it. @hvacengi have included some fix for it, but it still broken. Just in a few pages back it was stated that Blizzy Toolbar may be considered as unsuported until further notice. At least some progress is made with it. At the time I reported it, it was not possible to use stock toolbar for kOS either. So, for now you can at least use Blizzy Toolbar for other mods and stock toolbar for kOS until proper fix is provided.

You may also need to check new options for kOS under difficulty settings screen.

2 hours ago, MaxRebo said:

seems to be an entirely unrelated bug. True, you reported it 2 weeks ago and that actually slipped by me when I double-checked. But yours seems to be the only mention of the issue in what basically amounts to at least 8 months of continuously broken Blizzy support... I can only conclude that virtually no one actually uses it?

2 hours ago, kcs123 said:

Nope. That one is related due to changes in Blizzy's code. Nightingale found it trough KSP 1.2. prerelease that contract configurator triggers bug within Blizzy's Toolbar. He provided PR for toolbar and all other mods that use toolbar need to update wraper to avoid that nasty bug.

 

If there's an issue with the Blizzy toolbar, we deffinitely need to know.  It is a supported feature (I don't think we ever said that it should be considered unsupported) but it is a feature that is not tested very thuroughly.  I myself stopped using Blizzy's toolbar shortly after the stock toolbar was implemented.  I do see the appeal, it just was one more thing to have to manage.  The previous error was an oversight on my part because I don't have Blizzy installed.  This doesn't seem to be completely unrelated, in that it's still an issue with how kOS interacts with Blizzy, but it's a separate issue with a separate error.  Anything you can do to get me more information about the error (logs, screenshots, videos, etc.) would help narrow it down.  When kcs previously reported the issue in this thread, it was implied in a later post that it was related to the GUI alpha, so I stopped thinking about the issue.  This is one of the reasons I prefer to have bugs reported as github issues (at least eventually), as github allows us to have a separate thread for every issue ensuring that all of the information pertinent to that issue doesn't get lost in data for other issues.  It just makes things a little easier to track.

On 12/1/2016 at 11:05 AM, kcs123 said:

Here is log files regarding Blizzy's toolbar. It is based on Waz's alpha6 fork. This time it behave different.
kOS icon is properly added on toolbar at Kerbal space center. Clicking on it open kOS GUI properly.
However, in VAB/SPH and flight scene, kOS icon is not available to choose for toolbar.
Switching back to KSC and kOS icon missing from toolbar too. There is also no choice to add it on toolbar.

I'm revisiting this now because apparently this issue isn't related to the GUI alpha release.  If I'm understanding your correctly, the kOS icon is available and works from the Blizzy Toolbar when you first load at the KSC, but disappears when you visit an editor or flight.  What is happening with the stock toolbar at the same time?  The only error I see is in an attempt to access the save game settings from the main menu (which would explain the error, since there is no saved game loaded at the main menu) but if that's is causing the issue I wouldn't expect the button to work at any point, KSC or otherwise.  I also am surprised to find that the button is available to Blizzy on the KSC scene, since the stock button is not available for that scene. I'll have to look at that.

I'll try to install Blizzy's Toolbar tonight and confirm my above observations, but if either of you can confirm any of the behavior before I do that would be great too.

[Waz]

On 12/9/2016 at 4:22 AM, kcs123 said:

set HoveringChoiceRB_Altitude:STYLE:HMARGIN to 100. // in alpha8 produce error
set HoveringChoiceRB_Altitude:STYLE:ALIGN to "RIGHT". // in alpha8 produce error

 

The align works just like that. The margin is done with STYLE:MARGIN:H (note that you can now also specify LEFT, RIGHT, TOP, BOTTOM independently, not just H and V, which set two of those).

The docs for each release should be consistent with that release.

Edited December 10, 2016 by Waz

[Waz]

GUI Alpha 10

Another GUI update. Seems something was odd with the way the GUI skin was setup. It now defaults to the same Arial font used by other KSP dialogs. As a bonus, you can now set the Font to use via GUI:SKIN:FONT (for the whole GUI) or STYLE:FONT (for a single widget). Loading fonts is "left as an exercise for the reader" (it will use any font that happens to be loaded into KSP).

This is still built for KSP 1.2.1, and uses the final kOS 1.0.2/1.0.3 codebase.

As before, on https://github.com/WazWaz/KOS/releases

I also think I see what @kcs123 was talking about - I'd inadvertently made LABEL's STYLE:HSTRETCH default to false. This is also fixed.

Edited December 10, 2016 by Waz

[kcs123]

6 hours ago, hvacengi said:

I'm revisiting this now because apparently this issue isn't related to the GUI alpha release.  If I'm understanding your correctly, the kOS icon is available and works from the Blizzy Toolbar when you first load at the KSC, but disappears when you visit an editor or flight.  What is happening with the stock toolbar at the same time?  The only error I see is in an attempt to access the save game settings from the main menu (which would explain the error, since there is no saved game loaded at the main menu) but if that's is causing the issue I wouldn't expect the button to work at any point, KSC or otherwise.  I also am surprised to find that the button is available to Blizzy on the KSC scene, since the stock button is not available for that scene. I'll have to look at that.

kOS icon is not shown on stock toolbar at flight scene, but when you add icon on Blizzy's toolbar it opens kOS GUI near stock toolbar. Perhaps those few screenshots will explain behaviour better than I can with words. Availability of icon - appear/disapear between scenes is like I described in previous quoted post. I hope that it help to narrow down issue.

@Waz, thanks, and no worries, everything is in alpha stage in development, so changing behaviour back and forth is expected. Just sometimes is done on purpose and sometimes become different when it is not itended. Only using same kind of GUI may help to notice difference in behaviour.
I can only help for now with some feedback between updates.

9 hours ago, MaxRebo said:

Well, we're certainly not dealing with the CC issue here. The null-reference exception when clicking the kOS Blizzy button has been there since at least KSP 1.1.3 / kOS 1.0.1 (I wouldn't be surprised if it was already present as far back as KSP 1.0). The CC bug prevented toolbar buttons from affected mods from showing up in the first place, as opposed to merely making them unclickable... and not all mods were affected by it either - those that used custom toolbar wrappers were mostly safe.

Infernal Robotics, btw, works just fine with Blizzy for me, even in 1.2.2...

I have to check IR again with latest update available. I was playing career game where I didn't unlocked IR techtree nodes having faulty IR sequencer dll between updates and bunch of other things. It is actualy great to know that issue is something on my side, I will be able to do something about it at least. Thanks for that info.

[symmeclept]

I'm pretty much lost trying to use this thing, but I love the fact that it exists. Well done and keep it up! I just wanted to say that.

[kcs123]

4 hours ago, symmeclept said:

I'm pretty much lost trying to use this thing, but I love the fact that it exists. Well done and keep it up! I just wanted to say that.

You mean about GUI or kOS ? As for GUI, it is not too way complicated, once you start to use it. But perhaps it brings too much info at once when you try to use it for the very first time. Especialy if you are not familiar with ordinary objects in "normal" programing languages, like visual basic, visual C++ or C#, whatever someone prefer.

 

@Waz, alpha10 version fixes that radio button issue, but introduce something new. When you try to enter any number inside TEXTFIELD box it throws NullReferenceException error. TEXTFIELD no longer accept any input. Happens as soon as you press key, not even reaching CONFIRMED event on pressing return key. Here is relevant part of log:

Spoiler

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

NullReferenceException: Object reference not set to an instance of an object
  at UnityEngine.GUI.HandleTextFieldEventForDesktop (Rect position, Int32 id, UnityEngine.GUIContent content, Boolean multiline, Int32 maxLength, UnityEngine.GUIStyle style, UnityEngine.TextEditor editor) [0x00000] in <filename unknown>:0
  at UnityEngine.GUI.DoTextField (Rect position, Int32 id, UnityEngine.GUIContent content, Boolean multiline, Int32 maxLength, UnityEngine.GUIStyle style, System.String secureText, Char maskChar) [0x00000] in <filename unknown>:0
  at UnityEngine.GUI.DoTextField (Rect position, Int32 id, UnityEngine.GUIContent content, Boolean multiline, Int32 maxLength, UnityEngine.GUIStyle style, System.String secureText) [0x00000] in <filename unknown>:0
  at UnityEngine.GUI.DoTextField (Rect position, Int32 id, UnityEngine.GUIContent content, Boolean multiline, Int32 maxLength, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0
  at UnityEngine.GUILayout.DoTextField (System.String text, Int32 maxLength, Boolean multiline, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0
  at UnityEngine.GUILayout.TextField (System.String text, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0
  at kOS.Suffixed.TextField.DoGUI () [0x00000] in <filename unknown>:0
  at kOS.Suffixed.Box.DoChildGUIs () [0x00000] in <filename unknown>:0
  at kOS.Suffixed.Box.DoGUI () [0x00000] in <filename unknown>:0
  at kOS.Suffixed.Box.DoChildGUIs () [0x00000] in <filename unknown>:0
  at kOS.Suffixed.Box.DoGUI () [0x00000] in <filename unknown>:0
  at kOS.Suffixed.Box.DoChildGUIs () [0x00000] in <filename unknown>:0
  at kOS.Suffixed.Box.DoGUI () [0x00000] in <filename unknown>:0
  at kOS.Suffixed.GUIWidgets.DoGUI () [0x00000] in <filename unknown>:0
  at kOS.Screen.GUIWindow.WidgetGui (Int32 windowId) [0x00000] in <filename unknown>:0
  at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0
  at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0
 
(Filename:  Line: -1)

Let me know if you need full log or something else.

[MaxRebo]

18 hours ago, hvacengi said:

If there's an issue with the Blizzy toolbar, we deffinitely need to know.  It is a supported feature (I don't think we ever said that it should be considered unsupported) but it is a feature that is not tested very thuroughly. [...] This is one of the reasons I prefer to have bugs reported as github issues (at least eventually), as github allows us to have a separate thread for every issue ensuring that all of the information pertinent to that issue doesn't get lost in data for other issues.  It just makes things a little easier to track.

I'll compile material for a github issue tomorrow (provided no one else beats me to it). I was genuinely not sure if I should even bother... that's been cleared up now.

11 hours ago, kcs123 said:

when you add icon on Blizzy's toolbar it opens kOS GUI near stock toolbar. Perhaps those few screenshots will explain [...] Availability of icon - appear/disapear between scenes is like I described in previous quoted post

Ditto for the fluctuating availability of the icon in Blizzy toolbar, but I never - not once - managed to get the kOS window to open when clicking on the button in Blizzy toolbar (during the few times when it's actually there to begin with) - not in any of the kOS versions I tried since 1.0.0, not in a fresh, clean install, never. It blows my mind that you at least get it to open, even if it does so in the wrong place...

Edited December 10, 2016 by MaxRebo

[danielboro]

i copypath("0:/file.ks",boot.ks).

reboot did not run it

i movepath(boot.ks, boot/boot.ks)

reboot did not run it

is it a bug?

[kcs123]

32 minutes ago, danielboro said:

i copypath("0:/file.ks",boot.ks).

reboot did not run it

i movepath(boot.ks, boot/boot.ks)

reboot did not run it

is it a bug?

Check this post, one page back, it would be awkward to quote myself.

[danielboro]

@kcs123 that is not my problem

the file has the correct name and is in the correct location

my problem is that it is not running at boot time

in my old ships i can rename a file to boot.ks and thy will run

way cant i do it in new ships?

 

p.s.

i see you use "SET SHIP:CONTROL:PILOTMAINTHROTTLE TO myThrottle. "

you can use "LOCK THROTTLE TO myThrottle."

Edited December 12, 2016 by danielboro

[kcs123]

14 minutes ago, danielboro said:

@kcs123 that is not my problem

the file has the correct name and is in the correct location

my problem is that it is not running at boot time

in my old ships i can rename a file to boot.ks and thy will run

way i cant i do it in new ships?

Ah, sorry, I didn't read carefuly, probably because I should be in bed long time ago :).
Boot feature is changed in one of latest kOS patches. Now, you need to create "boot" folder. Whatever script is in that folder, it will be available to choose in VAB/SPH on right click kOS CPU menu.

Perhaps it is beter explained in changelog and in new files and volumes documentation. I also wandered how it is possible to change boot script when craft is already in flight. Answer i sburied somewhere in this forum:

set core:bootfilename to "/boot/my_boot_script.ks".

 

[danielboro]

thanks

that worked

but i still think that if a file named boot.ks is in root it suold be auto run at boot time as default