AccidentalDisassembly

Looks like tweakscale is not interacting correctly with MFT - easy test: just install both and scale something that's been MFT-ed. Unless I've borked a config somewhere... MFT values aren't altered on rescaling, essentially, so fuel amounts stay the same.

Very nice parts, but FYI: engines are missing ", 3" added at the end of their stack node definitions.

I have to admit to a little confusion here - the GitHub repo's link goes to version 0.0.1.0 here: https://github.com/BobPalmer/USI_Core/releases, but also says 0.1.0 on the 16th Your post says 0.0.1.0 is up, but references 0.1.0 from the 16th, and the GitHub repo says 0.0.1.0 is 4 days old... The KerbalStuff download says 0.5.1 here: https://kerbalstuff.com/mod/1194/USI%20Core Which is which?? =(

The way the thing surface attaches in the editor is determined by the presence of "node_attach = blahblahblah" in the config file. If you don't have one of those, the point the game uses for surface attachment is in the very center of the model (I think), or the position might be related to the origin point of the part in Unity. It *looks* like that's what's happening in the picture.

I found out that the problem was caused by the presence of FARBasicDragModel (or whatever it was) definitions in the part file, which were not being removed because the MM patch to remove them lacked necessary curly braces {}. At least that's what I think caused the problem.

Awesome! Thank you!

Added one to my post a minute or two after I hit the button. I don't know if it has anything to do with the contract pack itself, strictly speaking, or if it just so happens that this pack has missions that make the problem (from elsewhere) pop up - just to clarify.

Sorry if this has been brought up before, but basically every time I do a "help this scientist collect some data at this waypoint" type of mission, when I recover the craft with the scientist, I get the can't-click-on-the-KSC bug. I read elsewhere that it has to do with kerbals being dead or in the roster (or not) or some such, but... it happens every. single. time. =( Log if it helps: https://dl.dropboxusercontent.com/u/59567837/output_logContractsKSCNoclick.txt

Were you fiddling with the part in a directory where you had moved the corresponding textures or something? Dunno. When I put those lines in though, works well!

I think your config lacks these lines in the MODEL{}: texture = Mk3Fuselage , Squad/Parts/FuelTank/mk3Fuselage/Mk3Fuselage texture = Size3AdvancedEngineDiffuse , Squad/Parts/Engine/Size3AdvancedEngine/Size3AdvancedEngineDiffuse and the result is a completely black part.

FYI - Thread title says latest version is 1.9d. KerbalStuff download says 1.9b​.

FYI - at least a couple of configs in the latest SXT (GenericTweaks and FirespitterCompatibility) have parentheses ) in place of braces }. EDIT: Also PropEnabler.cfg and minidecouplertech.cfg

Not sure about the second part of your quote, but isn't this mod still around and working in 1.0? See http://forum.kerbalspaceprogram.com/threads/92290-0-24-2-ModuleRCSFX-v3-0-8-29-14

Ugh. In the process of creating a craft in a more controlled environment, I'm not able to reproduce it. So either it's been solved between when I last downloaded FAR's garbage_reduction and the changes you made a few hours ago, or it's a question of mod interaction, or there's something else in my GameData directory (bad patch or something) messing everything up. Oh well. At any rate, removing that from the CFG seems to fix it, so there's that! =) I give up. EDIT: Found (maybe, I don't freaking know) something that could be related or not. In _FARPartModule.cfg, the patch removing FarBasicDragModel from parts that have it doesn't have curly braces: !MODULE[FARBasicDragModel] (needs {}, doesn't it?)

I'm using the latest github FAR garbage_reduction branch (the GameData/FAR directory from the ZIP) with everything that comes with it - not just DLL. I guess I can give you a craft, if you really need it, but the (one) mod part config in question is included in the ZIP I linked, and the problem specifically stems from its FAR values (apparently, because removing that from the CFG seems to fix the problem). It doesn't have to do with the whole craft per se, only that part. Like I said - maybe this is something for the QT thread, maybe that part of the CFG is written wrong, or something, I don't know though.

I would argue that it is, but you can obviously do what you want! =) In the second picture, there should be 110 units of Oxidizer - that's what the config is saying (100% filled), but it's not actually creating a 100% filled tank (110 units available, only 48 or whatever used), it's taking both amount and maxAmount values from a completely different TANK_DEFINITION. Definitely shouldn't do that, IMO. What if you had two different tank types only, unlike the multiple ones I wrote, and they each had a similar resource? You'd have to set up the tanks through Show UI every time if you wanted the values to be correct, so the convenient tank-swapping feature would be useless.

Aha, OK. That clears up the engine thrust, I didn't think KSP actually did that - never seemed like it. Guess this was the one time I got some parts perfectly aligned behind the engines! Although it is odd that the propellers in the first pic produce thrust, then, but maybe they're not PERFECTLY in line with the wings, or maybe propeller parts work differently? Beats me. Still bizarre re: the QuizTech engines creating the lift problems under FAR. Only difference in the last pic and the attempt before it was the presence of QT engines, nothing else moved/changed, so there's something weird going on there...

Ferram, I have a couple of very bizarre things to report, and I *think* they can be reproduced if you use the same parts I am. Latest GitHub version of FAR. If using QuizTech in-line 1.25m VTOL engines on a craft, certain lifting surfaces won't have any lift. Secondly, when they're not producing lift (maybe when they are, too), BahaSP VectorJets, at least, will read as producing thrust but won't actually produce any if there is one of these dead lifting surfaces in its path. Check this out - picture illustrates both phenomena, bizarre craft for testing purposes. The two similar white cylinders on either side are the QuizTech engines, and the jets are the Baha VectorJets. Note the wings producing lift, but the horizontal stabilizers aren't - same AoA and everything. There isn't even a nub of a lift/drag indicator like there is on stationary parts normally. Although it's not possible to capture in a screenshot, the jets weren't producing any thrust - right clicking said they were. If I pressed S or A, the engines vectored, and thereby pointed away from the horizontal stabilizers (which are directly behind them). When they weren't pointed exactly at the stabs, they did produce thrust: Here's another plane with an identical tail piece to show that it does really produce lift with a different configuration - same session, didn't quit and restart or anything. I tried different wings - B9 and not B9, stock jets instead of Baha jets, same with stabilizers etc. In this next picture, I made one craft identical to what's shown, but with QT engines in front and behind the side tanks (like the first picture, pretty much). The tail parts were all dead. When I changed nothing except removing the QT engines, it worked again, like so: So there's something bizarre going on with the QT engines and bits not producing the lift they should. Very strange. Here is a zip with the QT engine config and model for reference as well as a log that includes only the session where I tried out the plane in the last picture (I think) - first with QT VTOL stuff, then without: https://dl.dropboxusercontent.com/u/59567837/QuizTechVTOL_FARshenanigans.zip Anyhoo, not that FAR is necessarily responsible for any of this, but I am reasonably confident there's some bizarre interaction going on. Edit - Ah, crap. Realized there's a FAR-specific bit in the QTech config. Maybe that's the cause of the problem? Sorry, maybe this whole thing belongs in QT thread - though I guess there's a chance that there's something going on with FAR too, I have no clue anyway.

Just FYI - two of the parts in this pack have borked config files. The cargo fuselage and accompanying cargo ramp tail part both have module = Strut rather than module = Part in the configs, and the medium cargo fuselage closes the PART{} curly braces before the TweakScale module and the RESOURCE. On the off chance anyone else is trying to use these parts with FAR, they will completely wreck the aerodynamics for anything on the craft that touches them. EDIT: Correction - other forces may have been at work with the aerodynamics, but the configs are still funky =)

