AccidentalDisassembly

Toadicus, I've noticed an unusual interaction between TweakScale and TweakableEverything, and I don't know how to diagnose which mod is responsible. It's specifically to do with tweakable reaction wheels. What happens is that scaled-up reaction wheels are shown to have bizarre and/or negative values for their strength in the editor. I'm wondering whether this is purely an issue of display or whether tweakscale + tweakable reaction wheels is actually messing up the values, which it seems to be (based on what happens when I launch). To reproduce: 1. Clean KSP, install tweakable everything & tweakscale 2. Place something like the advanced inline stabilizer, right click on it, values normal. 3. Scale up, now torques are negative, or at least a strange (wrong) number that very much does not correspond to whatever exponent TS is supposedly using. Values can still be changed, but unsure what actual torque is produced as a result on launch... Is this something to address from TweakScale's side of things or from TweakableEverything's?

I vote for a release! =)

One more small issue - sorry! =( The ends of the blisters/tanks on the shortest ventral cargo bay and the tail ramp are untextured on the default setting. LFO/LF etc. have textures. Additionally - something odd happens with the tail ramp when reverting to launch. It can be reproduced: 1. Make a craft with tail ramp, attach arcadia jets via adapters (or whatever you want) to ramp's side blister stack nodes. Put on runway, take off. 2. Revert to launch - ramp is open now. When closed, jets think they are stowed so won't start, but are not stowed when ramp's open.

Thanks haha And for AccidentalDisassembly and M_Ouellette i really give you guy's comment quite lot of thoughts because what you guys describes makes more sense than then current K fuselages. So instead of a single k-cockpit how about i add one more j-cockpit with more j to k adaptors? because that would be pretty equivalent to another k cockpit but it gives more versatility. Also the current K fuselage will probably make more sense to look more like a scaled up J fuselage rather than the current which are basically flying bricks. I created some mock up models (it doesnt look too good yet just an idea of how the K fuselage could be, they are roughly J fuselages scaled up by 1.25) http://i.imgur.com/xvlJZpj.png Note that the picture is from an anime called to-aru-majutsu-no-index, i found it when i was searching space plane images on googles and it's what i modelled the J cockpit after and main source of inspiration for the wing designs. Even though it's a anime i thought the ship is really well designed and it looked visually very convincing of it's function with it's atmospheric engines on the side and a pair of rocket engine at the rear. Apparently that scene only lasted few seconds as i couldn't find more reference images, im amazed how much thought the animators given it as a aircraft design. Its probably my second Favorited space plane design after the Valkyrie TAV. The new k fuselage design looks more like a extension of J parts with flatter bottom, also gives a much more smoother look overall. You could argue it looks very similar to the Mk4 fuselage with its bulge at the top and lobes on the sides but i would say its some kind of spaceplane fuselage design convergence haha. This new design remains unable to carry 3.5m cargos but compare to the J fuselage, its able to give the 2.5m cargos a much bigger clearance with flatter floor more suitable for rovers. So i think is a nice extension of the j fuselage. I do not plan to give it a cargo ramp because i find cargoramp in ksp is rather awkward so ill go for a elevator part instead. Also to mention i plan to create these little rectangular cargo modules thats designed to fit inside J and K parts. Because the K parts is huge so i plan to create as few parts as possible, mostly just hollow fuselage with a decent amount of fuel stored on the sides. I know this is going to be a huge change to the k fuselage, but i think im going ahead to make this change, im always open to more comment though when it comes to new designs! what do u guys think? In general I like it - my only point with the X to X adapter (J to larger J, new K to larger new K, whatever) was that I imagine it is a much easier part to create than most (may or may not even have to be hollow) and just one part like that suddenly allows for (tweakscaled) very large bays. Since you can do that for whatever cross-section you end up liking most, any cross section could hold whatever size someone wants when scaled up. With one or two adapters, now you've got a drop bay and a K bay with a flat floor that can hold 3.75, 5, whatever someone wants. With a decent-looking adapter, I think it wouldn't look terrible either. I'm not sure if I'm describing what I'm thinking very clearly, so here's a crappy picture - sorry for butchering your very nice J fuselage image: The J cargo bay in the back there is the same cross-section as the J fuel tank in front, of course, just scaled up - ta daaa, 3.75m J bay (or same with K). If you wanted to get really fancy, you could do an offset K to K adapter so that the floor stays flat between different scales, etc.

Found one texturing issue to look at - this is the shortest Mk4 cargo bay (top-loading) piece: Second small thing - I think this is another seam issue, on the tail cargo ramp - it's kind of hard to see in the image, so I put red around it: If I could make a suggestion for a part sometime down the road, like 2.2 or 2.9 or whatever you want - it might be neat to have a fuel-tank like part that you could attach to the bottom of other Mk4 bits, especially the hollow stuff. Would make the floor thicker, effectively, and then you could surface attach stuff without having it clip through the floor. Green bit in the image is supposed to be a stack node, blue part is the cross-section of the piece, landing gear for example. Bonus: geometrically simple to model, hopefully simple to texture! Maybe they could be auxiliary tanks, or specialized tanks for LH or Argon or somethingorother. Another minor issue: the engine pods' attach node is flipped so that the parts' default orientation on surface attachment is inside the surface of the thing they're attached to rather than outside:

That was me that mentioned part scaling, I think. Another thing that would be useful that I mentioned before is a part X to part X (self to self) adapter - e.g. a J to 1.25x or 1.5x J, same principle as 2.5m to 3.75m round adapter. Then you can have REALLY huge cargo bays... bwahahahahahaha!

You probably already checked this, but just on the off chance - did you load the plane completely with liquid fuel and no oxidizer? That could cause what you're describing, I think. Or maybe I'm the only one that does this from time to time, hah... EDIT: Also noticed this oddity on the Mk4 Extended Fuselage part, here viewed from the rear (default orientation in the SPH):

That's a lot of progress! This is really a neat pack and I especially like what you've done with it since the last versions, it's all looking great! I was wondering - since a lot of people around here seem to be knowledgeable about engines and whatnot in real life - what's the deal with engines gaining so much thrust as airspeed increases? Is this a real-life phenomenon on most jet engines, and is it simply because you start cramming a lot more air in the intakes (more O2 for combustion or something...?) as you go faster? Or is there something else going on?

I think what *could* (not saying should here) happen with respect to not having to write TS patches for every part is this: 1. Define one or two global scaletypes that will apply to all parts, make it go from (say) 0.25x size to 4x size. Or whatever. 2. Apply it to @PART [*] (or do engines vs. other parts separately, depending) 3. Everything is now tweakscalable with one very, very simple config, but you lose some of the functionality of how things work now: - Right now, patching parts individually means parts can be scaled between the same minimum and maximum actual sizes - like 0.625m (or whatever) minimum, 5m max, and the scale shown on the tweakable corresponds to the actual size of the part in meters too (for stack stuff). - If you change it to a blanket scaletype, parts would be scaled between min and max relative sizes, so parts that are actually larger to begin with can now be scaled to humongous sizes, which may or may not be what you want. - Result: Tiny parts can also be scaled down to absolutely minuscule sizes (like 0.15m for 0.625m parts in my example) as well, which is a bit weird. In short, you get a lot of weird size options now, but if everything's freescale, you can also move the slider to get the exact multiple you want. 4. One way around that might be to do a somewhat less simple config that reads cross-sectional size (if that's defined in part configs somewhere??), maybe... And somehow magically try to cover all the cases where someone didn't bother to define that, or for surface parts that don't have it at all. 5. Individual configs could still be written for particular parts requiring special mass exponents or whatever. So long as the config is fairly straightforward (one kind of scaletype for engines, one for everything else), it would actually save quite a lot of work and be not that hard to debug. BUT, as pellinor says, when you start trying to do something fancy - sorting parts by resources, size, modules, whatever - all in one config.. or if a user writes a config and doesn't know the difference between @MODULE and MODULE in an MM config (or some such)... I could see it getting hairy. Just thinking out loud.

