Waz

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/

So, for consistency, STRING:ISNUMBER?

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

A screenshot, even cropped to just 5% of it's size is worth more than 46 words. :-)

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!

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.

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!

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

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/

Easiest way would be to use a different config than the default one. See SVE on the first post in this thread. Did you click Save?

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.

It's not mine after a few glasses of red on a Saturday night either. It's not an issue with the GUI, but I think it's something worse adding to the system generally. 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. } 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. That's okay - most important is to get input on actual experiences you have. I can do the translation into code.

Sorry for the weird quoting. Forum editor is weird. Storing small simple values isn't easy. kOS really needs a key-value datastore linked to the savefile. AFAIK, all you can do is write files, and then, only poorly. Maybe someone else can answer that link better. So having the program itself do this would be easy, if there was some kind of: gui:x = STORAGE:GET("guix"). gui:y = STORAGE:GET("guiy"). ... STORAGE:SET("guix",gui:x). STORAGE:SET("guiy",gui:y). Also, I have no idea how to convert strings to integers. I have an "atof()" function in by kOS function library, but I too suspect I'm missing something - seems like obvious functionality. Certainly nothing is stopping you from having both open, the question is whether this is a big enough concern to implement this anchoring concept. To my mind, the TTY window has become bloated and ugly and full of all sorts of functionality that really belongs in the Settings, not the "primary" UI (not to mention ugly icons and poorly aligned gui elements), so the less I use the TTY the happier I am. YMMV. I definitely need to look into multi-ship scenarios, but the GUI is not even one-per-TTY, so I can't see how it will be a problem, except the minor issue of having a LABEL identifying which ship the GUI is controlling.

I'm sure everyone is different. I was mostly explaining how I use it. Once I've developed a program, I try to tune all output to a minimum that can be logged with HUDTEXT. I'm yet to investigate the multiple-CPUs scenario @kcs123 described. With the limitations KSP places on non-active vessels, I've never really made good use of multiple CPUs at once. Personally, if it was an issue, I'd just add a label with the ship:name and be done with it (having a label at the top also makes it clean to drag windows around), just as the TermWindow does. guialpha3 - up on https://github.com/WazWaz/KOS/releases/ Add RADIOBUTTON, SCROLLBOX and POPUPMENU widgets. Revert scope-based widget deletion. Add explicit widget disposal (removal from parent). Make top-level window auto-resize. Fix blank transparent space window margins. I think I'm done adding widgets now - these cover all the classics. Note that the height parameter is now optional (docs not quite up-to-date), and windows resize automatically to fit content.

Maybe - if we can work out how to make both sensible. For me, the main way to use a GUI is in order to invoke tried-and-tested functionality - where the TermWindow is not used at all. Someone using a terminal doesn't generally want to go over to the mouse to click a button rather than just keep using the TTY (of course, it still needs a READLINE function of some sort), and similarly, someone using a GUI doesn't want to first have to open the TTY (itself a 2-3 click operation), then type a command, just to interact with a simple GUI. Even if running a rarely-used GUI program from the TTY, the next thing the user is likely to do is close the TTY to free up screen space - should the anchored GUI then disappear? To give an example of real-world use, I've added GUI to my "Launch to Orbit" script to allow entering target altitude and heading (previously done by editing a little parameters file or by kludge parsing the core "name tag" as if it was parameters). After reaching orbit, or upon reboot, the script then switches to just showing 3 small buttons: MEX, LND, LTO, respectively invoking my old maneuver executer, lander, and launch-to-orbit scripts. The MEX and LND scripts have only been trivially changed: adding support for a gui_cancel button that if defined aborts the command (like Ctrl-C did for them when standalone, but also resetting throttle, timewarp, etc.). As you can see, the GUI as I'm using it is a way to tie together a collection of mature TTY-based functionality. A friend of mine has been using kOS ever since he got too addicted to RemoteTech's FlightComputer for executing nodes but then it wasn't ported to 1.2 for a while. All he ever does is boot into the launch-to-orbit script or manually "run mex.". I think this is a great way to get non-programmers to install kOS and eventually to think about looking under the hood. Some may doing all editing in Notepad (does anyone actually use the built-in editor?), and power-cycling the core to rerun their GUI, only ever opening the TTY if they need to see an error message when something goes wrong. In all cases, the GUI-without-TTY and TTY-without-GUI are the primary use cases I see. Only when developing a GUI would the TTY commonly be open in parallel to a GUI. @kcs123 - W,H,X,Y would be too confusing, I think. It's clear to just write GUI:X = 123. GUI:Y = 456, I think. I like the idea of X and Y somehow being "remembered" between invocations, but I can't think of a sensible way to do that without having some magic key for windows.

