Ven

Here's the fairing texture base that I used for VSR, All you need to do is change the color(s) of the base layer. I'd suggest scaling the new image to 1024x, but 512x works just as fine. Then convert the texture to DDS with DDS4KSP. http://www./download/73l8ec35pjv7vca/Fairing.zip Oh and a bit of a warning: The stock fairings are locked to diffuse and unwrap unevenly near the edges of the fairing (it's noticeable if you try to give the fairing a consistent pattern). license: This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/.

I can think of two reasons for this: First is that the name = is the same for both the T&R and PoA, which causes problems like this Second, Your 'MODEL{}' or 'mesh =' could be looking for and finding the wrong model. But that's the best that I can do with the information that is given.

That looks like the stock scale bug that may occur if the part uses MODEL{}, has a rescaleFactor or scale other than 1 and is the root part. It looks like the Containers are scaled with the use of too rescaleFactor, so I think that that's the culprit.

Oh, ok. Letting blender/unity converting N-gons to tris is a messy process and honestly, I don't trust either with anything more than a quad. I put this together in the editor with the shiniest texture I could find: I'd suggest that instead of having a single heat-tile, you make a quad heat-tile square for the base, then you can have a bit more variety in tiles, and you avoid messing with the mesh too much. I tried unwrapping your model myself and got a fairly good resolution on the mesh: http://www./download/qo25440ydz9a4an/mk4-16_v2_026_047.blend Oh! and you select Normal inside Transformation Orientation (its in the same bar where you select global or local transform/Edit mode/Viewport shading).

The strange shading is being caused by poor mesh topology. The edges of the model need to flow throughout the model and Ideally remain evenly spaced in order to avoid the pinching you see on the model. Don't make T-vertices (around the heat tiles), they cause lighting errors (in the form of abrupt cutoffs). Avoid making N-gons (more than 5 sided planes) (around the windows) Try to keep everything in quads, this makes editing the model a whole lot easier and prevents the bulk of lighting issues that you are seeing. Anywhom, I worked on the model, cleaning it up by quite a bit, this should show you what I mean: http://www./download/qo25440ydz9a4an/mk4-16_v2_026_047.blend

I don't think that Internal Space is caps sensitive, I've made several successful IVA's with the 'internal space' tag set to layer 20. I just tried overwriting the props directly and after a bit of config editing they load into the game now. The part loader seems to be a picky eater. That's one problem solved, now to get everything pointing in the right direction ( though for the life of me, I cannot figure out if the compass and the altimeter are pointing in the right directions(s), but eh, one thing at a time. Thanks for the help! Just one more thing, my throttle isn't functioning. What does the throttle module look for in the part? (the throttle lever dosn't react to any input, with the keyboard or by clicking. The debug log gives NRE's presumably because It cannot find the throttle's lever). Here's what I get when I expand it: File error: Cannot cast from source type to destination type. at KSPPartTools.BitmapWriter.Write2D (UnityEngine.Texture texture, System.String newPath, TextureType texType) [0x00000] in <filename unknown>:0 at KSPPartTools.PartWriter.WriteTexture (UnityEngine.Texture texture, System.String path, System.String filePath, KSPPartTools.TextureDummy tex, System.String filename) [0x00000] in <filename unknown>:0 at KSPPartTools.PartWriter.WriteTextures (System.IO.BinaryWriter bw) [0x00000] in <filename unknown>:0 at KSPPartTools.PartWriter.Write (System.String modelName, System.String filePath, UnityEngine.Transform target, TextureFormat textureFormat) [0x00000] in <filename unknown>:0 UnityEngine.Debug:LogError(Object) KSPPartTools.PartWriter:Write(String, String, Transform, TextureFormat) KSPPartTools.PartToolsInspector:DrawWriterGUI() KSPPartTools.PartToolsInspector:OnInspectorGUI() PartToolsEditor:OnInspectorGUI() (at C:/Users/Ven/Documents/KsPMAKE/Assets/PartTools/Editor/PartToolsEditor.cs:18) UnityEditor.DockArea:OnGUI()

