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

[*Aqua*]

I didn't include the project file because of not messing up your local projects.

Winmerge... don't know about that. I'll look it up.

How about my code? Is it ok? Is my programming style weird?

[Hellbrand]

did we ever fix the issue with tweakscale?

[Gaalidas]

It will be fixed when we do our next update. Until then, I'm afraid there have been too many changes made both to TweakScale and to the KF parts for anything to be done. Right now It works as intended in our dev copies though, so it should be fine when we release.

- - - Updated - - -

I didn't include the project file because of not messing up your local projects.

Winmerge... don't know about that. I'll look it up.

How about my code? Is it ok? Is my programming style weird?

weird? nah... I just did some cleanup and redundancy reduction passes a few minutes ago. I'm actually impressed with it, for the most part. I might even learn a thing or two.

Realistically I likely won't learn anything... but I should be if I were so inclined.

I haven't tried to compile it yet, though, so don't get relaxed yet.

Winmerge is awesome. Granted, no merger program is perfect, but it's pretty good so far. I have it set up to check the entire folders between my local dev project and the github synced folder. It then can tell me what binary files are different as well as track specific changes between textual files and allows merging them visually on a per-different-line basis. I still have to do some editing sometimes, but I can do that right within the program and see the differences in real time, if I have the auto-detect-changes setting on. It handles XML files really screwy and can mess things up sometimes, but for the rest it seems to be okay. I've been using this since before I even knew KSP existed.

EDIT: Also... I did actually do something with the camera toggle in the dust color stuff. Basically, if the camera is disabled, the colerAverage is set to just the biome color, otherwise it does the math to combine the camera with the preset.

Also, it should be noted that I never actually set all the presets to the actual biomes on the specified bodies, so they won't all represent the actual colors seen in the textures. We'll need to run through those sometime.

Edited July 14, 2015 by Gaalidas

[Tyren]

You lost me competely these past pages...but suggestion: let's make a feature cut here and polish it for a release, i can somehat smell the completion of an awesome mod update

[lo-fi]

That's pretty much where we're headed. May not be many new parts in the next release, but a bunch of nice features. Parts will follow as they are completed. However, both Zodius and Electronîcfox have parts in the pipeline that are set to use the plugin, plus we have configs for stock and some other mod wheels. And new repulsors, of course...

[*Aqua*]

I looked into the PQS stuff how we could get the color of the exact point of collision and then it came into my mind that there's no efficient solution to that.

If I understood correctly the PQS system stacks material layers* on a more or less round sphere (which are made of several bent rectangular shapes) which are then merged to a texel (pixel in a texture) during rendering in the GPU. To get that texel we would need to access the video RAM and believe me, you don't want to do that. We would replicate how the camera works you already use to get the ground color.

* There's at least a material for height color maps, "biomes" (to make grasslands look different to deserts), details ("grass leaves") and maybe more.

IMO the current system is good enough and works for everything except some parts of the KSC complex.

Edited July 15, 2015 by *Aqua*

[Gaalidas]

It's actually pretty insane what we've been working on, and yet for the end user there won't be much different other than the visual effects and such. If they look into how we did it though, I'm sure we'll be setting a new bar as to what can be done in KSP right now.

- - - Updated - - -

I looked into the PQS stuff how we could get the color of the exact point of collision and then it came into my mind that there's no efficient solution to that.

If I understood correctly the PQS system stacks material layers* on a more or less round sphere which are then merged to a texel (pixel in a texture) during rendering in the GPU. To get that texel we would need to access the video RAM and believe me, you don't want to do that. We would replicate how the camera works you already use to get the ground color.

* There's at least a material for height color maps, "biome" colors (to make grasslands look different to deserts), detail colors ("grass leaves") and maybe more.

IMO the current system is good enough and works for everything except some parts of the KSC complex.

Technically the biome colors are based on the biome identification maps, which really have nothing to do with the appearance of the region. It has more to do with science and/or tracking what region of the planetary body the craft is in. That's why some biomes are given utterly ridiculous colors, such as a grassy area perhaps receiving a default biome color of deep purple (just an example, I didn't actually look the color up). Some trial and error will be needed to fine tune the biome colors for non-Kerbin locations.

