Akira_R

mmmmm.... no definitely not confused there. This is what you are looking for no? Sorry for the kinda derpy plane just threw it together real quick like. And I don't think KF-C has any gear that operate like that gif.

That's it!!! Take a look at KR&D, like I said, with a bit of abstraction you could take this idea and turn it into a more complex version of KR&D. Here are my thoughts on that matter Implement a new set of resources, not resources your ships use but the resources we have in the space center (Rep, Science, and Funds) for the sake of not getting confused lets call them Currency for the remainder of this post. These Currencies would be various types of metals, you could aquire them by purchasing them for funds, or mining and recovering an equivalent in flight resource, this resource would give you the corresponding Currency instead of funds when recovered. An example for how these Currencies could be used would be to have an upgrade point system, a "lightweight combustion chamber" upgrade would cost a certain amount of say Aluminum and Titanium Currency. This "lightweight combustion chamber" upgrade could then be applied to an engine in the editor and it would decrease it's weight. A "heavy reinforced combustion chamber" could increase both vac and asl thrust and isp by some amount but also increase part weight. You could add as much complexity/realism you want into this upgrade point system, you could have variety of upgrades that are only applicable to certain types of engines such as reactor casings or something for nuclear engines, upgraded electrodes for electric engines etc., exotic alloys/currency metals that give ridiculous performance improvements but are only minable on Laythe or Eve or Eeloo, (and remember they have to be recovered), integration with other mods that add things like part failures etc. While what I have described above would still be a massive undertaking, especially in the mode compatibility department, it is definitely feasible.

It's an awesome idea, there is a game out there that does this, can't remember the name off the top of my head but I know Scott Manley did a video on it. It gives the option to select material used for combustion chamber/nozzle/pumps etc. select size and shape of the combustion chamber and nozzle, select fuel pressures and such, and you can do this for every part in the game, guns, reactors, hulls etc. However trying to accomplish this in KSP would be an absolutely massive undertaking and not one that just one or two developers could pull off. You are essentially asking for someone to develop an entirely new game and integrate that into KSP. Just off the top of my head there is one glaringly massive problem that would need to be overcome and that is how KSP loads and handles parts. The ability to generate at runtime a new part cfg is something that, to my knowledge at least, no modder has been able to achieve. The closest thing would be Shadowmage's procedural parts in SSTU, and that took an incredible amount of work in his(or hers I don't actually know) plugin to get already loaded parts to generate new MODULEs at runtime and change parameters already loaded by a MODULE. I feel it would take the combined efforts of the likes of ferram, sarbian, Shadowmage, Angel-125, and Rover Dude to accomplish something like this. Sorry for being such a negative nancey here, it's an insanely cool idea that sounds super awesome, but is absolutely gargantuan in scope, at least as described. If you abstract things a little bit it could work though. But you would essentially just end up with a more complex version of KR&D... Which isn't a bad thing in any way, wanting different levels of complexity is why we have so many versions of life support mods.

Kerbal Foundries - Continued has some adjustable landing gear that deploy exactly like that

As in are they supposed to be working currently lol, and yeah the Merlins and the LR-87, I wasn't at my computer at the time of writing that post.

@Shadowmage are the Space X engines supposed to have emissives? Because they don't have any in my install currently (at least the first two booster engines don't) and the RL-10 engines don't seem to have them either.

I haven't had this problem with any of my planes using the adjustable landing gears, but I'm not on the most recent version of kspWheel, will dl tonight and check

Is the current dev branch on git fairly stable? Is it save game compatible? Last question, any chance we will get a release of the new version for 1.2.2?

Might want to check out SmokeScreen, it will definitely allow you to do what you are trying to do, and for a bunch of pre-made engine effects pick up RealPlume Stock. Take some time studying the configs included in RealPlume and the documentation available in the SmokeScreen thread, it's a lot of stuff to figure out but once you get the hang of it you can do some pretty cool stuff.

Might I suggest taking a look at ProbesPlus? It adds a lot of gorgeous probe parts to the game and a number of very early solar panels and such that do have disadvantages, specifically deployable but non tracking panels and not having very great Ec/s values. Now I can't speak much to it's balance necessarily, I play a very heavily modded 3.2x Galileo's Planet Pack game with lots of my own tweaks to parts and moving things around the tech tree, and generally start my career games off with very low tech sounding rockets and am not launching any probes until I get to around the third or fourth "science tier", but the stock panels aren't unlocked until much later on (160 science I believe?) and I had the ProbesPlus panels shortly after or even before I got to orbit and I didn't move any of them around. I didn't unlock any tracking panels until well after I had already landed a few probes on Iota and sent many other science missions to Iota orbit. I find it looks fantastic along side the incredible SSTU parts and is my go to mod for probe and science parts now since the death of AIES.

@Galileo Bring it on!!! I already upgraded to 32Gb of RAM in my monster!!!

@VentZer0 Given @ferram4's above reply I wonder if an interim solution might be to attach the rail under the wing tip and move it using the offset tool out to the tip, would that still cause the wing to think it is closed at both ends?

