GUIs: which system to use; best practices?

[beabop]

We have a total clustereffup of three different GUI systems in stock, with yet another on its way with the Unity 5 port. Do mods use yet another system at all? Which one do you recommend?

Also, could we share some best practices for GUIs? Which toolbar do you put your mod's menu button on and why? What are some anti-patterns and pitfalls that experience modders all know about?

[Crzyrndm]

The GUI systems the devs refer to are not really relevant to plugin developers unless trying to edit stock UI elements (which is normally a huge PITA). Creating a completely new UI element goes through the Unity legacy GUI scripting system which lives in OnGUI, or if you're feeling really adventurous the new Unity system that Squad are shifting all their GUI to (which isn't particularly script friendly, although in syaing that, GUI scripting sucks either way). Tutorial, and the only KSP plugin example AFAIK is the building shortcut buttons)

Edited June 20, 2015 by Crzyrndm

[Ser]

Did I understood right that OnGUI() mod interfaces will all die on the next release?

[smjjames]

Did I understood right that OnGUI() mod interfaces will all die on the next release?

There will probably be an equivalent to replace it, but yes the current OnGUI thing will die because those three systems will be scrapped completely and replaced by a single unified GUI system.

I'm sure they'll try to make the transition as easy as possible though.

[Ser]

And is it possible to start programming GUI in a new way right now for not having to redo all this pain from scratch later? Does KSP support it?

[smjjames]

And is it possible to start programming GUI in a new way right now for not having to redo all this pain from scratch later? Does KSP support it?

I would think that you'd need to know what SQUAD is replacing the OnGUI module with in order to do that. EVERYTHING is likely to break in 1.1 with Unity 5, even part only mods.

[Ser]

Seems that 1.1 release is much like visiting a dentist.

[Nertea]

Squad has nothing to do with OnGUI. I'm pretty sure that it would take a lot of work to leave a Unity system out of the finished game. It still exists in U5, though it's legacy, and I doubt that it will disappear for a Unity version or so.

Now, they might not include their custom libraries like.. EZGUI I think. But I don't think too many mods use that?

[Diazo]

For GUI system to use, it's what you are familiar with. It's probably worth looking at using the new GUI system if you can though.

Having said that, I'm staying with onGUI as long as I can simply because (across all my mods) I'm pretty sure I have more then 2000 lines of GUI code and I'm not looking forward to having to redo those.

However, on the "which toolbar to use" question, it's easy enough to detect the Toolbar mod and use that if present, and if not use the stock toolbar.

https://github.com/SirDiazo/TWR1/blob/master/TWR1/TWR1.cs#L258-L275 is one of the places I do this.

D.

[Ser]

Now, they might not include their custom libraries like.. EZGUI I think. But I don't think too many mods use that?

You hit it Mine do. Even rely on that.

[DMagic]

OnGUI isn't going anywhere and doesn't have anything to do with KSP. The most that might be said is that the RenderingManager might not accept legacy Unity GUI Windows anymore, though I doubt it. But in any case you can always just use OnGUI directly and handle hiding/showing your UI manually.

And yes KSP can use the new UI system right now. The latest version of KSP (from 1.0 up) uses Unity 4.6, which includes the new UI system. There might be some additional functions added in Unity 5, but the bulk of the change was in 4.6.

That said, creating a UI that has the standard KSP look would be difficult right now. You would have to create all of the UI assets yourself. Mu said that we would be able to use all of the KSP style assets in the new UI system (the font styling and color, the button images, sliders, etc...) so you might not want to deal with the new system until KSP 1.1 comes out.

Whether you should use the new system is mostly a matter of how complex your UI is, and whether it's meant to be displayed all of the time.

Every UI element (buttons, labels, sliders, textures, etc...) produces multiple draw calls when using GUILayout, and elements can be drawn even if they are off screen or hidden in a scroll menu (try putting 1000 labels in a scroll menu that only shows 10 at a time, KSP will slow to a crawl). Manually positioning things with GUI can alleviate some of the problems, but it's a lot of trouble and doesn't help that much in most cases.

But if your UI is only really meant as a configuration window, or something not meant to be shown a lot then those performance issues aren't really a big deal.

Something like Contracts Window +, which is designed to be shown all of the time and can display a huge number of elements, is something that could really benefit from using a more efficient UI system. Which is why I'll probably end up spending a lot of time porting it over.

[sarbian]

DMagic said most of the useful stuff but I want to add this : don't jump on the new UI wagon too soon. While you convert your whole UI right now you would also miss any helper class that Squad may add for their use (and ours). The Unity New UI is quite verbose to code but other games (City Skylines) made some nice API to lower the amount of code by a lot.

Ser : your mod use EZGUI to interact with the stock UI. Squad is currently replacing that UI so you would have to redo your mod anyway.

Edited July 1, 2015 by sarbian

[Ser]

DMagic, I agree with you, the OnGUI method is a kind of a Rect-al way of GUI programming.

sarbian, yes, I've already realized that I'll have to redo, but fortunately I don't have as much GUI as say SCANsat by the moment.

- - - Updated - - -

Have a qustion, though: seems like in the new version it will be possible to draw GUI by Unity editor and export to use as a prefab. Is that possible for legacy GUI for not to draw it in code?

[sarbian]

Exporting the UI in an asset bundle may be possible but I don't know how easy it would be to interact with those once you load them. Since you would may not have your callback available in the Editor it may make things complex, or not

[Ser]

Exporting the UI in an asset bundle may be possible but I don't know how easy it would be to interact with those once you load them. Since you would may not have your callback available in the Editor it may make things complex, or not

As long as we are able to get a component by its name or some known id, it shouldn't be a problem to add a hook into it, I hope. And it would be wonderful to design your GUI visually and then import it to your assembly instead of trying to guess pixel by pixel.