There are, however, some issues with how the biome maps are set up. There's at least one area around the KSC that is marked as a tundra region, but the texture is obviously grassy. That's why I wanted to find a way to get the color visually, which led to then original idea to use a camera which, after a while, became possible with the "vessel module" feature. I have no idea how to detect these errant biomes and squash them, however, unless we were to override the biome maps in certain areas, such as around the KSC.

Edited July 15, 2015 by Gaalidas

[Gaalidas]

Alright, we're not in the clear yet with the GUI. I just did a test launch and I have absolutely no icon in the app launcher.

NullReferenceException: Object reference not set to an instance of an object
    KerbalFoundries.KFPersistenceManager.ReadConfig ()
    KerbalFoundries.KFPersistenceManager..cctor ()
    Rethrow as TypeInitializationException: An exception was thrown by the type initializer for KerbalFoundries.KFPersistenceManager
    UnityEngine.GameObject:AddComponent(Type)
    AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup)
    AddonLoader:StartAddons(Startup)
    :MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    :MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    GameDatabase:StartLoad()
    :MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    LoadingScreen:Start()

A little more insight into what could cause the icon to not load. First off, I switched it from [KSPAddon(KSPAddon.Startup.EveryScene, true)] to [KSPAddon(KSPAddon.Startup.EveryScene, false)] so that it would load more than once, which seemed to squash the above exception. However, I'm still getting no icon. I remember a while back reading something about the event "onGUIApplicationLauncherReady" not always firing properly in the current version of KSP. that would explain why there's no icon in the scenes that the class is supposed to run in. We need an alternative method to detect if the launcher is ready to receive buttons.

Edited July 15, 2015 by Gaalidas

[Tyren]

Did I read config for stock parts? A dream comes true

[lo-fi]

I remember xEvilReeperx saying that pulling stuff out of the GPU memory would be expensive too. Looks like its mostly under control with the gui and dust, minor bugs aside, so I won't poke my nose in

Yep Tyren, we've had then for a while, though they may well need updating. Also the ERS wheel and something else I can't remember. Any wheel can have a KF config made, so long as its not a complete vehicle in one part.

[xEvilReeperx]

I remember xEvilReeperx saying that pulling stuff out of the GPU memory would be expensive too. Looks like its mostly under control with the gui and dust, minor bugs aside, so I won't poke my nose in

It is. The current routine you have takes 4-5ms on average on my machine. If you eliminate the unnecessary allocations in there you can drop the average to 1-2ms. That's faster than I thought it would be though, so if you go with your strategy of only sampling every x frames it works out I guess

Edited July 15, 2015 by xEvilReeperx

[lo-fi]

Thanks for the input. Just out of interest, how were you benchmarking? I set up using the stopwatch, but is there an easier method? Every frame is certainly too much. Or is there a better method in general? A few other mods - RPM, reflective windows etc. seem to use cameras to capture and apply somewhere, but is there just a price to pay for doing so no matter what you do?

[lo-fi]

Thanks to a wildcard suggestion from V8Jester, I finally made some solid progress with this:

Also a big thanks to Baha for showing me the way with the Burn Together code. Still a lot of work to do on that before it gets released into the wild, but I'm no longer terminally stuck! Thanks to Gaalidas and *Aqua* for dealing with other bits while I'm off playing with crazy stuff. More to come I'd also like to see an end to the need for docking ports to tie rovers down for transport...

Seeing some null refs by the way, guys. Mostly related to DustFX when the game is paused. I'll do some more investigation later and report back. I assume it's probably just some stuff that needs hooks into the OnPause and OnUnPause methods, so should be no big deal.

[*Aqua*]

@Gaalidas

Did you change the KFGUIManager or KFPersistenceManager to run more than once? KFPersistenceManager only needs to do it's work once during startup.

The ApplicationLauncher has a broken life cycle system. It's present during nearly all scenes but doesn't always get destroyed immediately on scene changes. I have an idea to adapt to that but it'll take some work.

[WRN 18:32:35.917] [HighLogic]: =========================== Scene Change : From SPACECENTER to FLIGHT (Async) =====================

[LOG 18:32:37.347] AddonLoader: Instantiating addon 'KFGUIManager' from assembly 'KF_plugin'

