pellinor

My first guess would be no (don't understand that part of the code too well).

Works for me (it has changed since your post though). That file is auto-generated by github so no idea what could go wrong there.

Dev update: * Finally a solution for wheel colliders. I was darn close to dumping those wheels for good. * Fix wheelMotor ec consumption (torque still unscaled)

There was an issue with flipped IVAs that I could not reproduce yet (it seems to need more than a direct launch and scaled cockpit): https://github.com/pellinor0/TweakScale/issues/38 Has someone seen that yet in the 1.2 dev version? @nebuchadnezzar maybe? (since you reported the issue)

Could someone proficient with antennas test if scaled antennas work? A large antenna should be as strong as the same weight in smaller combined antennas of the same type. My suspicion is that the scaling will work for the antenna of the active vessel but not for unloaded relays.

Dev update: * fix scaling of input/outputResources (e.g. consumption of reaction wheels)

That would open quite a whole can of worms with its side effects, many of which also affect unscaled parts. I consider scaling of crewed parts a pretty exotic use of TweakScale, so it is quite important that glitches and side effects are limited to scaled parts. Most likely I'll also make the scaling of seats opt-in instead of doing it by default.

@Shadowmage since the prerelease forum is locked, let's continue the discussion about changing crewCapacity here. Are you adding of removing seats with respect to the prefab? You can probably get away with only handling one of those situations. I tested your code and the call on onEditorShipModified, this is what I found: == extra seats == * start with mk1 pod * add seats (in my case 1->4) * fill those seats with kerbals * try to attach a new pod => editor breaks: IndexOutOfRangeException: Array index is out of range. at (wrapper stelemref) object:stelemref (object,intptr,object) at VesselCrewManifest.UpdatePartManifest (UInt32 id, .PartCrewManifest referencePCM) [0x00000] in <filename unknown>:0 at VesselCrewManifest.UpdateCrewForVessel (.ConfigNode vesselNode, System.Func`2 persistFilter) [0x00000] in <filename unknown>:0 at EditorLogic.RefreshCrewAssignment (.ConfigNode craftNode, System.Func`2 persistFilter) [0x00000] in <filename unknown>:0 at EditorLogic.<SetupFSM>m__8C () [0x00000] in <filename unknown>:0 at KerbalFSM.RunEvent (.KFSMEvent evt) [0x00000] in <filename unknown>:0 at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00000] in <filename unknown>:0 at KerbalFSM.UpdateFSM () [0x00000] in <filename unknown>:0 at EditorLogic.Update () [0x00000] in <filename unknown>:0 ** The same happens if I try to launch with a filled extra seat. Did this work for you? ** When saving and launching directly from the pad, extra seats are ignored ** F5/F9 works (filled extra seats stay filled) For TweakScale it might be a viable compromise if extra seats are available in flight but not in the editor or at launch. == removed seats == * start with mk1 pod * remove seat * add another pod => seat has returned Any further change will fix things, for example changing fuel amount in a tank. This is a bit annoying but would work as long as any reappeared seats are cleared when launching from the editor (or saving the vessel). ** When launching a saved vessel directly from the pad, I can assign kerbals to removed seats. This seems to fail silently (still it is a source of confusion and might lead to problems with other mods that mess with the launch of a ship).

Yes it's known, as the post above yours already says.

dev update: * compile against KSP 1.2 * ModuleManager 2.7.1

About TweakScale support: my current configs are a bit of a mess because there seemed to be a lot of renaming and temporary stuff going on. I'll happily update the configs for the new packs once it is clear what will be in there. We can either leave them with TweakScale or distribute them with OPT, I'm fine either way. If the legacy pack is meant to support the transition it might be a good idea to package the configs there, so they can fade away as people are moving over to the main pack. Is it already clear how the final composition of those packs will be?

Dev updates * update MM * two new stock parts * messing with crewCapacity scaling (currently turned off because of problems) [edit:] * antenna scaling (range not tested yet) (a large antenna is worth the same weight/cost in smaller combined antennas of the same type)

Working on crewCapacity scaling I stumbled upon a new issue. I'm pretty sure that part worked back in 1.1.3. Any help is welcome.

Parts that belong to the same vessel do not collide with each other. However if one of them breaks off (I think that would appear in the flight log too) it becomes a separate vessel and collisions are suddenly checked. Generally TweakScale should not change the behavior of colliders at all, only their size.

"free updates, full expansion packs with an incredible amount of new content and much more" To me it sounds pretty clear that free updates and expansion packs are two separate things on the list.

Here are two reference images for wheels and legs, shrunk and enlarged by writing the member localScale of the part's "model" transform: http://imgur.com/a/cxMsU http://imgur.com/a/PHmFS It looks like something more needs to be done to get the wheel collider and the suspension limits right. When rolling, the rotation speed is also wrong (probably from using a wrong wheel radius). This behavior broke with the switch to unity 5 and the new wheel modules. When using the config value "rescaleFactor" for scaling, KSP seems to do these things right. The fields mentioned in the part.cfg are all unchanged for such a wheel, and I couldn't get the physical behavior right by tweaking them. Can anyone tell what needs to be done to bring those wheels to the right scale? PS: poking around I found that ModuleWheelBase::Wheel seems to always be null (checked OnLoad and OnStart), isn't this meant to lead to the inner workings of the wheel system?

Not yet, planned for the next release

A good start is to search for "exception" in the logfile (and there are many of them). These are problems that could cause collateral damage elsewhere. First thing I would try is to test without the mods mentioned in the exceptions (like partAngleDisplay). I didn't see any TweakScale related problem in the log.

I'm not too attached to that value, and don't really use scaled cargo bays myself. Any more opinions about the mass scaling of cargo bays?

Do you really need an active control or would it be enough if the object is aerodynamically stable (supposing an atmosphere)? If you drop a dart from space it should always orient itself along the airstream (hopefully before burning up, so you'd need the right amount of stability).

As far as I remember the cargo bays are tweaked to be consistent with stock balance (comparing mk2 and mk3). I'd say anything between 2 and 3 makes sense (so the wall thickness may or may not scale with the part). For changing you can change the scaletypes of those parts (stack -> stack_square).

Dev update: * move workaround for UI_ScaleEdit bug into the plugin (so it works for all scaletypes) * tweak some exponents and remove obsolete ones * compile against KSP1.2.0.1523 PS: still needs a recompiled MM to work

Recompiled the dev version. Consider it as unstable. I'll post updates in the dev thread:

Dev update (will not work without a new ModuleManager, so totally untested) * recompile for KSP1.2-prerelease * patches for two new smartParts * refactoring: do things earlier so the prefabPart is in a more consistent state I'll probably not have time to continue this before next week. If someone beats me with a fix: feel free to make pullRequests or post your own forks. Issues/todo: * no updated moduleManager available (or am I not looking in the right place?) * autoscale is broken (missing method, commented out) * upgrading mechanic will likely need support. No idea yet what is needed * check wheels and their exponents * any new parts to add?

This. Things are pretty similar with bug reports: no one likes a sloppy "this doesn't work" from from that guy with a huge mod list. However well written reports are worth their weight in gold. The same is true for feature requests if they make sense, are well thought out and placed at a mod where they fit well.