Jump to content

Manwith Noname

Members
  • Posts

    562
  • Joined

  • Last visited

Everything posted by Manwith Noname

  1. This is likely due to your graphics settings in game causing the reflection probe to be disabled. You need the reflection refresh mode to be set to something other than "off" but also your overall graphics preset needs to be "good" (I think) or better.
  2. If you are using this to install Textures Unlimited, simply replace the dll with the one that is bundled with the Stock Recolour pack or if necessary, uninstall TU from CKAN and manually install the supplied version. P.S. Sometimes fairings do not behave themselves but the result when that happens in my experience is different from what you have shown and typically happens after a revert to hangar if I recall correctly.
  3. @Phoenics Going to guess from your description of the errors you do not have the base stock recolour pack installed or you are missing a dependency for whatever pack you are trying to use.
  4. No. The included ReadMe file should state the one exception. The dll is taken from the dev branch as it contains an important feature relating to PartVariant integration. Certain parts of the configs do not work correctly without this dll as is stated in the OP and the ReadMe. I am also not aware of what version number should be stated in the version file as the dev branch file is the same as the master last I looked.
  5. @Spartwo Hehe, I don't know what the forum software is doing or if it is my currently inebriated state but that should be the link on the front page?! Is it not redirecting others to the overall GitHub releases page? Edit: Ok, even while...tipsy...I have changed the link to the overall releases pages...that seems weird to me but we should be good!
  6. Kill your foes in style Thanks to the time and dedication of @Spartwo you can now paint BD Armoury parts for added flare in your simulated war games. Link in the opening post. @InterstellarKev Maybe at some point if nobody else does. I don't have the DLC. I've considered getting it but I have not really played KSP in years, I only load it up to make colour packs. @grandmastergoober Unfortunately Restock is not currently paintable. @jebycheek Another unfortunate response, not easily solvable. Needs a shader wizard to fix and as of now, that's not me. Happy coronation weekend everyone. Long live the King!
  7. @JadeOfMaar Well, at least I'm likely not going mad. Thanks, that's good to know.
  8. @daddydante88 The current most effective way is to use the save and load pattern buttons on each part. It would conceivably be possibly to program an "apply to all" sort of logic in to the base TU plugin but it's not something that exists and I suspect it is unlikely to unless I learn C# and a whole load of best practices. An alternative if you wish to start from something other than the red, green and blue bases is to decide on a useful palette, configure colours if required and then point to them in the base texture set config. The base texture set ultimately looks like this once the commented out lines are removed... The main, second and detail colours in the COLORS block can be set to anything configured as a colour preset but you would need to do this prior to loading the game. You can find colour preset files in the base TU folder or in amongst the recolour files for a reference to create new ones or find appropriate existing ones to assign.
  9. Forgive this drunken old fool if this was covered in the comments above and I missed it or I have made some sort of faux pas but...what am I missing?
  10. Just a quick note that the stock recolour pack has been updated (completely delete existing stock packs when updating to prevent conflicts and errors) and a new "pGlass" pack is available for anyone using either or both of the procedural wings mods with the existing recolour pack. The main focus of the stock update was fleshing out the science parts so everything can be painted. The pGlass pack was the result of a conversation a while back and gives an option for creating procedural glass type things from procedural wings. It still has assorted rendering issues but some may find it useful. Note, the "Clear Glass" colour preset does not automatically make any part translucent. It's just there to give a reasonable starting point when this texture set is selected.
  11. @Arqane The quickest and simplest workaround is to open up the following files... 112x_Standardised_Switching.cfg 112x_Standardised_PBRMetallic.cfg 112x_Standardised_Switching.cfg In each of them use CTRL+F to find [mk2DockingPort] then change the :NEEDS section on that line so it reads [TexturesUnlimited&!Restock] It's worth changing the KSP_TEXTURE_SET lines relating to the part also. @CalixK First things first, I have not gone through all the parts in the pack but at first glance this is a great step in the right direction. I can further comment on some things I see but to first answer a previous question about choosing values, the best way I can explain how to understand these is they essentially set the value of the base texture that will result in the slider value of 255 giving a corresponding pixel value of 255 in the shader when rendered in game. This then means that the values along the slider should give a corresponding and representative output. So if a base texture contains an area you want to paint and it is mostly a value of 127/128 when measured inside PS or GIMP, using a value of 0.5 in those normalisation parameters would scale the slider allowing you to get a full range of colours when trying to paint that area. The three values separated by commas represent the areas of a texture covered by each of the colours used in the paint mask. So the first number is the normalisation value for the red area, the second number is for green and the third number is for blue. Strictly speaking, it's the pixel value so areas where red and blue might overlap to composite in to a magenta will be treated twice and results may be undesired. A good starting point for finding suitable values is to use the colour picker tool and look at the values in your image editor (photoshop). You may find it useful to desaturate textures based on luminance and using the values extracted from the resulting greyscale texture. This is what I do to get the colour normalisation value so it maintains all the existing artwork character in terms of "fake shading" for artistic purposes. It maintains the look of the part even if some of the pre existing texture works was really about faking ambient occlusion. This method may not always get you a result you are 100% happy with and sometimes I manipulate or completely recreate the diffuse texture to get something more akin to what I want. The metallic and smoothness values are typically found by educated guessing then trial and error tweaking. To some extent this is an artistic choice I would say. With the in game GUI sliders for these at 255 values, I want the bulk of the painted areas to be close to fully smooth but not necessarily obliterating all detail and conversely not only making a tiny portion of an area completely smooth. I've kinda waffled a bit so I'll wrap that up here and say, I am going to be reworking and adding to my OPT base pack because way back when I converted it to more current standards I did so very quickly and some things have changed in the TU plugin since that were not part of the consideration when I was doing so. Some things will not be drastically different but I mainly notice I did not normalise areas of the texture as I would have been. Before I pass comment on certain aspects of your legacy pack I suppose I should state anything I say is not meant to discourage you or otherwise diminish your efforts, what I have seen is genuinely a good beginning. It's mostly finer details and artistic interpretation that I see that I feel can elevate the pack. Some of them you may have plans to do. Some of them you may have just not noticed. Some of them you may just consider unimportant. All are reasonable positions. I also only bring this up because you said you consider it finished, so I guess I should ask, do you actually consider it finished or do you just consider that "hey, I get everything up and running with colour mapping" ? Trust me, I have been there. The stock project when I first converted it from KerbPaint was very much incomplete and just, "hey, you can muck about with colouring". Even today, I am still working on improving things in the stock pack. As a result of this and a conversation elsewhere I see some parts have been added to the base OPT I need to get covered and noticed the things I previously mentioned that I feel need to be brought more in line with my current methodology in stock.
  12. @CalixK It looks like the texture you are using for the metallicglossmap has the alpha channel / spmoothness layer completely white / opaque. I recommend starting out with the alpha channel being a 1:1 copy of the RGB layer. You can tweak and manipulate it later with a combination of the graphics editor you use and the normalisation vector values in the config. The normalisation vectors values only apply to the areas masked to be painted. Any area unpainted needs to be manipulated via the texture values. The main thing to understand about the metallicglossmap is how it is being interpreted by the shader. For the shader being used here, the red channel of the RGB layer determines the metal value applied. Strictly speaking, this should be 1 or 0 but artistically you can use values in between, particularly where materials transition. Rather than just editing the red channel, it is easier and possibly better with regard to block compression (not tested) to have all RGB channel values the same and essentially a greyscale image. Alternatively you could just work in shades of red but I found that too strange to visually process when I tried it out. The alpha channel is used to determine the smoothness and is greyscale. Hope that helps.
  13. @CalixK Alright just to provide what I think will fix it, a quick check leads me to suspect it is the mesh naming due to case sensitivity. So for example you need to use the mesh names Wing_D and Wing_E instead of wing_d and wing_e. A couple of notes about this and some other advice... 1) There are a number of tools out there that it will greatly benefit you to be aware of. a) One is built in to Textures Unlimited itself. If you find the GeneralConfiguration.cfg file there is an entry to enable UV exports. I highly recommend loading the game once with this feature enabled and only whatever models you want to export installed then disabling it. If you have lots of parts mods, it will take a very, very long time to process them all so I'll reiterate, only enable this with the parts you want to export in the GameData folder. You can even remove the majority of the Squad parts folder but for simplicity I would leave that alone. That said, modern CPUs may fair better than the aging Haswell chip I have as a mental reference. I should try this on my newer chips but I digress. The game will look like it pauses at a certain point during loading. It will create a folder in the game install that will contain wireframe UV maps for every part it detects in the game as svg format alongside a text file that details various properties about those parts. You can ascertain the correct mesh names to use via these files. The UV maps can also be useful when imported in to your graphics editor of choice to help understand where the mesh is transposed in the 2D space. I suspect once you play around with this you'll understand it. b) There are some other mods that can be useful in this regard also, like Object Inspector or DebugStuff. As an example... ...this gives you a visual indication of the mesh name and wireframe within the game if you prefer that over exporting the UV maps and text data via TU. c) Blender and the KSP plugin. Kind of a mix of both of the above. You can view the model, the UV map, the textures. I typically load in to Blender when UV maps and textures are all over the place making it difficult to see what is where. While I prefer to do my actual painting and texture authoring within GIMP, Blender has been infinitely useful at times to just paint on a model and see where that appears on a texture. d) Other softwares and utilities may be available that can do the same things. Use whatever you find that suits you best. 2) I don't know how far you are in to this but I would highly recommend not adding your configs and textures to the existing OPT Recolour files and folders. Make a new TU_OPT_Legacy or simlarly named folder that sits alongside the other existing "packs" and store your files there. It's not that I have a problem with you altering or adding to the files but if I update my OPT pack (which I kinda feel it could probably do with a refresh at some point to add more layers on some parts), you'll end up having to transpose your work over again or worse, potentially losing it if you did not have a backup. The sooner you do this, the less laborious it would be. Plus, if you complete covering Legacy parts and want to share it, compatibility will be almost ensured without people having to overwrite the existing OPT pack files.
  14. @NaviG Usually the lack of emissive texture showing is a result of the alpha layer being set for transparency. It can be fixed with a modified copy that set the alpha channel values to 1. @CalixK Probably best to post the config code so I can glance over it either here or via PM. Things that can lead to this off the top of my head are typos, which can sometimes be hard to spot when you've been staring at text for hours and incorrect mesh assignment if you are trying to specify those.
  15. @Sidestrafe2462 Ok, copy and paste the contents of the code block in the spoiler to a normal text file. That file can be named anything and placed anywhere inside GameData but perhaps put it in with the pWings TU configs. This is for ye olde pWings, not B9. This has issues, some of which are apparent in the previous screenshot. Other things to note, this just reuses the existing textures. Things could be better with custom textures that would essentially be a flat single colour with some dirt perhaps but if you play around you'll better see why it never went further than testing with existing textures.
  16. @Sidestrafe2462 Yes...kind of. That is something I experimented with some time ago with limited success. At least with what I was looking to achieve anyway. It got shelved because of a number of rendering issues. I can perhaps look and see if something has changed internally with KSP that fixes these problems but I suspect they might need a shader wizard to jiggle with TU internals.
  17. Re-sourced Resources The base recolour package has been updated with a focus on parts under the resources folder. Now your survey and mining vessels can receive a matching splash of colour. Alongside this there has been some more polishing of other parts including the MK3 fuel tanks. The MK2 and MK3 Expansion packs have also been updated and corrected for changes surrounding the not so new docking ports. As usual, I advise deleting the corresponding existing recolour folders to avoid any potential conflicts.
  18. Some catch up... @yoyotam3 Yeah, fairings are a known issue. Mainly when trying to apply the stock shader. Using a recolour shader should work, with other slight issues. @Baleurion Essentially, yes, to my knowledge there are no publically available packages for the mods you listed. Unfortunately. @Joker58th Thanks for the heads up. Fixed locally, kinda want to do some more to the base pack as the updated MK2 and MK3 expansion packs rely on some changes there. No ETA but Soon™.
  19. Err, well...that was a surprise when logging in... I hope anyone who has downloaded and used the various iterations of recolour mods over the years has found enjoyment from them and am humbled.
  20. @DeliriumTrigger Confirmed. Just downloaded everything and tested it. Aside from launching you can also save and reload the craft in the editor to fix the rendering issue. It seems like something weird with material changes and render layers causing it that gets fixed with a full refresh / reload.
  21. @DeliriumTrigger Putting my money on Depth Mask. I had that in the back of my head in the earlier post as I can recall experiencing issues with it in the past. My recollection was that it broke recolouring though but it kinda fits with what you see. Edit: Actually the more I think about it, it did what you kinda see. Certain viewing angles of where the depth mask was would make the rest of the part invisible. This was back in 2019 though and I may not have had mesh targets on everything...but this is still broken for some reason.
  22. @Akagi You don't necessarily need to open the .mu file. You can often just go by what the textures show you in photoshop or GIMP coupled with the mesh export function of TU. If you want to work in 3D, like Blender, you need to get the KSP blender tool plugin. @DeliriumTrigger I don't mind looking through the module manager cache, even if it's huge (CTRL+F for the win) I am mainly curious to see if we can find anything because even if it cannot be resolved, assuming we find the problem, at least we then know what the problem is.
  23. Yes. Probably the simplest thing to do is install the stock recolour, copy the Recolour_Texture_Sets.cfg and Colour_Presets.cfg files and move them up one level out of the TU_Stock_Recolour folder. Do the same with the Metal_Texture_Sets.cfg file inside TU_Extras. You can now delete both those folders. Then in the TU_Standardised_Switching folder keep the standardised texture sets config but delete the other two configs. You basically want to end up with all the Texture Sets config files, the colour presets (though these are not overly critical) and the placeholder textures. The textures need to remain in the folder path they come in or you need to edit all the file paths in the configs to match wherever you put them. Alright, that's a bit weird and I suspect a conflict of some kind. First thing that comes to mind is another TU config set, typically those that apply a metallic look to a bunch of stuff just through text files and not with textures. It used to be the case that the Texture Switch module would simply override MODEL_SHADER configs but maybe something is amiss. Perhaps the best thing to do is paste the contents of you module manager cache file to somewhere like pastebin and drop a link here and I'll see what I can see with regard to how the part ends up. Procedural Parts should come with its own set of TU configs but you need a specific fork, like this one.
  24. Yes, you just need to insert the line... crew = #autoLOC_20827 ...in to the Mk1-3 Pod PART module of the g_docking.sfs tutorial save state and start it again. Something like this... PART { name = mk1-3pod cid = 4294634394 uid = 3817944765 mid = 4004293368 persistentId = 643397188 launchID = 1 parent = 0 position = 0,0,0 rotation = 0,0,0,1 mirror = 1,1,1 symMethod = Radial istg = -1 resPri = 0 dstg = 0 sqor = 0 sepI = -1 sidx = 0 attm = 0 sameVesselCollision = False srfN = , -1 attN = bottom, 4 attN = top, 1 mass = 2.31799984 shielded = False temp = 304.62609337808368 tempExt = 305.11675208761795 tempExtUnexp = 305.11673133775491 staticPressureAtm = 0.98840547378581445 expt = 0.5 state = 0 attached = True autostrutMode = Off rigidAttachment = False flag = Squad/Flags/default rTrf = _default modCost = 0 modMass = 0 moduleVariantName = moduleCargoStackableQuantity = 1 crew = #autoLOC_20827 EVENTS { } ..... You could also edit the persistent.sfs the game created when you tried to play the tutorial and continue but I would suggest starting the tutorial again.
  25. As a result of a discussion elsewhere I performed some checking of files and the replacement docking tutorial save appears to have omitted the crew from the "Kerbal Rescuer" ship. In the original file, Valentina is the assigned crew member. crew = #autoLOC_20827
×
×
  • Create New...