[WRN 18:32:38.452] ApplicationLauncher already exist, destroying this instance

[LOG 18:32:38.464] AddonLoader: Instantiating addon 'NavWaypoint' from assembly 'KSP'

[LOG 18:32:38.468] AddonLoader: Instantiating addon 'KFGUIManager' from assembly 'KF_plugin'

[LOG 18:32:38.517] ------------------- initializing flight mode... ------------------

Yes, you are reading right. That's how broken it is. Also there could be a more fundamental error in Squad's code (why is the MonoBehavoir loaded twice?).

Also you get the NulRef in the method KerbalFoundries.KFPersistenceManager.ReadConfig(). I think it's related to the new DustColors.cfg which is in the other repo. Maybe you missed to pull it.

Btw, I think it's wrong to read the .cfgs using ConfigNode.Load(). KSP should already read those .cfgs during startup thus we only have to get them through GameDatabase.Instance.GetConfigNodes("node_name").

---

I stumbled upon the small tundra area near the KSC some time ago too. I'm not sure why it's there. I found player speculations that it's either an artifact Squad don't know about or that it's intentionally placed there for not-so-good players to grab science during early career play.

Then I heard of some players reporting the same's happening on Minmus. So I believe they are artifacts.

I don't feel like correcting errors Squad made. I could also be costly to fix that if we are able to get our hands on the biome maps data. On slower computers the game might stop for a second or two when processing all the maps.

---

And now something completely different (not really ^^):

In which scenes you want to see the app icon? And what should be displayed when you click it in that scene?

So far I imagined this:

Flight scene -> Enable dustFX & Enable dustFX camera

Editor scene -> Enable part orientation markers

Space center scene -> all three toogles visible

all other scenes -> disable app icon

What do you think?

---

@lo-fi

Great! You made it work! Incredible!

Here, cookies for you and Gaalidas

I'll look into the exceptions you mentioned.

[Tyren]

more gimmicks, you say?

[lo-fi]

I see what you mean - that's not ideal! The Gui stuff seems to be behaving, but the icon is no longer present in the space centre (which may be deliberate?)... If you open it in flight, you can't then close it when back in the space centre, though. That list seems pretty sensible to me.

I know almost nothing about the config node stuff, so I'll leave it to you guys. Agreed on the biome placements, that's a little out of our scope.

Ahhhhh, cookies!!!! Thanks, quite pleased about that. Though there's still the issue of what to do about orbits when the game is merrily going about its thing and the coupled vessels are nothing more than masses in orbit.

I'll get back about the nullrefs from DustFX.. EDIT: Then they magically disappeared....

Gotta love a good gimmick

Edited July 15, 2015 by lo-fi

[xEvilReeperx]

Thanks for the input. Just out of interest, how were you benchmarking? I set up using the stopwatch, but is there an easier method? Every frame is certainly too much. Or is there a better method in general? A few other mods - RPM, reflective windows etc. seem to use cameras to capture and apply somewhere, but is there just a price to pay for doing so no matter what you do?

Same, StopWatch. Using a camera isn't what's expensive, it's the ReadPixels. You can have your camera send its output directly to a texture property on a material set up to use a custom shader that does whatever work you need and avoid that performance penalty. That's what those other mods do.

I think the current solution is good enough for now though, aside from a little texture memory leak

[lo-fi]

Ah, I see. I'll have a poke about and see what I can find in other mods - if nothing else it's always instructive.

Edit: actually, something I struggled with on the camera, and related to your comment about the redundant allocations.. unless I destroyed the camera, KSP kept rendering the flight view through it. Which isn't massively helpful. I'll have to try and figure out why that kept happening.

Edited July 15, 2015 by lo-fi

[Gaalidas]

@Gaalidas

Did you change the KFGUIManager or KFPersistenceManager to run more than once? KFPersistenceManager only needs to do it's work once during startup.

The ApplicationLauncher has a broken life cycle system. It's present during nearly all scenes but doesn't always get destroyed immediately on scene changes. I have an idea to adapt to that but it'll take some work.

Yes, you are reading right. That's how broken it is. Also there could be a more fundamental error in Squad's code (why is the MonoBehavoir loaded twice?).

