Gaalidas

I wish... I've seen things you would never believe... except you probably would if you've been here a long time.

That's hilarious. I think I broke the translation system. - - - Updated - - - Nothing is pointless. No really, it is quite pointless. But that cannot be pointless. It is simply without a foreseeable point in the near future. You never know when you might want to zero out the size of something. I have a feeling it zeros out many values that are only used in the editors with the stock modules to clean up after itself. It's irritating, but at least it's clean. Maybe you could create a temporary file that is saved to the disk which handles values like that which are not saved between the editor and the rest of the game so you can retrieve them when they are zeroed out, sorta like we save the state of the configs when the settings GUI gets closed either deliberately or by changing scenes. Yeah, sounds like a bad idea...

Looks awesome. Now, go finish KONQUEST. Dooo eeeet! Naaaooooow! That's all I've got. I've disturbed myself again.

I definitely like option 2 as well, even if it is the heavier option as far as work load. It'd sure make it easy to toggle on and off per user. We'd just add that option to the editor setting-menu configuration. One thing that would need to be taken into account however is that it isn't the node itself being turned on or off, but simply it's visibility to the user. If a user attached some of our parts using a stack node, then turns them off to attach others by radial attachment, then launches the craft after our code has disabled the nodes that were still being used, you could have issues with the cohesion of the parts in flight. We simply want to make them invisible and, in the editor only, non-functional. What would be nice is if the hitch could be made to work off of the same model. That way you'd only have to add a hitch part to the crafts you want to get hitched (there's a pun in there somewhere) and wouldn't have to decide beforehand exactly which one would be the hitch and which would be the hitched. I think I'm confusing myself with all these hitches getting hitched to hitches and hitch-hitches.

Well... son of a motherless goat... I must say, this is the most disturbing thing I've witnessed here... ever...

Another small question for you lo-fi... at this time the Eye part has no modules in it to indicate that it is a required participant in the hitch. Is this accurate, or is that part still needed? With the renaming of it's associated module with the suffix of "OLD" and the more recent commenting out of the module in the part config, I've been wondering what the point of that part is for some time. In other news, I put a module in a few of the parts for local testing which implements the JSIPartUtilities module called "JSIPartComponentGroup" and set it up to allow toggling of the stack node on the wheel parts. From what I can tell, from the sample configs I used from the ERS rover system, if the user has the mod installed then the stack nodes will start out disabled with the option of enabling them in the context menu for that part. If the user does not have the mod installed, they'll have the stack node enabled as it is now. A better way for handling this might be to make it a global option, but we'd need to implement our own node toggling code. I'd like there to be an option to keep the nodes around, since I've found them very helpful in my designs, but I can understand that they might cause problems with others. A third option for the nodes would be to include an optional MM patch that, if the user enables it (renaming the file extension from... say... .txt to .cfg), would add a stack node to each part, otherwise leaving it blank. I might even know of a way to add the stack node to each part with a single patch by copying the value of the attach node, but I'll have to do some MM syntax research.

The draggable thing was just a theory in that area. BDArmory uses a similar setup, but there is one difference in his layout: he's using automatic layouts instead of specific layouts. it could be that dragging works better with an auto-layout. lo-fi, I noticed you re-added the DustColorFileWriter.cs, however this file is no longer necessary since the dust colors are handled in a completely different format now. It would be best to remove the unnecessary and obsolete file in this case. UPDATE: I just merged my own tweaks to format and whatnot, but otherwise it looks good. I'm calling the GUI complete for the time being then. It's been a big enough pain that I don't want to touch it again for a long time. My next line of research would be to find out how to implement some form of stack-node switching without coding it into the mod and without giving us a hard dependency. I'm thinking about implementing it in a similar fashion to how TS in implemented into our parts, simply by adding a module to the part configs that will function only if they have the other mod installed, which most people will have if they use ERS or B9. It shouldn't be too difficult to figure out, since I shouldn't need to code anything. So, lo-fi, do we have any ballpark values for the updates that need to be done to the parts that would work as a default starting point? Or are these config updates needing to be done completely on a per-part basis?

