[1.2] TweakableEverything 1.16-beta - For all your part tweaking needs

[OOZ662]

The first step to finding out is to describe what "weird" is. A list of your mods would help. A logfile would probably help more.

[toadicus]

toadicus, are these tweakables permitting powers that are not in stock, ie increasing the decoupler force, if I bump it up, is this more than stock values? If your mod increases values over what is found in stock, some players might consider that cheating. Is there a way to limit maximum tweaks to the maximum stock value if so?

You could just not turn them up above stock (which as far as I can tell is default). Not much reason to enforce limits on players in singleplayer games.

The standard range for all of my tweakables is [0X..2X], where X is the default value assigned in the part.cfg file. For some of the modules (Decouplers, DockingNode, Gimbals, ReactionWheels), these multipliers can be constrained within those bounds by changing the "x" (lower) and "y" (upper) values in the PluginData config files that the mods will generate after their first run.

In general, I agree with OOZ that fairness is not a huge issue here. I've tried to avoid allowing things to be taken well outside the order of magnitude of what Squad has in mind, and in general I think doubling the values indicated maintains Squad's general vision, allows for more flexibility (e.g. none of the stock radial decouplers are really strong enough to push off a big radial booster, so doubling the decoupler force might help streamline a design). As long as people in your subcommunity are all on the same page ("I built this with TweakableEverything"), comparison remains valid.

Just asking, is there a reason for why the Near Future mods, radiators, would not be tweakable to open in the VAB using this mod? I believe they are essentially solar panels which do not produce power. And if it is possible, could sommone make a ModuleManager config to make them work? Thanks in advance!

The NF radiators may look and act like solar panels that point the wrong way, but they use a completely different module under the hood and handle all of their animating internally without using any of Squad's modules. So, to support them I'd need to write a whole new module myself and then be prepared to support it. In general, explicitly supporting foreign mod products lies down the path of madness; if I support one mod explicitly then I'll be asked to do another, and another, and there's just too many for me to try to handle them all. Furthermore, the awesome thing about the mod community is that you can take requests straight to the developers themselves instead of relying on hack-around bandaids like TweakableEverything to get the functionality you want. I strongly encourage you to ask Nertea to add an open/close tweakable for his radiators -- that would be a much more graceful solution to your request. On the other hand, I'd like to see it happen, too, so maybe when I'm a bit less busy I'll shoot him a pull request.

Does it have any compatible issue or something? With it my shielded docking port works weird.

I am unaware of any compatibility issues with the base game or any other mods, except HoneyFox's TweakableGimbal, which is much more advanced than mine and should be used in place of mine (not in addition to mine), for users seeking that added functionality. My shielded docking port works just fine, so if you're having an issue you'd need to clarify your problem and get me some troubleshooting information like a debug log or another mod that triggers the issue or something like that.

Now, if you're talking about the in-line docking port, it does work weird, because of a Squad limitation. Squad only allows two attach nodes to be used for child->parent attachment in the editor (i.e. when first placing the docking port in the game, only two attach nodes will be valid). This preference is determined by the order in which they appear in the part file (first and last, as I recall), so there's nothing I can do to work around it. This means that you can't use an inline port as a "T" where the vertical leg of the T is the existing stack you're building in the editor, which is a bummer. Sorry.

Edited September 26, 2014 by toadicus

[BudgetHedgehog]

Quick question: what PartModules does TE add to parts? katateochi, the author of KerbalX, would liek to know. KerbalX works by scanning the craft file and listing out all the parts used. This is handy if a mod part is used as it uses a community-sourced knowledge base of mod parts. For actual parts, like KWR, it's easy and the part itself is a mod thing. However, when things like FAR and TweakScale are used, they add no new parts, but are still required to load and fly the craft. So, the crafts have to be scanned for parts that contain PartModules relating to 'partless part mods', like FarControllableSurface, which is applied to stock control surfaces.

You can see where this is going - TE adds things like ModuleTweakableReactionWheel to stock parts, right? What katateochi would like to know is 'what modules are added?'. Is it as simple as the things included in the cfgs in the download (like ModuleTweakableJettison and ModuleTweakableRCS etc)?

[toadicus]

All of the PartModules that TweakableEverything adds are added by ModuleManager patches, except the EVA tweaks, which are added dynamically. The full list is:

ModuleTweakableRCS
ModuleTweakableEVA
ModuleTweakableDockingNode
ModuleTweakableGimbal
ModuleTweakableResourceIntake
ModuleTweakableDecouple
ModuleTweakableJettison
ModuleStagingToggle
ModuleTweakableAnimateGeneric
ModuleTweakableLadder
ModuleTweakableCrossFeed
ModuleTweakableReactionWheel
ModuleTweakableSolarPanel

