xEvilReeperx

The game normally loads all the textures it can find when it starts but there isn't any reason why you couldn't load a new one afterwards (see Resources.Load (closer inspection indicates WWW or Texture2D.LoadImage would be more likely)in unity's online docs) if you have a use case for it

Does the log show any errors? Specifically any of the following: Failed to locate NavBall GameObject. NavBallTextureExport might be out of date! Failed to import new navball texture, even though it appears to exist! an exception right after "Did not find custom NavBall texture; creating a copy of the default" Did you rename the folder? Currently the mod looks for a folder named "NavBallTextureExport" in (KSP_Root)/GameData/. I'll fix that in the next release; there's really no reason why you shouldn't be able to rename it if you'd like.

I want to say I've seen something similar in the MJ code. Let me have a look... Here we go. That sounds like exactly what you're after (read comment).

Thanks for the report. The log was very helpful. Download has been updated.

Define "target node". You want to place a maneuver node on a particular position on the planet? I have yet to find a way to position maneuver nodes off of a given orbit path. Temporarily modifying an orbit works but it's hacky and not all the time. If you want to position a maneuver node such that executing it would result in the vessel's orbit intersecting a position on a body, you might want to look at the source to MechJeb.

Try this version. I'm beginning to suspect a system issue. It might explain why the texture is strangely flipped. What OS are you running on?

Are you sure you got the very latest version? I didn't notice the error when I posted it the first time, took down the download temporarily and replaced it with a new version (same zip name). The currently listed ivaFixed download is the fixed version Yes, mostly Unity. The online documentation is pretty good

It's as straightforward as the flight NavBall. But it's a lot darker (flipped texture already fixed). We've got a couple of options though, if something needs to be done We could enable separate textures for iva and the regular NavBall We could tweak the actual material (how the texture is displayed). Brightening it with a shader, for instance Option 2 with a basic emissive shader brightening the whole thing: It's nothing special, but it also doesn't require anything special. We could probably improve it somewhat with a custom shader. Option 2 with an emissive shader with an emissive map would look like this: It's much more visible, but it requires a second texture to define the "bright" areas and so is slightly more complex

Your class inherits that variable (and lots of other variables and functions) from its base class PartModule, which itself inherits some variables and functions and so on

When you create LineRenderer, its useWorldSpace property defaults to true. Guess what the Unity docs say about it? So that's why it's not going anywhere. line.useWorldSpace = false should fix it. As an aside, why create a new GO and destroy the old one every loop? If you create your debug line in the Start() function of your PartModule and attach its transform to your parent (obj.transform.parent = part.transform), you won't need to update its position every frame. It'll be handled for you.

No, you found the right one. I specify the class name when describing a function because whatever you're working with might not have a variable named "part" in scope (a simple MonoBehaviour working with a vessel, for example). Sorry if that caused any confusion. I'll try to be clearer in the future.

Great, I'm glad it's helpful!

I wasn't trying to be condescending. I was trying to tell you why you didn't receive an answer instead of cold shouldering you like everybody else did. Read your post again from my perspective. Only the rootPart's transform does. You're going to need to show some code to get any help. Whatever it is appears to be wrong and leads you to wrong conclusions

I had a few minutes to look into this and slapped something together for you. Download Version 1.5 (for KSP 1.2+), see repo for previous versions Source License: MIT How to use it: Unzip into KSP root dir Run the game. Enter flight scene with something The plugin will save the default NavBall texture to disk at (KSP_Root)/GameData/NavBallTextureChanger/Skins/stock.png Optionally enter IVA view of something with a NavBall to get a copy of the stock emissive texture Exit KSP. Edit the config file inside NavBallTextureChanger/PluginData/NavBallTextureChanger/config.cfg to your liking. The texture urls can be fully qualified or relative to the skins directory. They are extensionless filenames. For example, if you put your custom skin inside the skins folder and called it "mySkin.png", you would set TextureUrl = mySkin or TextureUrl = NavBallTextureChanger/Skins/mySkin The texture will replace both the flight and IVA view unless the appropriate option is disabled The stock IVA navball uses an emissive texture to make it a little more readable. You can edit the color (RGBA, floats) and/or supply your own emissive texture. Changelog 1.5 - Updated for 1.2 1.4 - Updated for 1.1.2 1.3 - Fixed a rare bug somebody had once; removed some debug code that caused unnecessary log spam each time the plugin loaded 1.2 - Fixed an issue that caused only a single instance of the flight and iva NavBall to be changed 1.1.a - Fixed working directory issue when KSP is launched by an external program. Folder can now be renamed and/or moved anywhere, as long as it's under KSP's GameData dir 1.1 - Fixed issue preventing NavBall texture from being changed if the vessel doesn't have an iva view 1.0.a - Now includes iva 1.0 - Released

It might be as simple as finding the NavBall GO's renderer, saving the mainTexture to disk, editing the texture, and finally using your plugin to change the navBall texture on any flight scenes. You'll need to write a plugin to make this work however.

Sometimes nobody answers because it's apparent you didn't bother to try anything or look anything up. Google: Unity transform, get result Part.transform.position is your answer

If you're looking for a particular transform in the Part's model hierarchy, there's Part.FindModelTransform and Part.FindHeirarchyTransform. There's also findAttachNode(string), although I seem to recall having some trouble getting that one to work in the past. Part.transform.Find may also work. Just in case you get thrown a curveball, something to check is whether the above will return transforms outside of the part's normal model hierarchy. For example, your part (near the top of the vessel tree) connected to a child octostrut. The octostrut doesn't have physics of its own* when attached to a parent that does, so it's possible that the above functions (minus perhaps findAttachNode) will also search the octostrut's model which is probably undesired. Using the part's prefab hierarchy instead should solve that if it does come up *has no rigidbody nor joint and instead its transform becomes a child of the part's transform

I can't speak to the IR code, but in the case of engine fairings they're attached as children of the part's transform. You can get their MeshFilters with a Part.FindModelComponents<MeshFilter>() call. The gameObjects they're attached to will have the tag "Icon_Hidden". I forget if their renderers are disabled or if the GO they're attached to is inactive but it shouldn't be too hard to figure out

Submeshes with a SkinnedMeshRenderer will have empty (unused) MeshFilters. My money's on that

Well, it does work in the version of MonoDevelop I have (4.0.1) but for some reason you can't expand results you get from a search. Still, if you're set on using it over VS express then you can make it work. Assuming you've added references to the right KSP Mono DLLs, you can open the object browser in MonoDevelop by using the menu View->Assembly Browser. Most of what you're be looking for will be in the Assembly-CSharp assembly. If you're looking for something in Unity, a quick google to find the wiki page on it is more informative than looking into the UnityEngine assembly yourself

1000/12 = 83 per second

Well, it's technically (but unlikely) for an unloaded vessel to become loaded while your skycrane is flying under exactly the right circumstances. How about instead of iterating through all vessels everywhere, create a cache of vessels with the same mainBody as your vessel. That could cut down your list considerably while not creating (very unlikely) edge cases where you could miss one.

This will compare vertical directions of a part and its parent (partially tested): double cosineAngle = Mathf.Rad2Deg * Math.Acos(Vector3d.Dot(part.transform.up, part.localRoot.transform.up)); if (cosineAngle > 180) cosineAngle = 360 - cosineAngle; if (cosineAngle > 90) cosineAngle -= 180; // angle is in range of [-90, 90] if (Math.Abs(cosineAngle) < 30d) // ... within 30 degrees of parent's up/down axis It might not be exactly what you're looking for though. An octostrut placed on the side of a fuel tank would work like you'd expect. A fuel tank radially attached to another fuel tank, though, will still be considered "vertical" (assuming default orientation).

Although they're occasionally useful, I personally find using an object browser (VS's built-in one works great, MonoDevelop is also capable) to be much better than the XML docs. Most events you might be interested in are located in GameEvents

Well, exporting the actual geometry of the vessel is quite straightforward. But it's probable you'd have to do some clean up in a modeling program yourself before it could be submitted to Shapeways. Automated tools can get it wrong. For instance, I exported this (using a plugin I hacked together in a couple of minutes and some copy+paste code from the Unity wiki): But it has some issues. For an obvious one, there is no face on the bottom of the launch clamp bases: There isn't a need for there to be since no user would ever see it as it's mounted to the ground, but for printing that's an issue. I ran it through cloud.netfabb.com and while I have to say the results were much more impressive than I thought, there would still be a serious problem: You can see their tool removed the section of the radial decoupler that attaches the side tanks to the center, so the vessel is now visually in three separate pieces. The tool actually broke it into a total of 15 separate meshes; probably not a good thing when you want it to be all one object. It's a cool idea but I think in this case some modeling experience will be necessary for good results. These meshes were designed with rendering and not printing in mind, after all