PolecatEZ

Isn't it generally ok just to let Unity export .tga's uncompressed, as they'll end up taking the same RAM when loaded in the game?

First, don't worry about parenting, it just helps you set up the key frames. What you would do in that case is ctrl-lasso everything and then set the keyframe for loc/rot/scale, or just tap the "a" key a few times to highlight everything. Every keyframe, highlight everything in the scene and then set the keyframe for locrotscale. Even unrelated objects, don't worry about them for now. Just get everything in place (use parenting if you want to help with rotations, but its irrelevant), and select all and keyframe each step. Save it as a master file, then follow the steps below if you have objects unrelated to the animation or multiple animated parts that need to be in Unity separately. I've had issues where Blender uses every object in the scene for the animation and breaks the animation when you export it to Unity because you need to re-child/parent everything to get certain things to work. My workaround was to break up the export. Build the whole thing in Blender and animate, then save to a master .blend. Delete everything not involved in the animation, then export it (.fbx?). Reload the master, now delete everything with the animation, export again with a different .fbx file. Now you can just keep the pieces together in Unity involved in the animation, and the others you import separately and not worry about parenting...throw them anywhere in the tree, go nuts.

What started as a re-texturing project for Squad parts has morphed into something totally different now that I can Blender a bit. Cockpits, wings, and engines will be getting full treatment, as well as a lot of replacement knick-knacks for basic Squad parts (fuel lines, batteries, trusses, etc). My intention is to be able to fully replace the Squad pack with same-size (but updated shape and style) B9-style parts. The pack will recycle B9 textures in a much smarter way and include a few of FStexture switch options. There will also be some tweaks with B9 parts to make them function like Squad parts (nosecones will be cut in half, so you have a 1.25m cone adapter and a .625m cap, for example). This will reduce RAM load by about 700mb and give lots of new toys to play with, while cleaning up the parts catalog a bit. I'll make both a standalone (needs B9 though) version and Squad knock-out version of the configs. 1.25m Rover/Cabin (tandem 2-seater) - Needs internals, but otherwise functioning well...the seam doesn't show up in the game, btw. Mk1-2 Inline Cockpit Replacement - Functioning very well in game. S2 Widebody Command Bridge/Bomber Cabin (5 or 6 crew) - Needs a re-make because of texturing FUBAR Original B9 wings will remain, but thinner Squad-sized remakes with original shapes will also be done, including Mig-29/F-15 style delta wing, 2 "swept versions" (realistic and rounded sci-fi), and some flaps/elevators/winglets re-done. I'm knocking out about 1 cockpit per night, but I think wings will go a lot faster. Fuel tanks of a variety of sizes and colors are already done - just a matter of config manipulation. Engines and intakes will be last because I'll need to downgrade my Unity version to make them work. Project should take 2 months and I'm definitely entertaining requests.

SLS looks like its made as a compilation of other mods, could you be more specific which mod? Link?

Is there a way to make simple script to add PART {} to something? I think it can be done with old .bat text editing commands. Then it would just be a matter of adding all else via MM config. Granted though, my school of thought on this has changed somewhat to a more Darwinist perspective. If something is no longer viable, a new mod-maker can basically re-make it (but better), especially while this game is still undergoing relatively rapid changes. I can't wait to see how 64-bit impacts everything, for example.

I wanted to do something like this a while ago and the license police started chiming in. Apparently some modders do just want their old stuff to die despite just needing a small .cfg tweak to keep them going most of the time. If its for new stuff, I'm all for having a repository where parts would be uploaded but could be batch processed to update to new versions as they come out to keep them up to date. The original uploader could also tweak his stuff as he sees fit. By uploading your stuff, you submit to whatever license necessary to let this happen. Majir was also talking about doing a standard hosting server on his personal equipment, if this idea could also be integrated I think it would be very cool and differentiate it from Spaceport's general anarchy. Examples: - In a future KSP version, all part textures MUST be in .mbm format, ergo a batch script will run through every texture and convert them. - All parts should have tech tree assignments, ergo a script will run through and auto-assign them based on whatever. - All parts need PART {} in order to work properly, ergo a script runs through every config, checks it, and adds the lines as necessary. - .dll's could be marked as incompatible with the latest KSP version, and the original owner could have a grace period of X days or months to update it before fixes are allowed by a 3rd party. That 3rd party would then have their own timer to make the fixes before another 3rd party could attempt it. Scope would be limited to making the mod work in the new version only.