[BudgetHedgehog]

Thank you! Also, is there any way to differentiate between a part simply having say, ModuleTweakableGimbal, and actually using it? Say I have TE installed (and I always do) but I don't change any engine gimbal with it. It's there, but just not needed for the craft to load and fly correctly. Is it a case of 'this part has a tweaked gimbal of default, everything is normal' or 'this part has default gimbal, everything is normal'? Make any sense? Mainly for my own sheer curiosity, this is...

[toadicus]

I don't have an easy boolean property like "IsUseful" or something that he can scan for. In general, when I duplicate a parameter (like gimbalRange), I name it exactly the same. If the user hasn't tweaked the parameter, my gimbalRange and Squad's gimbalRange will be the same value. If they have, mine will be different.

That said -- and I'm not 100% sure about this -- I think that most craft should work just fine without TweakableEverything, except the ones built with inline and shielded docking ports used in the preattached configuration. Whatever my tweak was doing will no longer be the case, so the craft might not work as intended, but it should load and not break everything forever. That's one of the benefits of my "helper module" approach, as opposed to extending and replacing existing modules.

EDIT:

Just asking, is there a reason for why the Near Future mods, radiators, would not be tweakable to open in the VAB using this mod? I believe they are essentially solar panels which do not produce power. And if it is possible, could sommone make a ModuleManager config to make them work? Thanks in advance!

The NF radiators may look and act like solar panels that point the wrong way, but they use a completely different module under the hood and handle all of their animating internally without using any of Squad's modules. So, to support them I'd need to write a whole new module myself and then be prepared to support it. In general, explicitly supporting foreign mod products lies down the path of madness; if I support one mod explicitly then I'll be asked to do another, and another, and there's just too many for me to try to handle them all. Furthermore, the awesome thing about the mod community is that you can take requests straight to the developers themselves instead of relying on hack-around bandaids like TweakableEverything to get the functionality you want. I strongly encourage you to ask Nertea to add an open/close tweakable for his radiators -- that would be a much more graceful solution to your request. On the other hand, I'd like to see it happen, too, so maybe when I'm a bit less busy I'll shoot him a pull request.

I took a closer look at the NFE radiators and it looks like they do actually extend the Squad solar panel so at the barest level of theory I feel like my tweaks should apply to it. But, it's been a long time since I wrote the module and I'm not really a C# expert, so I'll need to do some inspection. I do still think that implementing the tweakables in NFE is the right way forward, but now you've got me curious.

EDIT2:

Oh! I know why. The MM patch just isn't applying because it's based on name, not type. If you duplicate the TweakableSolarPanels ModuleManager patch to and make it something like this:

@PART[*]:HAS[@MODULE[FissionRadiator]]:FOR[TweakableEverything]
{
	MODULE
	{
		name = ModuleTweakableSolarPanel
	}
}

My tweaks should apply, and I'd guess they'll work. Do note, nertea already implements the sun tracking tweak, so you'll have two of those.

Edited September 27, 2014 by toadicus
Edit 2: THE EDITTING

[BudgetHedgehog]

I don't have an easy boolean property like "IsUseful" or something that he can scan for. In general, when I duplicate a parameter (like gimbalRange), I name it exactly the same. If the user hasn't tweaked the parameter, my gimbalRange and Squad's gimbalRange will be the same value. If they have, mine will be different.

That said -- and I'm not 100% sure about this -- I think that most craft should work just fine without TweakableEverything, except the ones built with inline and shielded docking ports used in the preattached configuration. Whatever my tweak was doing will no longer be the case, so the craft might not work as intended, but it should load and not break everything forever. That's one of the benefits of my "helper module" approach, as opposed to extending and replacing existing modules.

God amongst men, thank you. I suspect it'll just be easier to scan for those PartModules you listed - better safe than sorry, after all! Maybe just include a warning that the craft may not perform or load correctly without TE.. same with KerbPaint - '.crafts you download may be different to those pictured'

My Shuttle and I thank you tremendously.

[FennexFox]

Sorry, my post was insufficient. I just wanted to know there is any known issue.

I have some problem with shielded docking port. Although it toggled in VAB, but I can`t put anything on that opened port.

[toadicus]

Sorry, my post was insufficient. I just wanted to know there is any known issue.

I have some problem with shielded docking port. Although it toggled in VAB, but I can`t put anything on that opened port.

It's no trouble, I just can't help you without more info. You've taken a step in the right direction! But, like I said, it works just fine for me, so I'm going to need more information on what makes your experience different than my experience.