How do you get the Unity console into verbose mode? I've checked the log several times, and unfortunately most of the parts just have "Cannot find InternalProp 'x'" when they are compiled. There are several more errors that I've found, but they are secondary to getting the model loaded in the first place. (the square button model isn't named correctly in the parts .cfg, for example.) Here's my log file if your curious: http://www./view/0ll23jgoqkaablr/output_log.txt After a bit more testing, It seems that one of the models loaded into the game just fine if I remove the Internal Space layer and loaded it as a part instead of a prop. I also tried to set a stock Unity cube as a prop but that had the same "Cannot find InternalProp 'x'".

Oops, It seems that I did give the navball a DDS texture, Well I guess that solves one problem. Hmm, even after re-exporting most of the models (and caught that a number of them had more than one UV map assigned in blender), They still don't show up.

After Looking through the output_log, I did find a few errors (one of which is below), but most of the problem props lack any sort of description as to why they are failing. (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) File error: Failed to read past end of stream. at System.IO.BinaryReader.ReadByte () [0x00000] in <filename unknown>:0 at System.IO.BinaryReader.Read7BitEncodedInt () [0x00000] in <filename unknown>:0 at System.IO.BinaryReader.ReadString () [0x00000] in <filename unknown>:0 at A..ReadTextures (System.IO.BinaryReader br, UnityEngine.GameObject o) [0x00000] in <filename unknown>:0 at A..ReadChild (System.IO.BinaryReader br, UnityEngine.Transform parent) [0x00000] in <filename unknown>:0 at A.. (.UrlFile ) [0x00000] in <filename unknown>:0 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Model load error in 'F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\VenStockRevamp\Squad\Parts\IVA\Props\Navball.mu' And when I re-export the nav-ball in Unity it gives me this: File error: Cannot Cast from source type to destination type. at KSPParttools.BitmapWriter.Write2D (UnityEngine.Texture texture, System.String newPath,TextureType) [0x00000] in <filename unknown>:0 I might just try re-exporting all of the models and re-do the unity setup for this one.

I've come across a problem that I can't seem to solve, I've created a new set of props for IVA's but more than 2/3 of them fail to load ingame. In the debug log I get this: [Log]: Cannot find InternalProp 'RadarAltimeter' I don't know what is causing this, It's even more confusing when other props set up in a similar way show up fine. The PartTools exporter isn't showing any errors either. I have a feeling that it's something really simple too. Anyways, Here's the prop setup and config setups (Using ModuleManager, the first is the MM edit, the second is the final config) @PROP[RadarAltimeter] { MODEL { model = VenStockRevamp/Squad/Parts/IVA/Props/Radargauge } } PROP{ name = RadarAltimeter MODULE { name = InternalRadarAltitude indicatorName = indicator increments { inc = 0, 0 inc = 34, 100 inc = 70, 200 inc = 110, 300 inc = 145, 400 inc = 180, 500 inc = 215, 1000 inc = 232, 2000 inc = 250, 3000 } } MODEL { model = VenStockRevamp/Squad/Parts/IVA/Props/Radargauge } } This is the exported Unity Package File Thanks for reading!

That sounds like your suncatcher (or whatever you called it) isn't pointing in the correct direction. The Z+ axis is the direction that it'll detect the sun:

Does this happen in all IVA's or just the mk2? Does this occur consistently (even after a restart)? What other mods do you have installed? This is more likely an issue with RPM than anything else, I haven't modified either the MK2 nor it's IVA. I'd suggest poking around there for this problem (and include the answers to the questions above with a debug log).

I just complete them manually, I find it simpler that way.

I think that you need to just scale up the line object a bit, extending it past your target transform may just work.

I'm not quite sure what you mean by the complex animations bit but here's what I've gathered about solar panels: The parts rotator and those parented to it are just the panels themselves and don't do anything for the panels sun tracking abilities. If you want to see multiple working solar panels in action (also: nearly every part in the game) , download my VSR master folder here. Though it is 1.2Gb so... fair warning! Hopefully this helps in some way!

I think that the problem is being caused by the scale of my parachutes (their models), when interacting with the 'ModuleAnimation2Value' Module. When these modules are removed (with the use of //) the canopies return to normal. Otherwise I believe that VSR parachutes are otherwise the same as their stock counterparts. :/ However, by adding realchutes, the problem is entirely circumvented. I tried them out and I cant seem to find your problem. Are they receiving light from the wrong angle or something? It's safe to delete everything that is replaced, but it is easier to use the provided pruners (even when they are a bit out of date). The RAM estimate I gave was a very... conservative measurement, I don't trust Task Manager that much. You'd just need to delete the entire line to remove it. I've just updated the link, reducing the offset by a large amount (the 1-2 is now 0.07 instead of 0.2, and the MK1 is even less). I've added the offset to get around the removal of the offset of the escape tower (as having an offset on the tower itself led to explosions), plus it lends a little bit of realism to the pods themselves. The offset on the Stayputnik just moves the CoM closer to the center of the sphere.

Another solution could be with a special shader that dynamically alters the base texture (note: not the actual model) ingame. Example: Things like scorch marks, dents, scratches and glass cracks could be shared across all parts to save space; granted that'd require a lot of specific materials or a config nightmare to get working correctly.

What solar panel? Are you using the Pre-released version or the released? The one that I linked is a more recent version, I don't bother to update things like the version number until it's finished.

What are gimbal cylinders? Hydraulic pistons or something else? What small details have been lost? From stock or from the 1.8 era engines? Which of the jet engines have a gap? (I'm confused with your use of Turbojets) A new Fanjet engine? Are you referring to the J-33 Wheesley? Is the engines nodes too close together? Making picking between the 1.25m and 2.5m modes? Color wise, I use a very dark purple, then inside unity set the panels specular intensity to max with a light pink/ purple specular reflection. Are you using Real-Chute? Either way, try using the pre-release version to see if it's already fixed (or still broken, I don't know).

All you need to do is know which parts you want to remove, then go into the MM files and add // in front of the entry. //@PART[Mark1-2Pod] {...} Then the revamped part won't load. Just make sure not to run the pruner files (or at least the ones that you modify), or the parts will cease to exist ingame.

A specular map is placed inside the alpha channel of your diffuse map, If your using GIMP, add a layer mask (from black) and then paste your specular map into it. The result will be a semi-transparent Image that will have specular highlights in game. Specular map and the finished diffuse/ Combined specular map:

Add // before a part entry to disable it from spawning in, IE: Inside the command config: //@PART[mk1pod] {} (control+F to search if you cant find it) Inside the Utility config: //@PART[parachuteSingle] {} then they shouldn't be ingame anymore.

Yup, after re-rigging everything (as per nil2work's suggestion), the problem is gone. Thanks for the help!

Go to the Github link and look to the far Right, look for a 'download .zip' button and then you'll have it.

They don't actually affect physics thankfully, but if you really want to get rid of the problem, go here and download the Pre-release build.