Welp I was hoping for something simple like the right side was voxelizing weird after reattachment, I remember there being some issues way back with symmetry on the procedural wings and maybe that was rearing it's head again but it all looks good... unfortunately I don't have any other ideas... Part of me wants to say it's probably not an actual issue with FAR itself, I personally haven't had any issues so far in the dev build, it's been extremely stable and all odd aircraft behavior has been identified as my own design flaws, but this does seam weird. I don't have B9 procedural wings installed so I haven't had a chance to test them. I wonder if you were to readjust the shape of the leading edge after it's reattached so that the leading edge ends up in the same location as before you reattached it if that would fix the problem? It seams like such a small amount of change to cause such a drastic result in flight performance but who knows... Also no idea RE the rails...

Can you provide some screen shots with the debug voxels showing, of both sides of the plane before and after making all the mentioned changes, especially with close ups on the changed parts, also if you use the offset tool to close the gap instead of reattaching do you still experience the change in handling?

Maybe report your system specs over on the Smoke Screen thread: So far it looks like all of us that have reported the issue are using Intel CPUs, we are both using nVidia GPUs but one guy that reported over on Smoke Screen is using an AMD GPU.

Yeah I am doing this, however the whole reason sarbian implemented the shuriken particle system was because it is supposed to improve performance (at least that is what I gathered) however it seams that on some systems currently it has worse performance, my intention in reporting the lower performance was to just provide sarbian and NHawks with more information to use in the continued development of their mods and possibly help with other user reporting poor performance

Sooo delete the patch .cfgs for the Buffalo ASET IVAs?

Where can I find the config for SSTUNodeFairing? Clearly I'm blind or something because I can't find a .cfg or .xml file for that I wasn't aware of holding down SHIFT, I will give that a try, it's a fresh 1.2.2 install so there shouldn't be any legacy settings in there but if I'm still experiencing problems with it I will try deleting the settings file, thank you. EDIT: Oooohhhh derp, took a look at the source and realize now that I need to add the topDiameterIncrement and bottomDiameterIncrement nodes to the part cfgs, thank you Shadowmage

@Shadowmage I have couple of hopefully small feature requests. First would it be possible to expose a diameterIncrement variable in the part cfg for the SSTUNodeFairing module? Currently we can set the diameter increment for engine mounts, which is fantastic and I have set mine down to 0.3125, however the auto-fairings that are generated on these engines do not have as fine of an adjustment range (I am assuming this is handled by the SSTUNodeFairing module). Second for the interstage decouplers would it be possible to add an adjustment for "extra height"? Currently we can adjust the height of the decoupler which also adjusts where the attachment node is, the extra height slider would have the same effect on the model, making the height of the shroud higher, but leave the attachment node untouched. This would be very useful for nesting upper stages or other things down into the interstage, this can be partially accomplished with the stock offset tool however the offset tool has significant limitations, specifically when you try to move the center of mass of the attached part down below where the attachment node is, the attached part gets forced off to the side and can't be moved back to center. The change to the SSTUNodeFairing module would almost not be needed if the extra height feature could be added to the interstage decoupler as one would be able to simply disable the fairing on the engine and use the interstage decoupler as a fairing when there are odd ratios between the upper stage and lower stage diameters.

That's unfortunate, sounds like something is wrong there though, I'm on a i5 4690k and a GTX 980ti with 100+ mods, eve, scatterer and GPP and I maintain 60 fps even after 1-2 hour long flights around the planet. Now I'm not one the newest scatterer version, just the one bundled with GPP so maybe that is it.

I5 4690k @4.5GHz GTX 980Ti OCed 32Gb RAM Anything else?

I didn't actually look in the logs but the debug menu showed no spam during the performance hit, I'll do some more testing to see if I can narrow anything down, the lag seemed to go away once out of atmosphere but by that point I was using a different engine that only pushes out 400-500 particles.

Hey @sarbian I'm experiencing a performance issue on my system with the shuriken particles, please see my post here: Now that was using the 2.7.1 version of smoke screen, I have since updated to the 2.7.2 version of smoke screen and it has improved performance of the shuriken particles significantly, however I still find that the old particle system performs much better at least on my system. With the same launcher and max particles set to 3000 (which this launcher will provide) I get 26-30 fps with the shuriken particles and 55-60 fps with the old particle system. This really isn't a big deal as I can just change all the configs in real plume back to using the old system, I just thought the information might be useful to you, are there any logs I can provide that you would be interested in seeing?

Ok so after updating to the newest version there is a marked improvement in the performance of the shuriken particles. However on my system the old particles still outperform the shuriken particles by a significant amount. Using the same launcher and every thing and in both cases the max particles are set to 3000 (which this launcher will produce) I get 26-32 fps using the shuriken particles and 50-60 fps using the old particle system. I mostly am letting you know in case others in the future come with complaints of poor performance, it would be nice if you could maintain two sets of configs one using shuriken particles and one using the old ones, but obviously that would add more work and headache for you and I in no way expect this. I am going to bring the issue up over in the smokescreen thread as well, maybe sarbian can figure something out.

I am greatly saddened to hear that city lights are not to be included It feels so incredibly lonely up in my space station around my home planet whizzing over a black void in the night, is there any chance that you could be convinced to include these city lights in an optional separate download? Iv'e been contemplating putting some kerbin city lights onto Gael, even though nothing will be even close to lining up it will at least not feel so dead.