Jump to content

Manwith Noname

Members
  • Posts

    543
  • Joined

  • Last visited

Reputation

493 Excellent

3 Followers

Profile Information

  • About me
    Taster of rainbows

Recent Profile Visitors

5,059 profile views
  1. @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.
  2. @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.
  3. @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.
  4. 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.
  5. 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.
  6. 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
  7. A brief report from an initial install and run... https://github.com/meirumeiru/InfernalRobotics/blob/develop/Resources/GameData/MagicSmokeIndustries/Parts/Rework_Utility/Probe/Misc/IR_DockingPort/part.cfg MODEL { model = Squad/Parts/Utility/dockingPortJr/model } ...needs changing to... MODEL { model = Squad/Parts/Utility/dockingPortJr/dockingPortJr } Also of note, a few errors and exceptions on the large and small suspension. Looks like all the module indexes need to be incremented by 1 or move the IR Variants module to the end of the file. Edit: Just to say I haven't used anything in anger yet. Noticed the update, installed and ran. Spotted some errors and exceptions as I have them log to screen. Briefly glanced at what they were.
  8. Batteries Not Now Included - An Electrical Overhaul The Stock Recolour pack has been updated to bring an overhaul and completeness to electrical components. Of note, the "new" shrouded solar panels on any existing craft may need to be checked (and will probably be broken) due to renaming of a texture set for surprise reasons. People may or may not notice the changes but kinda needed to be done to correctly implement...something. Also many of the older parts probably want checking on existing craft as they were previously only "placeholder" configured. Oh, and batteries can now be messed with. Still some things I want to tweak some time in the future but everything "should" be very close to whatever those changes may bring. As always, probably best to delete the existing stock recolour folders before extracting this one. Depending on exactly what the problem is, perhaps. First things first, make sure you are using the supplied version of Textures Unlimited. This has specific features that are not present in the stable public release relating to handling Part Variants. However it does sound potentially like an issue I am aware of with part variant behaviour. If it is this, there is a workaround, or there used to be. When painting a craft with multiple of the same part that uses part variants as opposed to the Textures Unlimited texture switch module, only one set of parameters can be "live". You will notice that if you place a part and paint it, placing a new piece of the same part will contain the same colour scheme for the same variant. Adjusting either one so they are now different but then launching the craft will result in them both displaying the most recently set scheme. At least I think this is how it worked, it's been a long time since I found this behaviour and worked it out. In any case, reverting back to the hangar and then correcting the variant that had been adjusted to a scheme you want, then launching again would result in both parts having independent schemes. I also seem to recall that painting, saving, reloading and painting works too. Essentially you need to get the colour scheme data saved in to the part of the craft file before you can adjust another part that has the same variant data. Again though, long time ago I discovered this and I'm just going from memory. I'll investigate a bit more when I have the time and report if it's anything different from what I've described. Gonna be honest, unlikely. I've got my hands full with getting the packs I've already created finished alongside a couple of other projects.
  9. Alright, first things first... UPDATE It is advisable to delete the pre existing Stock Recolour installation The Stock recolour pack has been updated. Notable additions are things that were new in 1.12 but never got their lick of paint. So, new docking ports along with Swivel and Reliant engines. As I type this I just remembered an issue I spotted but can't recall if I fixed...such is life. Also of note, many parts have been tweaked or added among various other areas of the game. Forewarning, if you have recoloured and saved a structural beam or girder it will likely look weird now but only because the previous existing config was incomplete. In general, any craft that uses parts residing in the structural folder of the game files (not the in editer menu) may want a repaint. For visual reference... This likely also applies to many parts in the Utility folder (again, game files, not the editor menu). There's still many things I want to tweak / finish / add but now seems like a good point to upload what is done. While I've been busy stuff... Any discussion that is about creating configs is welcome to be added to the thread. I appreciate some cards may want to be held close to ones chest (like don't tell everyone your working on ReStock if you haven't even started it) but general "how do I do this?" and guidance for workflow is fine. We can all share and learn from each other. In all the zip files you should find a GameData folder. You can either extract that to the root install of your game or extract the contents of that GameData folder to the existing GameData folder of your install. The main thing to be aware of is not to create GameDataception by dropping the GameData folder inside the existing GameData folder. I think I need to type GameData one more time, so...GameData. To explain this, the included pack contains a dll file from the development branch of Textures Unlimited. This has added functionality specific to allowing increased configuration flexibility with the Stock ModulePartVariant. This is present on fairings among other things which is why using the dll that doesn't include this feature spits the error. There is a post somewhere in the earlier days of this thread I think that describes this but it's fairly simple to do so I'll type it here. Open the file 112x_Standardised_Switching.cfg in a text editor of your choice. Use the find and replace function to find... currentTextureSet = Stock_Default ...and replace all instances with... currentTextureSet = Alternate_Stock_Metallic This will for the most part do what you want. It will not work for parts which utilise the stock part variant module though. I did at one point start naming themes that would allow you to use the in game function but it got a bit messy so I mostly shelved it and planned on thinking about how best to do it. Some parts of that might remain if I didn't comment them out in the configs. Bye, have a beautiful time!
  10. They can but I'm 99.99% sure they have some sort of conflict in their mod collection or they didn't install the pack correctly so it cannot find the placeholder normal map.
  11. KSP should convert png files to the appropriate format but that might explain why your normal maps failed. A plain albedo / diffuse texture if it is only using the RGB layer can be DXT1. Anything that uses the alpha layer (like metal / gloss maps) should be DXT5. Normal maps want to be DXT5nm or BC7 BC5. If you export to BC7 BC5 you need to add the appropriate keyword in the config so TU knows.
  12. Any part these configs alter already have a flat placeholder normal map applied. That has been the case since the project began. When the problem you are referring to appeared, the place holder normal maps were not affected by the issue. I would perhaps suggest if they are using the latest TU or recolour pack with KSP 1.9 then they should source something from that time but as far as tracking down conflicts with other mods that might be causing it...unfortunately they'll need to apply their own investigative methods amongst their 100+ mods. Edit: I would also suggest checking that the install is correct. If the texture is not found then this problem would likely return.
  13. In a word, no. (EDIT: See edit below) I just downloaded the latest Scatterer and plonked it in my install, loaded up a basic craft painted with variations of the platinum metal all over (basically different levels of reflection) and it all behaves normally for me. Even tried different levels of reflection refresh thinking it might be that and got a whole load of nope in terms of recreating the effect from your video. So it's not directly scatterer per se from my experience but possibly a setting I haven't altered or something to do with scatterer and E.V.E combo. EDIT: Ok, I had some time to muck about a bit more and have managed to recreate the issue by adding E.V.E Redux in to the mix. I would also point out that it happens with just E.V.E Redux and no Scatterer. Why? Don't know. Something flickers / strobes in the reflection probe that isn't immediately obvious in the main scene. Possibly shadow related or perhaps the noise swirl thing that is going on. Can perhaps narrow it down with some config tweaking. Another edit: Yeah, if you make a part completely smooth you can see stroboscopic clouds.
  14. It is supplied with Kerbalism. Edit: I will add, if you are thinking of creating recolour sets you can proceed without concern. Setting up recolour will override the KSP_MODEL_SHADER config.
  15. @jonathan_92 The data for how a craft is coloured is stored inside the craft file and subsequently as part of the craft data within a save (persistence.sfs). This update should only cause issues on craft with the various docking ports if they used a recolour texture set. If it uses the blanket shine set it should be exactly as it was. If a file remains unchanged, it will also recall the correct settings when I finish the colour masks, provided I don't rename the texture set. Which I shouldn't. Also might be worth mentioning, if a texture set is missing and cannot be recalled, the part will just fall back to the stock look.
×
×
  • Create New...