pellinor

IMPORTANT: This is not how KAE works! This dll is special: mods compiled against a certain KAE version have a dependency on that version (and will not like a newer one). To allow this, it does some typing magic so different KAE versions can coexist in the same KSP install. If multiple versions coexist, the classes provided will exist in multiple versions and each mod will magically get the version it expects. So a mod should always keep the KspApiExtensions.dll that was bundled in the download. In my understanding, if a mod has an old KAE version that does not work in the current KSP, you need to recompile that mod against a new KAE version, and have that version somewhere in GameData.

Wait, you first launch a craft, then mod the game, and then your tank reverts? This would be no surprise, KSP does not magically move information from one FuelSwitch module to the other.

That already makes things clearer. So what happens at ctrl-z? For me the lag seems to depend on vessel size but not on the size of the reverted change. So it probably is like (or close to) loading a saved vessel. The cause of the known 'camera bug' (see first page) probably is that some things are done in different order on launch vs on quicksave/revert. Maybe something similar is happening here? The camera bug is also connected to scale changes being lost (but in that case the visual size is lost, and it happens only in flight).

Mine should be up to date. Are you sure this does not come from a KAE bundled with another mod? - - - Updated - - - This sounds like a messed up install, missing moduleManager or some conflict with other mods. The clean way to upgrade a mod is to completely delete it and then install the new version. For debugging things like this I keep a stock install net to my modded KSP, so I can test mods on their own. - - - Updated - - - With this setup there is nothing I can do other than tell that TweakScale alone does not break that node for me.

I changed my mind: if there is an MFT module on the part then this is the cause! In this case I let MFT do its thing and do not touch the resource nodes myself. And MFT might only scale tank size and not the contents. - - - Updated - - - Small dev update: exponent -0.5 for heatProduction, it seems to work now. No idea why last time I had the impression that KSP would ignore this one.

nuFar is still in development, and I am not familiar with it at all, so I don't think I can give any useful support at the moment. Until release I consider it a sack of bees that might change its behavior or interfaces at any moment, so compatibility efforts are better spent once it reached some stability. From tweakScale's side, all visual models are scaled by writing the variable part.transform.GetChild(0).localScale, no special treatment for any part. Maybe the similarity between the problem parts is that they are split into a fixed mesh and a moving one?

Just post in the CKAN thread, the people there will take care of everything that needs to be done. - - - Updated - - - EDIT: actually this would be useful in the editor too. When you move a TweakScale slider on an attached part, the scaling moves the CoM and the right-click menu with it. Especially for large vertical parts, this can be extremely annoying.

My bet is the fuelswitch (if the part is switchable). It completely overwrites resource nodes and keeps the scale as an internal variable instead. However it should work together with TweakScale.

First, Sepratrons are engines and do not have an ejectionForce value. The slider looks like TweakableEverything, which currently does not work together with TweakScale (support is planned). For stock+TweakScale I tested decouplers, I'd be surprised if they broke during the last few days. - - - Updated - - - I set the thrust (and mass) exponent to 2.5 because downscaled engines seemed too strong/heavy and upscaled ones to weak to be really useful. - - - Updated - - - I can't reproduce it, neither with reaction wheels nor with decouplers. Any mods that manipulate attachment nodes maybe?

Nice to hear! Still I hope they know that TweakScale is suffering from a stock bug that is already 3 versions old.

I'll gladly add the exponent in the next TweakScale version. To avoid conflicting versions, I'll write up some MM patch so it doesn't show up twice if yours is present. It would be best if you keep it in your download for a while until the current version of TweakScale has become extinct. (I didn't respond to your pm because your inbox is/was full)

Wow, this one was hard to find. Now everything works as expected. I also tested removing the "mass/volumeMultiplier = 1" lines on the stack gas tank from the download, and it still works. So you don't need these lines because the fields are already initialized to 1.0 when the module is constructed.

Did a quick test with the tanks from your download, and I think there is a bit more happening. The TWEAKSCALEEXPONENTS is there, also the multiplier config values are set, but I see all sorts of reverting (e.g. when changing fuel type of a scaled tank). So the problem is not people forgetting config lines.

