Manwith Noname

@mcwaffles2003 Heh, well, it is and it isn't. The current download is compatible with Restock in the sense that it disables certain TURD patches when Restock is present. It should be good for the releases of Restock against 1.7.3. I still need to go through and make the 1.8 configs do the same with the later release of Restock which added even more parts to their catalogue. There's also "bodge it" patches in the thread to remove patches if Ven's Revamp or Stockalike Station parts are installed. What none of them do is apply recolour to those mods, sadly. I did start work on Ven's but didn't get very far before Restock appeared, which kinda dampened motivation for that and I moved on to other projects that were more in my own interests, some of which were started quite a long time ago but got put back due to prioritising updates to the existing configs and general procrastination from time to time.

It's a combination. You don't need the UV maps and can derive colour masks from base diffuse textures but having the UV maps will at times offer additional information. Personally, I would import the UV maps to the project regardless of if you think you need them or not. They're just handy to have regardless and sometimes, they will point to potential issues and help solve them.

@lk00david It's for the original pWings... ...but it contains parts that were designed to fit with the original B9 parts mod.

No. It's a result of Squad restructuring the cones directory. Also, if you are going to edit configs, you might want to remove the "ModuleJettison" from the cf34. There's no attachment on the front or fairing mesh defined within the files so it spams the log with errors when placed in the editor and probably when in flight on a craft using it.

@bd1323 Firstly, I suspect your problem relates to the texture formats and how they are handled by the game more than anything else. The original texture files in pWings are png and I suspect you probably exported your textures as a form of dds. The game will convert png to dds during load and in doing so it will flip the file vertically. If this is the case (as in you are exporting to dds without any flipping), simply flipping the textures inside the graphics editor you are using before exporting will likely result in everything working as you expect. A lot of the time, the UV isn't really necessary to see from the texture where you want to map out colours. I worked on projects without them for a few years. That's not to say they are not helpful though, in fact, these days when working on these projects the first thing I do after opening the main texture when creating a project in GIMP is import the UV of the various meshes just so they are there. Sometimes, they'll give clues to odd parts of the texture which are being reused by other parts of a model. Now, how to get UV maps? Textures Unlimited features a UV exporter. Open up the "GeneralConfiguration.cfg" and look at the UV_EXPORT section. Simply changing the false to true will result in all models located within GameData having their UV maps generated as scalable vector graphics files to a folder within the root of your KSP install. You can specify an alternative directory away from your install if you wish. For example, I point mine to a location where I keep all my recolour projects, "E:\Creative\KSP\KerbPaint\exportedUVMaps". When working on a specific texture you can then import these files as layers to your project. If you're working on pre flipped files for exporting to dds, you'll need to flip the UV map to align correctly. That's basically all there is to it. Some notes: The game will seem to hang during load while it dumps all the information for the meshes if you have hundreds or thousands of extra parts from mods, this will take quite a while. You'll want to enable the exporter, load the game, close it once you reach the main menu, then disable the exporter. It might be possible to enable TU's debug mode which used to enable an icon in the games toolbar, from here, there used to be a button to export UV maps too. I've not done this for a while though as there were some changes to the general setup of TU that meant my "TU_Debug_Enable.cfg" no longer works. I think you can probably enable debug from within the difficulty options of the game save now though, but I have not done this as I have previously exported all the maps I need for the projects I'm working on prior to this change in TU. The pWings config has moved on a bit and now looks more like this... Technically, I could upload it right now but I've been holding out for TU itself to receive an official update to 1.8 before unleashing more configs. They should however be pretty agnostic to versions of KSP and TU aside from the parts that may or may not exist within the game, within reason.

Have you actually tried playing KSP 1.8.x without those mods? Garbage Collection was one of the areas changed with the Unity update. Granted, I don't really play KSP and when I do I'm running it fairly lean in terms of mods, just a few for the things I'm testing. I've noticed even in this state, the game no longer hitches like it used to due to the new GC method already in stock.

Just to be clear, it's only a problem in 1.8.x when KS3P beta build is installed. Using 1.7.x with KS3P beta build is fine. Using TU in 1.8.x alone is fine too.

@beaucoupzero It doesn't currently have a config that applies the metallic shader uniformly over the entire part but that can be easily achieved. The shader in use is however the metallic shader with a recolour mask and spec/met map so you can make them look metallic via the recolour GUI.

Might be worth mentioning, it only shows in "flight". Presumably because my KS3P configs don't have any setup for the editor. There may be other strangeness occurring but so far those were the only two I found. It's certainly a weird one as they (the Panther and Whiplash) are configured as two different texture sets yet the Wheesley engine which shares the same texture set as the Whiplash is functioning.

I have a pWings recolour ready to go along with some other things. I'm just waiting for TU to update to 1.8 to prevent unwarranted bug reports. Though, pWings itself has an odd issue in 1.8 too.

Given the recent comments and nature of what I'm about to post, please don't consider this a bug report but more a heads up in the hope it might prevent conflicts down the road. Something in the latest compile for 1.8 appears to conflict with Textures Unlimited in weird and not so wonderful ways. Strangely, it only seems to affect the stock Panther and Whiplash engines. Everything else works fine. It's also fine when using the build for KSP 1.7.3. Given the notes and nature of the mods involved I would point to the shader loader changes but could be completely off the mark. It could also be a problem on TU's end as that is currently not built for 1.8 but it has been "working fine" there when tested until I introduced KS3P to that install. I'm aware of the shaky ground upon which I stand, that's why I don't consider this a bug report but just findings for consideration by the appropriate persons. Maybe this is useful information, maybe not. Pinging @Shadowmage for awareness too.

