Utilize Tech Tree for Block Diagram GUI

[Skoth]

Hello fellow developers!

I have been working on an Add-on which utilizes block diagrams as a way of allowing the user to implement features of systems engineering (the vagueness of that description is due to the uncertainty of scope of the Add-on at this point in time). Rather than re-invent the wheel, I've been trying to find a way to take advantage of the R&D screen's tech tree GUI to draw the block diagrams. However, I have not been able to find any suggestions/recommendations for making use of the tech tree GUI other than ways to add more elements to the existing R&D screen. What I have in mind would be more along the lines of a custom window in the VAB/SPH and the Tracking Station, possibly even in flight, featuring a block diagram with the same or similar styles to the tech tree.

While I'm quite certain I'm way off base here, just to show that I've tried Google: I've looked through Anatid's KSP API Documentation, specifically the RDArchivesController Class as a means of doing so, but I do not believe this is related to my intent. I've also been reviewing Unity's Legacy GUI Scripting Guide, as some of the posts I've read on the forum suggest that KSP does not support the latest Unity UI specs. From the looks of it, I might have to put in a fair amount of work to implement a block diagram system (which I don't mind one bit!) if it needs to be built from the ground up. If possible, I'd like to avoid that.

So, my main question is if there is a way to utilize the tech tree GUI for custom graphs/diagrams/etc without having to create it from scratch? I recognize that the current static, unmovable tech tree does not have all the features that I am ultimately hoping for, however if I could access the Objects/Functions necessary to extend its capabilities, I think I'd have a lot easier time with it.

I'm quite new to the modding scene with KSP, but I've been a web developer for a number of years now and am proficient in C# and Unity. I say all this to ensure anyone who responds that I have the background necessary to understand more technical answers to this question.

[FreeThinker]

Even if your a experience KSP Mod developer, I would not recommend anything you are trying to accomplish as the GUI simply not made for extension. Also note that Unity is currently being replaced by SQUAD so changes are, if you manage to create anything functional at all, it will stop working even before you complete it.

[Skoth]

Ah, I see. I read in another post that most of that functionality is hard coded, so I figured it was a long shot.

[Skoth]

Since the Tech Tree is not available for customized use, I've been studying various existing mods' GUI approaches and utilized an amalgam of sorts to try to achieve the block diagram system I hope to build. The pictures shown below shows what I've been working on. It features draggable graph nodes/vertices with four different endpoints for creating graph edges.

In the first picture, I'm left-clicking and dragging the left-most node's right endpoint (the KSP Debug Console on the right can be ignored for this image). In the second image, I release the left-mouse button at the middle node's left endpoint, which triggers a DrawConnection function. The only problem is, the line drawn is nowhere near the points I specified (that is, the left node's right endpoint and the middle node's left endpoint--my apologies for any confusion that description may cause!). As can be seen in the second image, the line, drawn in red, is way off in the upper-right of the screen. The KSP Debug Console shows the GUI.matrix as at is transformed.

The code for the DrawConnection function is as follows:

public static void DrawConnection(Vector2 pointA, Vector2 pointB, Color color, float width)
{
            Matrix4x4 matrix = GUI.matrix;
            Debug.Log("Before Draw:\n" + GUI.matrix.ToString());

            Texture2D lineTex = new Texture2D(1, 1);
            Color savedColor = GUI.color;
            GUI.color = color;

            float angle = Vector2.Angle(pointB - pointA, Vector2.right);
            if (pointA.y < pointB.y) { angle = -angle; }

            GUIUtility.ScaleAroundPivot(new Vector2((pointB - pointA).magnitude, width), pointA);
            Debug.Log("After Scale:\n" + GUI.matrix.ToString());

            GUIUtility.RotateAroundPivot(angle, pointA);
            Debug.Log("After Rotate:\n" + GUI.matrix.ToString());

            GUI.DrawTexture(new Rect(pointA.x, Screen.height - pointA.y, 1, 1), lineTex);

            // Restore GUI
            GUI.matrix = matrix;
            GUI.color = savedColor;
 }

I've literally been at this for days and it's driving me crazy . If anyone has any recommendations I would be so grateful!

[Skoth]

For those that might be interested, I finally figured out what was going wrong. There seems to have been three main issues: 1) The GUIUtility.ScaleAroundPivot() call was too intense, and throwing everything way off. Instead of calling it, I just used the length between the two vectors and provided that length as the Rect's width argument in the GUI.DrawTexture() call. 2) The conversion between Rect coordinates and Vector2 coordinates kept conflicting with another. At first I thought only a few calls would work if I treated the first Vector2 (ptA in the code below) as if it were in Rect coordinates, but then I'd get weird offsetting behavior with the drawn line. I finally decided to just try modifying ptA so that every reference to it in the DrawConnection() method received it as though it were in Rect coordinates, and that seemed to do the trick. 3) The angle calculation was "right", but determining whether the value should be negative would often cause the line to rotate in the opposite direction. At the onset I was not sure whether positive rotations corresponded to clockwise or counterclockwise movement. But it looks like clockwise rotation corresponds to negative angles and counterclockwise rotation corresponds to positive anglesâ€â€which is convenient since that's the mathematical standard I learned.

