Jump to content

Manwith Noname

Members
 View Profile  See their activity

  • Posts

    568

  • Joined

  • Last visited

 Content Type 

Everything posted by Manwith Noname

  1. Manwith Noname
    @Electrocutor That would in some ways be useful but it also comes with undesired effects too in that, the textures would likely all still be loaded without using restocks blacklist. Really, the best course of action would be to make any packs entirely independent, which could be done easily enough. It was initially done this way as I figured anyone using a pack for a mod would likely be using it for stock parts anyway and it "saved" a couple of texturesets sitting in memory. As far as the project going forward, I still tinker on it. It's always in the back of my mind but due to a number of reasons I struggle to find the time and enthusiasm to make any serious headway. From certain stock textures being...not particularly pleasant to work with to other strangeness that has crept in to TU itself.
  2. Manwith Noname
    @G10wer Find the following files and delete them... XXX_Standardised_Switching.cfg XXX_Standardised_Recolour.cfg Where XXX is a three digit number. That should prevent any patching of stock parts but keep the textureset definitions intact which are then modified in other packs. You can also delete all the folders inside "TU_Stock_Recolour".
  3. Manwith Noname
    This is because I have not released an update for KSP 1.5 and Squad have used the same part names for those tanks as they used previously while moving the parts to a new folder, so, the configs are looking for textures in an old directory path which no longer exists resulting in them not being found. Even if they were still located as they once were, the paint scheme would most likely be misaligned and largely inappropriate. With the latest version of TU, some part icons will still display blue-ish with certain shaders, most notably, the new bump spec mapped. It's known as in one of the files there is a comment about it.
  4. Manwith Noname
    Alrighty. I've downloaded the mod, put it in my install and loaded the game. For me, the chutes work and display correctly without any changes, well, the one I tried which was the "red" one based on what I saw in your screenshot. I guess that something you have installed is interfering with them. My first hunch would be anything that is capable of modifying textures and shaders like Textures Unlimited or one of the many Texture Replacers. Do you have TU configs other than TURD?
  5. Manwith Noname
    From what I can see in your pic, everything is being rendered correctly with the exception of the bits that should be transparent so, I strongly suspect this a shader issue rather than texture. You most likely just need to ensure that "shader = KSP/Alpha/Cutoff Bumped" is applied to the chute, which you can do inside the variant section of the config I believe from looking at other stock parts with variants. I've had similar issues when trying to adapt the stock chutes to use textures unlimited shaders.
  6. Manwith Noname
    Yeah, that wasn't 100% intentional, I changed some values as a test at one point then never went back. You can simply edit the value for smoothness in the metal textureset config, higher values will give more shine. The main idea with the metallic config was to give people a starting point to create their own sets just by copying the files, renaming them and then editing certain values and texture paths. Open the standardised switching config, then using find and replace change.. currentTextureSet = Stock_Default to currentTextureSet = Alternate_Stock_Metallic That should work...hopefully. That was kind of the plan with how things are structured in their names anyway. I've already done this in my local configs as a result of the conflicts that came up with Station Parts and Ven's.
  7. Manwith Noname
    The other parts that need changing are the texture set entries in the texture switch module. From... textureSet = sometexturesetnamehere ...to... TEXTURESET { name = sometexturenamehere } It means, placing the TURD folder inside the GameData folder of your KSP install. You should end up with the following... .../Kerbal Space Program/GameData/TURD/...
  8. Manwith Noname
    The one on the left. Edit: Also, is the bloom and depth of field configurable?
  9. Manwith Noname
    I can understand that. If there was a way of hooking in so that a texture set could specify the "GAMEOBJECTS" it would be handy though. This will hopefully visualise what I'm explaining very badly... It could just be some weirdness with how I have everything setup but essentially, all inputs are the same for both shaders. The left is TU/Metallic, the right is SSTU/PBR/Masked. Edit: Huh...so this is the TU/Metallic shader on the SRBs. Both are recoloured but one is just my usual RGB scheme to visualise things and the other I altered the colours to look like the stock part. Note, it's not using the striped texture, the diffuse is all "white". Reminds me of the old saying, red and green should not be seen without a colour in between. Another edit:...and I'm going to improve the "wear and tear" so it doesn't look like someone blobbed a round pencil at the edges....
  10. Manwith Noname
    Only in so far as I remove the Stock system and replace it with the TU slider for textures. That's what you see in the pic, each "variant" becomes a texture set. The only snag with this is model switching and the issue with converting the configs to nest TU settings in variants is you can't recolour from the GUI. Here's what hilarity ensues when you remove stock variants from the new rovemate... I downloaded the dev build yesterday and have been playing around. The first thing I note is there appears to be some sort of issue where mask "layers" meet. If you've only checked this out on parts like the MK2 cockpit it would be easy to miss since all "layer borders" are in between the parts "panels" of the main texture (dark bits). This is using the TU/Metallic shader without normalisation right now.
  11. Manwith Noname
    Progress report....The (not so) leaning tower of Kerbal...
  12. Manwith Noname
    Well that's a nice update. It sort of heads toward something I've been desiring for a while. I don't know if it is possible or not but what I'm after is a way of finding out more information about meshes when drilling through parts. Mainly, it would be nice to be able to read the texture filename applied to the mesh, with a path if possible. Most of the time I've been able to figure things out just by looking and with stock parts, it's not that complicated but some mods distribute files over various folders and depending on the thought process of the author of those parts, sometimes I can follow their logic, sometimes not. I realise, if I expanded my toolset I could probably find these things out, I'm just dreaming about seeing it all in one place. That place being in the game where I'm mostly grabbing the information from. Edit: Oh, I also realise it might well be possible to do this already and I just haven't found it. If that's the case, let me know.
  13. Manwith Noname
    Yeah, I sort of figured this out after posting as I went to bed. "Why am I getting reflections when noone else is?" kind of thought, then guessed that even though it's not using TU shaders, it's picking up the reflection mapping somehow. I haven't put the whole project in to 1.5 yet but I had started planning for new parts...well...one part... Edit: Oh, be wary of this... ...go look at the HECS textures I think it was. They don't have information in the alpha...well they do but it's "1" everywhere. Another edit: It's the rovemate textures I was thinking of. HECS doesn't currently have separate textures.
  14. Manwith Noname
  15. Manwith Noname
    I'm inclined to say there's "real time reflection" going on. I stuck a sputnik and a QBE in orbit and you can see the faces updating and the "reflection" matches the colour of the planet below.
  16. Manwith Noname
    @bvsveera Alright, turns out not all part patches change the author to Ven. I didn't fully test it (clearly), just made it quick and checked some parts, then removed it. This "should" grab anything that has a model from Ven... @PART[*]:HAS[@MODEL:HAS[#model[VenStockRevamp/*]]]:FOR[zzzzVSRPathPatch_1] { !MODULE[KSPTextureSwitch],* {} !MODULE[SSTURecolorGUI],* {} } Also, you are correct, just paste it into a cfg file anywhere inside GameData. I'll just say though, remember where it is because you might want to remove it some time in the future
  17. Manwith Noname
    @Gordon Dry I'm 99.999999% sure what you have shown in your screenshots is related to the ambient light boost in the game settings. I noticed the difference in light levels between our pics and tested it before I edited my post. I stuck a craft in orbit so it was in the shadow of Kerbin and altered the setting. Anything with the stock shader got brighter but the parachutes which still had the metallic shader applied stayed dark. If as I asked earlier the canopy of the parachute is black even in sunlight when popped, that could well be another config. That config just needs to exclude the canopy mesh (or perhaps rather target the other meshes except the canopy) and it will revert to stock and appear how it should.
  18. Manwith Noname
    @Gordon Dry I've installed tweakscale and realchute and the parachutes appear to be working fine for me... As I said previously, my first step from here would be to remove any other TU patches you have installed and test without them. Edit: @Gordon Dry OK, I think I know what the problem is so I'm going to ping @Shadowmage. I suspect you are using quite a high level of ambient light boost and the shaders in TU (at least the metallic one anyway) don't appear to respond to it. There's nothing I can do about that. I'm also not sure that the "stockTextureSwitch" error is TU related but perhaps something to do with variants?
  19. Manwith Noname
    @Gordon Dry Dude....I think you need some more mods. I didn't mention this before but... That isn't a stock part. I notice you have real chute so I'll investigate with that but I'm sorry, I'm not downloading every single mod you have to check what they do. Also, if you have any other TU configs from elsewhere, I would advise removing them as a test.
  20. Manwith Noname
    Are you using the recolour pack? If so, I have half addressed this with a patch to remove the texture switch from stockalike station parts that are affected... @PART[crewCabin,cupola,Large_Crewed_Lab,dockingPort2]:FOR[ZZZZZZ_NEEDSMOARZEDS_ZZZZZZ]:NEEDS[StationPartsExpansionRedux] { !MODULE[KSPTextureSwitch],* {} !MODULE[SSTURecolorGUI] } At least, that's the parts I am aware of anyway. If you are not using the recolour pack, the patch may still work. Edit: If you don't know what to do with that.... 1) Make a blank text file somewhere in your GameData folder. 2) Paste the stuff in the code box above into that text file and save it. 3) Rename the text file to "anythingyoulike.cfg". Without the quotes. You'll get a warning about changing the file format but it's fine.
  21. Manwith Noname
    Just the canopy or the shroud too? I know about the canopy turning black but I thought I commented the offending code out so it wouldn't be listed. I'll investigate. I did dump tweakscale in as a test for a previous issue report but the parts I checked seemed to be fine. Kinda tricky testing everything though so thanks for the report.
  22. Manwith Noname
    No problem. I guess the version of TU was outdated so syntax was an issue.
  23. Manwith Noname
    @bvsveera Ok, here's a quick fix which should hopefully allow you to use VSR parts without texture switching alongside the Stock parts which remain untouched by VSR with texture switching and recolour. Not fully tested so there's a possibility it doesn't catch everything. I found a patch in the VSR pack which appears to target everything Ven and modified it. Edit: Err..nope it doesn't work as I expected. It removes texture switching from everything it seems so ignore this. I knew it was too good to be true.... Another edit: Right...here we go...quick fix... @PART[*]:HAS[#author[*Ven*]&@MODEL:HAS[#model[VenStockRevamp/*]]]:FOR[zzzzVSRPathPatch_1] { !MODULE[KSPTextureSwitch],* {} !MODULE[SSTURecolorGUI] } Again, may not catch all but the things I checked worked out. @bvsveera Just tagging again if you already read this post....not even sure if tagging in edits works.
  24. Manwith Noname
    Ok, let me talk you through what I have just done. I removed my own TURD folder from my game install. I downloaded the Stock Recolour file from the opening post (TU_Stock_Recolour_v0_2_8.zip). I copied the TURD folder from that back in to my install and loaded the game. It works. So... What version of Textures Unlimited are you using? Grab 1.1.2.15 from this link if you're not sure https://github.com/shadowmage45/TexturesUnlimited/releases The TURD folder should contain two folders named as follows, TU_Standardised_Switching and TU_Stock_Recolour. Do these exist? Does the recolour folder contain 4 config files?
  25. Manwith Noname
    I looked briefly at VSR when that issue with Stockalike Station Parts came up and I realised what was going on. Getting things working with VSR will take a bit more investigation to work out exactly what parts are targeted. The other alternative is to make maps for VSR and a conversion patch which adapts the current patching if VSR is present. I'll take a proper look and see.
×
×
  • Create New...