• Content count

  • Joined

  • Last visited

Community Reputation

2956 Excellent

About Shadowmage

  • Rank
    Sr. Spacecraft Engineer
  1. There might be a patch that you can add/create that will disable that mechanic. Something like: @PART[partNameHere] { %applyShieldingExtend = false } Replace the 'partNameHere' with the name of the part that you want to 'fix'. Refer to for more general information on module-manager use/patch creation/setup.
  2. Merlin engine emissives: Also updated the LR-81s for a bit more natural color-scheme (as shown on the Merlins above)
  3. Interesting bit of trivia: SSTU has over 25,000 lines in its source files (how many of those are 'lines of source' is open to debate). Also... Working on the emissive for the Merlin line of engines now, should probably have those wrapped up today / this evening. And has anyone figured out how to add Imgur albums (again)? They appear to be working again from some posts in the 'What did you do today' thread, but I haven't seen how to add them yet.
  4. Derp; yes That is what I get for posting without the info in front of me.
  5. Work on the RD-171 engine is nearly complete. Model geometry is finished anyhow. Need to clean up some of the rigging transform naming and create the configs for it. Managed to re-use the existing diffuse+AO map with quite a bit of 'fudging' in the model. Its not 100% correct (the AO), but is close enough for this use (you would be hard pressed to spot the 'errors'), and allows for re-use of the existing texture. Hoping to pull off similar for the -190 variant as well, so that all three derivatives can use the same single set of textures.
  6. Yes, this could be caused by the SSTU-OptionalPatches folder. It contains patches to delete most of the stock fuel tanks and engines (as they are merely part-list clutter when SSTU is installed).
  7. My method is already similar to that (only I did it first , and have been using this method for at least a year already). I don't have to mess with any 'animations' for my emissives on engines. Merely set them to the proper shader/material in Unity for the initial .mu export, and add the SSTU engine-heat emissive module to the config, and it uses config defined curves to adjust the emissive output. The engines listed above -- already have placeholder glow textures setup on them / were exported with placeholder textures -- literally all they need is for the texture to be created/finished, and they'll start to glow (config is already setup as well). Looking through the asset files it looks like the LR-81, Merlins, SRBs and SuperDraco engines are all currently using placeholder emissive textures (128x black images).
  8. Define 'supposed to'? (And I'm guessing you are talking about the Merlin line of engines?) In a perfect world (where I have infinite time), yes, they should have emissives. However it is already known that they don't. A few others as well, LR-87 LR-81 and Superdraco are also lacking emissives, and I think one more that I can't remember off the top of my head (one of the more recent engine additions). RL-10 does have an emissive texture (all but the RL-10-A-5; it technically has as well, but is mostly on the lower portion of the bell that was cutoff). If they are not working then something has broken on the config level. Feel free to open up an issue ticket on the repo regarding this; likely the only way I'll remember about them, which is they only way they'll get done.
  9. File a bug-report on the KerbalFoundries repository regarding that (missing landing lights) and I'll see about getting them added back onto the parts. I think that is one of those features that got missed during the reworking of those parts (I never used the originals, so had no knowledge of what features were originally present). --There is a spot on the legs for an emissive animation for the light, easy enough to add in the light transforms and a bit of plugin code to toggle it on/off/change colors (or perhaps can use the stock modules). Open up a bug report / feedback ticket regarding the multi-wheel side-folding landing gear, and I'll see what I can do. Probably at least a few weeks out, but depending on if I can re-use some of the other existing models (with changes), they might not take too long. And now back to your regularly scheduled Airplane Plus thread
  10. Thanks, I'm thinking it might be related to the part I was testing with having multiple wheel colliders on the same part, as I certainly remember testing it with the ALG parts without any problems. At least that lets me know where to start looking
  11. Last night saw the final finishing and figuring out of the motor power equations. Nothing should be changing much for power consumption (the numbers calculated are 'correct'), but the method to arrive at those numbers is so much cleaner and easier to understand. The solution ended up coming to finding the intersection of a line and curve within a specific domain (the peak efficiency rpm%), and using that intersect point to calculate input power at a known point (where the efficiency is a known value); from there finding the min/max power draw is simply a factor of applying a line/slope from that point. This cleans up and removes the 'magic numbers' that I had previously calculated/put together to 'simplify' the power calculations. True, the calculations are a slight bit more complex now, but considering they only need to run once during part initialization, I'll gladly take 'correct' over 'simple'. This means that BonVoyage should be able to have a much easier time deriving the power-use stats for any given KSPWheels parts in future releases. Also means I should be able to give more accurate display values for the part info (editor part list) and action windows (editor/flight). I also spotted a worrying bug (that I thought I had already fixed) -- one of my test craft would refuse to be recovered on the runway. Only occurred after I had retracted and re-deployed the landing legs (was actually deployable wheels in this instance, but legs should have the same effect). Is there anyone else who has experienced and/or can confirm this bug? (It could just be a quirk of the part I was testing)
  12. *Goes to start working on SSTU for KSP1.2.9+, and realizes that SSTU depends on ModuleManager, which is not yet available for pre-releases* *sigh* ... well, I tried to do something productive today... On the bright side there were only two compile-time errors from the upgrade to the 1.2.9 libraries, neither of which should cause any sort of functional problems (both related to display localization). The downside is that I won't be able to test anything until MM is available (as SSTU relies on MM to manipulate a ton of the configs for shaders and model setups; could recreate those configs by hand, but it would be an extremely long and error-prone process). Hard to do pre-release testing when you can't actually do it. Can only pray that there aren't any modding-api related bugs that need to be found/reported/fixed in the pre-releases, as it certainly won't be me finding them. Can't hold it against Sarbian though, I understand why he holds back releases during the ksp-pre-release period. Understanding sadly still doesn't allow me to test anything though. Oh-well, back to playing with engine geometry I guess (working on -170 and -190 derivatives), and contemplating custom mount options. Perhaps I'll try again next week.
  13. Updated release is available: A couple bugfixes and plugin side enhancements, and adds the RD-180 engine as usable in-game (might still see a few changes)(model by @blowfish). See the above link for full change-log and downloads.
  14. Updated release is available: One new part courtesy of @TiktaalikDreaming (Large folding hydraulic leg), and several bugfixes and minor improvements to a few modules in the updated KSPWheel plugin. Should not be any breaking changes in this release. See the link above for full change-log and downloads. This will likely be the final release for KSP 1.2.2, future development will be switching over to the pre-releases in preparation for 1.3.
  15. Updated release is available: Several bugfixes and minor improvements to a few modules. Should not be any breaking changes in this release. See the link above for full change-log and downloads. This will likely be the final release for KSP 1.2.2, future development will be switching over to the pre-releases in preparation for 1.3.