[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Waz]

4 hours ago, kcs123 said:

@Waz, sorry, english is not my native language, so I probably didn't explained my thoughts well enough.

It's not mine after a few glasses of red on a Saturday night either.

 

Quote

No worries about storing position values somewhere outside, there is no special need for this. Ability to reposition GUI trough script command set GUI:x to something is good enough. It is up to user how he want to handle this. At least position:x,y is provided for that purpose.

It's not an issue with the GUI, but I think it's something worse adding to the system generally.

 

Quote

That was not main point of my previous post. Biggest issue is how to convert string to number or scalar. Since it can't be done trough kOS scripts, it have to be handled trough core C# code. You missed this part:

In other words, TEXTFIELD widget should be extended with properties:

• HASNUMBER (true,false) readonly value   - or HASSCALAR - whatever name you think fits better to kOS language
• SCALAR  readonly value                            - if HASNUMBER is true it is filled with proper value, otherwise it holds "0"

Again, if there is no clean way to do it, it's a weakness of the rest of the system. The kOS StringValue class in C# has a ToDecimal conversion, but I've no idea how to use it from kOS code. I use this horrid thing:

declare function atof
{
	declare parameter a.
	declare parameter def.
	local r to 0.
	local dec to false.
	local div to 1.
	from {local i to 0.} until i=a:length step { set i to i+1. } do {
		local c to a:substring(i,1).
		if c="." {
			if dec {
				//print "error - multiple decimal points".
				return def.
			}
			set dec to true.
		} else {
			if dec set div to div * 10.
			set r to r * 10.
			if c="1" set r to r + 1.
			else if c="2" set r to r + 2.
			else if c="3" set r to r + 3.
			else if c="4" set r to r + 4.
			else if c="5" set r to r + 5.
			else if c="6" set r to r + 6.
			else if c="7" set r to r + 7.
			else if c="8" set r to r + 8.
			else if c="9" set r to r + 9.
			else if c="0" set r to r + 0. // :-)
			else {
				//print "error - '"+c+"' not number".
				return def.
			}
		}
	}
	return r/div.
}

 

Quote

By the way how sliders work in unity, they were not always precise enough, so there will always be need to enter some exact value trough script.

One thing is to make sure your min and max values are sensible. For example, my launch script on planets with atmospheres sets them to body:atm:height and body:atm:height*1.5, since anything beyond these isn't really useful.

Quote

Sorry, don't know how to better explain this or where is exact place in your C# source code where should be applied.

That's okay - most important is to get input on actual experiences you have. I can do the translation into code.

Edited November 26, 2016 by Waz

[kcs123]

2 hours ago, Waz said:

Again, if there is no clean way to do it, it's a weakness of the rest of the system. The kOS StringValue class in C# has a ToDecimal conversion, but I've no idea how to use it from kOS code. I use this horrid thing:

Ah, I missed a part where you said that is C# code part, that prevent changes in a way that I proposed. That horrid thing would suffice until better solution is provided. I was also thinking about it for myself as last resort.

I forgot that you said you use existing "built in" Unity GUI. My guess here is that there is no direct access to unity objects(source code) and unity does not provide meaningful interface for thing I proposed. I'm not familiar with either, KSP API or unity itself. Only have experience in other areas of IT that could possible be meaningful and of some help.

That small kOS function will suffice. That example can also be part of documentation. As soon as other users start to build their GUIs they will ask same question. If there is limitation of current kOS system of any kind, that should be part of documentation and some workaround provided. So, noone will complain about it.

Anyhow, got enough to start creating something useful with existing stuff. I hope that I can get something worth to show soon enough.

[kcs123]

I have modified slightly function provided by @Waz to accept negative numbers too, require only one parameter for input and return "NaN" in case of errors.

Here it is, if anyone else need it

Spoiler

