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

[*Aqua*]

I guess Gaalidas used my example as a basis.

I don't know what he coded there but I guess he didn't include that:

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

This should make sure, that the drawGUI() method (I think he renamed it to InitGUIElements()) runs in the context of the GUI thread.

But seriously the current three GUI systems just suck. Maybe you should wait for KSP 1.1 and it's new GUI.

[Gaalidas]

I guess Gaalidas used my example as a basis.

I don't know what he coded there but I guess he didn't include that:

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

This should make sure, that the drawGUI() method (I think he renamed it to InitGUIElements()) runs in the context of the GUI thread.

But seriously the current three GUI systems just suck. Maybe you should wait for KSP 1.1 and it's new GUI.

I started with your example but, over the course of 5 or 6 iterations, I slowly migrated over to several other attempts to implement this stuff. In the end, everything failed to function properly.

[lo-fi]

I guess Gaalidas used my example as a basis.

I don't know what he coded there but I guess he didn't include that:

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

This should make sure, that the drawGUI() method (I think he renamed it to InitGUIElements()) runs in the context of the GUI thread.

But seriously the current three GUI systems just suck. Maybe you should wait for KSP 1.1 and it's new GUI.

Thanks, I was just poking through your original posts. I'm trying to get the app launcher button working correctly first, then I'll look at the GUI stuff.

I started with your example but, over the course of 5 or 6 iterations, I slowly migrated over to several other attempts to implement this stuff. In the end, everything failed to function properly.

It's not far off. I can get the app launcher button up, but it's turned all the other buttons to the KF logo and doesn't have one itself, just a blank square... Though progress is being made!

[Gaalidas]

"settingsRect = GUI.Window(GUI_ID, settingsRect, KFGUI, string.Empty);" is what I copied directly from another mod (changing the method names to match what I called them) and I put it under the same method that they used in their mod. The mods I used as templates are BDArmory and PlanetShine. As for the "outside OnGUI" business, I wasn't aware I was trying to do that at all. I'm simply copying what I've seen other mods do, which don't produce any errors when used. I'm not trying to do anything that hasn't been done before. That's why this is so frustrating.

Keep in mind, the state of the code right now is not what I would have liked it to be in. It's been messed with a lot while trying to figure out what is supposed to happen when certain method calls are made in a certain format. I'm getting conflicting information from the other mods that seem to do the same thing in many different ways.

What confuses me about what you're getting in the logs is that I never got any errors related to "OnStart" in the first place. All my errors were related to "OnGUI" and the complaint about trying to do GUI-related things outside of that method. Overall, I'm tired of struggling with the cruddy GUI systems in KSP.

- - - Updated - - -

Thanks, I was just poking through your original posts. I'm trying to get the app launcher button working correctly first, then I'll look at the GUI stuff.

It's not far off. I can get the app launcher button up, but it's turned all the other buttons to the KF logo and doesn't have one itself, just a blank square... Though progress is being made!

That's funky. So, we can change the icons of other mods eh? Could be useful if we ever want to hijack another mod.

[lo-fi]

You really did get in a pickle between the blizzy and stock stuff, didn't you! I've almost got it working. Buttons are fixed - as Aqua pointed out, variables that want to be accessed by the gui stuff need to be declared static or something else I can't remember.

- - - Updated - - -

I'm just going to put this here

Save/load of the config nodes seems to work, so you got that bit spot on. Only thing is it doesn't reset the colour of the icon when the save button is used, but I'll hand it over to you for tinkering now it's actually working.

Also. someone please rep *Aqua* for UI assistance. It won't let me again!

Edited July 13, 2015 by lo-fi

[Gaalidas]

I'll see about all of that when I get home from class in a few hours. Looks great. I knew someone here could fix my blunders. By the way, the variables were being read perfectly fine from the other modules before I screwed with he GUI stuff, so that at least will be okay. I'll clean things up and get the GUI to fit the content within it. The icon thing is a strange one, but should be easy to fix now that the rest of it is fixed.