One of the best ways to get me that information is by giving me your debug log after a run of the game that exhibits the problem. You can find your debug log here: Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log. Put it up on pastebin or gist or dropbox or however you like to share big files, and put a link to it here. With a log, I may be able to find the problem directly, and work around it or notify the author of the incompatible mod if the problem is on his/her end.

You could also list all of the mods you have, and from there I could try telling you the mods that I don't use, and therefore that you should try removing to see if the problem goes away. Once you find it, I can take a look and find the right solution, as I above.

[toadicus]

TweakableEverything has been updated to version 1.4.1! This update brings KSP 0.25 compatibility and a fix for LV-N fairings.

CHANGELOG:

v.1.4.1 [2014-10-07]
* Updated for KSP 0.25.0.
* TweakableEngineFairings: Probably fixed an issue that caused the LV-N fairings not to do as they're told.

[toadicus]

TweakableEverything has been updated to version 1.5! This version formally deprecates the TweakableLadders module, and removes the "double tweakable" on animated parts in the editors.

INSTALLATION NOTE:

You should delete TweakableLadders.dll and TweakableLadders.cfg from your GameData/TweakableEverything folder when installing version 1.5.

CHANGELOG:

v.1.5 [2014-10-19]
* TweakableLadders IS NOW DEPRECATED.  Squad's tweakable has finally and completely caught up.  You should delete TweakableLadders.dll and TweakableLadders.cfg.
* TweakableAnimateGeneric: Now disables the default ModuleAnimateGeneric tweakable in the editor, because ours is sexier.
* TweakableDockingNode: Removed special animation handling; now using TweakableAnimateGeneric instead.
* Minor code changes throughout.

[BudgetHedgehog]

Yaay! I kept meaning to tell you that the animate function appears twice in the menu.. good job!

[katateochi]

Hi toadicus, thank you (and ObsessedWithKSP) for the info on the part modules earlier. That's made it very easy to add in detection of TE, so now craft that been built with TE present are being detected by KerbalX, you can see the craft on KX that use TE by doing this search http://kerbalx.com/?search=~TweakableEverything

I can't tell if scale is being applied thou. With TweakScale there is a default value as well as the scaled value in the module. Is there any chance you could add something like that in?

[SlimJim89]

Is it possible for me to group a bunch of engines in separate groups, and give a certain group a percentage of 30% of total max thrust while the other group can be kept at 100%?

For instance, I have a large ship that I want to keep hovering at a certain altitude, which requires 30% throttle on the Mun(for instance), while my nuclear engines push the ship at 100% throttle.

Is this feature here, or is there another mod for this somewhere?

[toadicus]

This mod doesn't actually provide the throttle limit slider (that's stock these days), and makes no provision for automatic control. While I could conceivably provide action group entries to let you apply or remove a thrust limiter setting from specific engines, doing automatic leveling or decoupling the throttle from certain engines is definitely out of scope here.

That said, I think you might be looking for qfey's Throttle Controlled Avionics. I've never used it myself, but from a quick read of the OP, I think you might find it useful.

EDIT:

Hi toadicus, thank you (and ObsessedWithKSP) for the info on the part modules earlier. That's made it very easy to add in detection of TE, so now craft that been built with TE present are being detected by KerbalX, you can see the craft on KX that use TE by doing this search http://kerbalx.com/?search=~TweakableEverything

I can't tell if scale is being applied thou. With TweakScale there is a default value as well as the scaled value in the module. Is there any chance you could add something like that in?

So, I definitely can add something like that, or I could even add a boolean like "isUsed" or something that might be even simpler for you to detect. But, if I'm going to do that, since it has no practical use to the mod itself, I want to make sure that I'm doing it specifically in a way that is useful to you. So, knowing that I haven't read the source of your site at all, is there a specific implementation that would best enable you to do what you're trying to do?

Edited October 26, 2014 by toadicus
Added response to katateochi

[katateochi]

*snip So, I definitely can add something like that, or I could even add a boolean like "isUsed" or something that might be even simpler for you to detect. But, if I'm going to do that, since it has no practical use to the mod itself, I want to make sure that I'm doing it specifically in a way that is useful to you. So, knowing that I haven't read the source of your site at all, is there a specific implementation that would best enable you to do what you're trying to do?

Awesome! Thanks, that would be great. Yes, a boolean would be the best, something like isTweaked as an attribute added to the Tweakable modules would be the simplest for me. At my end I currently check if a craft file contains any of the TweakableEverything modules. Having found a module I can then read the attributes from it, so as long as each TweakableEverything module gets isTweaked = True added to it when its active then that will work great for me. If isTweaked is set to False or is not present I will consider it as not tweaked.

