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

[Gaalidas]

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?

Edited July 18, 2015 by Gaalidas

[lo-fi]

Could be some things a litle bit earilier in tech tree? cause for career most of them are in last thier of science-bulding so its laaate game some small tracks or something

To be honest, up until this point I hadn't even given it any thought. It's one of the milestones to be addressed for next release, though

Really interesting looking through the fault finding stuff - thank you! I'll wade through and see what sense I can make of it when I have a bit of time.

I have another crazy idea... Must. Not. Get. distracted!

[Gaalidas]

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?

Edited July 18, 2015 by Gaalidas

[lo-fi]

My programmatic education is the fault finding stuff

It's not an easy thing to learn. It's even harder to teach, IMO. But, the penalty for failure is zero, frustration and time aside. Didn't work? Oh well. Research. Add some checks, recompile. Try again.

Thankfully, when I've been really stuck, there have been proper kind enough to point me in the right direction (an enormous debt of gratitude is owed to those people).

I expect there's a more intelligent way of going about it - there usually is. Revisit the Baha code? I believe I removed some extra stuff to do with states to simplify finding what was what.

[Gaalidas]

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!

Edited July 18, 2015 by Gaalidas

[lo-fi]

Chill out, dude, it's no biggie. I think you've got a case of "not seeing the wood from the trees". You're dealing with something quite complex and convoluted that someone else wrote - it was never going to be easy

For what it's worth, I tend to take a different approach: never copy/paste large chunks of code. Ever. A few methods, new stuff you don't know the syntax for, maybe.

Build up in blocks. In this case, the button. Try the hover and colour change stuff. Then the gui rectangle open close methods. When all that works, add in some toggles. In the process you'll learn far more about how the code works and what it does, and you'll be far better placed to debug it.

If I'd copy/pasted the FireSpitter or RBI stuff, I'd probably still be tearing my hair out and no further forward - that's precisely why I didn't do it.

Not that I'm saying what you've done is wrong, it's just a tall order when it doesn't work and you don't know how it works in the first place...

[xEvilReeperx]

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.

Hard to say why the other mod doesn't have problems without seeing its code.

1) Rather than simply run in all scenes and then not do anything on the wrong ones, I suggest you set out to target the correct scenes directly.

2) once you eliminate that erroneous scene, your addon is registering for the GUILauncherReady event too late and missing it. Based on output from the log I posted, I suspect you won't be able to catch it in time with a KSPAddon initialized in the space center. My suggestion there is to avoid using events entirely. Wait (if necessary) for the toolbar to exist using a coroutine instead.

Here's what my version of KFGUIManager looks like with those two implemented; sorry for the odd formatting I'm not sure why the code tags are doing that

public class KFGUIManager : MonoBehaviour
{
    private abstract class GuiRunner : MonoBehaviour
    {
        private void Awake() { gameObject.AddComponent<KFGUIManager>(); }
    }

    [KSPAddon(KSPAddon.Startup.Flight, false)]
    private sealed class RunInFlightScene : GuiRunner
    {
    }

    [KSPAddon(KSPAddon.Startup.SpaceCentre, false)]
    private sealed class RunInSpaceCentre : GuiRunner
    {
    }

    [KSPAddon(KSPAddon.Startup.EditorAny, false)]
    private sealed class RunInEditor : GuiRunner
    {
    }

    #region Initialization
	// AppLauncher Elements.
	ApplicationLauncherButton appButton;
	Texture2D appTextureGrey;
	Texture2D appTextureColor;

	// Icon Constants
	const string strIconBasePath = "KerbalFoundries/Assets";
	const string strIconGrey = "KFIconGrey";
	const string strIconColor = "KFIconColor";

	// GUI Constants
    private Rect settingsRect = new Rect(Screen.width - 258f, 42f, 100f, 100f);

	/// <summary>Local name of the KFLogUtil class.</summary>
	readonly KFLogUtil KFLog = new KFLogUtil();
	/// <summary>Name of the class for logging purposes.</summary>
	public string strClassName = "KFGUIManager";