Edited July 2, 2015 by Ser

[sarbian]

I am one of those evil dev that wrote Swing/AWT UI by hands so I am not that afraid But yeah, it would be nice.

[Ser]

sarbian, sounds like "I know what the pain is, I was married... three times..."

Now you have a great opportunity to code JavaFX GUI by hands instead. Hands are our best tool

Edited July 2, 2015 by Ser

[ziporama]

I can share my experience:

Unity deprecated the old GUI (onGUI) calls with 4.6.x and IIRC indicated it would be completely gone in 5.x. GUI calls in Unity have very little to do with KSP and the exposed API by Squad, it's squarely a Unity scope.

I can tell from the last two months in the trenches with the new UI and figuring this out that the new UI is much better thought out than the old GUI and feels almost "normal" if you're used to UI development, although it still lacks many of the expected UI objects, so doing a toolbar for example is not in the box, but it can be built. It's got great flexibility and potential however as you can build just about anything you want from very raw and basic components. If you're used to .NET components, Unity feels more like the assembly language version and barebones beginnings.

As was mentioned above, the main problem from the plugin standpoint is that Unity wants you to develop any new UI objects and libraries exclusively from within the Unity editor/designer and not from scripting. As this is not an available mode or option for KSP plugin development.

There is virtually no documentation from Unity at all on how the new UI works from scripting and this is unfortunately by design. It is clear to me that Unity does not want you to write UI code from scripting at all. This said, you can figure it out by trial and error, which takes an enormous amount of time and can be an exercise in frustration culminating with "so, this is HOW it works!". The new UI completely work from scripting, however the work is 95% investigating how the various Unity objects "fit" together, in what order, as well as what to use for API calls. The editor of course knows how to do all this, and you can do all of this inside the editor, however the output is not a script, it's compiled modules that are designed to be packaged with the game, not at all packaged as an add-on.

What I ended up doing is working in the design environment to mock up my UI and making it work (primarily for positioning), then analyze how it does things (so what object is the parent of what, what hidden components get added to make the thing work, and how that impacts the objects, particularly relating to the new rectangle and positioning). The primary issue I ran into is with loading textures at runtime in various resolutions so they show up correctly in the ui (essentially, loading a png into a texture and then into a sprite), and finding what the heck happened with my object positioning relative to one another, as well as stacking (front to back) so that UI elements show up properly. You cannot believe how many times things disappear from the screen just because an anchor is off, or the parenting of an object (or the order of parenting) messes something up with canvas objects and canvas groups.

So between Unity not wanting you to do UI outside of the editor, and you not able to write KSP modules inside the editor, quite the interesting dilemma this.

So yes, based on my testing to date, you can indeed use the new UI (available with 4.6.x and above) to do UI items in KSP, be ready for absolutely no help from Unity documentation from a script standpoint (even though it works, as the Unity designer internally does this), and little help from the global Unity user community as they are in the same boat as we are. All references you will find online are mostly all about how to do something in the editor, and at least currently, has next to nothing from the scripting angle although there are a few gems out there.

Quite the challenge this, although it's also a significant way to learn the ins and outs of Unity under the hood, and at least for me, understand how stuff works using elemental building blocks. The editor does a lot for you - it's dreadful from scripting and very repetitive too.

My recommendation: wait until Squad has KSP ported to 5.x, or buy a case of scotch, you will need it.

Z

[sarbian]

Unity deprecated the old GUI (onGUI) calls with 4.6.x and IIRC indicated it would be completely gone in 5.x.

Please give a source for that because I never saw anything like that mentioned anywhere.

And the whole Unity UI is open source. They stated on their forum that they have no problem about scripting the UI but that they won't add helper call because there are too many case with all the available variables. Other games have a lib that provide some common elements (CS) so I hope KSP will have the same.

Edited July 16, 2015 by sarbian

[ziporama]

Yes, the new UI source code is available which is great. At the same time, the code is rather poorly commented (no surprise there, it's like turn signals, I know where I'm going, why use them?), and the documentation is non-existent. Using the new UI from scripting only is a significant spelunking expedition that I think could be alleviated by a little more documentation. While I am confident this will eventually come, the materials available are squarely on the side that this stuff should only be used from within the provided editor, and not from scripting, and that's fine. The source code is a trove of goodies.

Z.

[Ser]

ziporama, Have been nearly excited when I read this, a bunch of stuff but at least doable. Now you've almost made me cry. I think if that is true then we have two hopes: Squad creates a handy toolkit for creating a KSP GUI or someone creates a software that would be able to export GUI design as xml and than import it to build a view in a runtime. That would be cool.

[ziporama]

I have not been able to make Instantiate work inside KSP as the path looks to be all wrong - I get an I/O error with a not found - I think that's because it's looking for the prefab in the game package file, not in the standalone plugin folder.

I've seen some tools that load the prefab using an async web call using a file::// as the URI instead of the usual http::// - it seemed very convoluted.

Any examples anyone can post loading a prefab inside a KSP plugin would be great (and apologies if it's blatantly easy to use - I am not there yet and still learning!)

Z.

[sarbian]

Did you use a Bundle ? If not then it s normal, unity loads its content from its asset files or bundles.

[ziporama]

*edit* I have not tried a bundle. I take it you're recommending the editor output to a bundle file, then loading the file using Instantiate from within the plugin in the Start() call?

Just tried a bundle: Looks like it requires a Pro version of Unity 4.x to do that (5.x not a problem as that is now a feature of 5.x without the pro license apparently).

...

Edited July 23, 2015 by ziporama

[ziporama]

So the good answer to this thread seems to be addressed here that I just discovered:

http://forum.kerbalspaceprogram.com/content/345-KSP-and-Unity-5

I'm waiting for the port to 5.x.

Z.