Gaalidas

As far as I'm aware, it really just needs a functional (RPM enabled, and transparent pod enabled, I hope) IVA attached to it. In the future I'd love to see the work you did on the engines, lo-fi, be expanded into allowing the engines to work together to emulate gimbal action by adjusting the positions of the extended engines relative to the craft upon input to the gimbal system. But, that's for another time. Something that would be amazingly cool for the future would be some sort of rover body that would fit inline with the rest of the tug parts. I remember, as a workaround for the IVA, some people started clipping the IVA from the command pod in the... (forgetting the name of it, that little 1-seater command pod with the transparent pod enabled spherical view) ... anyway, putting that IVA into the tug, which worked relatively well if you ignore the fact that the internal side of the transparent spherical view port didn't really fit the tug pod very well. If one were to strip out the badly fitting parts of that IVA though, and stick it in there, it would probably work rather well. I jsut with the author would come back. He had some pretty crazy ideas for making customization of the parts more and more unique. That tug pod, for example, can take both a window texture swap, a semitransparent window decoration texture swap that can take standard flags from the stock game or mods as input, and several texture swaps for pod color and warning-tape style decorations.

Taking the Minmus thing out of the equation for the time being (which is like taking the numbers out of an addition problem and expecting it to work still, but let me work this one anyway...) I remember first off that there were some issues back in the days before we had KIS and it was just the KAS attachment. I am unsure why it would persist after a scene reload, however, since that is the normal fix for such issues. If you were using the latest dev version of the mod, I could also expect the brake issues if you craft is extremely light. Lo-fi might have fixed it since, but I remember making an extremely light vehicle that could overpower the brakes and do complete flips just by tapping the forward/backward button while the brakes were turned on. Now, add Minmus back into the equation and it suddenly all makes sense for you. For me, not so much... I was on Kerbin when I did my flips. One thing i do notice however is that those appear to be tracks, not wheels. Tracks tend to use a track steering which means they really don't visually "steer" at all, they simply run forward or backward at a different rate on opposite sides of the craft to turn the vessel. - - - Updated - - - I wasn't aware they were broken... what's the story with those? Did you simply forget to patch the corrector into some of the new equations? - - - Updated - - - I think maybe it's time to put the sound element to rest. If we want an impact sound effect, we should really dedicate a different module to it. DustFX should be related to the effect, and not the noise. The only reason it's in there is because the original code I started with, in CollisionFX, had an impact sound feature. Considering the errors we've dealt with over the many iterations of DustFX since I merged it with KF, I think it's a bit more trouble than it's worth right now. i might be interested in tackling that as a new module, or simply extending the already established methods of playing sounds when running the wheels/repulsors with an impact effect after the Dust and GUI stuff is more or less settled. In other news, this morning/afternoon I started trying to fix up the last thing I want for the GUI: a "save and close" button at the bottom. I managed to get one to show up, but it was not functional. I have no idea why it wouldn't function either.

The part icon zoom bug (infinite zoom right?) is something to do with resources and such. It only happens on modded parts as far as I know, and there's a mod for fixing it (I think it's called ModuleFixer) but there are hacks to get rid of it in a per-part basis. I don't know the details, I still use ModuleFixer and it hasn't even been updated since... well, forever. if you're referring to the position of the parts in the icons, however, then that's a different matter and is related to how the tracks cannot be shielded properly in a fairing and overheat, even though they are visually protected. PartIconFixer (a mod made during the early days of KF track development by a 3rd party) is avaialble which can fix that without requiring any module definition in the part, and thus no dependency. - - - Updated - - - Indeed, that was based on old code of mine before Aqua joined the team and corrected by blunders.

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.

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

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.

So, to answer the original question... yes, mods will break. Sucks to be us.

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

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

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.

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.

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.

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.

gotcha, alright thanks.

You're kidding right? for a basic cube, we're talking what... 6 surfaces? Poly count will be the least of your worries.

All I can see is a mess of explosions and debris when I think about trying to land something on it in the way you'd normally land on a runway.

So, can I simply reference the icon by name, or do I need to provide a gamedata-relative path to the icon to use? Normally I would simply ship with the folder structure for this mod in the archive containing just the added icons and the config, but this isn't my mod, at least not fully. I contribute heavily to Kerbal Foundries and I'd like to provide a category config with our next release, but convincing lo-fi to reorganize how his archive is structured is easier said than done, so I'm looking to simply stick a config for this mod into the same folder where we have our part configs, and reference the icon (and it's associated "selected" icon) in our Assets folder.

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]; }

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 - - - Taken care of.

Hey, quick question. Can a mod category reference a pair of icons that are located in a different location than the ones shipped with the mod? If not, would it be possible to add a field where I could tell it what base path to use when searching for the icon name in my mod category config?

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.

Where did you get the idea that this isn't for the current version of KSP? We're all using it right now.

"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 - - - That's funky. So, we can change the icons of other mods eh? Could be useful if we ever want to hijack another mod.

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.

Take a peek, but I wouldn't spend a lot of time trying to figure it out. We can revert a few changes back so that we can use the config loader again like before and shelf the GUI for a later release. I just wanted to see if it would be possible. The priority is getting the rest of the parts rewritten for the new module rewrites and completing the dust stuff. On that note, we need to re-add the biome color definitions for when the global variable that enables the camera sampler is turned off, which should also be automatically set to "false" internally if the dust is disabled. In fact, if the dust is turned off globally, there shouldn't be any cameras, dust definitions, or any other effects defined during flight at all ideally. That said, I'd like to look into scrapping the MM patch to apply the module and instead simply predefine the module in the part configs that we have.