	#endregion Initialization

	#region Startup


    private IEnumerator Start()
    {
        enabled = false;

        while (ApplicationLauncher.Instance == null || !ApplicationLauncher.Ready)
            yield return 0;

        InitGUIElements();
        appButton = ApplicationLauncher.Instance.AddModApplication(onTrue, onFalse, onHover, onNotHover, null, null, ApplicationLauncher.AppScenes.FLIGHT | ApplicationLauncher.AppScenes.SPACECENTER | ApplicationLauncher.AppScenes.VAB, appTextureGrey);
    }




	private void OnDestroy()
	{
	    if (appButton != null)
	        ApplicationLauncher.Instance.RemoveModApplication(appButton);
	}


	/// <summary>Retrieves button textures.</summary>
	void InitGUIElements()
	{
		appTextureGrey = GameDatabase.Instance.GetTexture(string.Format("{0}/{1}", strIconBasePath, strIconGrey), false);
		appTextureColor = GameDatabase.Instance.GetTexture(string.Format("{0}/{1}", strIconBasePath, strIconColor), false);
	}

	#endregion Startup

	#region AppLauncher Button


	/// <summary>Called when the button is put into a "true" state, or when it is activated.</summary>
	void onTrue()
	{
		appButton.SetTexture(appTextureColor);
		enabled = true;
	}

	/// <summary>Called when the button is in a "false" state.  Saves configuration.</summary>
	void onFalse()
	{
		appButton.SetTexture(appTextureGrey);
		enabled = false;
		KFPersistenceManager.SaveConfig();
	}

	/// <summary>Called when the cursor enters a hovered state over the button.</summary>
	void onHover()
	{
		appButton.SetTexture(appTextureColor);
	}

	/// <summary>Called when the cursor leaves the hovering state over the button.</summary>
	void onNotHover()
	{
		if (!enabled)
			appButton.SetTexture(appTextureGrey);
	}

	#endregion AppLauncher Button

	#region GUI Setup

	/// <summary>Called by Unity when it's time to draw the GUI.</summary>
	void OnGUI()
	{
		settingsRect =
		    KSPUtil.ClampRectToScreen(GUILayout.Window(GetInstanceID(), settingsRect, DrawWindow,
		        "Kerbal Foundries Settings", HighLogic.Skin.window, GUILayout.Width(256f)));
	}


	/// <summary>Creates the GUI content.</summary>
	/// <param name="windowID">ID of the window to create the content for.</param>
	void DrawWindow(int windowID)
	{
		GUI.skin = HighLogic.Skin;

		if (HighLogic.LoadedSceneIsFlight || Equals(HighLogic.LoadedScene, GameScenes.SPACECENTER))
		{
			KFPersistenceManager.isDustEnabled = GUILayout.Toggle(KFPersistenceManager.isDustEnabled, "Enable DustFX");
			if (KFPersistenceManager.isDustEnabled)
				KFPersistenceManager.isDustCameraEnabled = GUILayout.Toggle(KFPersistenceManager.isDustCameraEnabled, "Enable DustFX Camera");
		}

		if (HighLogic.LoadedSceneIsEditor || Equals(HighLogic.LoadedScene, GameScenes.SPACECENTER))
			KFPersistenceManager.isMarkerEnabled = GUILayout.Toggle(KFPersistenceManager.isMarkerEnabled, "Enable Orientation Markers");

		GUILayout.Space(10f);
		GUILayout.BeginHorizontal();
		GUILayout.FlexibleSpace();

		if (GUILayout.Button("Save & Close"))
		    appButton.SetFalse();

		GUILayout.FlexibleSpace();
		GUILayout.EndHorizontal();

		GUI.DragWindow();
	}

	#endregion GUI Setup
}

[lo-fi]

That actually makes it look straightforward!

Although now I need to look up abstract and sealed classes. Always something more to learn!

