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

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.

I have VS 2015 RTM (released July 20) and also the new Unity tools for Visual Studio 2015 released along with it. The Unity mono tool pdb2mdb fails with a bit error: Fatal error : 1> Microsoft.Cci.Pdb.PdbDebugException: Unknown custom metadata item kind: 6 1> at Microsoft.Cci.Pdb.PdbFunction.ReadCustomMetadata (Microsoft.Cci.Pdb.BitAccess bits) [0x00000] in <filename unknown>:0 1> at Microsoft.Cci.Pdb.PdbFunction..ctor (System.String module, ManProcSym proc, Microsoft.Cci.Pdb.BitAccess bits) [0x00000] in <filename unknown>:0 1> at Microsoft.Cci.Pdb.PdbFunction.LoadManagedFunctions (System.String module, Microsoft.Cci.Pdb.BitAccess bits, UInt32 limit, Boolean readStrings) [0x00000] in <filename unknown>:0 1> at Microsoft.Cci.Pdb.PdbFile.LoadFuncsFromDbiModule (Microsoft.Cci.Pdb.BitAccess bits, Microsoft.Cci.Pdb.DbiModuleInfo info, Microsoft.Cci.Pdb.IntHashTable names, System.Collections.ArrayList funcList, Boolean readStrings, Microsoft.Cci.Pdb.MsfDirectory dir, System.Collections.Generic.Dictionary`2 nameIndex, Microsoft.Cci.Pdb.PdbReader reader) [0x00000] in <filename unknown>:0 1> at Microsoft.Cci.Pdb.PdbFile.LoadFunctions (System.IO.Stream read, Microsoft.Cci.Pdb.BitAccess bits, Boolean readAllStrings) [0x00000] in <filename unknown>:0 1> at Microsoft.Cci.Pdb.PdbFile.LoadFunctions (System.IO.Stream read, Boolean readAllStrings) [0x00000] in <filename unknown>:0 1> at Pdb2Mdb.Driver.Convert (Mono.Cecil.AssemblyDefinition assembly, System.IO.Stream pdb, Mono.CompilerServices.SymbolWriter.MonoSymbolWriter mdb) [0x00000] in <filename unknown>:0 The rest of it works, the conversion from the pdb output to mdb just fails. I tried downloading the current version of Mono (4.0.2 release which has the 4.5 release of pdb2mdb) however this runs into another issue in that the release of Unity 4.x doesn't work with that (Cecil library dependency is the wrong version). Unsure if anyone has run into this and solved it. The same code works fine with Visual Studio 2013 btw so it's a tool/version issue as far as I can tell. There is a note on the Mono source for pdb2mdb that says there was a problem reading bits dated sometime in May which was fixed, I however conclude that the fix is definitely not in the version of Mono included with Unity 4.6.x - that uses the 4.0 Mono library. Unsure if this has anything to do with the error I'm getting above when running pdb2mdb. I would however think that the 4.5 release of pdb2mdb requires the 4.5 runtime which is fine, however once the mdb file is output, it should work with the 4.0 runtime for the purpose of guiding the debugger. Assumption there of course as I can't get pdb2mdb 4.5 to work at all right now. Thanks! Z.

Thanks for sharing

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.

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