Shadowmage

Hi all; Curious if anyone has designed electric rotocraft capable of flying on Duna? Helo, coax, quad, tilt-rotor, std fixed-wing, whatever. Would love to see images. Trying to get an idea of what is needed for allowing for aero flight on Duna. I built an excellent little tilt-rotor that flies great on Kerbin; ascends stably at ~1.5 degree of prop pitch in vertical mode, and can do ~150m/s in airplane mode. Sadly, when testing on Duna the best I could get is a semi-controlled 30m/s vertical descent. The props didn't seem to produce much/any lift at any sort of RPM or blade pitch; craft dropped at 30m/s regardless of 0-degree, 40-degree, or 80-degree of prop pitch. I only tested the one iteration on Duna though. It used 2x the smallest airplane prop per rotor (4 rotors total). My next test will be a 4-bladed variant; possibly just needed more actual lift? I also experimented with using helicopter blades for the tilt-rotor blades. Worked really well in helicopter mode/vertical ascent (in Kerbin testing at least), but the max speed in airplane mode was abysmal at something like ~35m/s. Anyone have any luck at Duna rotorcraft they would like to share/show-off?

Thx for the link; apparently that is just taking me to the dropbox home page. Not sure it uploaded properly? Would have to find some method other than an iris; that is one of the least space-efficient mechanisms I can think of (and absolute PITA to model). Interesting concept, but really not sure how to get expandable heatshields that aren't inflatables. Would have to see some source/references, as nothing is coming to mind for me.

Thanks for the report. Indeed, is a bit of a 'known issue' regarding shaders with OpenGL (OSX/Linux). I -thought- I had it fixed in the latest versions, but apparently may have missed something. Can you confirm that you are using the latest version of TU? And is it only a few specific parts, or most/all parts?

Hi, and welcome to the forums Thanks for including your log file; should help us track down what the problem is. From reading through the log, you've got something messed up with your installation; duplicate folders, incorrect paths... really bad stuff (but probably easy to fix) 1.) It is finding duplicate resource definitions. [WRN 11:42:28.168] PartResourceDefinition list already contains definition for 'Metals' [LOG 11:42:28.168] Resource Metals added to database 2.) it is finding duplicate part-upgrade definitions: [ERR 11:42:28.125] [Upgrades]: Error! PARTUPGRADE named SSTU-MFT-D6already added! Skipping. 3.) Umm... this path is incorrect (likely causing the other issues): Squad/SSTU-0.11.47.159/GameData/SSTU/Data/ModelData/ModelData-MFT-Adapters-Cone/Adapter-3-2-Long The correct installation path for mods is: <KSPFolder>/GameData/<ModFoldersHere> So, for SSTU that is: <KSPFolder>/GameData/SSTU I believe the path/installation errors are causing all of the other issues. If the above is not enough to help you sort it out, please let me know and we'll dig into further instructions.

Not as separate or stand-alone 'parts'. The models and textures are freely available to use and reference if you have SSTU installed; you could write part-configs for them to make them available in the parts menu. You could also adapt your favorite mod parts to use the SSTUModularPart system, but that is far more work and requires a good understanding of KSP modding, configs, and the ModularPart system itself, and has a potential to break existing craft/vessels using the part.

Sure; just drop a link to it on dropbox/etc. Huge logs are what 'find' features are for

Hi, and welcome to the forums Parts failing to load can be caused for a number of reasons, the most common of which are missing dependencies, mod conflicts, or incorrect installation. I'll be glad to help track down the problem and find a solution, but I'll need a little bit more data to know what is going on. To start, please upload a copy of your KSP.log file to a file-sharing site or cloud-host (DropBox, OneDrive, pasteBin?, etc), and post a link to that file here. The log file should contain enough information to identify the problem, or at least where to look next.

Pretty much this. You can't fix it in the craft file, as a control point requires a reference to an object transform in a part, and that all needs to match whatever was specified in the control module for that part. If things don't match up, bad things happen. But you can add a -new- control point oriented in the proper direction, and use that as your 'control from here' part.