The boot script can be changed programmatically with core:bootfilename. The only time I've changed it in the past is to set up miners to restart themselves every morning. Window position can be set with X and Y properties after creation. I guess they could be done via a 4-argument function, but I dislike effectively having default parameters that aren't at the end. Also, I've reconsidered the use of scoping to control widget lifetime and I'm pretty sure it's wrong. I'll revert that in the next build.

@kcs123 looks like you worked out the textfield :text attribute. Was the checkbox doc the only one I needed to fix? That foreach was fine (it's not executed every frame), but I found another one worth fixing. I've spent some time porting my launch and node execution scripts to use the GUI, and I found a few things: MARGIN - split in HMARGIN and VMARGIN PADDING - split in HPADDING and VPADDING Honour scoping so that UIs can be usefully made with locals, not just globals. Add ADDHLAYOUT and ADDVLAYOUT - like HBOX/VBOX, but default to entirely no style or borders, just pure layout A number of fixes, such as making LABEL honour HSTRETCH being set to false (and it will now default to false too) I've updated the release zip file and edited the comment accordingly.

Alpha test of GUI ToolKit I've put together a simple but powerful GUI system for kOS that allows you to make real on-screen GUIs like this: Using code like this: // Create a GUI window LOCAL gui TO GUI(200,100). // Add widgets to the GUI LOCAL label TO gui:ADDLABEL("Hello world!"). SET label:ALIGN TO "CENTER". SET label:VSTRETCH TO True. // Take up spare space. LOCAL ok TO gui:ADDBUTTON("OK"). // Show the GUI. gui:SHOW(). // Handle GUI widget interactions. // Can safely wait and GUI will still be responsive. UNTIL ok:PRESSED { PRINT("Waiting for GUI"). WAIT(0.1). } // Hide when done (will also hide if power lost). gui:HIDE(). I'm keen to add anything you might find missing before this becomes a candidate for inclusion in kOS proper, so if you'd like to try it out, here is a zip file of the current pre-release for KSP 1.2.1, plus the GUI. https://github.com/WazWaz/KOS/releases/ The documentation is in GameData/kOS/html/structures/misc/gui.html in this package. Obviously, only report problems with this release that relate to the GUI, and only complain to me. If you're on github, you can also discuss the branch here: https://github.com/KSP-KOS/KOS/pull/1878 Enjoy! Post pics!

The trouble is, duplicate configs is perfectly fine according to the design - it doesn't matter if you put your Kerbin cloud layers in separate files or all in one fine, for example. Similarly with config values - just about anything is "legal", and a structurally incorrect cfg file doesn't even get to EVE at all (it's as if it never existed). In a few cases, EVE will report "Unable to parse config node". Yes. Specifically, the UV of each point is moved by an amount based on the last few decimal places of the position (which would normally be doing nothing, just giving "nice crisp" delineation between pixels, exactly what you don't want to see in clouds). Currently it distorts the main texture, not the detail texture, so under-using it and over-using detail textures will make the effect less useful. SVE's textures don't use it, for example, as those instead rely on high resolution main and detail textures (but you'll still see ugly pixels with SVE sometimes). It can also be used for animation, in the example config it's both gently in the fine detail as in Kerbin clouds, or more microscopically in Jool's clouds.

Thanks for continuing this mod! I've sent a pull request with searching and sorting and stuff.

In fact, regardless of EVE, sometimes there are two copies of Kerbin at the main menu. Normally this isn't noticeable since they perfectly overlap - but clouds get lighter and citylights and cloud shadows appear to Z-fight with the extra Kerbin. I have confirmed this with KerbalObjectInspector with today's latest Kopernicus from github.

If there is something about the first page of this topic that you don't understand, please clarify. I'm not really an expert in *using* EVE to get good looking clouds. It's also hard to know what you mean by "funky" in a static gif - I can't know what you *want* the clouds to look like - maybe weird brown clouds is normal for this planet. If you can post the cloud .cfg file you're using, I can take a closer look.

I'm trying to clean up some weirdnesses in EVE and one of them is how with Kopernicus installed the clouds on Kerbin in the main menu get messed up. I think I might have identified the root cause - it's seems Kopernicus (I think) at some point creates a deep copy of the Kerbin GameObject - so all the children are copied (with "(Clone)" at the end, I'm guessing thanks to Unity's Instantiate function). But of course these objects are no longer known to EVE so are not correctly updated. Worse, since the objects appear unclouded, EVE merrily adds (more) clouds, making it worse. Any suggestions? Currently I'm just ensuring the EVE objects are named uniquely and deleting all objects of those names that end with "(Clone)", but it's pretty ugly.

Gladly. The only reason I didn't for the first time I published it was to minimize change so that the CKAN update would be as smooth as possible.

It should be marked as 1.2.1-compatible now.