Edited July 18, 2015 by lo-fi

[smjjames]

I keep getting these symmetry wierdness errors while trying to fix the tracks so that when I push forward (w key), they go forward instead of backwards for some reason.

I think it might be a stock issue though.

Edit: Also, this might be a known issue, the tracks on the inverting tracks disappear when the part starts going off-frame from the central editor window.

Edited July 19, 2015 by smjjames

[damerell]

So, the real question is this: where did we all go wrong?

Not "should I perhaps apologise for saying things like '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.'" ?

[smjjames]

Like Lo-Fi said, you guys really need to chill.

Also, trying to put those tracks on without symmetry doesn't help

Edit: Grrr, un-bork dangit. I wonder if the problem is that they don't have a 'mirror' texture or something.

Edited July 19, 2015 by smjjames

[ZodiusInfuser]

I keep getting these symmetry wierdness errors while trying to fix the tracks so that when I push forward (w key), they go forward instead of backwards for some reason.

I think it might be a stock issue though.

Edit: Also, this might be a known issue, the tracks on the inverting tracks disappear when the part starts going off-frame from the central editor window.

http://img.photobucket.com/albums/v214/smjjames/screenshot85_zpsmblgexyl.png

http://img.photobucket.com/albums/v214/smjjames/screenshot87_zps5zthv4rb.png

http://img.photobucket.com/albums/v214/smjjames/screenshot86_zpsv8otou3f.png

The problem you show in those pictures is a known issue with the KF parts and node attachment. There's a particular orientation the parts need to be set up in Unity for node attach to work in mirrored symmetry, which Lo-Fi didn't know about back when the parts were first created (because the Stock wheels are set up wrong too). The solution is to re-export all the affected parts with the correct orientation, which will break everyones existing craft.

[smjjames]

I'll just have to live with it being borked on one side then. :/

[ZodiusInfuser]

It should be possible to put the strut on in mirror symmetry then the track on each side separately. If this is not the case then I'm not sure what would be causing that.

[smjjames]

It should be possible to put the strut on in mirror symmetry then the track on each side separately. If this is not the case then I'm not sure what would be causing that.

I tried that, it only resulted in the controls being flipped 90degrees so that w and s are right and left and a and d are forwards and backwards. I could try putting the whole unit on individually on each side, haven't tried that.

Also, with the tracks borked on one side, it's unable to turn in place.

Edit: It works, but it's still moving backwards when I press w. I tried flipping the probe core, which works, but now the probe core is backwards.... I could just slap on one that's facing correctly maybe.

Edit2: Any idea how to fix? Putting on a correctly facing core and controlling from there makes it backwards again. I've tried invert steering, but that only inverts left and right I think.

Edited July 19, 2015 by smjjames

[lo-fi]

Really, the stack nodes should not be there. Attach via surface and all will be fine again. Comment the node_stack out of the config of you're desperate! Apologies, it's something that made it into the release before that particular little nasty was found and there it stayed. I can't fix it without breaking every save and craft using the parts, so it's a bit of a tricky one.

The inverting track needs a culling setting changed. My bad, I forgot!

[smjjames]

The Unity 5 release with 1.1 is probably the best opportunity since wheels are changing anyway.

[lo-fi]

That's a fair point, actually. Though hopefully they'll just fix the stupid bug along with that and I won't have to worry

[Gaalidas]

Not "should I perhaps apologise for saying things like '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.'" ?

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.

Edited July 19, 2015 by Gaalidas

[Starwaster]

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.

He GAVE you an answer to your problem. Practically handed it to you on a platter. It's not his fault you didn't understand it.

Everyone of us using the AppLauncher in our mods has had to go through this when KSP updated.

[lo-fi]

I have to agree, I think you're being a bit unfair, Gaalidas. xEvilReeperx was being helpful. I do understand your frustration, but if you don't understand, you need to ask or research. I've been there, trying to understand code written by someone vastly more experienced than myself. It's the best learning tool there is if you can let the frustration go and approach it methodically.