// function to use with new GUI to convert string to kOS SCALAR
declare function StringToScalar
{
	declare parameter InputString.
	local def is "".
	local r to 0.
	local dec to false.
	local div to 1.
	local sign to "".
	// check for negative number 
	local startindex to 0.
	if InputString:substring(0,1) = "-"
	{
		set startindex to 1.
	}.
	
	from {local i to startindex.} until i=InputString:length step { set i to i+1. } do {
		local c to InputString:substring(i,1).
		if c="." {
			if dec {
				//print "error - multiple decimal points".
				set def to "NaN". // For meaningful info that conversion can't be done
				return def.
			}
			set dec to true.
		} else {
			if dec set div to div * 10.
			set r to r * 10.
			if c="1" set r to r + 1.
			else if c="2" set r to r + 2.
			else if c="3" set r to r + 3.
			else if c="4" set r to r + 4.
			else if c="5" set r to r + 5.
			else if c="6" set r to r + 6.
			else if c="7" set r to r + 7.
			else if c="8" set r to r + 8.
			else if c="9" set r to r + 9.
			else if c="0" set r to r + 0. // :-)
			else {
				//print "error - '"+c+"' not number".
				set def to "NaN". // For meaningful info that conversion can't be done
				return def.
			}
		}
	}
	if startindex = 1 {
		return -1 * r/div.
	}.
	return r/div.
}.

 

 

[Dunbaratu]

I never knew the string class didn't provide a conversion to numbers.  (I didn't write that part).  That definitely seems like something that needs to be fixed.

I started an issue for it here: https://github.com/KSP-KOS/KOS/issues/1882

 

[Waz]

Any thoughts on signal delay and GUI?

Currently, the TermWindow delays each user command (and appears to only allow one being sent at a time), but this would seem pretty terrible in a GUI.

 

Edit: oooh, in investigating, I discovered "batch." and "deploy." commands.

Edited November 26, 2016 by Waz

[kcs123]

I encountered strange kOS interpeter behaviour. Here is file with used scripts, log and craft file.

When I run provided "mun_land" script I got error:

It started to happen only when I added additional triggers for AG5 and AG6. Before that script was working more/less as expected.
I tried command runpath("mun_land"). as well as run mun_land.

I added AG5 and AG6 to debug/figure out why script does not recognize changes made in global variable "AutopilotOn". That one was planed to be used as safety triger to abort execution of function in cases of emergency. I wanted to move main mun landing code to one simple function in other file/library. I wanted to make it like this before I proceed to build new GUI and terminal front end user interface.

Thing that I noticed is that ship no longer properly lock steering manager in chosen direction, while same code being part of main script code was working as intended. That is reason to start whole debug process. Before that I used ManeuverBurn function (provided in few posts earlier) that lock steering properly regardless being used in external function.

Thing that I'm suspicious is usage of "@lazyglobal off." command that I didn't used previously. That might break kOS interpreter. There is some other odd things in log that belong to kOS regading laser range finder and again some exceptions regading icon, possible conflict with Blizzy toolbar.

Here is interesting part of log reletad with above picture.

Spoiler

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
kOS: At interpreter, line 1
run mun_land.
    ^
 
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
kOS.Safe.Exceptions.KOSArgumentMismatchException: Number of arguments passed in didn't match the number of DECLARE PARAMETERs.
 Too many arguments were passed to run
  at kOS.Safe.Function.SafeFunctionBase.AssertArgBottomAndConsume (kOS.Safe.SafeSharedObjects shared) [0x00000] in <filename unknown>:0  
  at kOS.Function.FunctionRun.Execute (kOS.SharedObjects shared) [0x00000] in <filename unknown>:0  
  at kOS.Function.FunctionBase.Execute (kOS.Safe.SafeSharedObjects shared) [0x00000] in <filename unknown>:0  
  at kOS.Safe.Function.FunctionManager.CallFunction (System.String functionName) [0x00000] in <filename unknown>:0  
  at kOS.Safe.Execution.CPU.CallBuiltinFunction (System.String functionName) [0x00000] in <filename unknown>:0  
  at kOS.Safe.Compilation.OpcodeCall.StaticExecute (ICpu cpu, Boolean direct, System.Object destination, Boolean calledFromKOSDelegateCall) [0x00000] in <filename unknown>:0  
  at kOS.Safe.Compilation.OpcodeCall.Execute (ICpu cpu) [0x00000] in <filename unknown>:0  
  at kOS.Safe.Execution.CPU.ExecuteInstruction (IProgramContext context, Boolean doProfiling) [0x00000] in <filename unknown>:0  
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
Code Fragment
File                 Line:Col IP   label   opcode operand
====                 ====:=== ==== ================================   
                        0:0   0000         jump +27  