Huh... didn't know that. Still though, I think the general point stands even if the jet engine isn't a perfect example, or maybe everyone just needs to start throwing around CoM offsets on their engines or something =)

I see what you mean, but I would simply add that some stock values for parts are a bit crazy, and I think there's a lot of leeway to make parts lighter while still making them perfectly reasonable. Crazy stock mass actually becomes a problem under some conditions, too, like if you want to use FAR. Things become (effectively) really, really heavy all of a sudden in FAR, and you have to get a 4-ton plane with gigantic wings going something like 180mph just to lift off. Just by way of example: a stock jet engine weighs 1.5 TONS. That's 3,306 pounds. It's roughly 4 feet (~49 in) in diameter and maybe 4 feet long. That's kind of big, but random googling revealed that a J40 turbojet from 1953, which is 25 feet long and 40 inches in diameter, weighs about 3500. Maybe the stock part is just supposed to represent the tail end of a long engine like that, but it creates problems with the center of mass of craft that are really only resolved by cockpits being equally ludicrously heavy to balance it out. I think so long as an effort is made so that the parts don't become super overpowered if they're low-weight (e.g. huge TWR or something), then there's a good case to be made that stuff should really be lighter than it is even when you're not hell-bent on "realism" per se.

Ferram, why are B9 procedural wings excluded from KJR's R? Is there a particular reason? Out of curiosity I removed that exception from the config XML file, and they seem to work OK. Is something going to blow up on me that I won't see coming?

Just a small bug to report with MFT 5.6.0. Description 1. Happens when switching TANK_DEFINITIONS using the right-click menu in the VAB and typeAvailable = tankname1, typeAvailable = tankName2 in the MODULE applied to a part 2. When the tank definition you switch from contains a resource as the tank definition you switch to, the tank you switch to will have as much of that resource as the last one did (see Tank 3 to Tank 2 in picture, note tank volume compared to resource amount) 2a. The tank quantities are correct in the TANK{}, it looks like this: TANK { name = Oxidizer amount = full maxAmount = 100% } 3. Quantities will be right again if you switch from and to tanks that don't have the same resources (from Tank 1 back to Tank 2 in the picture) How to reproduce Have two or more references to TANK_DEFINITIONS that have the same resource next to each other in the list of typeAvailable definitions, switch back & forth in the VAB, e.g.: typeAvailable = Default typeAvailable = LiquidFuel typeAvailable = Oxidizer typeAvailable = ServiceModule typeAvailable = RCS

Haha, not sure what your native language is, but in English it's also an onomatopoeia, though it's for a dismissive sound, or being noncommittal, or saying ça m'est égal, if you happen to be a French speaker: (an example)

Hmm, dunno what to tell you, I'm trying on a relatively clean copy of KSP with the new version and I can definitely go out onto the water, it just rides lower over the water than the land... you've got electricity and all? I mean, I assume so, since you're making it to the water from the runway or whatever in the first place... Linux? Other mods?