I read over in the MK4 the Second thread that Nertea might be working on a plugin that allows extending a ramp to different angles/positions. Thought you might be interested - if I've understood what you mean, that is!

Just a heads up on a funk engine, I think - the Merlin engine has some really weird curve applied, or something: stationary, it will produce something like 15kn, but moving at 5 or 6 m/s it shuts off; in the editor it reads as 2668 kn at mach 0.4.

Hmm, well, that's great then! Yeah, the plane is pretty crappy, its only purpose was to test the flaps funkiness I was seeing and wasn't meant to be usable in any real sense. Looking forward to the next version, then!

There's a setting in FAR's stuff that allows you to define a default key for increasing/decreasing flap deflection. I think it's on the KSC screen only, not sure. For me, flaps DO seem to help, but only if they're at very shallow angles, my issue is more that they have crazy amounts of drag when they go beyond a certain point and it made the wonder whether something funky was going on in general with flaps. Ferram, I edited my post with a better explanation since I think I was getting hung up on the terms. Maybe I have understood now. Thanks for the explanations in any case! Here's the craft: https://dl.dropboxusercontent.com/u/59567837/WhatsWithTheFlaps.craft

Thanks, that's very helpful! I still am confused about a couple of points though, especially the drag of the flaps. Here's another picture - I am just guesstimating that the flaps are at roughly 50 degrees to the airflow (41 degrees deflected, something like 5 or 10 degrees of AOA from the way the wheels are). The airbrakes look like they're maybe 50 or 60 degrees to the air too. But the flaps are radically more draggy. Top speed of the aircraft with flaps at 30, 37.5, 41* is ~14 m/s. With all four airbrakes fully deployed but no flaps, it takes off just fine and top speed is something like 70 m/s. Are the airbrakes just that weak in KSP? Is it their placement that makes them so much less draggy than the flaps? The picture is at ~14 m/s. EDIT: I think I have terminology problems and that that's the source of some of my confusion. I was thinking of angle of attack as something relative to the ground, but it's relative to the air the plane's moving through. Let me try this and see if I've understood: Normal plane moves through air at a steady altitude. Wings are angled to hit the air at a 5* angle (or whatever), making lift in addition to whatever else makes lift on a wing, but the plane overall is perfectly parallel to the ground. Extend the flaps and their downward deflection of air makes the plane climb a little. On the navball, the angle of the plane relative to the ground might be the same, but the flaps' extra lift, which makes the plane move upward on a 5* slope, let's say, makes it so the wings are now effectively moving straight through the air - so much less lift. So that's what I'm seeing here, I think. I was only focusing on the plane's angle to the ground.