[built-in]              0:0   0001 @LR00   pushscope -999 0  
[built-in]              0:0   0002 @LR01   push $runonce  
[built-in]              0:0   0003 @LR02   swap  
[built-in]              0:0   0004 @LR03   storelocal  
[built-in]              0:0   0005 @LR04   push $filename  
[built-in]              0:0   0006 @LR05   swap  
[built-in]              0:0   0007 @LR06   storelocal  
[built-in]              0:0   0008 @LR07   push _KOSArgMarker_  
[built-in]              0:0   0009 @LR08   push $filename  
[built-in]              0:0   0010 @LR09   eval  
[built-in]              0:0   0011 @LR10   push True  
[built-in]              0:0   0012 @LR11   push null  
[built-in]              0:0   0013 @LR12   call load()  
[built-in]              0:0   0014 @LR13   br.false +6  
[built-in]              0:0   0015 @LR14   push $runonce  
[built-in]              0:0   0016 @LR15   br.false +4  
[built-in]              0:0   0017 @LR16   pop  
[built-in]              0:0   0018 @LR17   push 0  
[built-in]              0:0   0019 @LR18   return 1 deep  
[built-in]              0:0   0020 @LR19   push $entrypoint  
[built-in]              0:0   0021 @LR20   swap  
[built-in]              0:0   0022 @LR21   storelocal  
[built-in]              0:0   0023 @LR22   call $entrypoint  
[built-in]              0:0   0024 @LR23   pop  
[built-in]              0:0   0025 @LR24   push 0  
[built-in]              0:0   0026 @LR25   return 1 deep  
interpreter             1:1   0027 @0001   push _KOSArgMarker_  
interpreter             1:1   0028 @0002   push _KOSArgMarker_  
interpreter             1:5   0029 @0003   push mun_land  
interpreter             1:5   0030 @0004   push null  
interpreter             1:5   0031 @0005   call run() <<--INSTRUCTION POINTER--
interpreter             1:5   0032 @0006   pop  
interpreter             1:5   0033 @0007   pop  
                        0:0   0034         EOF  
 
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
kOS: Stack dump: stackPointer = -1
 
 
(Filename: C:/buildslave/unity/buildrtifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
SCREENSHOT!!
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
SCREENSHOT!!
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
[UIMasterController]: ShowUI
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
Game Paused!
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
 
[FlightDriver]: Flight State Reverted to Prelaunch.

 

EDIT:

Another update for bug described above. I just deleted ON AG5 and AG6 from main mun_land script and kOS interpreter started to work as intended again. With one exception. I figured out that steering manager become broken when it is locked inside provided RocketLand function.
It throws error that it can't lock to null direction. Proper heading is provided to function, I even tried to put MyHeading parameter to global variable. It didn't helped.

So instead of using external function in library, I moved exact same code back into main script, with removed parameters (using global variables instead) and that piece of code regarding steering manager started to lock into chosen direction properly again.

Wierd.

Edited November 27, 2016 by kcs123

[kcs123]

Some WIP regarding new GUI and possible usage:

Found small issues though. I have this in code

set HeadingButton to HeadingInputBox:ADDBUTTON("Set").
set HeadingButton:ALIGN to "RIGHT".
//set HeadingButton:WITDTH to 30. // gives error
//set HeadingButton:SETTOGGLE to false. // gives error

Also, VMARGIN suffix seems does not have any influence. I wanted to reduce space between radiobuttons for chosing autopilot mode, but seems it does not have much influence. It does not throw error but spacing is not reduced in that vertical box between widgets.

EDIT:

Forgot to mention, I have solved issue with multiple GUIs in such way that I added showing GUI command on AG instead to show it on boot. Hiding is done with CLOSE button as you can see on picture.

However, if you crash craft and kOS CPU no longer exist, GUI also does not respond to close button and stay forever on screen. Not issue if you switch scene and have only one craft in area, but it can be problem with multiple craft in area and you switch between them.

Edited November 28, 2016 by kcs123

[Waz]

For the next build, I've implemented what feels like a very clean and usable means of signal delay. I only intercept the critical messages (changing a label, pressing a button, etc.), not even little mouse move event, so that the GUI stays responsive, but acts as if run remotely from the core:

In this video, the user moves the slider, these changes are sent to the core over a 2-second link, then the program on the core sets the label according to the new value to "90km", and this change is sent back along the link to be shown in the GUI.

As you can see, it's actually sitting on the launch pad, but by setting GUI:EXTRADELAY you can test that GUIs are usable over interplanetary links in RemoteTech. Also added is connectivity support: if the vessel is not in control range, all GUI is greyed out and faded with a reddish tint.

Also in the next build, I've tweaked the popup menu to make it very easy to use it for showing things other than strings (in the video, there are two lists of BODY objects, displaying the NAME of each BODY in the popup). It works like this:

local popup to vbox:addpopupmenu().
set popup:OPTIONSUFFIX to "NAME".
list bodies in bodies.
for planet in bodies {
        if planet:hasbody and planet:body = Sun {
                popup:addoption(planet).
        }
}
set popup:value to body.

The new build (#4) is up at https://github.com/WazWaz/KOS/releases/

Edited November 28, 2016 by Waz

[kcs123]

@Waz, something become broken in alpha4.

At first I was thought that I messed up something badly, but does not seem to be case this time. Although it is always possible

I used exact same code for powered landing, as it is was before I started to work on GUI frontend. IIRC, it was also worked in alpha2 or alpha3 (I started to work on hovering optimization, so I didn't tested landing only part of script, lost track what version worked).

In alpha 4, first thing I noticed is that regular "Set" button no longer work. When I press the button it stay visualy in pressed state. That is not only issue.

When I start powered landing procedure, PID throttle no longer respond properly on time, not setting craft throttle on time properly, resulting in crash. I lost some time in debuging, thought that I not properly configured PID, or something. Finaly, I compared that part of code with backed up verion that I checked for sure if works and nothing relevant is changed there.

In code for GUI buttons, I have this:

ON HeadingData:CONFIRMED {
	if StringToScalar(HeadingData:TEXT) <> "NaN" {
		set MyHeading to StringToScalar(HeadingData:TEXT).
	} else {
		set HeadingData:TEXT to MyHeading:TOSTRING.
	}.
	preserve.
}.
ON HeadingButton:PRESSED {
	if StringToScalar(HeadingData:TEXT) <> "NaN" {
	    set MyHeading to StringToScalar(HeadingData:TEXT).
	} else {
		set HeadingData:TEXT to MyHeading:TOSTRING.
	}.	
	preserve.
}.
// ---

When I commented out ON HeadingButton trigger, everything started to work properly again. I did it for each "normal" button use to set heading, pitch, roll.

So, either, I reached limit how much triggers kOS can handle at time, or something else is broken with buttons in alpha4.
Let me know if you need anything else, output log does not show any signs of errors regarding this. Current workaround for me is to avoid using buttons for a while and focus on other things.

[sebseb7]

Note to the devs: when designing the gui, please make sure that this easily incorporated into rasterpropmonitor. I always like to control manned crafts with RPM.

 

 

thanks.

[Waz]

10 hours ago, sebseb7 said:

Note to the devs: when designing the gui, please make sure that this easily incorporated into rasterpropmonitor. I always like to control manned crafts with RPM.

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

18 hours ago, kcs123 said:

@Waz, something become broken in alpha4.

At first I was thought that I messed up something badly, but does not seem to be case this time. Although it is always possible

I used exact same code for powered landing, as it is was before I started to work on GUI frontend. IIRC, it was also worked in alpha2 or alpha3 (I started to work on hovering optimization, so I didn't tested landing only part of script, lost track what version worked).

In alpha 4, first thing I noticed is that regular "Set" button no longer work. When I press the button it stay visualy in pressed state. That is not only issue.

I'd have to see more of the code; do you have previous versions of your scripts? Check exactly when it broke - maybe just your other edits.

Buttons didn't change in alpha4. If a button stays visually pressed, that means you're not calling PRESSED on it.

I'm assuming you're not using RemoteTech - that's the main change for alpha4 (comm delay).

Edited November 30, 2016 by Waz

[kcs123]

You are right, I'm not using RT at the moment, waiting for a version that will be build on top of stock comm network. Signal delay was not of highest importance for my playtrough at the moment as some of other mods were also not updated at the moment.

I have proper PRESSED call for those buttons. Even most simple one, to close GUI stoped to work. Meaning, I have AG4 assigned to open GUI and I close it trough GUI button. I can do that only once, next time I open GUI with AG4, it shows GUI with Close button pressed and if you try to press button again, it no longer works.

On the other hand, radio button and checkbox sitll work properly as intended. Here is what I got for Close button.:

ON CloseButton:PRESSED {
	Hover_GUI:hide().
	preserve.
}.

Do I need to add explicit call to set button:PRESSED to false ?

Anyhow, I will pack all relevant scripts and upload for troubleshooting ASAP.

EDIT:

@Waz, here is latest iteration of script with GUI. I also provided latest known version without GUI, using only AGs, for comparison.
Problematic parts of code is commented out. Once you do that, craft no longer can properly land. Try to use Landing radio button before you uncomment triggers for buttons, and then try landing with that part of code enabled.

Edited November 30, 2016 by kcs123

[kcs123]

Some progress. I excluded ON RegularButton:PRESSED triggers from GUI and added missing functionality, to hover at desired altitude and to execute maneuver. Seems to work properly, but require some more testing to be sure that I didn't oversight something.

Wha tI have noticed is that kOS does not love stock SAS much. It seems that rocket hover much more stable in any chosen mode, with zero vertical velocity or on desired altitude when cooked are used and SAS off. With SAS in stability assist mode, PID have hard time to establish equilibrium.

I didn't actualy measure anything, but looks like FPS drops down slightly and more CPU power is needed with SAS on, more time pass between physical tick for PID calculation and larger is error from desired output to hover. Need to observe everything more to be able to tell more about it.

Anyhow it is quite satisfactory if you take into account that it is very early alpha stage of development. I wanted to make those "set" buttons smaller, but it is not possible to set width on them to be smaller, for some reason. I'm also in doubt to add sliders in addition to text fields or not. I'm afraid that those would take up too much of screen if I do that.

Now it is time to create some GUI for launching script. Trough development of this one it seems it would be too much if I add widgets on GUI for orbital insertion.

[Waz]

8 hours ago, kcs123 said:

I have proper PRESSED call for those buttons. Even most simple one, to close GUI stoped to work.

Definitely a glitch introduced in alpha4 - I spent so much time focused on the time delay stuff, I didn't notice that I broke this (basically, the visual change wasn't propagated across the link).

Alpha5 is up, which fixes the problem.

Edit: Alpha6 is up now, which is up-to-date with the 1.0.2 pre-release (in preparation to hopefully integrate) and so includes the new string:TONUMBER, which you @kcs123 might find useful!

Edited December 1, 2016 by Waz
alpha6

[hvacengi]

On 11/24/2016 at 0:08 PM, kcs123 said:

small critics for plugin code. IIRC usage of "foreach" commands create garbage in unity - memory leaks and FPS slowdowns.

Yes, sort of.  Yes, foreach uses extra allocations that generate garbage, and yes it can have an effect on the game's FPS.  However it's fine when used intermittently.  The problem is when you call multiple foreach loops every single physics tick you're accumulating extra garbage.  That has the effect of increasing the frequency of garbage collection, but isn't technically a memory leak (because when the garbage is collected, the memory is freed).  Calling it when an object is created or destroyed should be perfectly fine, unless for some reason the objects are constantly being created and/or destroyed.

(For what it's worth, we do have a true memory leak, that I'm working on fixing but I don't know if it will make the next release or not)

 

On 11/25/2016 at 11:47 AM, kcs123 said:

I belive Wazs fork comes from your updated code for Blizzy's toolbar. Now it is possible to have kOS icon on stock toolbar, values from stock difficulty settings regarding kOS work properly now. 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. When using stock toolbar, kOS UI shows properly.

I'll have to install the toolbar to check this behavior.  Can you post a log file?

 

On 11/25/2016 at 11:47 AM, kcs123 said:

There is still some unwanted rotation when switching between two. Also in space, locking to maneuver vector also cause undesired rotation. Usage of monopropelant for RCS to rotate craft while rotation is not necessary at all.

Interesting, in my experience the UP variable didn't really vary all that wildly.  Given that it's created the same was as vector:direction I can't say I'm surprised.  But regardless, kOS already does provide you a way to prevent rotation: http://ksp-kos.github.io/KOS_DOC/math/direction.html#function:LOOKDIRUP

lock steering to lookdirup(up:vector, ship:facing:topvector).

 

On 11/27/2016 at 6:47 AM, kcs123 said:

I encountered strange kOS interpeter behaviour.

...

I figured out that steering manager become broken when it is locked inside provided RocketLand function.
It throws error that it can't lock to null direction. Proper heading is provided to function, I even tried to put MyHeading parameter to global variable. It didn't helped.

I'll try to run your scripts at some point to test.  The error from the log should be thrown before actually parsing the script file, so changing the content of the script shouldn't matter.

But I'll need more information about the steering error.  There are a couple different points in the steering code where it may throw an error, and some of them should continue to display the error message on every tick.  Can you provide that log file?  Did you make any changes beyond removing the two action group triggers before you started getting that error?

Edited December 1, 2016 by hvacengi

[kcs123]

@hvacengi, you missed link for logs, scripts used and log file. All is in one zip archive.

On 27.11.2016. at 0:47 PM, kcs123 said:

Here is file with used scripts, log and craft file.

"mun_land.ks" is broken script. "mun_land_old2_OK.ks" is basicaly same code but in main script file. Nothing fancy, but it can be used for comparison.
Those ones does not have new GUI inside.

Files provided for Waz, later on is same thing, but with GUI on top of it.

1 hour ago, hvacengi said:

rotation: http://ksp-kos.github.io/KOS_DOC/math/direction.html#function:LOOKDIRUP

Have yet to try with that, I was using "UP", didn't noticed that LOOKDIRUP is different kind of thing. I was thinking that UP and LOOKDIRUP are same thing. Anyhow, I ended with using HEADING(desired_heading,90) instead of up, rotation is much less with it, although, option to exclude rotation would be nice to have, in various situations.

1 hour ago, hvacengi said:

Did you make any changes beyond removing the two action group triggers before you started getting that error?

No, nothing else is changed.Just those two AGs.

EDIT:

Reproducing steps, before I forget about them. Use that broken "mun_land.ks" - to get error with run command.
Delete mentioned AG5 and AG6 triggers. Now script can run. Throttle up and launch rocket in air for about 500-1000m.
Use AG4 to trigger landing function call.

PID will try to adjust thrust for landing, but if you open console with ALT+F12 you can notice that steering manager throws error in log. Steering manager does not lock at all in provided directions (between retrograde and UP direction).

Run "mun_land_old2_OK.ks" where landing code is in main script, Do same thing, launch rocket up to 500-1000m and use AG4 for landing. Steering manager locks properly in desired directions between UP and retrograde vectors.

Have yet to add kOS icon in game, click on it and then provide log file. I will try with that latest fork from Waz that include latest PRs to see if still happens.

 

EDIT2:

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.

Exit game to desktop, start again and kOS icon is in flight scene. But going to VAB, flight scene and back to KSC break everything again - icon is missing.

Edited December 1, 2016 by kcs123
more stuff provided

[Drew Kerman]

On 11/29/2016 at 11:18 PM, sebseb7 said:

Note to the devs: when designing the gui, please make sure that this easily incorporated into rasterpropmonitor. I always like to control manned crafts with RPM.

then you should be looking into kOSPropMonitor

[hvacengi]

6 hours ago, kcs123 said:

you missed link for logs, scripts used and log file. All is in one zip archive.

I only see one output_log.txt, and it has the error for "run", not the error you mentioned for steering.  Not a huge deal at this point I suppose, since I'll be able to test it myself when I get home from work.

On 11/29/2016 at 11:18 PM, sebseb7 said:

Note to the devs: when designing the gui, please make sure that this easily incorporated into rasterpropmonitor. I always like to control manned crafts with RPM.

5 hours ago, Drew Kerman said:

then you should be looking into kOSPropMonitor

As Drew points out, kOS itself does not provide the support for RasterPropMonitor, so we don't really know how gui objects are instantiated there.  I honestly cannot see this working well in the raster window, simply because of scale.  That doesn't mean that we can't look at keeping a certain level of abstraction available so that it might theoretically be possible.  But I wouldn't expect that to exist in the first incarnation.  After the GUI system is working we can look at pulling out the necessary components so that it can support any kind of UI system available.

Edited December 1, 2016 by hvacengi

[Waz]

7 hours ago, kcs123 said:

regarding Blizzy's toolbar. It is based on Waz's alpha6 fork.

Please ignore this. My alpha tries to prevent heaps of TermWindow objects being created every time you reboot the core (which you'll do a LOT if designing a boot GUI), but it's only a quick-fix. I'll leave that kludge out for alpha7.

[kcs123]

2 hours ago, hvacengi said:

I only see one output_log.txt, and it has the error for "run", not the error you mentioned for steering.  

Yes, I forgot that I noticed steering bad behaviour later on, while I was already uploaded scripts, craft and log file. Should be easy to reproduce, though, once you get time for it.

44 minutes ago, Waz said:

Please ignore this. My alpha tries to prevent heaps of TermWindow objects being created every time you reboot the core (which you'll do a LOT if designing a boot GUI), but it's only a quick-fix. I'll leave that kludge out for alpha7.

Ah, OK, good to know. Not of ultimate importance, I can make workoaround of this while testing other stuff, just wanted to know about this.
I mentioned that I use alpha6, so if hvacengi can't reproduce this on official code we can then know that GUI fork break things with it.

Can't help you much more with this except with log files and feedback as much as accurate I'm able to observe.

[Waz]

alpha7 is up (I've left alpha6 there for now too).

This release pushes all the style attributes into their own Style class (accessed from the STYLE attribute of widgets). So, for example this:

SET ok:FONTSIZE TO 20. // Big!

becomes:

SET ok:STYLE:FONTSIZE TO 20.

Having real Style objects also allows the GUI to expose a Skin object containing all the Styles that are used, so you can make a uniform look by setting the styles in the skin of the gui before creating the widgets:

SET gui TO GUI(200).
SET gui:SKIN:BUTTON:FONTSIZE TO 20.
SET ok TO GUI:ADDBUTTON("OK"). // already big!
SET cancel TO GUI:ADDBUTTON("Cancel"). // also already big!

 

Edited December 2, 2016 by Waz

[kcs123]

What is acceptable value for default error when using new built in function TONUMBER ?

I tried with this:

if (AltitudeData:TEXT:TONUMBER("NaN") <> "NaN") {
		set seekAltitude to AltitudeData:TEXT:TONUMBER("NaN").
	} else {
		set AltitudeData:TEXT to seekAltitude:TOSTRING.
	}.

But that one gives cast error.  I just replaced my own custom function with built in TONUMBER, so I also need to change both sided of equation for checking in something that make more sense to kOS.

EDIT:

I think that I found info on this page: https://github.com/KSP-KOS/KOS/pull/1883/commits/1d67c12b66278039578edfba772e32374194e46d

Seems that you only predicted number of any kind to be accepted as default error. Don't know if that is good idea.
Puting some large number, large negative number or zero for default value in case of error could be misleading in any scenario where numbers are possible to be anything between -999999999 and +999999999 including zero.

Because we can't use NIL or NULL in feasible way within kOS, is it possible to return string "NaN" or whatever user choose as default result ?

In other words, is it possible in C# to have two overloaded function that give some string as result in cases of error ?

Edited December 2, 2016 by kcs123

[Waz]

4 hours ago, kcs123 said:

What is acceptable value for default error when using new built in function TONUMBER ?

 

The TONUMBER method takes an optional SCALAR value. I agree it's odd design, but kOS hates nil, null, and NaN throughout, so it's consistent.

You could detect error with:

LOCAL xnum TO x:TONUMBER(1).
IF xnum = 1 AND x:TONUMBER(2) = 2  { bad ... }
ELSE { good ... }

 

[Dunbaratu]

11 hours ago, kcs123 said:

In other words, is it possible in C# to have two overloaded function that give some string as result in cases of error ?

Possible?, Yes: Desirable? No.

Right now such things only work because of the fact that everything can be secretly promoted to string when doing equality comparisons, so you can ask "is this thing (that might be a number or might be a string) equal to this string 'NaN'?" without a crash when it is a number.  But it's a clunky workaround.

I'm hard pressed to think of a scenario where you can't pick *some* actual numeric value that isn't a possible valid result, so you can use that as your test.

That being said, I've always been of the opinion that the lack of nulls (and the lack of NaN's, which isn't quite the same thing, of course) was a bad decision.  But introducing them now means having to go back and re-do a large amount of the manuals and the API which currently go out of their way not to teach the concept (remember the audience is supposed to include people who've never programmed before, so if we use nulls as a means of an API call saying "the thing you asked for doesn't exist", then we need to change everything in the docs to make sure it's using that paradigm all over the place and gives people plenty of introduction to it.).

All the places in the API where there exists a "HAS...something" suffix are there specifically as an alternative because you can't test if a value is null.  So at this point adding nulls in a way that isn't an ugly shoehorn'ed side feature means going back and removing all the HASwhatever suffixes because having both means of testing it sends mixed messages.  You've got to go with one model or the other, not both, or the language gets very incoherent and ugly.  I'm reluctant to add nulls now without a major version number shift that warns people that their older scripts will break (because adding them means I also want to REMOVE the HASWHATEVER suffixes to keep things consistent.)

I suppose we could extend the HASwhatever model and introduce a means to query if the string *would* be translatable to a number without actually returning that number.  String:ISNUMBER or something like that.

 

Edited December 3, 2016 by Steven Mading

[Waz]

2 minutes ago, Steven Mading said:

All the places in the API where there exists a "HAS...something" suffix are there specifically as an alternative because you can't test if a value is null. 

So, for consistency, STRING:ISNUMBER?