No, actually, an answer was not actually given. At as of his last installment into that topic, I was still unable to actually fix the problem presented to me. I was made to look like an idiot just because I'm not the elite programmer that he obviously is (and I mean that, he's on a complete different level than I can comprehend right now). Honestly, I don't blame him overall. As one reaches higher degrees of education it becomes extremely difficult to descend down to the levels of those who are not at the save level of learning. I have that issue every time my grandparent's call me to say their computer is broken and that they are completely innocent of any badly handled pop-ups or anything. I know for a fact that they are guilty of unknowingly installing a new add-in to Firefox that is not screwing them up, and that, for instance, AOL is not, in fact, blocking them from getting to the internet. It's only replacing their startup page. it's a bit of a struggle to help them when the terminology is all wrong on their end. Really annoying, but I have to find a way to descend toward their level to help them effectively. If I try to tell them to click on a series of buttons that could be in a different location based on how large the window is on their specific monitor size with a specific screen resolution, assuming they haven't accidentally gone into full screen mode, they will get confused very quickly and be unable to follow the directions. Similarly, based on what he could see in my code and on the level of the questions I was asking, I would think that the response could be geared towards the questions I am actually asking about. I mentioned that I based my code off of another mod, which I named, and that I could find no different between the two source files other than the context of the implementation (I don't need the same options being toggled as BahamutoD needs) which is different for every mod, obviously, since we all want to use our own GUI layout and whatnot. The answers I was receiving were of the type that asks a relatively uneducated person to contemplate concepts that are way above his/her level of understanding and then letting that person know that they are not as smart because they couldn't do something really simple in response to the higher degree of knowledge they were being asked to contemplate. In the end, I still could not solve the problem no matter what I copied from his posts because none of it was written into the context of the code I was trying to fix. I need a working example to work from in order to make sense of it. That's why I use other mods as examples. If the exact same thing works for BahamutoD, then I expect it to work for me. I could not see the difference, and I expected that someone would take what I was providing and, if they were unwilling to give a working example in the context of this mod, at the very least they could show me what the difference is between the two implementations. Instead, I had to grapple with a situation that made absolutely no sense to me, and when I expressed that, I was provided with more of what I could never hope to understand which does not help at all. So, yes, I was extremely frustrated with him and I feel that was a justified feeling on my part. I have a lot of respect for the guy and his achieved level of thought in relation to programming, but his approach to my questions were slightly demeaning and quite unhelpful. I don't feel like any apologies are necessary on either end. It simply is what it is. - - - Updated - - - I will respectively disagree with your assessment of my fairness. I was researching and asking, but when I say something makes no sense and am provided with something that is even more complicated, that only leads to more frustration. I didn't ask to be taught, I simply wanted to know what my answer was to the problem at hand. I'm glad you're satisfied with the result however and hopefully we can come up with a proper solution in the future. I consider this situation closed unless anyone else would like to point out my unfairness and give me unwanted advice about my wrong doings? Lets just set this aside and start working towards the future now. - - - Updated - - - When I was researching how KSP does all this itself, I also looked at other mods which try to determine the size and mass of objects in flight. I didn't come up with anything too useful, but the mods I was researching are Vessel Viewer, Mechjeb, any mod with a landing aid or an auto-gimbal system (km_gimbal and it's various versions). Looking at those might give you some hints, though doubtful it will supply and fixes for this problem directly. My only real thought on all that is that Vessel Viewer seeks to find out what the size of the craft is so it can scale it's view properly. I find myself wondering how it deals with this problem when displaying tracks and scaling the view properly.

