bac9

For the first issue, no idea, but make sure you don't have Kronal Vessel Viewer installed, it can cause similar issues. For the second issue, those are DXT compression artifacts and they are completely unavoidable no matter the source format. The game is not using your textures at runtime, be it MBM, PNG or TGA - instead, everything is converted to DXT format understood by your GPU, and that format has lossy compression.

I don't remember anything like that in B9 gears.

They have simply integrated this system with no apparent changes: http://forum.unity3d.com/threads/highlighting-system-released.143043/ It's probably well documented and described in that thread.

Welp, this looks fundamentally broken no matter what numbers you output as dimensions. Can't help with it, sorry.

Version 0.31 Fixed a bizarre issue with font type randomly swapped by KSP, breaking layouts in the custom menu. Font reference used by all styles is now independent from KSP. Added a part size interface to feed the career editor info about the wing dimensions (why it's incapable of doing it by itself is another question). Axis order is undocumented so I don't know whether values I output go into the right directions, needs testing. Fixed some smaller UI issues Added a DRE module with uniform reflectivity of 0.25 until DRE implements per-axis shielding to allow protection to be dependent on how you configure the surfaces Fixed the part descriptions - - - Updated - - - That's insufficient, all non-wing parts must have attachment nodes placed on the bounds of a part in such a way that an averaged position from all nodes arrives into the center of a part, - otherwise occlusion checks would produce incorrect results. As I allow thickness adjustment, you can't just add two nodes through a config either. I'll look at it later, it must be supported from the plugin.

Woah, thanks, that's pretty bizarre. Why aren't they simply using renderer bounds Unity already provides in a precise and consistent way? That's a rhetorical question

Ah, so it was in a part description. I thought you were talking about descriptions in the window so I only looked for it in the code. Will change that next time then.

We don't need to mod them, we need a name of a method that updates the dimensions, I think. After getting it, triggering it through reflection _after_ all geometry for procedural wings is constructed would be pretty easy and would fix the issue. The release screenshot is also made on 0.30, and everything seems to work there. Make sure you're not alt-tabbing on load, this breaks KSP texture loader sometimes.

If you want to make the wing 1 meter wide before it's even attached and sits in the catalog or in the air, it's impossible - I don't have access to geometry at this point. 4x4x0.24m is the size of the original model, and only when it's attached, it is distorted into a new shape according to parameters you set. You can change default parameters to whatever values you want using the appropriate button in the menu. There are no invisible colliders or anything like that floating around from the original shape, though, and I correctly recalculate mesh renderer bounds and colliders on every geometry change, so this erroneous readout is entirely on KSP and I very much doubt that changing the size of the original model can fix this issue.

Version 0.30 Shape match now calculates tip width relative to proportions of parent wing part (credit for the solution goes to ferram4) Shape match now calculates tip offset which in combination with automatic tip width option allows you to perfectly match sweep angles between wing pieces. Split the shape match button into three separately invoked options - sweep match, width match and edge match. It is now easily possible to make a section in the middle of a multipart wing have smaller tip/root width without stopping it from having sweep angles perfectly matching it's parents. This makes it easier to make wings with inserted control surfaces on the leading and trailing edges Minor UI fixes- - - Updated - - -

It's a config value that is only taken into account on initial load of the part, so as far as I understand I can't disable it in VAB or enable it only in SPH - it will have no effect.

It's impossible to fix it, mirror symmetry I'm using in SPH is done by KSP, not my mod, and it will invert whenever it wants as you rotate the craft. Unfortunately, there is no proper mirror symmetry that works with VAB. I'm afraid you'll have to make the shuttle slightly tilted in the VAB to stop KSP from misunderstanding the desired mirroring axis.

Unfortunately it's impossible to change that without completely redoing how wings are shaped (I will need two semispan parameters and two offset parameters, which breaks parameter reuse with control surfaces and is not compatible with current geometry handling on wings). I can only suggest using the rotation tool from updated 0.90 editor to make the origin segments assume the rotation you want.

Glad to hear it works for you, although I'm suspicious about those struts. Two-piece wing like that should not need any struts to work properly without significant bending. Either struts aren't necessary, or there are some serious issues with how joints on my wings are set up. I'll take a look at making a method that auto-calculates appropriate offset and tip with to match sweeps of a given parent. I'm not sure what counteraction are you talking about.

To be honest I strongly dislike pwings-style abstract multipliers in place of objective thickness measurements so I'd prefer not to go that route. I already provide tools that allow you to quickly match thickness (and other parameters) to those of a parent, making modular wing assembly pretty easy and fast. Doing things like forcing the upper thickness limit from the parent tip thickness, though, I feel, would be potentially problematic for many designs. It's logical when you attach your next wing to the tip cross section of another wing. But what if you're adding a perpendicular tail? Or small protrusion with an internal fuel tank, or an aerodynamic drop tank? The code has no way to know the difference, and forcing some changes to thickness setup would be pretty irritating to users in the latter cases. I'll look into it. Initially edges were using a multiplier dependent on the thickness of the wing to make them proportional, but that approach was extremely inconvenient when you wanted to match multiple wing segments and control surfaces together, since edge length jumped all over the place with unsightly distortion and non-obvious origin. I feel that, just as with thickness, making the user set an absolute width like 0.48m makes things look nice and makes editing more simple. I'd like to come up with a way to dynamically change field limits first, though - I don't want to allow two meter long trailing edge on a wing that is eight centimeters thick, just like I don't want to allow sixteen meter offset of the wing tip for a wing that is just fifty centimeters wide, and so on. Once that is in place, I can allow higher limits for bigger wings without enabling silly stuff with smaller wings. It's not possible to keep edges nice-looking at an arbitrary width too far beyond 0.24-1m so I can't do that. The purpose of the flat section of a control surface is to allow the edge to keep vertical component of texture coords completely fixed by taking most width away from edge geometry. Edge texture coordinates are very complex and unique on most vertices, making it an extreme hassle to remap them procedurally anywhere but on the U axis. Also, take a look at the edge texture - it's never supposed to be tiled vertically, so surface-like tiling is out of the question even if I write some kilometer long algorithm that can remap hundreds of vertices on arbitrary edge models. So yeah, split between flat section and trailing sections on control surfaces is a necessary evil and there to stay.

Unfortunately that's impossible, I'm is using up everything you can possibly access per-vertex (RGB vertex color, A vertex color and even both channels of UV2), so adding adding highlighting is not possible - there is no variable available to pass info on which areas are highlighted to the shader. Thanks, I'll fix that.

Successfully tested proof of concept implementation of changes to DRE that I need to add proper shielding support to the wings. Just reflectance, but same thing can be done for ablation pools or whatever else. Details here, hopefully Starwaster will be interested in adding that to DRE. http://forum.kerbalspaceprogram.com/threads/54954-0-90-Deadly-Reentry-v6-4-0-Jan-20-2015?p=1692671&viewfull=1#post1692671

@Starwaster I implemented some changes I suggested in this post some time ago: http://forum.kerbalspaceprogram.com/threads/54954-0-90-Deadly-Reentry-v6-4-0-Jan-20-2015?p=1656547&viewfull=1#post1656547 I only did reflectance as a proof of concept, but exactly the same approach can be used to add per-axis ablation. I tested the implementation, it seems to work correctly, giving properly changing degree of protection depending on your orientation and multiple reflectance values. Here is an illustration of the general idea: Here is how module config can look: MODULE { name = ModuleHeatShield direction = 0, 0, 0 // ignored if reflectanceDirectional is present and correctly set up, otherwise used as fallback reflective = 0.25 // ignored if reflectanceDirectional is present and correctly set up, otherwise used as fallback reflectanceDirectional = 0, 0, 0.5, 0.05, 0.1, 0.25 // X+, X-, Y+, Y-, Z+, Z- } Here are some additional variables I added above your KSPFields: [KSPField (isPersistant = false)] public string reflectanceDirectional; public float[] reflectanceDirectionalArray = new float[6]; public float reflectanceDirectionalAverage = 0f; public bool reflectanceDirectionalUsed = false; Here is your Start method with additions to parse the new parameter into an array of per-axis reflectance values: public override void Start() { base.Start(); if (ablative == null) ablative = "None"; if (reflectanceDirectional == null) reflectanceDirectionalUsed = false; else { reflectanceDirectionalUsed = true; string[] reflectanceDirectionalStrings = reflectanceDirectional.Split (','); if (reflectanceDirectionalStrings.Length == 6) { for (int i = 0; i < 6; ++i) { try { reflectanceDirectionalArray[i] = float.Parse (reflectanceDirectionalStrings[i]); } catch { Debug.Log ("DRE | Directional reflectance value is not a float, parsing failed at " + i); reflectanceDirectionalUsed = false; break; } } } else { Debug.Log ("DRE | Incorrect number of values (" + reflectanceDirectionalStrings.Length + ") was used to define directional reflectance"); reflectanceDirectionalUsed = false; } } // rest of the stuff involving conductivity and shielding // no changes there } And here is your AdjustedHeat method with simple changes to use the resulting array in rad calculation: public override float AdjustedHeat(float temp) { if (!reflectanceDirectionalUsed) { if (direction.magnitude == 0) dot = 1; else dot = Vector3.Dot (velocity.normalized, part.transform.TransformDirection (direction).normalized); } else { float dotXPos = Mathf.Max (Vector3.Dot (velocity.normalized, part.transform.TransformDirection (Vector3.right)), 0f) * reflectanceDirectionalArray[0]; float dotXNeg = Mathf.Max (Vector3.Dot (velocity.normalized, part.transform.TransformDirection (Vector3.left)), 0f) * reflectanceDirectionalArray[1]; float dotYPos = Mathf.Max (Vector3.Dot (velocity.normalized, part.transform.TransformDirection (Vector3.up)), 0f) * reflectanceDirectionalArray[2]; float dotYNeg = Mathf.Max (Vector3.Dot (velocity.normalized, part.transform.TransformDirection (Vector3.down)), 0f) * reflectanceDirectionalArray[3]; float dotZPos = Mathf.Max (Vector3.Dot (velocity.normalized, part.transform.TransformDirection (Vector3.forward)), 0f) * reflectanceDirectionalArray[4]; float dotZNeg = Mathf.Max (Vector3.Dot (velocity.normalized, part.transform.TransformDirection (Vector3.back)), 0f) * reflectanceDirectionalArray[5]; reflectanceDirectionalAverage = dotXPos + dotXNeg + dotYPos + dotYNeg + dotZPos + dotZNeg; } if (canShield && temp > 0) { float rad = 0; if (reflectanceDirectionalUsed && reflectanceDirectionalAverage > 0) rad = temp * reflectanceDirectionalAverage; else if (!reflectanceDirectionalUsed && dot > 0) rad = temp * dot * reflective; else return temp; // rest of the stuff involving ablation // no changes there } return temp; } } I think implementing this is pretty simple and doing so will not break thousands of existing configs in any way, since the implementation only kicks in if relevant values are explicitly defined. P.S.: Slightly different, potentially more performant (in most use cases) and more flexible approach would be to use an array of Vector4 values (where XYZ is direction and W is reflectance - or, well, Vector3+float pairs, to avoid inconveniences when XYZ has to be normalized for use in a dot product without touching reflectance in W) of an arbitrary size so that you can define only directions that are relevant to you. Example above can be considered a special case of that approach, with six vectors being implicitly defined for you (Vector3.up and all that) and six floats attached to them being parsed alone, but it's pretty much the same approach. In case of a wing, only Y+/Y- and Z+/Z- directions are relevant and cross section directions are not (if you have them exposed and facing prograde, you don't really get to complain about the shielding). Finding sum of all dot x reflectance values for an array of four pairs would be faster than finding sum from per-axis checks I posted above. Some parts might warrant only three vector+value pairs, which will be even faster. Some parts (dunno, maybe some ultra-realistic configuration of shielding on a Shuttle replica) can use an array of, say, 12 pairs to get very detailed gradients of shielding on some intricately covered nose piece. Everyone is happy. Only thing a bit more inconvenient is parsing that array from the config, but I don't think it will be an obstacle.

I don't use it myself, but wasn't Kerbalstuff supposed to add any mod from it to that database?

Is it possible to use this mod to revert to pre-0.90 part order in the catalogs? Config name based sorting drives me insane, old sorting that was using folder names was far more convenient, leaving mods grouped together.

Version 0.28 Unresponsive field group headers fixed Field values in the new UI have contextual format (material reads "HRSI" instead of "4.000", edge shape reads "Biconvex" instead of "2.000" and so on) Cost interface returns values based on part dimensions now Cost interface stops adding fuel setup cost if RealFuels take over that functionality Multipliers used in dimension-based cost calculation are now exposed in the configs KSP API Extensions dependency removed since tweakables are no longer used _______________________ Version 0.29 Fixed a potential issue with fuel tank cost calculation causing NRE on part attachment

Goddamn it :^) I can not reproduce the issue with groups not opening, something else is at play, but labels are removed now. Version 0.27 Fixed default visibility state of part properties to prevent them from appearing in the context menu as uneditable labels

Version 0.26 Whoops, fixed wing properties not being correctly loaded and saved Edit: Whoops again, uploaded 0.25 without the .dll itself :^)

Version 0.24 Fixed the KSC scene configuration menu not initializing it's style properly Full wing volume no longer used to determine fuel tank size - trailing and leading edge volume almost never contains them, so their contribution is removed now Shape and material controls removed from the tweakable menu, now editable only through the new UI

Well, they are not exactly modelled as 2d surfaces, equations use a certain profile, I think. It just can't be adjusted from the wing config.