Shadowmage

That is pretty much the correct answer. I could possibly, maybe, put in a custom ISP/thrust curve that was zero until ~>10km, but at the end it would still be a rough approximation of the effect of 'this isn't an engine that can run at sea-level'. Yep. I've done similar with the ISP/thrust on some of the other vacuum-only engines such as the RL10's, Merlin vacuum variants, etc. I thought it was an easily workable abstraction for the effect -- you get a functional engine in the regime it is intended to be used in, and a 'less than fully functional' engine in the regime it is not designed for. Not perfect, but easy to implement, and 'works'.

Judging by the dust-effects on the wheels, I'm guessing you are using the KSPWheel stock configs? Been awhile since I've tested them compared to the stock modules -- they still performing well without all of the stock module quirks?

Fairly similar. I've had good success on patching every other mod leg that I've seen. If it can work with the stock modules, it will certainly be able to work with the KSPWheel modules. The precise settings/configuration needed will of course depend on the specific model, but they should all be able to be converted.

Assuming that was spawned from a 'rescue' contract, I have a solution for those --

Pretty much exactly that (please feel free to post up any feedback on those patches in either the KSPWheel thread or KF thread; either works for now; or simply report issues on one of the repositories). And now back to your regularly scheduled F.A.R. programming....

Good, functional. I'll raise you one though. @madindehead Open the stock in-game settings, find the stuff that deals with reflections, and turn it off TU uses the stock reflection probes and stock reflection system, and the reflections can be disabled that way, globally, across the entire mod (and entire game). (note though: anything that should be metal/chrome will instead show a solid color instead of reflections, whatever stock has specified that color to be, and is entirely out of my control).

Did you set the motor reverse settings appropriately for each side? By default when using symmetry the motor for one side will be automatically inverted. If placed separately (not using symmetry), they will both use the same motor direction (which is relative to the part), and one of the sets of wheels will be spinning backwards. Generally though this should be much more visible when driving, as you would just spin in place. Just trying to eliminate the simple/obvious before getting into more in-depth diagnostics.

The wheels didn't get welded into the hull by chance? That would certainly mess with things. The wheels -can- be used in 'welded' parts, but require much manual editing of the configs to get it all working, on a part-by-part basis. I really need a stock + KF only craft that exhibits the problem, if for no other reason than to eliminate potential mod conflicts. If the issue does not occur with 'standard' built craft, then the problem is likely due to unforseen / un-handled mod interactions. Do those same parts have issues when you use them in other craft designs?

I have not previously heard of any such issue, so you would be the first to report it. Could you provide a sample .craft file that exhibits the problem (preferably one with only stock + Kerbal Foundries parts on it)?

Updated release is available: https://github.com/shadowmage45/SSTULabs/releases/tag/0.11.49.161 Updates TU to include latest features, and includes a few PRs for better Kerbalism integration. It should work fine with 1.6.x.

Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.5.8.23 Many bugfixes and enhancements. See the link for changelog and downloads.

Not possible; its a linked-dependency of the SSTU plugin. You could remove the texture-switching and recoloring GUI functions through careful patching, but it will always require that TU be installed.

No worries, sorry I couldn't point to anything more specific. If you do manage to track it down, please let me know which mod it is, as I'm kind of curious myself Unfortunately, no, they are a fixed size.

What you are seeing there isn't reflections, but the stock icon shader inflating the diffuse lighting. I don't have access to the stock shader source, so have no reference on what they are doing, or how to duplicate it. In order to fix issues with the stock icon-shaders on DX11 (they are flat blue for everything), TU has provided its own replacements; however as mentioned above, they are not entirely equivalent replacements. Long story short -- if the icons bug you, you will have to remove TU or disable the icon replacement configs. It is a side effect of me fixing issues with stock DX11. Personally I think the stock icon shaders look far too bright and washed out, and the replacements don't bug me. Combined with lack of access to the stock shaders to know what they are doing to replicate it, the chances of this being fixed are minimal. If you use ModuleManager to delete these nodes, TU will no longer patch icon shaders: https://github.com/shadowmage45/TexturesUnlimited/blob/master/GameData/000_TexturesUnlimited/Shaders/TUShaders.cfg#L21 E.G. (or whatever the correct syntax is) -KSP_SHADER_DATA[*]{} Yes. TU is only an API and by itself doesn't do much. No. See above. I provide configs for my main parts mod (SSTU), but I'm not aware of any other comprehensive sets for stock or other mods. The closest available is likely:

Yep, that works. From your logs, a few potential errors that might be causing the issue you are seeing (none SSTU related): Kopernicus has an error during loading: [EXC 21:34:18.234] TypeLoadException: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'KatLib'. System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) System.Reflection.Assembly.GetCustomAttributes (System.Type attributeType, Boolean inherit) Kopernicus.RuntimeUtility.LogAggregatorWorker.Awake () UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>c__Iterator1:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>c__Iterator0:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>c__Iterator0:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) Waypoint manager throwing an error: [EXC 21:38:36.514] NullReferenceException: Object reference not set to an instance of an object WaypointManager.WaypointManager+<RemoveDuplicateWaypoints>d__30.MoveNext () UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) I couldn't say for certain if either of those is causing the repeated error you were seeing; they don't appear to be directly related, but in KSP any error during loading can cascade to seemingly unrelated systems. And I can see the repeated error regarding the missing method/constructor, but sadly the log is not stating -where- the error occurs (quite odd, normally it will state what class/method was being processed when the error was encountered). I have checked SSTU code, and I do not have or use any classes called 'ResourceRatio', so whatever is causing that error is not in SSTU directly. Now, stock code -does- have a 'ResourceRatio' class, but SSTU is not interfacing with that class directly in any fashion, and that class does have a constructor. This all points to the likely cause being some out-of-date mod that you have installed that was not compiled for recent KSP versions (e.g. was compiled for KSP 1.3). At this point your only real recourse to solve that error (and it does need to be solved), is to remove mods one at a time, until the error goes away. Whichever mod removed last is likely the culprit. Or do the reverse and start with a clean installation, and then install mods one at a time until the error occurs, at which point the last added mod is likely the culprit. Do you have this issue with any non-SSTU parts? Can you duplicate the issue in a stock+SSTU only installation? If you can find a way to duplicate the issue on a Stock + SSTU only installation, then I can likely find how to reproduce the problem, at which point I could do further debugging. However, if the problem is not present in a Stock+SSTU only installation, that would point to the error being in another mod, at which point I cannot really offer any further assistance (I can't fix other mods' issues).