Is this needed? My understanding is that you can initialize those values with 1 in the declaration of the kspField in the c# source. When the module is loaded from a config node, each line in the config overrides the respective kspField. So you only need a config line if you want something different from the default. TweakScale does not know about config nodes, it only knows kspFields inside partModules. For example it can scale maxFuelFlow which seems to be a kspField in the new engine modules, even if it does not appear in the part configs. PS: now that I see the mass multiplier, you probably just overwrite my changes like with the resource nodes. So everything should work well. - - - Updated - - - I'll gladly add the exponent in the next TweakScale version. To avoid conflicting versions, I'll write up some MM patch so it doesn't show up twice if yours is present. It would be best if you keep it in your download for a while until the current version of TweakScale has become extinct. Looking into your download I can see why people tend to throw away stuff they shouldn't. The fuelswitch download bundles a generic functionality for broad use (the fuelswitch module) with content that looks interstellar-specific (the resources and parts). If this is meant to be included in other mods, it would be cleaner to package only the minimum that everyone would need to include.

+1 this definitely should get a switch in the stock cheat menu

Exactly. In the reported case the size is right and the resource amounts are wrong. This once worked with the old FSFuelSwitch, though I do not know exactly how. Can you tell what you changed to improve the interaction with TweakScale? On the TweakScale side I don't find anything special treatment for resources. They are just configured to use relative scaling. So whenever a part is rescaled I look into the part (not the prefab) and scale whatever resources are there. In the reported case of a scaled stock tank, I probably scale the original contents, and you overwrite them with the (unscaled) fuelSwitch values. So maybe something goes wrong with the scaling of these values, or they are read from the prefab instead of the part? (Just throwing some guesses into the room here) I also see possible coflicts with mass and cost (if you manipulate it too). I guess it's best to test these once the resources work together.

Yes there is a switch now (see the end of scaleExponents.cfg). Seems like I missed that in the change log of v2.0. - - - Updated - - - I'll look into it tomorrow. My guess is that the fuel switch is overwriting what tweakScale does. Did the old firespitter fuelswitch work with tweakScale?

Maybe the problem only occurs when the target craft is landed and more than 2.5km away? So it is not loaded when you try to switch, and this might be what the game checks. EDIT: there is not one 'physics range' anymore, there are only loaded and unloaded vessels. So, in more detail, my guess is that the game asks * is the target vessel (landed) loaded? (false, because landed and more then 2.5km away) instead of * will the current vessel (flying) stay loaded after the switch? (true, because less than 12(?) km away from the target)

I had to rethink what is a good default and what are the exceptions. So cubic mass is the most obvious behavior one would expect from an enlarged model. Also there are a lot more tanks than engines. I also put this up to discussion but got no replies. If there are open questions with the KSPI configs I can have a look if you want.

Another small fix is to pump fuel from the lower to the upper tanks, so your CoM stays in the front while moving through the lower athmosphere.

I found an interesting explanation about overheating of engines: So if a scaled engine burns at the same temperatures, the thermal energy conducted to the part should go with scale^2, just like the thermal energy the part radiates. Then scaled engines should have the same asymptotic overheating behavior (small ones will converge faster because mass goes with scale^2.5). To achieve this I think I'd need to scale heatProduction with an exponent of -0.5 (since it is normed to thrust and thrust goes with scale^2.5). Now the only problem left is that KSP ignores the manipulation of heatProduction...

Mass scaling was about the last thing that has always been broken with TweakScale (constant mass fraction clearly is by design in stock KSP). So I fixed it for KSP1.0, which I consider the best possible time for introducing breaking changes. This also balanced the weight of a rew other things (like solar panels properly preserve power/mass now).

Wow, I haven't seen this yet. Which one is the root part of the vessel? Any other mods which mess with RESOURCE nodes / tank contents, like fuel switches, MFT etc? @enceos: The replicated revert bug with the root part is the other way round. It has the correct stats but the visual model reverted.

Since the HAS statement seems not to work with a full path, I put a variable into the part config. Added a patch to clean up those variables before the part is loaded by KSP.

Here you are: http://forum.kerbalspaceprogram.com/threads/80977-WIP-KAP-Kerbin-s-Age-of-Pioneers-%28A-Career-Mode-Overhaul%29 No idea what the current status of this mod is, but it sound interesting.