It's not automated but you might want to look at BULB which allows altering lights during flight. There's a newer recompile toward the end of the thread. Don't know if it works in 1.8.

I don't know if a mod exists but a quick glance at the part config suggests this can be achieved with a fairly simple module manager patch, which makes me think you could probably just pull those patches out of the mods you mentioned. Inside "ModuleScienceExperiment" there's an entry for "xmitDataScalar" which I'm guessing is the multiplier for transmit value. So a patch for that would look something like this... @PART[sensorAtmosphere] { @MODULE[ModuleScienceExperiment] { @xmitDataScalar = 1.0 } } I could be completely wrong mind you and that value means something else entirely

Heh, well it's all part of the learning process when doing something new. It's quite common for people to use bump and normal interchangeably.

@NermNermNerm How are you making your normal map? A couple of years ago when I first tried my hand at adding some to stock parts, I experienced a similar issue. This seam would show due to a combination of the mirroring used for the textures but also my poorly made normal map. I was doing everything in GIMP and it took me a few hours to realise that "bumpmap" in GIMP's tools was not "normalmap" for game textures.

I could be wrong but I suspect you are suffering from the same issue as here. Essentially, if you are using a shader that looks for a normal (bump) map and don't have one, things behave strangely. Either switch the shader in use on the part to one that doesn't need a bump map or supply a bump map if this is the case.

Kind of. DXT3 has a different algorithm for the alpha layer compared to DXT5. You can convert a DXT3 texture to DXT5 but depending on the original artwork, you may well be missing information. Yes, that information was missing in the DXT3 texture distributed within the mod, so you can say you as an end user who has been playing with the mod isn't missing anything but it would be nice to have the original artwork converted at source and getting the better results. The following spoiler contains an image that show two results of alpha layer compression, DXT5 on the left and DXT3 on the right. Variant switching is a core feature of the game, no DLC required.

@lk00david Heh, if you're not keen on how it works, why do you want more? The subject of B9 has come up a couple of times and while I suspect it could work, it is likely going to require that the B9 mod itself be rewritten due to it using it's own shaders and recolour system. Given that in the past I had configured some of the original pWings to work with KerbPaint, I took some time to download that and start configuring TU to work with it. There's more to do but it's a start. The curved wing is going to be weird too as I don't think it was ever UV unwrapped, which poses some problems.

It might even be a stock issue. Zooming in I can definitely see clouds and possibly land beneath the haze. Would be interesting to see if Kerbin shows without scatterer or E.V.E installed. Edit: It is a stock problem. Modified the rover probe core shininess and dumped it in a low lunar orbit, you can see Kerbin.

Might be worth mentioning then that I use it all the time and yes, it's amazingly helpful. Certainly beats failing at back porting models in to Blender and trying to export UV. Not that I've done that in KSP but have tried for skinning projects in other games. Usually I end up downloading templates made by others but they can be hit and miss at times.

@Prathtel I had some time to investigate further and it seems using a different version of module manager fixed that problem. So, most likely, the only issue you'll have is with parts that Squad have "revamped". In particular, the old versions of the parts in this image will probably behave strangely (I know the puff does for sure as I found it during the above test)... So, to summarise, current download of the recolour pack, current version of Textures Unlimited (v1.5.8.23) and Module Manager v4.0.3, seemed to work fine in KSP 1.6, part revamp issues aside.

@Prathtel There isn't really a specific version for 1.6.1 as the project just continually evolves with improvements and additions. You can use the latest download which is tested with 1.7.3 and the latest version of Textures Unlimited alongside a suitable version of Module Manager. I've just thrown everything I have, including additions and fixes for 1.8 in a 1.6 install, it caused two problems that I noticed: 1) Certain cone parts have no diffuse textures. This was obviously going to happen as in 1.8 they moved things about which I have adjusted for. You shouldn't need to worry about that with the currently available download as it doesn't contain those changes. 2) Module manager complained about 3 exceptions, these all related to the large stack adapters. Not really sure why on first glance, particularly as I don't think anything has changed here since 1.6 and I don't have this issue in 1.7.3 and 1.8. Now, I'm not saying there are no other issues, just I knew one of these would happen for me and the other was promptly shown by module manager during load. I placed numerous parts in the editor and they all worked, except the large stack adapters. They have variants showing as available but only the stock variants function. I don't really have time to investigate beyond that right now. As a general update, the new 1.8 parts are all done. Textures Unlimited "works" in 1.8 on Windows (there are some issues, though I have not tested it fully, just using it to check new part work) but I'm not too keen on uploading configs until it is officially updated just to prevent people complaining about things that aren't properly supported.

This may have been asked before but regarding the above, is there a limit on the number of sub directories you can specify? As in, is there a reason something like this would be seemingly ignored completely? :NEEDS[ModFolder/Subdir1/Subdir2/Subdir3/Subdir4] I can probably get around it since there is another common element I can use with :HAS but figured I would ask. Edit: Nevermind, coffee kicked in, major brainfart occurred. NEEDS is just checking the folder exists, not specifying to only apply to parts in that folder.

You're welcome. I only really did what I did because I know how much you do. Less time chasing dead ends and all that.

I didn't answer the question because I'm not the person that reported it poorly that you asked. I'm the person that noticed everyone is talking about textures when pink/purple things means shader problems and decided to try and be helpful by saying that, then when it was seemingly glossed over, downloaded the mod, took a screenshot and found the exception. To answer your question though, no, I didn't run the bat file because the folders, model and texture were already in the download. It's not related to the textures or the model being missing. Edit: Oh...Windows.