You can probably use the spawner in the EPL mod to do this easily, just shrink the base part to fit into whatever bay you want -or- add and tweak the module to the part config for the bay itself. I did this to a duped R3 aircraft carrier floor part and was able to populate my carrier anywhere in the world with updated designs this way.

But with those nice Normals and Textures you start hitting another limitation, the almighty RAM cap, which you really need to keep under 2.7 on a fresh load if you don't want your game to randomly crash when it decides to suddenly eat a lot. My framerate with my GTX770 did take a hit when I was playing with making objects and put in a block of spheres with a poly count of 77,000. I lost a whole 10fps (from the capped 61) when I threw the object on the floor in the VAB. I came here hunting for what the acceptable limit would be, and I see its still under debate. Roundy objects just don't quite look right without a high poly count, unless I'm missing a trick (likely, just got Blender yesterday).

If you haven't done so already, can you make sure the 45m carrier deck has a tech tree node assignment? Its easy enough to edit in, but the plebians might appreciate it. Can't wait to break the backs of real carrier fleet

Looks like KSPI might be getting some more toys I was thinking they badly needed a capacitor the other day...

Its why Moses came down from the mountain and gave us the Norden bombsite...someone really should make one for RPM integration. Skip bombing might also be a fun thing to play with...in game logic, the bomb would bounce on the ground until a set number of bounces or its in proximity of a bad guy...then boom!

Actually, it happens sometime after I place those smaller lateral jet engines from B9. Maybe there's a specific module that's killing the CoM in the B9 pack...more investigation now. Thanks.

There are a few things with the GUI that could break it, just check to see if its still there.

Seems to work just fine, though there is a bug where CoM disappears...not sure if that's old or new though.

Unless you see an update build, still broken. They might have been sneaky and were working on it during the beta, in that case you can go digging for it on github untill they release it...or...nobody has touched it yet. Until then, I can't alt-tab out during my launches any more

Theoretically Squad solved the issue that this mod was designed to fix, we'll see if it needs MOAR! joint support.

As you're probably aware, very broken with the latest official release of the game. My rockets simply fall apart on the launch pad with this installed. With the new way they did their own joint reinforcement, will this do more/different things in the future?

Found an easier way to do dogfighting... MechJeb autopilot - initiate hold on direction and altitude - keeps working when you switch away from the craft. I just chased another airplane about 1/4 way around the world before I got a gun kill, but it worked. MJ has a sort of altitude bounce as well, so there is some "dodging" on the part of the target craft. If your target aircraft is balanced well for take-off, you just set the altitude, heading, and throttle and let it go.

Actually it will cut it by 3/4. Its 65 for me without, and 19 with aggressive on. I'll do some optimizations on my next pass also. If I kill all the B9 orphans also, that's probably another 30 or so at least.

This next one went faster than I thought, just a few niggling details and minor parts to work now. I'll probably do a combat re-skin for the FS Fighter parts also (cockpit, wings, nose, intake), since I'm ahead of schedule. Oh, and transporting an entire armor platoon has never been easier. Flies like a dream. She carries two ICBM's in those side tubes and 4 armored vehicles in the centerline HL FatBoy bays. Clears an entire square km and then lets the tanks go mop up. Now if it only had VTOL ability...

Some parts that were consolidated were made flexible by ModularFuels. Fuels for KSPI and Kethane were also made available to these parts through ModularFuels (if you have those packs installed). *Most* parts should work just fine without it, as I later added switching to some things that I didn't originally plan on. As for preview pics, they work just fine for me. I'm not sure how to correct it. If anyone else can second this then I'll try to find an alternative.

XOverPacks Version 0.2 is up and contains lots of actual textures for switching! See the OP for details, enjoy!

I got a little side-tracked, but at least something useful popped out. I'll get back to the textures now...

FSTextureSwitcher allows you to also pick a custom bumpmap (normal) file to go with your new texture file when you switch them out. I prefer to do things with NO bumps at all for B9 style, so I will need to define a blank (1 pixel) map to go along with my own textures. From what I understand, you have custom bump maps to go along with your KW textures. We can have those switch out with the main texture if its set up right.

Nope, for my own stuff I'd like to get rid of them entirely, which in FSTextureSwitcher is the same thing...I'd need to set a bump map secondary switch to null. If you want to send me the bumps for anything you make, I'll try to make it work.