• Content count

  • Joined

  • Last visited

Community Reputation

3143 Excellent

About Shadowmage

  1. The good news on this front is that there might be an upcoming project from someone (not me) consisting of a patch set to be used with RSS (but not RO) that features SSTU being used as the core of its set of parts and feature set (fuel switching, engine clustering, modular parts, etc). As I understand it, it would be an 'RO-lite' that would be intended as a rebalance for real-scale solar systems (whether RSS or upscaled stock system), featuring real-world stats and model scales for engines and other spacecraft parts (capsules, rtg, solar, etc). I haven't checked in on it in awhile but last I heard it was making good progress. I'll try to see where the project stands currently and get a few more details on it. This isn't really a 'modpack', but more of a single really large mod. Due to the use of texture and mesh/model sharing across many of the parts it is extremely difficult to have a clean separation between the different series' of parts. For example many of the engine models and textures are re-used in the various ShipCore part-series, as are the RCS blocks and docking ports. If you have a specific list of parts that you do want to keep I can probably give you a quick write-up of what all would be safe to delete/remove. Mounts will be getting free-recoloring with the next update (along with tanks, nosecones, adapters). Should be easy enough to include a silver specular map; would use the same diffuse texture merely with a different pre-set base color for the silver texture set. I'll try to play around with this next time I'm setting up plumes and let you know what I find out. Probably something simple in the patches/edits thats getting missed or messed up. Could also be the known error with the kerolox plume configs/patches in RealPlume itself.
  2. Thanks I'm not sure how to -patch- the config files for plumes, have never tried. You would need to find a way to make your patch run after the SSTU patches, but before real-plume does its bit. Which... I'm not really sure how that would work considering how the existing patches are structured (with merely a BEFORE[RealPlume]). Editing the existing files however should be quite simple -- find the RS-68 and where it says 'Hydrolox' change it to 'Kerolox'. Should be as simple as that. Four places that need changing; two where 'Hydrolox-Upper' becomes 'Kerolox-Upper'; and two where 'Hydrolox-Lower' becomes 'Kerolox-Lower'. Or.. just change the existing RS-68 patch/config to this (untested): @PART[SSTU-SC-ENG-RS-68]:NEEDS[RealPlume&!RealismOverhaul]:BEFORE[RealPlume] { PLUME { name = Kerolox-Lower transformName = RS-68-MainFXTransform localRotation = 0,0,0 localPosition = 0,0,2.4 fixedScale = 2 energy = 0.6 speed = 0.6 } PLUME { name = Kerolox-Upper transformName = RS-68-RollExhaust localRotation = 0, 0, 0 flarePosition = 0, 0, 0.65 plumePosition = 0, 0, 1.0 fixedScale = 0.25 energy = 1 speed = 0.5 } @MODULE[ModuleEngines*],0 { %powerEffectName = Kerolox-Lower %runningEffectName = Kerolox-Upper } } Note, however, that the RS-68 is a -hydrolox- engine, and is configured for the hydrolox plume already. I'm not sure if the in-game visuals for RealPlumes 'hydrolox' plume match up with the real engine, but it is already 'technically' setup correctly according to the naming.
  3. One of the best transfers and maneuvers I ever managed to wrangle, was this Jool insertion and multi-moon encounter setup. Capturing at Jool and getting flybys of 4 out of 5 moons for <100dV, no dedicated insertion/braking burn (and the fifth moon likely doable for very little extra dV, once I get closer and can get more accurate trajectory predictions). This was all plotted from Kerbin orbit, and the maneuver shown on the dV widget is the ejection burn. Haven't gotten back to the game in a few weeks, but when I finally do, it is going to be one busy little probe returning scads of science from all the flybys and still having a few k of dV left in the tanks. Apparently I misplaced the rest of the screenshots showing the rest of the flyby encounters. Sad. I'll have to load the game up and see if it is all still in place
  4. Well then sadly, I cannot see how this would be of any use for 'module-swtiching'. (I would probably label it more properly, as a 'module disabler') At least two things are needed for any proper implementation of 'module switching'. 1.) The module is only present on the part when it is actually supposed to be. This means it is not 'there but simply disabled'. It does not 'still run its init code even when disabled'. The module is either present when it is needed, or it is not present at all. This is for both performance and compatibility reasons (less modules and update calls = less overhead for disabled modules = higher performance; modules being added/removed properly = better compatibility with other mods, as those mods won't think a part is an engine just because it has a 'disabled' engine module on it). 2.) Config support -- to enable dynamically-added/enabled/disabled modules to still be patched through MM, and still have access to all proper config-file based utilities. This is needed for widespread and general compatibility with the modding community. From my various and sundry attempts at developing a proper module-switching implementation I can tell you that there are several problems that will need to be fixed in stock code before it can actually be implemented in a non hacky fashion. Mostly regarding to part module loading/saving mechanics and how part-modules are restored from a combination of prefab and persistence file. If you are not working towards a proper implementation of module-swtiching, then I wish you the best of luck. Not something I would have any interest in or use for, but there might be others willing to live with the constraints.
  5. One major problem that you are going to run into is that the 'moduleIsEnabled' flag only works on a handful of stock PartModules. Notably it does not work with ModuleEngines*, and several other 'common' part-modules. Second, even on the modules that do support 'moduleIsEnabled', they often will do initialization even when disabled. This can cause problems if, for example, the model transforms that they rely upon are not (yet) present in the part (e.g. from mesh-switching); the module will attempt to initailize, and then null-ref partway through. I would say that before you could make much meaningful progress on -this- mod/question, those two problems need to be fully fixed in stock. -All- partmodules need to support the 'moduleIsEnabled' flag, and they need to only initialize when the 'enabled' flag is actually enabled (which means they will need a way to re-initialize when the user toggles that flag in the editor/etc).
  6. Holy cow... after only like 3 months of it bugging me, I finally found a solution to the seemingly misbehaving shaders that would cause white pixels on some edges when anti-aliasing was enabled. Silly Unity de-normalizes the surface normal when passing it between the different shader functions, which causes problems with the specular lighting calculation, resulting in... bad/ugly stuff as can be seen in the image below. Now, this is actually a problem with the stock Unity and KSP shaders as well (though nothing I can do to fix those). I thought I was going nuts, having researched the problem 3-4 times, tried swapping to KSP and other Unity shaders, rewrote my own shaders multiple times, tried different textures, anti-aliasing settings, so many things. Turns out its just a bug in Unity. Thankfully the fix is easy to adapt to the existing custom shaders. Not the most performant bit of code, but I would rather it look good and not have random white pixels driving me crazy. After fixing up the shader code, it now looks like this (even when zoomed out it still looks very much improved): As a bonus, this also fixes how some smooth-shaded objects had some sort of odd sided bias; they should once again look cylindrical instead of....whatever they were. The 'silver' tank texture especially benefits from this. Solar panels and other high-poly parts should also see quite an improvement.
  7. Along with the rest of the tank/texture reworks, I've spent a bit of time finishing off/cleaning up the spherical tank set(s), including a new set of no-frame models and entirely new geometry for the framed models. Each body set now includes three switchable end-caps/adapters (which will also be available on standard tanks as nose/mount adapters I think). Will include texture switching and recoloring capabilities for the spherical tanks, with at least two different mask options. Tank model reworking is all done I believe, as is the actual tank texture work. Need to finish up all of the config work for the new texture setups, and possibly create a few more masks. After that will be reworking all of the engine mount textures and creating masks for them. Lastly will be cleaning up/finishing the recoloring GUI and presets system. That should hopefully wrap up the recolorable part rework, at least its initial offerings (tanks/adapters/mounts). I do want to expand it to include some other parts in the future, but those will come over time
  8. Your particular problem is actually solvable -- there is a distance-setting in PhysicsGlobals that determines the effective solar power at various ranges. float distMult = (float)(vessel.solarFlux / PhysicsGlobals.SolarLuminosityAtHome); Now, the 'PhysicsGlobals.SolarLuminosityAtHome' is the value that I'm referring to, and it should be configurable through the stock config files, or possibly through Kopernicus (not really familiar with that one to know). I'm not sure what the default values are for the stock system, or what the adjusted values should be for any given scale, but taking a peek at the existing configs should probably make it a bit clearer.
  9. That would appear to be a Kopernicus problem, with the way they re-parent, re-order, and re-arrange the CelestialBodies. Stock code (and stock-compatible code) expects CelestialBody[0] to always be the Sun (kerbol). Kopernicus-enabled mods often re-arrange the CelestialBody array/list to put a black hole/other star at the center of the world. Thus all radiators/solar panels align to whatever the new replacement body is (in your case, 'The All', whatever that is). Essentially the solution to this needs to come through stock code. There needs to be a way to specify the current 'main solar body' so that solar panels can look at it, and radiators can look away from it. Until such a time as this is fixed in stock code there is little that I can do to properly solve the situation (there are some hacky workarounds, but I prefer to not use hacky stuff if at all possible, and even these work-arounds would not fix the problem in setups with multiple stars).
  10. This capability already exists in the stock code + configs; stock SRBs fully support adding a thrust-curve to their config file. All it takes is a simple patch to add the thrust-curve data into the part config files. Now.. changing in the VAB / editor -- that runs afoul of the stock 'no complex GUIs' mantra. Absolutely doable (I have a setup for exactly that in SSTU), but not without adding additional fairly complex GUIs, which is something stock KSP seems allergic to.
  11. Slowly working through the back-log of stuff I've got WIP, finished off the geometry of the LMDE: Mostly unwrapped already; few new meshes to unwrap, but nothing major (mostly piping, and those are easy). Going to combine the LMDE and LMAE onto a single texture I think, likely a 256x or 512x. Think I have the updated geometry finished for the MFT-D tanks (and soyuz nose-adapters). Debating on if I want to keep the mounting plane straight or angled. Neither is technically 'correct' as on the real R-7, the engines themselves are offset inside of the mounts; whereas I have modeled the mounts as being straight. Hoping to finish up the textures on these throughout the week/weekend.
  12. Which landing gear are you referring to?
  13. Interesting.... I haven't noticed any of the SSTU parts causing instability, but they very well could be (I certainly haven't tested all of them in every possible combination). Is this reproducible; does it occur every time you are focused/flying the station? Is there a craft file / save file that I could take a look at?
  14. All of the code for enabling the station-core endcaps to contribute to volume is already in-place and working (its the same code that handles the core volume), it merely needs to be enabled in the configs. All of the adapters/etc already have their volume specified in their model-data config. It is intentional that the adapters do not currently contribute to usable volume of the parts, in order to maintain the specified balance regardless of the configuration (e.g. to make sure the DOS modules always have the specified dV). But if you wanted to enable those features in your games, you can add the following lines to the SSTUModularStationCore module in each of those parts config files: useAdapterVolume = true useAdapterMass = true useAdapterCost = true The first line controls whether adapters will contribute to the available volume. The second line controls if adapters will add additional dry mass (as specified in their model-data). The last line is the same thing, but for cost (uses the cost specified in the model-data config).
  15. Old 0.90 Minmus station: Jool Mobile Shipyard (also 0.90): Lots of part welding on those first two stations. 1.2.2 Duna Transfer Craft (has docking ports and crew capacity of ~60, using as a research lab until its transfer window comes up, so counting it as a station...). Uses real-world density for its LH2 tanks, which is why it is so large. Dry = ~200t, wet = ~400t. Powered by 5x NRV engines converted to run on LH2. Carries a small re-usable duna lander in a saddle-truss. Maneuvers like a beached whale. Custom shader on the large solar panels allows for back-lighting / light bleed-through: And a 'real' station from early in my last career game -- Minmus Station Alpha. Its a hodge-podge of modules that were added as they were unlocked. About 3/4 of it is scheduled to be de-orbited (as soon as the attached lab is done processing). Docked is a small lander (left), and two crew-transfer vehicles (the Orion pods, one for the current crew, one for the just-arrived crew; usually only one docked at a time). I've built many other stations, but it looks like those are all that I have screenshots of