Y'know, the fact is there was a lot of crud being sent my way that made absolutely no sense and I did not appreciate it, so apologies are not on the table at all. I don't need to be told what I should be pondering, or that i should be taking two seconds to do something when, in reality, it takes more than two seconds to type even the beginning of something into the code, especially when I have no idea what is being asked of me. I didn't ask someone to try and "teach" me what is happening behind the scenes, I was looking for an answer to the question. So no, there are no apologies for my reaction to these things. If, if fact, I were asking for the theory behind what is happening here and requesting a hint or some such thing, then perhaps I would be in a position in which an apology was necessary. as it is, I felt I was being fed information that was not at all helpful and really didn't do anything to fix the problem. All it did was make me feel like an idiot. That's all in the past now, and I've given up on that kind of GUI system and have reverted to the last working version of the settings menu. Moving on now... Symmetry is always an issue in the various editors. For parts that are meant to attach horizontally, you have to use a radial attachment method for symmetry to really work correctly. If the parts you're attaching to are not themselves attached in a radial symmetry then you will end up with your new part symmetrically attached only to the part you're attaching to, instead of the entire craft as you would expect. Stack node attachment is completely optional since there is a key you can hold down (completely stock functionality here) that will force the editor to ignore the stack nodes. I forget the exact key right now, but it's one of the modifier keys (shift, ctrl, alt) that does the trick. I have fiddled with the idea of adding an optional module into the parts that would, if the other corresponding mod was installed, all the user to turn off the nodes temporarily while editing them in order to make it easier, but I've been a bit too busy to experiment with that lately. The issue you are experiencing is due to the interaction between stack nodes and how the SPH symmetry conflicts with stack nodes. Unfortunately, I am unsure how one sets a series of stack nodes to be friendly with symmetry, especially in the SPH. when using surface, the editor automatically flips the part to appear correctly on the craft, but it doesn't know what to do with the Stack nodes because originally they were meant only for attaching hull pieces together end to end. Now, on some parts where the stack nodes are set up and aligned correctly, symmetry can work rather well with symmetrical attachment. For instance, the ERS rover body can do it rather well and without any of these quirks. However, there are also parts which are not meant to be used with parts like these and they don't work well with symmetry as you've discovered with those trusses. It's still attaching to the same node on either side, but it's not accepting that the part should be flipped. Either way, it's not the stack nodes on the wheels that are the problem, and they were added to these parts for a reason that is still quite valid. This does not mean you have to use them to attach these parts, it just means that they are available when rover bodies are made specifically for rover use and provide nodes for wheel placement, such as on the ERS and a few others out there in the cloud somewhere. My best constructions using symmetry in that way was to first make a single instance of the entire construct that will be symmetrically attached to the rest of the craft, then I pick up that entire construct, from the part that will radially attach to the craft, and activate the symmetry then and reattach it. I then copy the construct from that same attachment-part and create as many copies as needed. This usually eliminates the issues that come from individually trying to attach each part in full symmetry. Also, for the control problem, keep in mind that horizontally aligned crafts have not only a forward and backward, but also an up and down. If your probe is not aligned in the exact correct direction in relation to both forward/backward and up/down, then you could have issues with the steering being flipped with the acceleration and such. However, I have not actually seen anything like A/D being swapped with W/S since the functions behind those keys are completely different. The former set controls turning direction, while the other set controls movement. It's not the same as translational movement in space using RCS, where the different keys can swap based on the orientation of the control unit. Now, for the issue with the inverting track moving backwards, that is something I remember experiencing a long time ago with the old DLL that came with RBI. I'm unsure what the real problem was, but I suspect it had something to do with the orientation of the part in relation to the control part of the craft and the orientation of the root part of the craft. Sometimes, if the root part is not the controlled part, and the root part is not in a standard orientation, you can experience strange control issues that don't make a lot of sense. I have personally had issues with my gimbals on the back of a repulsor craft using gimballing jets to control my steering being reversed in flight due to my control pod technically being angled straight up. Unfortunately there aren't a lot of known fixes for these incidents. the causes are numerous and the fixes are unique to each situation.