The icon is pretty basic. If we have a mod logo, I could look into integrating it. I also need to see if filter extensions can be set to load an icon from outside its own folder structure. If so, I can add a patch (there's MM again) to add KF to a dedicated editor category like I have on my local install.

EDIT: Okay, looks a lot better than it did with my attempts. Still having a spammed NullRef on the "OnGUI" method though. Gonna look at some other mods to see if there's anything we're missing, but either way we need to squash that.

Edited July 13, 2015 by Gaalidas

[lo-fi]

Cool, it just wants tweaking now. I'm now working on the repulsors to get the status and energy drain sorted. Dust stuff needs tweaking, and I still can't work out why the dust is white anywhere on Kerbin when using the biome defs.

[Gaalidas]

Your computer just has issues with the biome defs I guess. I can't figure it out really, since it works on my end.

So, I've tried several different options but still can't seem to squash the "NullReferenceException: Object reference not set to an instance of an object KerbalFoundries.KFConfigManager.OnGUI ()" spam I'm getting. There is absolutely nothing missing that is present in any other mod which uses OnGUI, though I have noticed some of the mods out there simply not having an OnGUI at all, which is really confusing me since it appears you must have it in there somewhere for this stuff to work at all. I reduced the height of the window to 250 which feels better. Couldn't figure out the strange mathematics required to scale the height to the content, so we'll have to wing it as we add more options.

- - - Updated - - -

Also. someone please rep *Aqua* for UI assistance. It won't let me again!

Taken care of.

[*Aqua*]

Thanks for the rep!

The OnGUI method is required when you use Unity's GUI system. But KSP has additionally two other GUIs systems (something selfmade for the main menu I believe and EZGUI)! I guess that's the reason why you are confused.

Couldn't figure out the strange mathematics required to scale the height to the content

It should autosize when you don't specify width & height.

Concerning the NulRef problem there must be something different between your's and lo-fi's dev versions.

[lo-fi]

Grab the latest, I broke, then fixed then broke as usual.

Biome colors are 100% broken on Kerbin. Fresh install of 1.04, dust is white wherever I go. My KF is what's in Git, as it pulls it straight from GameData. Used to turn brown the moment I drove off the side of the runway. Now it's just white everywhere:

To prove my point, I set:

DustColorDefinitions
{
    DefaultColor = 0.75,0.75,0.75,0.007
    BodyDustColors
    {
        Item
        {
            Name = Kerbin
            [B]DefaultColor = 0.75,0.75,0.75,1.0[/B]

Which gives:

In other words, it's not marrying the biome name up with what's named in the config and it's defaulting. Which is what we were batting back and fore before I went all leftfield and started messing with the camera. Duna is fine, just for reference:

I hard coded the plugin to temporarily ignore the camera, just to make 100% sure it's not getting data from that. Kerbin, we have a problem.

Edited July 13, 2015 by lo-fi

[*Aqua*]

Weird. For me it's working. In the left picture you can even see different colors (white on landing strip, green/brown on shore biome).

I drove a bit here and there and IMO it looks like it's working. Or did you change something in your local install in the last half hour?

Edit: Is there something for me to do?

Edited July 14, 2015 by *Aqua*

[Gaalidas]

See lo-fi? It works fine for the rest of us. I'm totally baffled as to why it won't work for you. There is simply no good reason as to why it would fail. My only idea would be if you were using some sort of custom biome mod, but I doubt you are. The only other idea is that something has gone wonky with how you're calling them up in the dust init method. However, if all you did was uncomment the previously working line of code which allowed that system to work, then I really don't get it. You'd need to ask xEvilReaperx to look at it, since he wrote most of the stuff that sits in the background.

Also, what's up with the super huge particles in the desert region? You messing with different effect models? I am glad to see that Duna works, I never tried any of the other planets.

The trouble with not defining a height and width is that all the Rect() calls require a height and width to be inserted into them.

The question now remains: Why is OnGUI spamming NullRefs from the moment the start scene selected is reached, all the way until the game is shut down?

NullReferenceException: Object reference not set to an instance of an object
  at KerbalFoundries.KFConfigManager.OnGUI () [0x00000] in <filename unknown>:0 

[COLOR=#ff0000]void[/COLOR] [COLOR=#191970][B]OnGUI[/B][/COLOR]()
{
    [COLOR=#0000ff][B]if[/B][/COLOR] ([I]isGUIEnabled[/I])
    {
        [COLOR=#191970][B]KFGUI[/B][/COLOR]([I]GUI_ID[/I]);
        [I]appButton[/I].[COLOR=#191970][B]SetTexture[/B][/COLOR]([I]appTextureColor[/I]);
    }
    [COLOR=#0000ff][B]else[/B][/COLOR]
        [I]appButton[/I].[COLOR=#191970][B]SetTexture[/B][/COLOR]([I]appTextureGrey[/I]);
    [COLOR=#000080]return[/COLOR];
}

Edited July 14, 2015 by Gaalidas

[Mekan1k]

Any Idea when we, the humble players, may have a version to play around with?

[lo-fi]

Soon^TM(ish). Still a lot to do finishing parts and balancing config, but the list is shrinking!

That's very odd with the dust colours. Be interesting to see what happens when it's released into the wild!

Looks like you're using an out of date commit, Gaalidas. Those appbutton.settexture lines are the culprits. They snuck in while I wasn't looking and since got fixed. Naughty things...

I guess it depends how much of a challenge you want, Aqua! I'm afraid many areas of the code aren't very well commented, so it may be a little tricky right off the bat. Most of the core stuff is ready for testing, with the most critical bits being KFModuleWheel, KFWheel, KFRepulsor, DustFX. A little code review probably wouldn't hurt! If you would like a real challenge, have a peek at the hitch code and see if you have any bright ideas for reload/time acceleration problem! I had an idea that we could force docking when time acceleration is started, but I'm not sure this would be possible when scene changing or save/reloading. It all seemed a little flimsy! It will be a total mess from where I was messing with trying to force things back together.

I can't think of any other features we've talked about but not got round to implementing... Unless! Was musing about some code to figure out vessel weight and wheel loading to be able to auto set the spring rate and braking force. Not critical, but nice to have. Oh, also, accessing the wheel collider slip properties to allow a sound to be played when they're slipping. Could also tie in some extra dust.

A few bits to play with, but open to ideas

[*Aqua*]

Code reviewing is a good idea! I see quite a lot of weird code.

I created KFPersistenceManager which will now handle all reads & writes from & to the config files. That means KFConfigManager now only handles the GUI and therefore is renamed to KFGUIManager. I also reworked all of the dust color definition stuff. It should be now much more easiler to handle.

Works great!

Edit:

@lo-fi

Please give me access to the KF_plugin repo so I can commit my changes.

Edited July 14, 2015 by *Aqua*

[lo-fi]

Marvelous! Done

Not surprised, it's all just sort of fallen out of my head and been beaten into shape until VS stopped bleating

[V8jester]

You guys really have some neat stuff on the horizon, Definitely looking forward to what's ahead.

[Gaalidas]

Code reviewing is a good idea! I see quite a lot of weird code.

I created KFPersistenceManager which will now handle all reads & writes from & to the config files. That means KFConfigManager now only handles the GUI and therefore is renamed to KFGUIManager. I also reworked all of the dust color definition stuff. It should be now much more easiler to handle.

Works great!

http://i.imgur.com/9TJAZ3b.jpg

Edit:

@lo-fi

Please give me access to the KF_plugin repo so I can commit my changes.

Does this mean the way we're calling up the globals needs to be changed? Currently we call them up using "KFConfigManager.KFConfig.variable_name" and what does this mean for the biome color configs? are there any changes to the format of that file? To be honest, this morning I was considering scrapping the current definitions in favor some something simpler such as the setup that PlanetShine and/or DistantObjects uses, where you simply have a bunch of nodes all named something like "BiomeDustColor" and then the "name" parameter under that node would be the planet name or the biome name and the "color" parameter would contain the color, obviously. This would eliminate the complicated curly brace setup of the current def file. I'm unsure which would be more efficient in the long run though.

I must say, however, that seeing the wheels producing different colors based on what they're colliding with is awesome. That's one thing that the camera color sampler isn't able to do yet, unless we can find a way to sample a small area under each wheel without killing performance.

Which brings me to another thought: we need to look at making sure the camera isn't still sampling when the craft gains air or takes off from the planet surface. Also, on crafts with both wheels and repulsors, we're probably redundantly setting the color average way too much. If we could do all the color sampling through the class that handles the camera itself, we might increase performance a bit. Sure, if we end up sampling per-wheel or something, it will have to be moved back into the dust class, but if we're doing it per-craft then I'd think the vessel modules would be a better place to do most of the non-part-specific setup for these effects.

Also, lo-fi... you said that Duna was working okay with the biome definitions, but did you try moving into another biome on Duna? If you enter the polar regions, for example, it should change to a snowy color to match. It's possible that none of the biome defs were working for you, only the planetary defaults. Kerbin defaults to a grey dust (the default usually corresponds to whatever dust you want when colliding with something other than the surface of the planet since all the planets are covered with biomes I believe) and Duna defaults to a more reddish tone to match the layer of dust that would likely settle on every open surface on the planet.

Edited July 14, 2015 by Gaalidas

[*Aqua*]

Thx for access, lo-fi!

I guess you could call the GUI almost finished. But only the first toggle works. For the others I don't know where to hook into yet.

Also the app button isn't displayed in the VAB yet.

@Gaalidas

Look into the commits I pushed a few minutes ago. I literally remade most of the dust color stuff. I hope it's more easier to understand and use.

Edit:

I forgot to push the new DustColors.cfg.

Edited July 14, 2015 by *Aqua*

[Gaalidas]

By the way, I heard back from the FilterExtension guy, and I can actually provide an icon for that mod in our Assets folder and, assuming it's a uniquely named icon, I can assign it by name only in a filter extension config which I can also simply stick into our Parts folder. I'm going to rework my config i created a while back and upload the files. This means that, for users of Filter Extensions, there will be a dedicated category in the editors for KF-related parts, along with subcategories for the various part types (wheels, utilities, structural, pods, etc. if defined in the part configs). No hard dependencies either, just available if the other mod is present.

[lo-fi]

Looks great! The camera toggle does nothing just yet - the state needs to be picked up by the vessel module and dustfx module. The orientation marker bool gets picked up by the orientation marker module. Just reads the bool and figures out what to do.

Actually, no I didn't go to the poles on Duna. Will do later. I checked that the load is successful, have up to date MM, only other thing I'm running is the dev helper and a couple of parts. Very odd indeed. I'll have another play later.

Thanks V8Jester. We'll get there eventually!

[Gaalidas]

as for the config stuff, you don't need to hook into anything specific right now. All you need to do is set them to toggle the variables that I was previously referencing in my old GUI attempt. I named them internally the same as what's in the KFGlobals.cfg in the KF root folder.

I run the dev helper too. I love being able to skip the main menu, yet still have the main menu initialized for a moment so that mods which start at the main menu still function correctly. If I was still a user of Load On Demand, that would have totally fixed the incompatibility between the two mods.

Oh, and back to the GUI stuff now... I committed a change last night that told the icon to only load in the space center scene. If that's what you started with, then that would explain it. I was trying to limit the number of odd problems I might have which would cause the spammed nullrefs by limiting where the addon would be initialized. It still failed for me but, theoretically, if you have it fixed now, you could re-enable every-scene initialization from the top of the class in the [KSPAddon] entry. That should Allow it in the VAB/SPH and the flight scene. What I am unsure of is if the modules, while actively running, would respond to changes in those configs.

Edited July 14, 2015 by Gaalidas

[*Aqua*]

KIS and IR adds subcategories without the help of Filter Extensions. Maybe we should do that too.

Edit: Ninja'd. You guys really post too fast for me. ^^

@Gaalidas

So far the GUI only changes the global variables. As it should.

Edited July 14, 2015 by *Aqua*

[lo-fi]

Hehe! Ninja! I really need to start bashing the configs into shape so we can release this stuff at some point..

[Gaalidas]

Those other mods may do that, but that has been known to conflict with users of Filter Extensions, which I find to be immensely helpful in my craft editing sessions. Also, that requires a bunch of new coding to make it happen, whereas Filter Extensions has already done the hard work for us. Either way, I'm going to provide the config and icons because even if we do create our own category code, if someone is using the other mod, that category may not show up and thus will need a config for it to work right.

By the way, Aqua, if you're going to change file names and stuff, updating the project file to match the new structure would be awesome. I usually just use Winmerge to merge the changes to just that area of the project file, so that I don't mess the rest of you up with my differing local paths for reference DLLs and stuff.

Edited July 14, 2015 by Gaalidas