Thanks for considering this toadicus, I really appreciate it.

[ginsuguy585]

Howdy, is there a way to enable the tweak ui for reaction wheels in-flight? I want to be able to change reaction wheel strength without changing other control forces.

[toadicus]

There's not currently a way for you to do that. As a part of what I'm trying to do for katateochi, I'm working on figuring out a more consistent way of rebuilding the underlying systems in use here that would also make it easier for me to add such options for you, but right now there's nothing you can do.

[Spheniscine]

Request: Ability to turn crossfeed off for radial decouplers? Seriously they shouldn't have crossfeed capability at all just like stack decouplers (and just rely on fuel lines for times when you want crossfeed)... but just the ability to turn it off would be nice.

[toadicus]

Huh, when did radial decouplers start crossfeeding? Well yeah, that's not OK.

I've actually had a crossfeed tweak written for a long time; let me dust it off and make sure everything still works OK.

EDIT:

Playing with it some more, the crossfeed on radial decouplers seems like a bug. It works differently than normal crossfeed, e.g. if an engine is on a fuel tank on a radial decoupler on another fuel tank, you'd expect it to drain the host tank first, but it doesn't. In fact, it'll only feed across the decoupler if there is no fuel available on the "out" side of the decoupler; not just "enough fuel to run", but no fuel that applies to the engine. I had a couple units of liquid fuel, but no oxidizer, left in the outboard tank, and the engine wouldn't drain from the central tank unless I disabled the LiquidFuel flow control on the outboard tank. Weird stuff.

Fortunately, my tweak appears to work just fine. I'll get it in the next release, but for now here's the standalone DLL: http://ksp.hawkbats.com/TweakableEverything/TweakableCrossFeed.dll

To add the module to radial decouplers, open up TweakableDecouplers.cfg, and change the ModuleAnchoredDecoupler patch to look like this:

@PART[*]:HAS[@MODULE[ModuleAnchoredDecoupler]]:FOR[TweakableEverything]:NEEDS[TweakableStaging]
{
	MODULE
	{
		name = ModuleTweakableDecouple
		decouplerModuleName = ModuleAnchoredDecoupler
	}

	[b]MODULE
	{
		name = ModuleTweakableCrossFeed
		fuelCrossFeed = false
	}[/b]
}

Bolded region is new.

Edited November 11, 2014 by toadicus
Added explanation of radial crossfeed behavior, TweakableCrossFeed link, and patch.

[Padishar]

Huh, when did radial decouplers start crossfeeding?

It has been this way for a considerable time (at least 0.23 and quite possibly earlier).

Playing with it some more, the crossfeed on radial decouplers seems like a bug. It works differently than normal crossfeed, e.g. if an engine is on a fuel tank on a radial decoupler on another fuel tank, you'd expect it to drain the host tank first, but it doesn't. In fact, it'll only feed across the decoupler if there is no fuel available on the "out" side of the decoupler; not just "enough fuel to run", but no fuel that applies to the engine. I had a couple units of liquid fuel, but no oxidizer, left in the outboard tank, and the engine wouldn't drain from the central tank unless I disabled the LiquidFuel flow control on the outboard tank. Weird stuff.

It follows the well established fuel flow rules described in this thread. Post #8 describes the particular rule that affects this, but basically, if a part is surface attached to its parent part then it will only draw fuel from that parent if the part itself can not contain fuel of the particular type (or has the type of fuel disabled). So a fuel tank attached to a radial decoupler will not draw fuel through the decoupler but another type of part can. It is a bit weird but whether or not it is a bug is debatable. It certainly isn't a bug in the fuel flow rules but it may have been unintentionally left active when the default crossfeed of parts changed from false to true at some point in the past.

[toadicus]

Wow, that's astonishingly thorough. Thanks for the info, Padishar! Learned a few new things today.

[praise the suuun]

is it possible i could get my hands on a copy of TE 0.24? i installed the 0.25 version but im not getting any tweakable options on my docking ports. (im using ksp 0.24)

Edited November 28, 2014 by praise the suuun

[toadicus]

Here's the last version that was released for 0.24.x: http://ksp.hawkbats.com/TweakableEverything/TweakableEverything-1-4.tar.xz

If that still doesn't work I'm happy to look at a log and see if there's any troubleshooting we can do, but at this time I'm not maintaining legacy versions.

[passinglurker]

Is it possible to make the fuel flow mode used by an individual engine tweakable? say let you change an ion engine from xenons default "all_vessel" to "staged_priority_flow" in the editor or even on the fly?