Something about the conservation of energy and laws of thermodynamics might have some input here Taking mechanical energy from rocket exhaust and using it to spin a turbine, which then spins props to produce thrust, I cannot envision any method where it would be more efficient than using the reaction mass/exhaust directly. The energy output from the combustion of fuel doesn't change, but you are introducing more inefficiencies through the mechanics of rotors, bearings, gears, etc (friction, drag). The reason that jet-engines are 'more efficient' on Kerbin is simply that they don't need to carry (and accelerate) their oxidizer. At least that is my understanding of the physics of it (someone please correct me if I'm wrong on any of those points). Would love to check the ISP of a jet engine converted to burn LFO at the same total mass-flow-rate as the atmo equivalent (assuming IntakeAir uses something approximating a sane density/mass value).

The GameObject.rigidbody get method was removed in a (semi) recent Unity update. You instead need to pull a reference to the component with GetComponent(). E.G. Rigidbody rb = part.GetComponent<RigidBody>(); Cache the results if you need access more than once, as it is fairly expensive to use getComponent every frame. Edit: check the casing on my example; I don't remember if its 'Rigidbody' or RigidBody'... but it is only one of those...

The usual solution is to upload the file to a cloud hosting site such as DropBox, Google Drive, OneDrive, or various file-sharing sites like Rapidshare(?). Pretty much anything that will give you a sharable link will work, or if you have a Github account you can open an issue ticket and drag+drop into the ticket textbox to attach files.

Could I get an upload of a log file where this is occuring? That sounds like some incompatibilities between mods/libraries, as you can't normally compile a .dll with missing methods. Full log should contain much more information, likely stating exactly which libraries were having issues. Usually this is caused by some sort of version mismatch between a mod and its external .dll dependencies. Yeah, that particular error is a known issue with the integration code for that module and shouldn't have any impact on the functionality of the MRCS part itself (as it doesn't have resources). A side effect of how the RF/MFT integration was worked out, and the generic-use intention for the MRCS module. Should be cleaned up in future releases, and I don't think this is related to your previous issue (as I do see this error, but have not seen the missing-method one). You are in the clear on this one, and it actually is an issue with the mod (well, the second message anyway). I'll know more about the first error once I can see a log file.

Glad I'm not the only one to come to that conclusion. The props work a treat on Kerbin.... but I haven't been able to get good thrust out of them on Duna at all. The helicopter rotor-blades are a bit of a different story, and work logically on Duna just as they would on Kerbin (e.g. work fine, just need a bit more pitch / blade surface).

I believe the part is already recolorable, so you can make it as black and shiny as you desire.

Thanks for the responses and feedback guys, much appreciated I have managed to create a semi-micro VTOL that flies very well on Duna. I'm sure it could be refined a bit more with some further knowledge and testing. but the design was holding up my mission planning, so I went with what worked. Barely managed to sneak in under my 2t goal, though it was a bit wider than I had desired. Indeed the trick seems to be to simply give more lifting surface than you might think necessary, by about 3-4x what you need on Kerbin. Stuck with a minimalist design, only the bits needed to make it function. Wings are mostly decorative / to give a place to mount stuff. They are angled such that on Kerbin they provide decent lift, but in the thin Duna air... its nothing compared to the rotors. Has sufficient lift from the rotors to fly up to at least ~6km and remain very controllable, haven't tested beyond that. Sustained top speed of ~45m/s in level flight at 6k, or ~65m/s closer to sea level. With limiting of the rotors' motor torque it is capable of indefinite flight under solar power, but has very limited battery capacity otherwise. Extremely controllable at all attitudes and altitudes, it is about as COM and COP neutral as a flying machine can get, in every angle of attack. Wings are directly on the vertical COM and COP, so even in vertical flight they do not effect stability. Even with SAS off it simply flies wherever you point it, at whatever attitude you left it (aside from from very slight weathervane effect from the tiny tail-fin). It has a bit lower top-speed than I really wanted, but given the very gentle nature of the craft and its well rounded flight capabilities, I'll call it a win. Jeb got a fun little rockhopper, and I got to learn a few things about KSPs newest physics toys

I should probably note that TU now 'works fine' with DX9, so if you can run KSP, you should be able to run TU. ('works fine' as in, it now uses the Stock reflection system; DX9 is still rife with issues compared to DX11/OpenGL-Core). At this point there is nothing in TU that would require any sort of special hardware support beyond what is required for stock, as it is in fact using the stock systems. I should also note that the 'legacy texture' support will still require TU for the texture switching; that requirement/dependency is not going away.

Heads up regarding future update plans: Kerbal Foundries has been in a bit of a development hold for the last few months, pending decisions on the direction of texturing and the updated models. Well, decisions have been made, and the plans for the near/immediate future (at least the next couple of updates) are the following: Future releases will use the PBR texturing by default. Stock now includes PBR shaders and reflection probes, so it is not too far out-of place. The new/changed part-names will be staying in place. As this will impact existing saves when upgrading, I will write up a guide on how to best upgrade an in-progress game to the new version. Most of the old parts should continue to load fine, and this will likely be the method for upgrading in-place; install the new version, and then copy in any parts from the old version that are needed. Part-names have been made consistent and logical, so no further changes should be needed. Likewise with texture and config names. I will be creating 'recoloring' texture set configurations for the Kerbal Foundries parts, and by default each part will have a standard PBR texture set as well as a recolorable texture set. Recoloring will allow for the setup and use of visuals mostly equivalent to legacy shading (e.g. no chrome), but will still be using global-illumination for better visuals. Balance -- I still intend on finishing the WIP balance pass over all parts, setting their initial balance to be something close to the most equivalent stock part. As always, feedback on balance is appreciated. I still intend on creating a 'legacy' texture-set pack, baked from the original models and textures onto the new ones, where appropriate and possible (not all models will allow for direct transference). This will come at some point in the future after the rest of the update has been completed. I still have a few new models that were WIP, and would like to finish them off and get them usable and released. New landing legs, new ALG parts, and new landing skids (gotta have something for those helicopters to land on). Currently working through a pretty large update to TexturesUnlimited, which is nearly complete. I then have a few items to clean up in SSTU in regards to bugfixes and mod integration (RealFuels, Kerablism), and then should have sufficient time and resources to dedicate to a good cleanup pass of KF.

Unfortunately, looks like no release for this weekend. There have been a lot of changes that might impact existing configs, and I want to give some additional time to review those changes for side-effects. Also want to take a run at trying to fix up the atmosphere and skybox reflections in the stock reflection probe, as those add quite a bit of impact to the reflection maps that is currently missing, and take a look at cleaning up Scatterer reflections. And finally, I want to finish up the external toolset that can be used for normalization data generation, time permitting. However, for anyone so inclined, the dev branch is being kept up-to-date with the fixes, and you are welcome to download the /GameData folder directly from there if you wanted to give the new stuff a try. It shouldn't break anything, but please let me know if you encounter any issues, new or otherwise. Will aim for next weekend for the next release, as that should give sufficient time for review and testing, and hopefully give time for cleaning up some of the reflection stuff.