Well, I attempted to add a check against (!Equals(HighLogic.LoadedScene, GameScenes.LOADINGBUFFER)) and above that I had a single log entry line to tell me whenever the Awake method was called. Unfortunately, it seems that Awake isn't working quite right because I'm getting absolutely no log entries at all. Strangely enough, the GUI will still load up but now the toggles are stuck in the "true" state but the button no longer causes a nullref. Is still doesn't do anything though. So, I'm really just confused now as to why my log entry isn't working when it's fired off whenever Awake is called? Cause right now is looks like Awake never happens. UPDATE: So, I decided to put another stop between the button click and the activity it produces by starting a new method I called CloseGUI() in which I stuck a bunch of log entries for the state of "appButton" and even attempted to make a local copy of appButton in the feeble attempt to tie into the proper instance of it. No luck there, and I still have no idea why the GUI spawned from the currently active and not-null "appButton" would launch inside of a copy of the class which is supposed to be garbage. Anyway, the button no longer nullrefs on me, and I can now close the GUI from it using that middle-man method I made, but I still cannot reset the "appButton" to the grey texture, nor can I get it to save the settings from that button. at this point I think I'm going to have to scrap the idea of having the "appButton" icon lit up while the GUI is active. If it returns to grey when the mouse leaves it, and doesn't bother to do anything while the GUI is loaded, then none of this should be a problem at all. There's still something whacky going on in the background with multiple instances of the class being loaded at the same time, but I can't do anything about that right now and there are no examples of this happening to anyone else in identical situations so there's no hope of finding a fix for it right now. I'll let you all know if it works. In the back of my imagination right now there is a possibility of separating the appButton itself and the GUI stuff into separate classes in which I could add public booleans to track the states of things and simply have the appButton part of the code check the update cycle to see if a boolean in the GUI class has been set to false, indicating that the GUI is no longer open and the appButton needs to be updated to match. But, I have no idea what sorts of problems I would be opening up in the process of doing that. UPDATE 2: Okay, I think I've finally hit my limit for the complete bovine excrement that this program is giving me right now. I stripped out all attempts to control the texture of the "appButton" from the GUI or anything that is called from or on the GUI. No more nullrefs. Since adding another method between the button and the action it's told to do worked before, I simply reworked the method to save the current state of the config when called. Now, however, instead of sorta-working like it was before, I can't get the toggles to function anymore. They won't toggle, and the button no longer works again. So now I have a completely non-functional settings menu. I'm fed up with this. I am doing nothing different than everyone else with the same GUI settings window is doing, but for me it simply won't work at all. The more I try to fix it, the more broken it gets. The more I start to understand why I'm getting a particular error, the more it starts not giving me the same error when it's supposed to! I feel like I'm battling a sentient entity that exists only to screw up my every attempt to make this thing work! I can't fight this any longer. Nothing makes sense now! What worked yesterday is no longer even working today!

Maybe we could get around the entire thing if we add another check against that strange scene that is running between the main menu and the space center and just have the class do nothing at all if that scene is present. I don't know how to check against that scene though because it's not a scene that is present in any of the normal. Can we detect a scene by string instead of by the highlogic stuff? The fault-finding stuff is a lot of gibberish to me I'm afraid. I'm not high enough in my programmatic education for that. Scratch all that, just found it when looking through Assembly-CSharp... scene 1, LoadingBuffer. Who'd have thought it? The question still remains: why must we do anything like this when every other mod, in which I've downloaded the source for to learn how to do this, doesn't? What's so special about this mod that makes all these things happen so much differently?