Please forgive me if there is just something I'm completely missing, but aircraft with FAR in 1.0.4 just don't seem to do what I would expect. I am guessing it's because I just don't know that much about aircraft, so I'd be curious to learn what's going on here - or maybe whether FAR actually is doing something funky, if in fact it is. The effects I'm noticing are: 1. Flaps seem to produce a really, really large amount of drag when extended past something like 20 degrees (ish), even at low speeds. Also, the drag they produce at those angles jumps very quickly from just a little at ~5 m/s to a WHOLE lot at ~10 m/s. If they're not deflected as much, you can watch the drag vector arrow things slowly grow in proportion with speed, like the lift arrows. Is this how they work in real life? I thought flaps on something like a 747 extend to a pretty steep angle without bringing the plane to a screeching halt. The flaps at around 40-45 degrees are far more effective than airbrakes... This drag is happening at 14.4m/s. I had to go 120m/s to produce equivalent(ish) arrows from a fully-extended airbrake. Fully extending those 3 flaps (on the double-wing version) in flight at ~70 m/s basically made the plane fall out of the sky in a couple of seconds. 2. Wing area seems to correlate to slower takeoff speeds less than I imagined. I've put absolutely massive wings on small planes, reduced wing mass on the slider in the VAB, took out fuel tanks, whatever, but it seems kind of "off" somehow. For instance, I doubled the wing area on the plane in the picture, and it went from maybe 36 m/s takeoff to 33 m/s (doubled version below). The craft with single wings weighs ~9.5t, double 11.5 - middle bits are cargo bays, no fuel in rear, 40 fuel in tank behind cockpit. The wing seems absurdly large to me, like the thing should be able to take off at pretty darn slow speeds. It sits with something like 10-15 degrees of AOA on the runway; its stall speed is the same as takeoff speed, I think, so I don't think it's a question of not being able to nose up enough. I mean, 33 m/s is only 70ish mph, but still... Flaps help, but are my expectations unrealistic given the proportions of the plane? 3. Flaps seem to interact strangely with the rest of the wing. When I extend flaps one notch (max deflects are 30, 37.5, 41 from outside to inside), something like 80% of the lift is lost from all of the wing pieces, and only the flap parts produce much lift. I would have expected that the wing parts right in front of the flaps would "transfer" their lift to the flaps, so to speak, but should the entire wing lose lift uniformly? Pics: Is my perception here just based on false aerodynamic intuition?