public static void DrawConnection(Vector2 ptA, Vector2 ptB, Color color, float width)
{
            Color savedColor = GUI.color;
            GUI.color = color;
            Matrix4x4 savedMatrix = GUI.matrix;
            Vector2 rectPtA = new Vector2(ptA.x, Screen.height - ptA.y);
            float angle = (ptB.y < rectPtA.y) ? -Vector2.Angle(ptB - rectPtA, Vector2.right) : Vector2.Angle(ptB - rectPtA, Vector2.right);
            GUIUtility.RotateAroundPivot(angle, rectPtA);
            float mag = (ptB - rectPtA).magnitude;
            Texture2D lineTex = new Texture2D(1, 1);
            GUI.DrawTexture(new Rect(ptA.x, rectPtA.y, mag, width), lineTex);
            GUI.color = savedColor;
            GUI.matrix = savedMatrix;
}

In any case, I'm quite relieved to have overcome what I initially thought was a very minor and simple problem ! That seems to be a common theme in software development.

[monstah]

I support your attempt! I'd just like to reiterate something FreeThinker said in the second post: the game's UI is undergoing a major overhaul in its code; there are currently some 3 or 4 different systems being used in different parts of the game, and they will be unified into Unity's new UI (or something). So, thread carefully, and don't burn yourself out before the new version comes out.

[Skoth]

Thanks for the heads up! I read related articles about that, and am hoping the UI updates will not interfere with the work I'm doing. Actually, part of the reason I was able to figure it out was because I created an isolated test project in Unity 5.1.1 so that I could solely analyze that one function's operation. I know it could be difficult to say this early on, but if it works in a completely separate Unity project, is that a good indicator for how well it will work when KSP has migrated to the new UI?

[nightingale]

Thanks for the heads up! I read related articles about that, and am hoping the UI updates will not interfere with the work I'm doing. Actually, part of the reason I was able to figure it out was because I created an isolated test project in Unity 5.1.1 so that I could solely analyze that one function's operation. I know it could be difficult to say this early on, but if it works in a completely separate Unity project, is that a good indicator for how well it will work when KSP has migrated to the new UI?

There's a lot of FUD about the new Unity GUI. It's been around since Unity 4.6, which is what KSP 1.0.x uses. So the new UI is already there. What may break is if you are using some of the third-party plugins that Squad has used (stuff like EZGui), as Squad is moving away from those and they may very well be removed from KSP 1.1.

So although you're using what Unity considers the legacy GUI, I wouldn't worry too much about it, have a read of this page (emphasis mine):

The legacy GUI system has been replaced with the new UI System. The legacy GUI is still functional but is not recommended to use in your game or application. The legacy GUI system is still used in Unity’s own interface and can be used to create custom editor GUI.

So because Unity would need to re-write their own tools before they can drop support for the legacy GUI, I don't think that's it's something that anyone needs to worry about for KSP. They might hypothetically drop it in Unity 6.0, but that's not even a thing that exists today, and I doubt by the time it does that there's any economic incentive for Squad to port KSP to another Unity major version upgrade.

My personal opinion of the new Unity UI system is that it's next to worthless for KSP modders. By design it's meant to be used through the Unity tools by creating "proper" unity prefabs and objects. Doing it through the scripting interface is... ugly to say the least. The only example in the wild of the new UI in use by a KSP mod is one of DMagic's modlet (source here, you can read a little bit of his opinion on the new UI here).

The only thing that may change around this for KSP 1.1 is that Squad may release their own wrappers/classes to make doing Unity GUIs through scripting simpler. But even then, the performance benefits of the new UI are really only seen with big GUIs with complex layouts with relative positioning/sizing of elements (see Mechjeb). In your case, if you were to port what you're doing the new UI, I suspect the only noticeable difference I'd expect is that you'd have a really bad headache after it's done.

Sorry about the long rant on your thread... Short version of what I was trying to say is keep rockin' on and don't worry too much about what KSP 1.1 will bring.