Using stock, or realplume? And log files (specifically I'll need the KSP.log file)? Likely there is some mod version conflict or out-of-date config file somewhere causing grief.

I'm not seeing any TexturesUnlimited patch sets there, except for links specifically for Procedural Fairings and Feline Rovers. The KSPF mod from that page is something else entirely, and not related to TU or recoloring. You might have more luck trying the patches from here: https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/ But keep in mind, those are quite a bit out of-date last I checked, and I cannot guarantee that they will work entirely. On that note, I am slowly working on putting together a proper patch+texture set that adds basic recoloring to stock parts, but it is very early in the design process. It is based on the mask textures from the link above, but provides entirely new configs that utilize the latest TU shaders and features. I might start offering downloads of this in the near future while it is still in development after I get a few more parts added (possibly even sometime over the weekend); if so, I'll post links here. No guarantees though as I'm still determining if I want to do WIP releases, and even if this is something that I want to continue to completion (currently at part #21 out of 327).

Couple good images from some recent playtesting of SSTU: Scatterer and EVE for environmentals, RealPlume for the flames, and TexturesUnlimited for part-textures and reflections.

Link to that patch set? When I last looked at Electrocutor's patches, he wasn't distributing any 'general' patches anymore that I saw, only for specific mods. (At one point, yes, he had a patch set that would add a form of recoloring to nearly all stock parts)

You'll have to get that information from whichever config/patch sets you have installed. At this time I do not include any patch-sets with the mod, but there are a couple linked on the front page from other authors. If you haven't installed any patch-sets, then there will be nothing to list. (installing TU, by itself, does nothing; it relies on mod authors to provide their own configuration files or patches) The 'easiest' way to get recolorable parts is to install SSTU ( https://forum.kerbalspaceprogram.com/index.php?/topic/117090-wip17x-sstulabs-low-part-count-solutions-orbiters-landers-lifters-dev-thread-11-18-18/ ), and use the parts that it provides. Pretty much the entire mod supports recoloring. Aside from that there is TexturesUnlimitedRecoloringDepot that provides patches for stock and a few mods' parts (may be a bit out of date, but should mostly work) -- https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/ Unfortunately not many mod authors have been receptive to creating or providing TU patches or configs. Please let me know if there was any more information I could provide;

The recoloring button is present on individual parts (in their right-click menu), and only those parts that have been patched to support it.

@Geonovast There is no issue in Blender/Unity from self-clipping geometry as far as physics are concerned. Clip away. Same thing with using multiple colliders for a single part -- they can intersect and clip as much as you need. Now, hidden faces are often still rendered to some degree, at the very least a culling/depth test on the fragment, so they do add some minor overhead to rendering (fill-rate based), and should be avoided and minimized wherever possible. Also note that it is often bad to use the Blender Boolean tool (it does have uses, but simple intersections are not it). The meshes created from cutting/joining are so far from optimal, they make me cry (so many useless and skinny triangles created). Much simpler to intersect the geometry and deal with a bit of extra overdraw than to render dozens of un-needed triangles.

Strangely I'm able to use the MJ landing assist for biome-hopping just fine. Strip-mined Minmus just a few days ago using this technique. This is how I do it personally: While still landed, select your new destination using the landing guidance 'select target' function. Manually loft yourself onto a trajectory that gets you somewhat close to the target Wait until near or just after AP Press the 'land at target' button on the landing guidance window. MJ will perform a course correction, and then initiate suicide-burn mode. Now.. I should also mention that I'm using a slightly older version of MJ. Not sure precisely how old it is (prob. from KSP 1.6 era?), but it still appears to function. Perhaps something has changed in recent MJ versions that breaks this workflow?

I don't believe in the stock VAB part-count limits. They make zero sense to me, and I would not intentionally handicap a player by artificially adding more parts. I would be happier if that arbitrary and nonsensical limit were removed from career entirely, especially in stock where 'part stacking' is a mandatory thing. Its almost like they want to actively punish you for trying to design a well functioning craft. The mass and size constraints make more sense -- you have a limited size available in your VAB (and its doors/hoisting equipement), and your launch pad can only take so much weight / so large of a rocket. But logically you should not be prevented from launching a rocket just because you made a fuel tank 2 meters longer (e.g. added a stacked tank, +1 part count), or add a bunch of science bits (+6 part count), but are otherwise still within all other size and weight limits.

Just starting to really play around with the robotics parts myself. Certainly some interesting prospects become viable that were difficult or impossible previously. Now, to take that ramp, and add some further leaves to it; both length and width (and somehow balance it all). That would be the 'holy grail' of part-count reduction, something that I've termed 'dynamic part-welding' in the past, but is not really possible in KSP due to how some of the rest of the code is structured (expecting one rigidbody-per-part). It would be exactly how I would do it if I were to write the parts system from scratch, but at this point I don't think it is really possible to retrofit such a system into the existing code. Might still be workable to some extent, but it would mostly depend on how the stock KSP code treats parts (and rigidbodies) on collision -- there would need to be some method to 'split' the parts prior to collision handling for things that would cause explosions. And I'm not sure where else in stock code that the PartModules (and/or flight-integrator?) might be expecting one-rigidbody-per-part. Hmm... might be worth some further investigation at some point. Really don't think it would work out, but if I could get it working, opens nearly limitless options for extreme craft design. No more part-count limits due to joint-physics, and instead the upper bounds on FPS would be defined by the number of colliders in use and other KSP 'per-part' systems (aero, thermal).

Part of my problem with these parts is exactly that ^^. Those blades in your image do not look like 'zero pitch' to me -- that looks like it is mounted precisely at the angle it should be to produce gobs of thrust in a static test (based on the tip of the prop, looking at the airfoil shape and orientation). However, you are saying that is the 'zero thrust' configuration for these parts? (*smacks head*) Perhaps I've just spent too much time playing with RCs (slow-fly in particular), and have too many expectations based on that (where the tip of the prop is nearly edge-wise to the airflow), and with the above information I might be able to get something working. Just need to remember that 'mounted 'correctly' = 0 thrust', and in order to actually generate thrust I need to mount them at 'chopping lots of cheddar' angles. Pretty much this. Or more precisely, for my purposes, an in-SPH indicator of potential thrust output direction vector at current mounting angle and current engine rotation direction. So I can adjust angles and deployment while in the editor and get an idea of thrust output. Bonus points if they can make a 'wind tunnel' widget where you could specify the oncoming simulated airstream speed (and direction?), so you could test the needed pitch for specific airspeeds (and performance at various velocities). And as you mentioned, symmetry... some method is also needed to not have to adjust individual blades, one at a time. I haven't been able to get them to work well with symmetry (esp when using the attach nodes), so mostly have to resort to placing them one-at-a-time, which then mandates adjusting deployment/etc one at a time. Painful for a pair of 2-bladed propellers for an aircraft, and over-the-top-far-too-much-work when trying to create a functional quadcopter.

As promised, a small collection of screenies. Nothing too spectacular as far as craft design goes, just some rockets, landers, and an airplane. No touchups or edits done, only graphical mods are TU, Scatterer, and EVE. Early career orbital rocket; 2-stage (entire rocket shown). Second launch of the career. Stock coloring on the capsule closely matches the SSTU black, giving a fairly unified aesthetic: First Mun-Flyby-Return probe (includes sample return canister For Science!) (is that Kerbin-shadow on the Mun? IDK): Playing with the new deployables: More stuff, mostly chronological..: Example of my craft design process -- fairly plain and simple rocketry: Dying-light shot of a minmus probe on its way out: Extremely short-stop science-mining aircraft. T/O = ~15m/s, can climb vertically, and can land on a postage stamp (stall + flop) Heaviest launch of the career - secondary module for a station - fully fueled fuel depot segment (~40t) I don't remember which launch this was, but the lifter uses an unusual triple-engine configuration. Upper stage from something: Last few seconds of a suicide-burn landing on minmus. Basically the same lander design I used for the Mun (with additional solar panels and more science!); grossly over-engineered, and can almost biome-hop the entire planet with one fueling. So.. yeah.... the above I think exemplifies why I don't include any example craft designs in SSTU. Nothing is standardized, everything is purpose-built-for-mission, and there is nothing really surprising in any of my designs. Certainly SSTU can be used to make more complicated craft; but are they really necessary? and would they serve as good 'example' craft? I would personally answer 'no' to both.

In a (two) word(s): Normalization Values. (most likely this, or related) The way that TU manipulates textures relies on some patch-author-provided 'normalization' values, so it knows how to pull just the details out of a texture. If those values are off, even slightly, (or completely omitted as is often the case), the result can be output colors that do not match the user-specified RGB values in the UI. What TU'd fuel tank are you adjusting that has color issues? (Or more importantly, where can I take a look at the TU configs for that part?) Likely that the author has not included any normalization data, and/or is using 'tinting' mode (aka color multiply), which relies on the original provided texture colors, and can only ever make textures equal-to-or-darker than they were originally. Really, the 'standard candle' for TU recoloring implementation should be SSTU -- it is the only place where the recoloring setup of the mod is used as intended. On SSTU parts, setting something to 255,255,255 results in blindingly-bright-white, as it should be, and setting something to 0,0,0 results in pure black (again, as it should be).

Took some time over the weekend to do something I haven't done in ages... actually played some KSP. Not just quick testing, but actually playing the game Used a basic install; only QOL, graphics mods, and mods that I do development for (KF, TU, SSTU). Other mods included Scatterer, MJ, EVE, KAC, MemGraph. Very basic install. Essentially 'stock' for most intents and purposes. After progressing 3/4 the way through career mode, I am happy to say, that the only real issue I encountered with SSTU was, maybe, one of the MRCS blocks not persisting fuel selection properly (changed to MP in editor, did not work in flight). Thankfully the other ship in that docking operation had functional RCS, so it had no real impact on the mission. One thing that I did note from a balance perspective (aside from stock tech tree still makes no sense), is that SSTU does perhaps make career mode a slight bit easier with the configurable tanks and increased selection of engines. Really need to do some side-by-side comparisons though to see how pure-stock craft line up. The other note that I'm taking away from this session, is that perhaps some of the SSTU parts have been made a bit 'too' configurable. The UIs on the tanks (especially the MUS) are a bit of a nightmare with all the various controls. I'm really not sure any other way to do it though while still maintaining the same level of configuration and keeping a goal of 'low part count'; some sort of custom UI might be a viable alternative, but only if creating UIs in KSP was a simpler prospect. I previously had a concern that perhaps some of SSTU wouldn't fit well beside the stock parts due to the mismatch in shaders, but at this point the stock parts are just as mixed up themselves, what with half of them using PBR and half not. The color palette used on the newer/redone stock parts is also much closer to the SSTU coloring, so the whites/blacks are a much closer match and not quite as jarring as it used to be. Overall I felt the stock pieces worked acceptably beside SSTU (or vice-versa); not a perfect match, but not too visibly jarring either. Overall I'm fairly happy with the experience of SSTU in career mode in its current version, for use alongside 'stock' mechanics. No real surprises, and decent coverage of parts to use for stock game systems. Possibly could use some SSTU-based ISRU stuff... but I'm going to have to play around with that a bit before I could decide -- I've never made use of the stock ISRU system, so have no basis for SSTU parts or functions. Anyhow, this is the first of what I intend to be 'balance testing' play-sessions, with each group focusing on a specific mod environment for the purposes of developing integration patches for use with those mods. My next play-session and mod-set (likely in a week or two) will likely be including a life-support/habitation system (most likely USI-LS) and possibly a couple of parts-mods that I'll be creating patches for. Pics/mission logs/etc to follow later this evening.

Define 'white'. Good luck TLDR: There is no standard definition for 'white'. What KSP calls 'white', I call 'mushy grey'. What I would call 'white' is pure white (255,255,255), and not used often in texturing or game graphics. There is also massive differences in the exact same color when rendered using legacy shaders compared to the PBR shaders used by TU. What you are seeing could be any of those. I cannot control how others create their textures, or define their colors, nor would I want to. I have created a default color palette and set of preset colors that works for me, but notably it is not the same palette used by stock or other mods (it is close to the old KW rocketry palette, but not exact). Notably the TU 'white' is brighter than stock/most mods 'white', and the TU 'black' is darker than stock/most mods 'black'. Also, you can change the TU colors to whatever you want them to be. Want to match a specific mods coloring scheme? Go ahead and edit the color presets file (or patch it), or add new presets in an entirely new file; you could even create one set of preset colors per mod, for extreme mod-color-matching-craziness.

Nice How did you manage the torque/thrust balance between main rotor and tail rotor? My first attempts at a single-rotor heli, I had no way to synchronize the thrust output from the tail with the main rotor, so had to manage torque-induced-yaw mostly manually; lots of manual input and adjusting of trims/defaults. Was a barely controllable mess, but did manage to go up, and come back down in one piece.

Honestly, its NOT accurate to real life (at least RC modeling). On my aircraft, I slap on a prop, hit the throttle stick, and watch it leap into the air. None of this dickering with deployments, inversions, etc. For my RC craft, it goes about like this: Put one of these: Onto one of these: And... IDK... profit? Have thrust? It really is that simple. Zero playing with orientation, zero messing about with deployment toggles, zero setup. Put motor on airplane. Put propeller on motor. Apply electricity/generate torque. Get thrust. Granted, these are fixed pitch props.... But...that seems exactly like a 'stock' KSP thing to me -- a selection of pre-configured fixed-pitch propellers fits exactly in the stock design paradigm. Even the collective pitch RC propellers aren't that much of a PITA to work with. One extra axis to map to a servo, and one additional servo to configure, and the rest is exactly the same (mount propeller on motor, profit!). Even full cyclic-collective propellers (yes, they are a thing...when you want extreme thrust-vectoring on an airplane) are only slightly more complicated to setup, requiring only adding additional servos for two more axes'. After playing around with the propellers and helicopter blades, I will certainly agree that these have been made far-too-needlessly-complicated for a stock KSP mechanic. And I love complexity and configuration, so for me to say something is 'too complex', generally means something is wrong with it at the basic design level. (essentially, there needs to be configuration, but things should 'just work as expected' when used in their simplest configuration; these do not work as expected, in any configuration) (I'm not saying that don't work... because they do in very specific configurations... but the configuration needed to make them work is has zero logic in it). I guess I'm just curious why it is such a PITA to configure the props for a plane? It could be that I am trying to configure it wrong... but that again goes to my last point -- it should be intuitive enough that it should be extremely difficult to 'configure it wrong'.