[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[Gaalidas]

Indeed that is helpful. For the GUI itself, I've rediscovered an old download that included an entire library useful for generation and managing GUI elements which I'm using as a base for my own attempts at a GUI. It really simplifies things a lot. Of course, when KSP goes Unity 5, we'll have access to visual GUI designers similar to the form designers in modern programming environments.

What would be really awesome would be for someone to make an easily-imported project that did all the hard work of getting something like this set up and provided an easy way for someone to then simply define what the button should do when pressed. Something along the lines of the Blizzy toolbar's set of methods that I see imported into just about every mod that supports the toolbar mod. I may have to export whatever I end up with here for such a purpose. It just seems to me that we shouldn't all be reinventing the wheel every time we make a new button.

As for throttle control... I did actually think about that a while back too. It would definitely save on having to hold buttons down while driving. To emulate that, I've often used mechjeb's rover controller to maintain a certain speed, along with subtle stability control.

EDIT: Okay, I have this now to work with:

[COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]SetupAppButton[/B][/COLOR]()
{
    [COLOR=#0000ff][B]if[/B][/COLOR] ([COLOR=#191970][B]Equals[/B][/COLOR]([I]appButton[/I], [B]null[/B]))
    {
        [I]appButton[/I] = [COLOR=#004085]ApplicationLauncher[/COLOR].Instance.[COLOR=#191970][B]AddModApplication[/B][/COLOR]([COLOR=#191970][B]onTrue[/B][/COLOR], [COLOR=#191970][B]onFalse[/B][/COLOR], [COLOR=#191970][B]onHover[/B][/COLOR], [COLOR=#191970][B]onNotHover[/B][/COLOR], [B]null[/B], [B]null[/B],
               [COLOR=#004085]ApplicationLauncher[/COLOR].[COLOR=#004085][B]AppScenes[/B][/COLOR].[I]ALWAYS[/I], [I]appTextureGrey[/I]);
    }
}

And this to modify the texture based on hover status:

[COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]onHover[/B][/COLOR]()
{
    [COLOR=#008000]// To-Do: Swap the icon with the colored one.[/COLOR]
    [I]appButton[/I].[COLOR=#191970][B]SetTexture[/B][/COLOR]([I]appTextureColor[/I]);
}

[COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]onNotHover[/B][/COLOR]()
{
    [COLOR=#008000]// To-Do: Swap back to the grey version of the icon.[/COLOR]
    [I]appButton[/I].[COLOR=#191970][B]SetTexture[/B][/COLOR]([I]appTextureGrey[/I]);
}

The programming environment seems to think everything will function correctly as far as the code itself, so I'm going to call this a success at the moment. Next, i'm going to use elements from AffinityGUI to create a GUI for toggling our global variables. For the icons, I'm using an icon I made for FilterExtensions which is basically just the letters "KF" in the middle of an Icon, but with an enabled state that colors the letters with a golden hue, which I'm using for the onHover state.

One thing I noticed was that some mods have been using 40x40 images for the app icon, but the code documentation specifies a 38x38 texture. Does the texture size really matter that much?

Edited July 9, 2015 by Gaalidas

[lo-fi]

Throttle control won't be hard. I'll do my best to add that it - it will only be a few lines of code.

In other news:

I got to grips with sending particles out where I wanted them. Both they and the lights need tweaking now. Particles need to me more subtle, lights need to be diffused more if I can manage that.

[Gaalidas]

That's some sweet looking stuff there lo-fi. Was that over water or something? It you had some sort of light-blueish tone in them. Also, it could have been my imagination, but it looked at the end like there were RCS flares coming from within the repulsor spheres. I agree though, the dust objects need to be toned down a bunch. The parameters for handling all that are rather sensitive at the small scales we're running these parts in. The game was built to handle these types of effects on rockets and such, which tend to be a lot larger at their smallest scale.

I am unsure what the smallest values possible are, but I was thinking that what you have there would be for the strongest force, likely reached only when impacting the surface, rather than just repulsing off of it.

[lo-fi]

no, that's over the ground outside KSC. The blue glow is the lights! I'll keep playing with the dust, it's quite fun to mess about with.

[V8jester]

Looks really good Lofi! But you didn't show the animation for on / off. Is it still a hallow ring when turned off?

[smjjames]

Would it be possible to optionally disable the dust effects? Just wondering as it can potentially cause performance issues.

[lo-fi]

Looks really good Lofi! But you didn't show the animation for on / off. Is it still a hallow ring when turned off?

Yeah, that's all same as before

Would it be possible to optionally disable the dust effects? Just wondering as it can potentially cause performance issues.

Yep, we've got a global config file that handles that, and that's what the gui will be for. Just a few simple toggles - nothing complex.

[Hellbrand]

what happened with tweakscale btw I cant seem to resize any surface attach parts.

[lo-fi]

Gaalidas can probably answer that one, as he made the configs. I imagine they need tweaking to work with later versions of TS. How annoying!

[Gaalidas]

Hmm... which parts exactly are having trouble? (no, wait... I think I know what's going on...) Last I checked, using the latest release of TweakScale, all the wheels, tracks, and repulsors were functioning with TweakScale. i would first check that you're using the latest release of TweakScale, however... Now that I think about it, we haven't released any updates for this mod yet and if you're using that latest release, none of the old configs will work anymore. Once we release an update, that shouldn't be an issue for anyone. As it is, I may have to go grab the latest release we made and hack together a new config for the scaling. Unfortunately the people maintaining TweakScale didn't have the good sense to code their new stuff in such a way that legacy configs could still function. How annoying indeed.

- - - Updated - - -

Just a few simple toggles - nothing complex.

Just a few simple toggles my arse! This GUI stuff is anything but simple.

[lo-fi]

Making any progress? We could get it to make config changes the old school cheat fashion by doing button combinations?

[Gaalidas]

No, that won't be necessary. I'm making slow progress. I don't have time to devote whole days to the project, but it's coming along. I'm just trying to figure out what parts of the AffinityUI package I'll need so I don't end up importing the entire library into KF. It's going to make constructing the GUI a lot easier though. I'm going to try and strip down my install of KSP for an extremely lightweight testing platform and work on that over the next few days. I figure if I back up nearly everything related to "parts" and force KSP to load without them, then it will simply be a matter of loading the bundled assets and spitting me out to the main menu. I can start a new save for the sole purpose of testing the GUI and simply get it to output any changes done to the config state to a log to make sure it's working properly. We can worry about testing if it actually works on the parts or not after I get it looking presentable.

My trouble with doing stuff like this is that my brain doesn't make all the connections as to how things are supposed to go together in the code until I'm able to see a working example or the code and the output. this is why I've often wished for a KSP console-only mode for loading configs and testing interactivity with those configs without the rest of the game getting in the way. Along those lines, an ability to load KSP into a GUI-testing mode where it would load everything it needs to display a dummy scene with the app launcher and any settings screens that KSP comes with, along with a fully functional config database. This way I could even test GUI additions without having to manually purge my gamedata folder of parts to test this stuff.

Fortunately, though many other GUI-using mod authors would disagree about it, when KSP goes to Unity 5, we'll have access to a GUI designer in Unity (I've read this anyway, not confirmed) which will ease the issues with designing and coding interactions and visuals for a GUI addition. On the down side, it will also screw over any form of GUI mods currently use because it will require the use of the Unity 5 GUI rendering system. I for one am looking forward to it though.

EDIT: Never mind that progress report above... I'm back to the drawing board. AffinityUI is a lot easier to create a GUI with, but the examples it provides don't include how I'm suppose to call it from the stock toolbar or anything. Even the example plugin, which supposedly will load into KSP and let you bring up an example of what can be done, doesn't even contain any code to actually put the GUI button on the app launcher! How am I expected to view the example if all it does it create the GUI and doesn't actually have a way of displaying it? This is getting really stupid! I just need some working example code to learn from and I'm good to go, but everything I look at either only has parts of what I need, or claims to have what I need and then doesn't deliver in the end!

Edited July 11, 2015 by Gaalidas

[lo-fi]

I'll have a look at adding in what Aqua posted, it didn't look too tricky.

[Gaalidas]

No no no, what Aqua posted was easy, it's the actual GUI that's screwing with me. However, I'm making progress again. I discovered the perfect example in BahamutoD's BDArmory mod. It's turning out to be an amazing resource for stock toolbar goodness.

One thing I've discovered which is kinda screwy is that it looks like every time you want to show a GUI in KSP you practically need to rebuild it from scratch in the code. I was looking at it in the way you display forms in Windows based UI forms, where you create the form first, then call it up from the code. The form stays as it is like a template for what the code works with. In KSP, when you display your GUI the code is the actual code that builds it. You're not just telling KSP to make your GUI visible, you're telling KSP to rebuild it on-demand every single time you need it. This makes it difficult for me to wrap my head around, but I'm slowing making my way there. Later today I'm going to create my dev install of KSP stripped of all the parts and other useless assets so I can test the GUI layer and start making this thing work.

Edited July 11, 2015 by Gaalidas

[*Aqua*]

One thing I've discovered which is kinda screwy is that it looks like every time you want to show a GUI in KSP you practically need to rebuild it from scratch in the code.

Yeah! When I stumbled upon that I was like ...?! This is a concept that was used 20 years ago but we live in the 21st century now! Rebuilding the GUI on every frame draw is just %!"#!

Edit: The forum censors words?

[EpicCybertronian]

Do you think it will be possible in a future update to add "Procedural" tracks? So you can adjust how many wheels there are per track, change the length and height, wheel size, and so on. That would be super sweg

[lo-fi]

Ah, I see. What an omnishambles (the forum won't censor that one)!

Procedural tracks... Yeah, we've kind of talked about that before, and it would be awesome. I don't think it would be impossible, just insanely difficult. If I had unlimited time and some funding, maybe. But realistically, I'm afraid no. Adjustable width is something I'm looking into, though

[Gaalidas]

If you manage adjustable width, you might as well also make adjustable scale and we can just scrap TweakScale for an in-house implementation. Besides, I'm unsure how we would make adjustable stuff play friendly with the other mod.

I'm so going to start using "omnishambles" in my daily life now. That's awesome.

EDIT: The stuff Aqua posted isn't going to work quite right. The compiler can't find the methods to override for several of the methods that were tagged as overrides (the Awake and OnDestroy methods) and the GUI calls for spawning the GUI aren't accepting my methods that have the GUI builders in them because it's looking for something called a "method group" instead.

So, we're back to the drawing board... again!

Edited July 11, 2015 by Gaalidas

[*Aqua*]

Visual Studio bugged me that I have to use "override" or "new". The reason is my class inherits MonoBehaviorExtended from the KSPPluginFramework.

You should be fine without "override".

A method group is what the name says: a method group. It's a bunch of usually overloaded methods (methods with the same name but different parameters). If you get that error you probably forgot to add parentheses behind a method call. Or did some weird stuff. ^^

I had a quick look on how I did some GUI tests and... I don't understand some stuff of it anymore. I didn't comment my code.

Parts of what I did:

I added a callback to the RenderingManager for drawing the GUI.

public void Start() {
    RenderingManager.AddToPostDrawQueue(0, new Callback (drawGUI));
}

Then I draw a window:

windowShown is a bool which tells if the window should be shown.

windowPosSize is of the type UnityEngine.Rect and describes position and size of the window.

windowGUI is a method I wrote to fill the window with content.

windowTitle is a string. (Cpt Obvious)

void drawGUI() {
    GUI.skin = HighLogic.Skin; // use KSP's visual style

    if (windowShown) {
        // make sure the window will stay inside the screen
        // (windowPosSize was filled with numbers from a config file before)
        windowPosSize.x = Mathf.Clamp(windowPosSize.x, -1, Screen.width - windowPosSize.width);
        windowPosSize.y = Mathf.Clamp(windowPosSize.y, -1, Screen.height - windowPosSize.height);

        // 10007 is a unique ID. Choose one which doesn't conflict with other windows!
        windowPosSize = GUILayout.Window(10007, windowPosSize, windowGUI, windowTitle, GUILayout.MinWidth(650));
    }
}

Note: ID is the same ID you used in drawGUI(). (Or at least it should be.)

void windowGUI(int ID) {
    GUILayout.BeginHorizontal(); // stuff will be arranged in a horizontal manner
        GUILayout.Label("label");
        if (GUILayout.Button("button", new GUILayoutOption[] { GUILayout.MaxHeight(21), GUILayout.ExpandWidth(false) }))
        {
            // the button was clicked, add code here
        }
    GUILayout.EndHorizontal();

    GUI.DragWindow(); // makes the window dragable
}

I think this should work.

God! I hope Unity 5's GUI system is better. At least it can't get anymore worse than this. I hope.

The forum needs auto-highlighting for code.

Edited July 11, 2015 by *Aqua*

[Gaalidas]

We're trying to avoid external dependencies like KSPAPIExtensions. Anyway, I removed the override part and still had issues with it not being able to find the GUI methods, or rather unable to do what I witnessed in BDArmory exactly where he called up a custom method from the call for a new GUI window. Very irritating.

Whatever you do, don't claim that it can't get worse, cause it probably will now that you've said it.

Edited July 11, 2015 by Gaalidas

[*Aqua*]

The code above doesn't need KSPPluginFramework (KPF) so it should work out of the box. Probably. I didn't test it before.

About the override stuff it's just overriding the methods KSP and Unity already provide or call if they are present in a class. Instead using OnDestroy() you could also hook onto GameEvents.onGUIApplicationLauncherDestroyed.

[Gaalidas]

Might have to do that because, while I've used overrides successfully before, apparently there isn't a method available, which can be overridden, with a name of "OnDestroy" or "Awake." That still doesn't explain why I can't draw a GUI. Also, I've never heard of this KSPPluginFramework...

I'm very close to jsut doing a complete copy/paste from BDArmory and then customizing it for my needs from there. I'd rather be able to build it specifically with KF in mind, but if it's going to be that complicated, then copy/paste will have to do.

EDIT: I haven't actually looked at your latest post with examples, which I'm going to do now. I was in Costco with my mother when I responded to that message.

Edited July 11, 2015 by Gaalidas

[*Aqua*]

KSPPluginFramework is made from code Kerbal Alarm Clock and Alternative Ressource Panel shares. There're some mods which use that. It's often compiled into a mod instead of distributing it as a separate dll.

Also some methods are only called if present. Yeah I know that's weird. Usually you have interfaces for stuff like that but Unity haven't.

Click this link and scroll down: http://docs.unity3d.com/Manual/ExecutionOrder.html

Edited July 11, 2015 by *Aqua*

[Gaalidas]

Well, I finally just did a huge copy/paste of what BDArmory uses, which I know works. The only thing I'm choking on now is how to save the settings. BD uses a config file without a parent node. It simply just lists the variables and their values in order. I'm using a parent config node and putting the values inside that, so saving the values from the GUI isn't going to be as straight forward as his mod has. Going to dig around in the DustFX stuff and see if the default file generator will be of any use to me. I haven't tried compiling again yet, but it looks almost identical to the other mod I'm using as a template and that mod did compile a few minutes ago when I tried. His mod doesn't do anything with OnDestroy, or anything that references something being destroyed, nor does it use an "Awake" state or anything, and from my experience there's never been any problem with it sticking around after scene changes, or duplicating itself for any reason, so I'm calling it good for the time being.

UPDATE: So, it looks like the current way I load the config is not going to be compatible with the way I want to save the settings, after a user changes them in the GUI, in order to allow the settings to persist between KSP launches. Once that's handled, I'll do a little testing to make sure the settings are loaded and saves from the GUI. This conversion of load and save methods will also make it easier to set up default values and have it create a new file if the old one is deleted.

I made a copy of KSP this morning with nearly-zero parts in it and Holy Jebediah did that baby load up fast. Time to do some heavy culling of my main install to hopefully regain some of that speed when I return to my mod-laden game.

Edited July 11, 2015 by Gaalidas

[lo-fi]

All sounding very promising! It's a steep learning curve, isn't it. Been there with different stuff to face down. I don't know how much it helps with your college stuff, but it'll look fantastic on a CV, so don't forget to make sure you're appropriately credited. In a position as a potential employer, I'd hire someone with a degree and some experience in an open source project over someone with just the degree every time.

Actually, making our own local scale module may not be too difficult. As the parts don't allow attachment, they will always be last in the chain, so all the complicated, clever stuff TS does to position down-tree parts isn't needed. I'll do some playing about, but adjustable width is definitely on the cards.