Also you get the NulRef in the method KerbalFoundries.KFPersistenceManager.ReadConfig(). I think it's related to the new DustColors.cfg which is in the other repo. Maybe you missed to pull it.

Btw, I think it's wrong to read the .cfgs using ConfigNode.Load(). KSP should already read those .cfgs during startup thus we only have to get them through GameDatabase.Instance.GetConfigNodes("node_name").

---

I stumbled upon the small tundra area near the KSC some time ago too. I'm not sure why it's there. I found player speculations that it's either an artifact Squad don't know about or that it's intentionally placed there for not-so-good players to grab science during early career play.

Then I heard of some players reporting the same's happening on Minmus. So I believe they are artifacts.

I don't feel like correcting errors Squad made. I could also be costly to fix that if we are able to get our hands on the biome maps data. On slower computers the game might stop for a second or two when processing all the maps.

---

And now something completely different (not really ^^):

In which scenes you want to see the app icon? And what should be displayed when you click it in that scene?

So far I imagined this:

Flight scene -> Enable dustFX & Enable dustFX camera

Editor scene -> Enable part orientation markers

Space center scene -> all three toogles visible

all other scenes -> disable app icon

What do you think?

---

@lo-fi

Great! You made it work! Incredible!

Here, cookies for you and Gaalidas

http://media.tumblr.com/tumblr_krmqfbCdeO1qa400q.jpg

I'll look into the exceptions you mentioned.

And they say I have large postings. You have a ways to go yet before you can best me, Aqua, but you're well on your way.

So, I've done some fiddling and I think I know why it's not showing up properly. First off, it seems the event for the application launcher being "ready" only fires now between main menu and space center (as of 1.0) and the best way to check the ready state is using "ApplicationLauncher.Ready" instead.

Also, I discovered that the button definition was set to be visible only in the flight scene. Messed up.

Biome maps have been overridden before, and it wasn't all that costly really from what I could tell, but I wasn't a developer back then. Just a regular peon. A simple peasant. A wee underling...

As to the config node loading... I did that because it was the easiest way to then handle saving back to the file. I really would prefer if we simply grabbed the already-loaded information that the game grabs on its own. I simply couldn't wrap my brain around how to re-save that information without first loading it in the same way. Feel free to revamp it.

So, I wasn't going to have different GUIs in different scenes, but I suppose it would make the most sense to me if all the options were available in the space center, but only the editor specific options allowed in the editor itself. The arrows disappear in flight anyway, so no need to have that option there.

Any other changes I've made can be reverted if they weren't related to the problem I was having. I'm just trying to get it to work correctly on my end. If I'm not seeing an icon when I'm trying to tell it to render one, I'm going to start changing everything I see that could have anything to do with it. I'm not nearly educated enough in C# to properly diagnose this stuff.

- - - Updated - - -

EDIT: Then they magically disappeared....

It always works that way. Just when you start to narrow down what's going on, they disappear robbing you of the pleasure of squashing them. They'll reappear just when you think everything is going as it should.

- - - Updated - - -

I think the current solution is good enough for now though, aside from a little texture memory leak

Considering the extremely tiny resolution of an image we're capturing, and the fact that it's only reading the scenery layers, it's likely an extremely small cost overall. That is, until I try something really crazy like per-wheel cameras. That might not go over too well.