When I've really got stuck, I've usually had to ask. We were lucky enough here to have someone dive in and not only provide an answer, but also try to help teach the diagnostic steps before doing so.. That's not something to pass up!

Now let's move on. As you can probably see, I've not done much over the weekend, which I spent fitting hundreds of large metal tubes into a steam locomotive boiler. I'll get back to it in the week!

[*Aqua*]

@xEvilReaperx

Using inner classes to determine which scene is running is a good idea but IMO it doesn't tackle the real problem: the creation of multiple instances of KFGUIManager.

I guess there are references which aren't destroyed when a scene switch occures. The garbage collector then won't destroy the instance (because it thinks that MonoBehavior is still alive).

I'm in favor of using [KSPAddon(KSPAddon.Startup.Flight, true)] to make sure there's only this one instance of the GUI. Of course I'll need to create and destroy all the GUI and the toolbar button upon each scene switch but that isn't difficult.

I wonder why KSP doesn't force-destroy a MonoBehavior when destroying a scene. That way we would always know about the current state of that MonoBehavior without relying on additional tests.

Edit:

I did it! It turned out that [KSPAddon(KSPAddon.Startup.EveryScene, true)] and subscribing to GameEvents.onGUIApplicationLauncherReady / GameEvents.onGUIApplicationLauncherUnreadifying is all I need to control the GUIs behavior. Why didn't I did it this way before?

Atm I'm tidying up the code and making sure I didn't miss something.

Edit2:

I think I messed up git. Please have a look if everything is still alright.

Edited July 20, 2015 by *Aqua*

[lo-fi]

It's cool, all looking good

I had some changes to merge, which I had to merge with Gaalidas', and then I guess you had to merge yours in. All builds, runs and operates smoothly! Nice one.

I don't know if you saw that we got some answer to my question about GetModuleSize()? Nothing amazingly helpful (in the interface), so I guess the workaround is to set values in the config and pass them back to the editor that way. What an absolute pain :/ Unless there is a way to get data on the proto vessel size when the part is first created... Though that could get messy.

Config updates are the biggest thing now. What an 'orrible job!

[*Aqua*]

Yeah, I read the answers on IPartSizeModifier. Still I have no idea what to do about it. Nathan said we have to return the offset, how do we know the offset? And offset of what, Prefab? Never heard about that.

part.partInfo.partPrefab's + offset = "real" size?

It might be better to just write the right values into part.partInfo.partPrefab (if it let us do it). That way we'll only have to care about that once per game start (KFPersistenceManager can do it) instead of fiddling with the interface.

[Gaalidas]

He GAVE you an answer to your problem. Practically handed it to you on a platter. It's not his fault you didn't understand it.

Everyone of us using the AppLauncher in our mods has had to go through this when KSP updated.

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 have to agree, I think you're being a bit unfair, Gaalidas. xEvilReeperx was being helpful. I do understand your frustration, but if you don't understand, you need to ask or research. I've been there, trying to understand code written by someone vastly more experienced than myself. It's the best learning tool there is if you can let the frustration go and approach it methodically.

When I've really got stuck, I've usually had to ask. We were lucky enough here to have someone dive in and not only provide an answer, but also try to help teach the diagnostic steps before doing so.. That's not something to pass up!

Now let's move on. As you can probably see, I've not done much over the weekend, which I spent fitting hundreds of large metal tubes into a steam locomotive boiler. I'll get back to it in the week!

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

It's cool, all looking good

I had some changes to merge, which I had to merge with Gaalidas', and then I guess you had to merge yours in. All builds, runs and operates smoothly! Nice one.

I don't know if you saw that we got some answer to my question about GetModuleSize()? Nothing amazingly helpful (in the interface), so I guess the workaround is to set values in the config and pass them back to the editor that way. What an absolute pain :/ Unless there is a way to get data on the proto vessel size when the part is first created... Though that could get messy.

Config updates are the biggest thing now. What an 'orrible job!

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.