Taverius

I meant they won't work in Gamedata at all

works just fine, install as normal.

They won't be recognized either. Example crafts have to be in the root /Ships directory of the main KSP folder to work.

http://bugs.kerbalspaceprogram.com/issues/290 Someday it will be fixed. Until then, strut /ALL/ surface-attached engines and wings, as well as any radially-attached boosters and such.

The problem with that, apart from needing to redo the connection values for every single part ever, is that the flexibility of a connection is related to its breaking ratings. So if you give them realistic braking forces, you craft will also bend like slinkies at the slightest provocation, which believe me is not particularly realistic. As an example, if you decrease the strength of a wing's connection so that it fails at say, 6gs, it will bend roughly 20 degrees up once you take off.

Huh. Seems to be loading all 270 legacy parts here fine ... guess I'll have to check that.

Supposedly yes. Unfortunately that feature is broken.

Its exactly because you're not top-heavy that you're flipping over. If you were top-heavy, it would be stable. If your rocket flips over its because your CoL/CoD is in front of the CoM. In other words, you're bottom-heavy, with the drag/lift centre above it. So when you go off-center, the heavy part wants to go in front. Welcome to rocket science Make your payload more compact, use fairings, and if necessary add winglets (static ones) at the bottom to stabilize.

Plugins? There's only 1 plugin, firespitter. Just use the one from Firespitter 4.2, works fine in the legacy location.

Yus. Hopefully it'll work in 0.20.1

@KasperVLD: How about fixing the connection strenghts? All 'small_' parts should have: breakingForce = 50 breakingTorque = 50 All 'large_' parts should have: breakingForce = 200 breakingTorque = 200 As it is I still have to keep an extra set of .cfg files to overwrite the small and large parts with otherwise they flex way too much and snap way too easily. As it stands, only the parts where Claira copied a stock .cfg file and edited it have the right values, all the ones where she created the .cfg from new lack them. Edit: my .cfg edits on mediafire

0.20 compatibility is coming. It won't work with FAR until FAR itself works with 0.20, mind. Edit: 1.3.5 is out. Since overriding of values with the new db system is broken, I'm still overwriting the stock files for now.

You must be using FAR. As noted in the OP, we're setting the values of the FAR aerodynamic module correctly as we go, but FAR itself doesn't yet pick up on our changes. That won't happen until ferram4 has time to get back to us about how to make that happen

No, not necessary yet, though the legacy folders will stop working some time in the future. Some of the stuff may not work because 0.20 has issues with some .dae files (but doesn't log any error) and refuses to load the texture for them. Those parts will have to be converted to .mu, unless Squad fixes the issue.

Yup. My mod is 90% rescales and rebalances of stock parts, and just like 0.19 I'm overwriting the stock config. In Squad/Parts/Blah. Any other mods that modify the stock values or refer to the stock models either have to replace the stock config, or add their supplementary .cfg files to the Squad directories. Not exactly what Squad had intended, but that's the card's we've been dealt. Hopefully .20.1 will actually do what its supposed to.

No, it will only ever see the default values for the wing, until ferram4 gets back to us with how to make FAR pick the changes up. That will be a few days, he has to fix FAR for 0.20 first

In case Dishy is not around for a few days and you absolutely must have your BillJeb 9000 fix, here is my personal .mu and 0.20 conversion: mediafire Dishy, here's the unity sources for that: mediafire I might suggest shrinking the texture to 512x for a future release, the names will still be readable, its a little large right now P.S. The parts are also rotated so if you stick them to the front of a rocket with the text right-side up, or similar for a plane, the horizon is correct when you do 'control from here'.

Yes and yes. You can also do part1.cfg part2.cfg, or blah.cfg foo.cfg bar.cfg and define any number of parts (or props or whatever) in there. What you can't do is: Refer to models/textures outside the directory the .cfg is in (broken) Use PART { config = path/to/base/part @node = value } syntax to only define the values that changed from a base config (broken)

.dae models will not load textures, ever.

.dae are broken, yet another undocumented 0.20 change. Should be easy to convert to .mu

From the OP:

Yes. Commenting out the COMOffset line in the wing configurations has helped some people with that issue. Personally I can still make things exploder with it, but give it a try. We've disabled the line for 2-6, which hopefully isn't too far off, now that we have all the major modelling and texturing work done.

One of the things I'll be taking care of is making sure all the plugins we use work in .20. It seems like most things just work outright, anyway If the Firespitter .dll included with 2-5 doesn't work in 0.20 (I haven't tried yet) keep an eye on Firespitter, I'm sure Snjo will do any necessary fixes quickly.

That's planned, and DYJ did get a totally broken one to not-work in game, but there's still a couple of gnarly bugs to fix in the main module before we start poking that.