As to all that talk about materials and shaders, I think I ran into that stuff when I was trying to see if I could get the TextureReplacer reflection module to use a different texture to define reflectivity instead of relying on the alpha layer of the part's diffuse texture, or at least use the inverse of what it currently uses instead, to make modification of textures easier to handle while still allowing reflectivity on parts where the reflective areas are not separate objects that could be targeted. In the end I gave up because of the custom shader stuff that I couldn't figure out. My goal was to do something similar to how KerbPaint (I miss that mod sometimes) had a bunch of extension-less files that were basically png masks that defined paintable regions, and what layer of paint would be used. These files had no extension in their file name, so the game would ignore them (since they served no purpose being loaded into the game's allocated memory) and KerbPaint would process them itself.

I gave up pretty quickly. I don't speak "shader" very well. In fact, not at all.

Edited July 15, 2015 by Gaalidas

[*Aqua*]

Now I'm sure there's a fundamental bug in KSP. KFGUIManager instances do not get unloaded/destroyed on scene switch. The number of instances just keeps increasing. WTH?

Is that why there's a memory leak between scene changes?

[V8jester]

Thanks to a wildcard suggestion from V8Jester, I finally made some solid progress with this:

http://youtu.be/UwuiPtsmvW4

Also a big thanks to Baha for showing me the way with the Burn Together code. Still a lot of work to do on that before it gets released into the wild, but I'm no longer terminally stuck! Thanks to Gaalidas and *Aqua* for dealing with other bits while I'm off playing with crazy stuff. More to come I'd also like to see an end to the need for docking ports to tie rovers down for transport...

Seeing some null refs by the way, guys. Mostly related to DustFX when the game is paused. I'll do some more investigation later and report back. I assume it's probably just some stuff that needs hooks into the OnPause and OnUnPause methods, so should be no big deal.

You're giving me way more credit than I deserve. You and BD are the wizards here. I'm glad it worked though I knew there had to be a similarity there.

[*Aqua*]

I pushed out two commits. The app button should now only be displayed in editor, flight and space center scenes. Also the window is disabled on game scene switch. Furthermore the contents of the window change depending on the current game scene.

I hope the changes works for everybody.

What's left for the GUI is to change the window position and size depending on game scene and window contents. Gaalidas, do you want to do that?

[Gaalidas]

Isn't the size handled automatically now, or did you not get around to changing that? You seem to have a better hold on GUI layout stuff than I do. As for position, I'll do a bit more digging. I know that a GUI can be made to appear below/above (depending on scene) the button that calls it, but I have no idea how that's done just yet. In all, those are pretty unnecessary additions since, as long as the window opens within the user's screen space, I believe it is drag enabled and, since no information is really displayed in the window, we don't need it to stay open. One thing I'd like to see is whenever the window is closed, either by scene change, save button, or re-clicking the button, that it commits the changes to file. Some testing needs to be done also to see if the parts will respond to changes such as disabling the global dust toggle. I have code in dustFX that changes the visible state of the context menu dust toggle (for per-part toggles) but I have no idea if the conditions for its visibility are checked per frame or some sort of heatbeat timer, or if it's only checked on the scene loading. The idea is to not allow the per-part toggle to show up if the global toggle is disabled. Ideally, I'd love to have the button in the context menu be replaced with a textual field that displays something like "Dust system disabled" when globally disabled.

First, I'll grab those commits and see what's happened.

[Cyrious]

Thanks to a wildcard suggestion from V8Jester, I finally made some solid progress with this:

http://youtu.be/UwuiPtsmvW4

Also a big thanks to Baha for showing me the way with the Burn Together code. Still a lot of work to do on that before it gets released into the wild, but I'm no longer terminally stuck! Thanks to Gaalidas and *Aqua* for dealing with other bits while I'm off playing with crazy stuff. More to come I'd also like to see an end to the need for docking ports to tie rovers down for transport...

Seeing some null refs by the way, guys. Mostly related to DustFX when the game is paused. I'll do some more investigation later and report back. I assume it's probably just some stuff that needs hooks into the OnPause and OnUnPause methods, so should be no big deal.

AWESOME! Is this going to be a part of the main mod in terms of code (single DLL for all functions) or will it be split (DLL for the wheels, DLL for the hitch)?

[riocrokite]

Thanks to a wildcard suggestion from V8Jester, I finally made some solid progress with this:

http://youtu.be/UwuiPtsmvW4

Also a big thanks to Baha for showing me the way with the Burn Together code. Still a lot of work to do on that before it gets released into the wild, but I'm no longer terminally stuck! Thanks to Gaalidas and *Aqua* for dealing with other bits while I'm off playing with crazy stuff. More to come I'd also like to see an end to the need for docking ports to tie rovers down for transport...

Seeing some null refs by the way, guys. Mostly related to DustFX when the game is paused. I'll do some more investigation later and report back. I assume it's probably just some stuff that needs hooks into the OnPause and OnUnPause methods, so should be no big deal.

Superb stuff guys \o/ congrats