Starting a new sandbox makes AGX work - thank you for looking into this. I went back into AGExt.cfg and OverrideCareer had been changed back to 0. I am positive I had changed it to 1, saved the config, closed KSP and restarted when I tested to see if that was the issue, dunno what's going on there. Could there be something in the order I did things in that overwrote the cfg? I re-saved the cfg again, this time wtih KSP closed, and all appears to be working. I can only wildly speculate that what I did before didn't work because I edited & saved the cfg while KSP was open; maybe AGX saves over it when KSP closes? Sorry to make a wild goose chase for you.

I'm having a bit of a problem with AGX - namely that I can't assign any actions to keys. Here's a picture of what I mean: I thought it might have to do with overriding the career-respecting setting in AGX.cfg, so I did that, reloaded - nothing. Here's the log - https://dl.dropboxusercontent.com/u/59567837/output_logAGX.txt - it involves me loading up an existing game where I took that picture, then starting a new career save to see whether action groups worked there - they didn't. Any idea what's going on? Maybe some other mod is conflicting...?

Small bug to report: in your MFT config for FTP, the first three entries are duplicates. They should be like this instead (I think):

Just one very small issue noticed so far - the PPD-8 lander can's bottom node needs the flipperoo as well if you're not using the Non-Strict Part Attachment Orientation thing. I haven't downloaded the version since the last one where I mentioned the same thing about the airplane tail however - so you may have already fixed this.

Awesome that you are doing this, NathanKell! Did notice one small fix to make: C7 2.5m Tail Connector's stack node needs the ol' flipperoo, I think. Attaches backward currently.

I'm definitely not confused, unless I'm REALLY, REALLY confused. Here's a picture. Note that the stack nodes are on the same end, and one is off-center. I mean... maybe there's some random config somewhere in my GameData that is patching the nodes for some reason, but I don't think so...

Just another quick fix (latest dev): the T2 tail adaptor's nodes appear not to have been updated yet (maybe still need the 1.0 to -1.0 flipperoo thing?)

Sorry if this has already been mentioned - didn't see it in the last few pages; read the commits on bitbucket, not sure if it was fixed. In the dev version before the one I just downloaded right now, the stack nodes weren't placed right on the long MK2 to 1.25m adapter - they were both on one end of it.

Hmmm... I also tried a TWEAKSCALEEXPONENTS {} for only blastRadius and blastPower, but that caused the same problems. I wondered if I've got some weird franken-folder going on with old parts - but the latest release of BDArmory's mk82 bomb config looks like this, with explosionSize still in there: So that might explain some of it (some other parts I think don't have explosionSize defined?), but I don't know why it would mess up with just blastRadius and blastPower given to TweakScale to modify, unless maybe changing some other aspect of the part (mass? attach stuff? something else that TweakScale modifies?) just doesn't work with weapons, maybe? What I mean by that is that it *seemed* that maybe the mere application of a TweakScale module would make bombs and such break - so maybe something entirely unrelated to the actual MissileLauncher module is causing the problem.... dunno.

Would it suffice for now to simply remove those modules from the craft files included with the mod? I mean - could that break them as well somehow? I would just assume that would remove the conflict between craft-file-has-this and my-version-of-MechJeb-has-that...