Manwith Noname

  • Content count

  • Joined

  • Last visited

Community Reputation

78 Excellent

About Manwith Noname

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

840 profile views
  1. 14th April 2016. You can just mouse over their name in the OP @Skylon Ah, yes. I can remember encountering that too. I haven't got round to wheels in my ongoing update of the maps. It might be possible to avoid it with what I'm about to ask about.... I wonder if anyone who reads this my be able to throw me a bone? I don't have any 3D modelling software installed and because I'm not a 3D modeller I kinda don't want to KerbPaint has a command that allows a map to target a specific "sub model" (my term, don't know what else to call it). The best way I can try to explain this is with the part I'm primarily concerned about currently, the fairings. The way the part is made, there are multiple textures for different parts of the model. The fairings themselves are obviously procedurally generated but that shouldn't be a problem as I have previously had maps working on the procedural fairings mod. The difference being, I think, the mod had one texture that covered not only the base but the procedurally generated shell too. With the stock fairings, my paint is being applied to the base only so I'm looking for a term to use with the "specific = x" command within Kerbpaint which I'm hoping will only apply the map to the shell itself. Can this term be found if the model was opened in something like Blender? I could probably get the map applied with the deep replace command but it will still apply the paint to the fairing base I suspect....actually...I should go and try that... Edit: Never mind, I solved it. I must have typo'd or something because I'm pretty sure I tried the solution prior to posting.
  2. Oh wow! This looks like some awesome work improving things. Kinda disappointed about the "ticking sun" but it explains why that is used in many games with day night cycles I guess. Interesting.
  3. It needs addressing. There's a whole load of nonsense occurring over something completely unrelated to KSP. Send them home.
  4. Bully 2: Jebediah's Skool Dayz.
  5. Erm...did this same issue with parts get some love? There's no specific mention of it. Thanks for all the hard work.
  6. @Azimech I was going to get to that eventually. I've had a similar thought about asking a shader wizard nicely if they could take a look. Just to confirm though, shadows are still an issue and you don't need to go to the runway to notice it. In the SPH, they don't cast shadows either...well...the flag decals do. I have also encountered an issue with using "DeepReplace" that needs to be investigated as I'm not sure it happened in the past, though it may have and I just got lucky that I never encountered it. Basically, if you have a part that uses "DeepReplace", everything appears as you would expect (there's another issue with it painting the old style flags but I can live with that as I would disable them anyway) when painting the craft you have created but when you load a saved painted craft, things get a little wonky. Firstly, every part attached to it takes on the "DeepReplaced" parts scheme. Then, if you repaint a "DeepReplace" part, every part attached to it takes on that new paint scheme as you do so. It seems from my testing however, simply hovering over the affected parts and pressing "P" will revert them back to their saved scheme. I tried playing with the "Specific" command but I feel like a blind man trying to hit a bullseye on a dart board. On the shadows, I suspect something has changed with how KSP casts shadows or somehow the shader now overrides the component that does so. I know that something did change with shadows in KSP as Squad have acknowledged a problem with them and I have seen in one of the weekly updates they resolved it (shadows are not solid and have lines of light appearing in them). I would be tempted to see what happens with this fix from Squad as it may negate any need to start messing with KerbPaint. This fix may even have been pushed in to the 1.2.9 pre release but I'm not sure as I have not opted in to it. Edit: Uch, typed this out once then accidently closed the tab. Slight update on the DeepReplace issue. Most parts attached "downstream" do not take on the parents paint when loaded, they do so when you try to repaint that parent. It just so happened that the part I had connected was affected by the command and so the parent paint was applied to "seperate" parts. It seems older parts are a problem in general due to how they were made and textured. Things tend to play much nicer on the newer models.
  7. @gomker The code that creates the shader or the map that determines how the colours are applied? I have not the foggiest clue about the code but it looks neat enough to me. The maps however...they're old and don't fit the current selection of parts in many cases, which I'm hoping to rectify...though I'm not an artist really, just indulging my creative side and hoping to not see this mod die completely through neglect on this side. My current plan is to at least get everything working with a decent base coat that doesn't cover cockpit glass...though I have a tendancy to try adding the 2nd and 3rd layers.... can largely ignore the colour scheme. It's just so I can visualise the RGB layers from the maps. At least if I put together a complete, tidy base coat set, others can add their own flair with the green and blue layers that go on top.
  8. Well, I only know about the configs I've used in the past and how to make the shader maps. The plugin and shader code themselves is well beyond me...though I can spot things that are plain English So, at this stage, what I'm seeing is if the lines starting at 113 in the shader loader source could be changed to this... case "EmissiveBumpSpec": name = "KerbPaint/Emissive/Bumped Specular"; break; ...then we will be back to the configs calling the right shaders to be loaded.....I think. I'd need to check each shader file to be sure but they look good aside from this so far.
  9. Ok, tested and using emissive bump spec no longer causes pink parts but the lights still don't function. I looked at the shaderloader source and it's now calling just straight bumpspec... case "EmissiveBumpSpec": name = "KerbPaint/Bumped Specular"; Is there a problem with the emissive bump spec that means it can't be used? I'll admit, I'm not sure how critical this is. I started just using the Emissive Specular shader and that functions well enough but I always used the bump version in the past.
  10. It can work and indeed, it used to work. Things have kind of got a little confusing with the recent repacking of the mod. I've just checked the old post where it was available and sadly the link is dead. All is not lost though, I am feeling kreative so I'm slowly bumbling through various parts and working on getting things functional. If you don't want to wait you can make your own config and paint scheme, it's not too hard just takes a bit of tinkering with notepad and a paint program. Following on from above, things have got a little messy over time so the latest download with a functional dll doesn't include configs and / or paint for some parts. In some instances this will cause parts to have a very simple "cover everything in colour" scheme. @gomker I've been doing a bit of snooping and I noticed in the source something that might be causing the EmissiveBumpSpec shader to fail. I'm not a coder but I spotted a possible typo... Line 114, there's a space where perhaps there shouldn't be. Reading through this it does make me wonder though, isn't EmissiveBumpSpec then just the same as "Alpha"? Edit: In fact, looking further, why isn't this calling "KerbPaint/Emissive/Bumped Specular"?
  11. Other than that, real plume? The half splitting technique is very useful either way.
  12. I appreciate the concern about maintaining a certain amount of realism and not making some sort of cheat mode. The way I see it with the lights particularly is, if I was actually running a space program and I want or needed to attach more lighting to a station in space, the lighting would be configured to fit those needs before launch. Also, there are actually lights that can have their colour defined in situ and even have aspects remotely controlled. Anyway, I resurrected my old module manager patch, did some editing and have added BULB functionality to the lights in my install. I can post it if anyone want's it. I would do it anyway but I'm trying to decide which thread it would be most applicable in.
  13. So a small note on "fault finding". The quickest way to determine conflicts with mods is to first make sure you have a definite method of reproducing the problem. Then, remove 50% of your mods and test. If the problem still exists, remove 50% of what remains and test. If the problem goes away, remove the mods not causing any issue and put back the ones you initially removed Test again. Repeat. If you ever get to the point where the 50% you have removed stops the problem and the 50% you put back doesn't make the problem manifest itself, you need to start dividing your two halves up (50% of each) and merging them. I hope that makes sense. Now, that said, it's clear this issue involves scatterer as the flicker is the water shader and atmosphere it creates, or at least that's what it looks like to me, so don't ever remove scatterer in this instance. Also, it was mentioned this occurs when firing engines which makes me wonder, is the Engine Lighting mod involved?
  14. I know this was months ago but I just wanted to comment on this as it was something I felt was needed a few years back due to the fact I do configure my lights to not use the default colour balance so white light is warmer. Then when adding lights with KAS / KIS I was left with no option but to use the horrible white light of stock. However, even back then there was a mod that did exactly what was being asked for and fortunately, it still exists... So, at least for now, BULB has this feature covered should anyone desire it. Oh and a belated thank you for keeping these lights alive.