At what point does the inventory get cleaned though? If it's happening when allowed # of Kerbals in the part is being reduced due to retracting the habitat space, then it kinda makes sense that anything specific to that Kerbal, as in taking up the same slot as the Kerbal as far as the code is concerned, is going to be lost along with the allowed slot that the Kerbal could inhabit. What you would need is some way to export all of the Kerbal's belongings that are not held within the individual Kerbal's own inventory (backpack or whatever, I'm not that familiar with the inner workings of these mods honestly) into an external (or programmatic equivalent within the same part's modules) container. No clue how you would go about making this happen though. best practice would be to empty the part of any containers before doing anything that would change the # of Kerbals the parent part can contain. If that's not the issue, then disregard and continue as you were. I'm just thinking aloud... or... textually... I guess...

Okay, that's all very interesting and very confusing. Actually, it's headache inducing. I understand maybe 1% of what you just said. I've looked at other mods that are doing this same thing that I'm trying to do and they aren't doing anything different than what I have in my code, and they seem to have absolutely no problems. So, why am I having problems and how do I fix it? I'm really not interested in knowing what all the inner workings of these things are right now. I'm looking for a solution to the problem. If I can see the solution, then maybe I can make sense of it. I learn best by seeing a working example and disassembling that to see what makes it tick. Also, I'm still confused as to why this has anything to do with appButton. In the latest attempts I've made locally, the code between the brackets of the button's "if" statements doesn't even ask for appButton at all. Why would an independent button within a GUI window be dependent on an AppLauncher button? The only connection between the two is that appButton launches the GUI window. It simply makes no sense to me. Also, keep in mind, this isn't a solo creation here. If something has been done wrong in here from the start of this whole class, then it's been a collective screw up. The first iterations were copied directly from BDArmory, after which I stripped a lot out and rewrote a few things to be specific to our mod. Aqua attacked it then to try and make things actually work, where I tend to hit things until they stop moving and then yell at them until they live again. So, the real question is this: where did we all go wrong?

You weren't saying I needed to do that. You were giving me grief because I couldn't take two seconds to add a check against something being null that, since I was able to spawn a GUI window from a toolbar button at all, obviously isn't null. If you wanted something like what you posted, you could have actually said that. What I don't understand is how appButton could be null, considering we've already made it not-null and the only reason we have a button in the toolbar is because it has been defined. Because we have a button in the toolbar at all, and there has been no scene changes with a toolbar present, and the rest of the GUI is working perfectly fine, then appButton simply can't be null. It's completely impossible that it could ever be null, cause we're using it and it's already been used. It doesn't make any sense. Besides, it's not appButton that I'm having the problem with. Telling me to add thigns that I don't understand how to add, then telling me to ponder useless stuff, and in the end telling me what you wanted me to do all along but didn't have the time to actually say doesn't help me at all. Why waste all that time saying useless stuff? If you have some information that could be of help to me, then just say it. I'm not going to sit here playing guessing games. Now that you've apparently made the button clickable without an immediate Nullref, I'd really like to know how you did that. Whenever I click the button, no matter what I put within the "if" statement brackets, all I get is an immediate nullref and nothing else. You somehow got it to send something to the log, but I don't see anything in the code you posted that is any different than what I've already tried. There's got to be more to it.

I shouldn't have to prove that point simply because the check being suggested (and not in terms that I can even figure out how to do) isn't even having to do with the problem I am having. "appButton" is not null, otherwise there would be no button on the toolbar, nor any GUI being rendered on the screen. The button I am using is already inside the GUI window, and renders without issue. The issue is on the action when I click on it, and there's nothing in that which could be null because it's created within the same statement that tells it what to do. If it's null, it doesn't even appear. I can't click on a button that does not appear. - - - Updated - - - [redacted]. It's not doing anything with appButton in that area because it won't even activate anything within those brackets in the "if" statement, as I've been saying this whole time. It can't even get there at all because I've commented all of those commands out and left only a log entry in there to see if it was working and guess what? I got no log entryand a nullref instead. This has nothing to do appButton. Even without that in the area, the same thing happens. The button that is clicked on from the bottom of the GUI WINDOW is the problem, not "appButton." [redacted] my log entry code, I've been using it for weeks with no issue, and lo-fi or any of the others that are working on this mod and compile it from the github source could tell you that they work perfectly fine. It's the button itself, when clicked, that gives a nullref. "appButton" has nothing to do with it. In fact, the most recent edition of that code doesn't even mention "appButton" at all.

What the HECK are going rambling on about? Do you really take me for a complete idiot? Two "KFGUIManagers" ?? You've got to be kidding me. There is only one KFGUIManager class in the entire project. I am not going to create two versions of something and then complain that it doesn't work. I'd have to be a complete idiot. I really don't appreciate bringing these idiotic thigns to my attention when you apparently have access to the code and can see that what you are proposing does not, in fact, exist. I really thought you were more intelligent than that. I'm having a legitimate problem here and you're giving me fantasy. I'll grant you, it could have been destroyed improperly in a scene change, but get this: as the code clearly shows the application-button does NOT get created in a scene where it does not belong and, as I clearly stated, I am testing this in the initial load of the space center after first loading the game. Thus, there has been no other KFGUIManager doing any GUI rendering calls. Now, what is this about "isGUIEnabled" that you're going on about? I'm not having trouble with that. As I clearly stated the GUI will close and open perfectly fine using the AppLauncher button. This is not the problem here. The problem is with a button (as in "GUI.Button()" and not the "appButton") inside the GUI window that is labeled "Save and Close" which, when clicked, is not returning it's true state like it is supposed to, which would allow me to execute some commands when it is clicked. Nope, instead it's giving me a NULLREF error in my log and ignoring everything between the braces of the "if" statement it's running in. Is this some strange coding on my part that is simply not correct? NO, because it's identical to a line of code I copied from another mod that I know for a fact WORKS! So far, my impression of your "power of deduction" is that you need to get a tune up. Stop deducting and start reading the post so you know what the real problem is instead of spouting out completely insane ideas that are not even valid in this situation. Also, as I have told you before, I'm really not fully educated programmer, otherwise I likely would have this stuff working perfectly as of weeks ago. That being said, I have absolutely no clue where you want me to stick a null check, nor what I'm supposed to be checking for this null state. So no, I couldn't take two stupid seconds to do something that I have no idea how to do! If you're here to help, then help, and stop giving me all this stuff about things that don't even apply in this situation. I simply cannot believe this. All I want is the stupid button to do what it does in every other mod I've looked at which uses a button in the same stupid way, and I'm being told I have duplicate instances of things running when the game only just started, and only just loaded the first toolbar it was about to create. Insane. Is there anyone out there who can actually help with the real problem here instead of everything but the real problem?

What I always did was this: take the original texture and extract the regions I want colored into new layers. I then filled the background with black and removed the original layer that I extracted everything out of. I then filled the regions of the other layers that were to be paintable with Red, Green, or Blue for the primary, secondary, and tertiary colors, respectively. I then set the layer modes to "additive" and merged them all on top of each other, and then merged the result onto the black. This created an image that had the three colors, plus the additive colors for overlapping areas of the original texture. For example, a region of the image which would take a value from all three color layers would appear white in the final image. In the end, save as a PNG in the folder where the rest of the masks are kept, rename it to remove the file extension so KSP doesn't load it up itself (KerbPaint does this itself) and then enter it into the config like you've already done. If this is done properly then, in theory, it should work fine. One thing to look for, however, is that KerbPaint might already have an MM patch that is putting a mask on the part. You may need to seek that out and either replace the mask it references with your own and scrap your own patch, or comment the KerbPaint patch for that part out so it only uses your patch. A third option is to format your patch as follows: @PART[mk1InlineCockpit]:AFTER[KerbPaint] { %MODULE[ModulePaintable] { %name = ModulePaintable %Texture = mk1InlineCockpit_paint %Shader = BumpSpec %DeepReplace = true } }This tells the MM patch to replace the module of that name, and all the parameters as well. If any parameters are not found, they will be added. Likewise if the module by that name is not found, it will be added. Finally, the tag at the end of the top line ":AFTER[KerbPaint]" ensures that it runs after any KerbPaint patches have run. Hopefully, that covers it.

If appButton were null, then I wouldn't get a button on the toolbar, nor would I ever even get a GUI in the first place. Nowhere in those messages in the log does it say that appButton is false, besides the state of appButton does not define whether or not the GUI element inside the GUI window is an instance of an object or not! all appButton does is define what the button is for the toolbar. At this point, our absolutely not null appButton has already put a button on the toolbar and the GUI has been called. Can a null object do that? I think not. If I were testing this outside of the scenes that allow for the GUI to exist, then I would be doing something that is completely and utterly impossible. The button only spawns on the toolbar if we are in a scene that is specified in the button's defined visible scenes. it is destroyed when the toolbar destroys itself (between scenes and whatnot). However, to answer the question, I am launching the game, going to my saved game which takes me to the space center, clicking the button for the KF GUI to open, then clicking my button inside the GUI to "Save and Close" and that is all. Art assets are all in the other repository where our source used to be. We have a folder named Assets in there, and everything is in there. It shouldn't matter for this button though, it uses art that comes with the game because it's a simple button. It really sounds like you didn't take the time to look at what it going on in there before making a decision about what I'm doing wrong. I didn't say anything about the entire GUI failing to load, I was talking about a button inside the GUI. And by GUI, I mean our GUI, which I couldn't be talking about if it wasn't even loading (in the case of appButton being null). EDIT: I did a little research on the Unity API documentation and even their tutorial button code looks exactly like mine, which just makes this even more weird that it won't work for me. - - - Updated - - - What now? Oh, is that the part that he used transforms to define the nodes in? yeah, so, if you were to define the nodes in the format that other parts tend to use, and strip out the transform nodes, it will simply use that form of node instead. The only reason for editing the model again is if you still want to use the transforms to define the nodes. My understanding is that the nodes are now much more strict about the orientation of a node when compared against the orientation of the connecting node on the other part. This could be nice when dealing with parts that have no attach node defined and are not capable of being attached radially. For instance, issues with really small engines being stack attached to a large fuel tank, you have a lot of issues with the engine wanting to snap to the bottom node with the bottom node of the engine, instead of attaching with the top node, and ending up inside the tank. I'm unsure if this was what they were going for, nor if it was successful, but that would make sense to me.

If I knew that, I might be able to fix it, eh? It's very vague. From the log: [EXC 12:38:27.261] NullReferenceException: Object reference not set to an instance of an object KerbalFoundries.KFGUIManager.DrawWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) From the output_log: NullReferenceException: Object reference not set to an instance of an object at KerbalFoundries.KFGUIManager.DrawWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1) These entries tell me absolutely nothing! all it's saying is that there's a problem, but the code is EXACTLY like that of another mod which works PERFECTLY in relation to the button. I need MORE than just a message saying "it's borked, do it right next time!" if I'm going to make anything work. I'm not trying to freehand code this thing, I copied and pasted it from a functioning mod with absolutely no extra defines or using directives that would be needed for a simple button to work! I'm not jsut spouting off after a single attempt either. This is at least two days of trying various thigns over and over and over and over. This is completely and utterly stupid!

You mean the stock nodes? There was some change done to that system a while back, though I don't see it affecting the wheels and such so I don't know how or why. I do know that there were some orientation values that had to be flipped from positive to negative after KSP 1.0 released for them to function correctly, but I haven't read any documentation about that change. On that note, someone finally revamped parts of NodeHelper and got it released for the current game version, which means I'll be able to go in and visually diagnose node errors. It probably still suffers from the inaccuracies between the numbers and how the part actually gets loaded, but I think I figured out how to do a little math and get around that problem by finding the difference between the original and new numbers from NodeHelper and then applying that difference to the original numbers from the config. I don't know why, but NodeHelper does not report back the proper node locations when it accesses that data from the part itself, and if you use the numbers in the output from NodeHelper, upon reloading the game the nodes will be really whacky. In other news... I'm having a real problem with the GUI again. I added a button to the bottom, again using another mod as a template. I've checked and rechecked that no separate definitions or "using" statements are different between the files, and copied the original code that simply checked the state of a button and executed a command when it was pressed. i added that in to our GUI and set it's text to "Save and Close" and then, when the "if" statement found that button to be in a "true" state (which is returned when it is pressed) it then sets the variable "isGUIEnabled" to false, which should cause the next check that the game does to OnGUI() to hide the GUI, and then makes a call to "KFPersistenceManager.SaveConfig()" in the exact same manner than the "onFalse" method does it. I then added a debug log entry to that "if" statement to make sure that the stuff inside it was actually being called properly. In-game I get no debug log entry, no configs saved, and no closure of the GUI. All I get is a Nullref error in my log. I re-checked my template mod, which I have tested to make sure it works, and it does. So, I have no idea what is wrong with my implementation of it. There's literally no difference other than the names of the methods to match the mod except that in the template mod the config saving method is held within the same class. Considering it seems to not even be activating the button properly, I don't see how the stuff I'm telling it to call have anything to do with it since it's not calling them. Why must everything be so screwed up all the time?

Indeed, that would be awesome. Wouldn't be too usable in daily Kerbal-killing.... errr.... scientific adventures.... though. Hey, another thing I thought of: fixing up the cargo hold of the rover body to properly shield interior parts might be something to look into in the future. I mean, the likelihood that someone will re-enter with the rover body as the main hull is slim, but you never know.

Well, that's doubtful to be fixed officially anytime soon. You'll notice that the icon problem seems to mostly affect KF tracks, with maybe a few outliers in other mods here and there, but it's a very rare occurrence. In fact, the only log entries I get from the icon fixer mod are related to KF. With the move to Unity 5, perhaps there's something new in there that could be useful here, but that also comes with a change to how wheels work at the core which could provide its own issues to tracks and such. Anyway, looks like the part icon fixer is still needed then.

A similar packing system could be used to create a craft capable of carrying lots of small satellites for a mission that aims to pass by multiple bodies in need of mapping. I've been trying on and off to make something like that where the probes could go out, map a body, then be picked back up when the craft makes it's return trip.

Dat be one purdy plane thingie.

Totally didn't see this post before making my own post about it. I look forward to seeing that. It's unfortunate, but we're going to get more and more reports of the part icons being messed up as more people start using this mod, despite any OP warnings. I expect any days now we'll get two reports in the same page too, cause people don't tend to read backwards much. I'm guilty of that as much as anyone. I wonder if fixing the issue with the size report will also fix the problem with the part icon...