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

[toadicus]

Speaking of docking nodes, I just had a crazy idea. Assuming it's even possible, what if the "nodeType = size1" in the following was tweakable?

Could this be a "poor man's" alternative to a universal docking port? Cpt. Kipard, this might be of special interest to you.

Please forgive me if this has already been suggested. And if I haven't said so already, thank you thank you thank you toadicus for this wonderful mod. I can't even imagine going back to KSP without it.

Intriguing idea. I'm not sure how well that would work though. I suspect that from a gameplay point of view it might be difficult keeping track of what docking ports are compatible.

Something else might be in the work though. Stay tuned.

As Cpt. Kipard hinted, we've developed a plugin to handle the universal docking ports so no one need settle for such a "poor man's" solution. The tweakable idea had occurred to me as well, though!

I've had trouble with this before, with any part that has more than a couple of attach nodes.

Turns out the order the nodes are read in by the game affects which ones can attach in the editor - to fix this, I've changed the dockingPortLateral section to look something like

@PART[dockingPortLateral]:Final
{
	// remove original bottom node
	!node_stack_bottom

	node_stack_tdn = 0, 0, -.671, 0, 0, 1, 1

	// add it back after stack_tdn to allow editor attaching
	node_stack_bottom = // actual value

	// etc...
}

Don't have the files nearby at the moment so I can't check the actual value, but you get the idea.

Ooh, good find! Thanks, I will test this and get it into a new version Soonâ„¢.

Is there a module aside from the one that contains all the other docking port functionality (I assume applying that module to something that wasn't a docking port wouldn't end well) which would allow fuel cross-feed to be toggled on a part, in the editor and in flight? If not, could that be offered at some point in the future?

At present no; there's no functional granularity available below the module level. I'll look into the possibility of adding a config file to disable tweakables that you don't want, but I'm not going to break the functionality out into an entirely separate module.

Edited April 10, 2014 by toadicus
Added response to ArcaneZedric

[Superfluous J]

I just had a flash of inspiration while reading this thread about how flags orient themselves semirandomly. Like most of my best ideas, it involves other people doing the acutal work.

Would it be possible to tweak a flag's angle after it's been planted? Obviously it'd have to be able to be done by a Kerbal that was nearby (like how they can open solar panels) or the flag itself would need some magic juju to get it working.

[Jethro Bodine]

As Cpt. Kipard hinted, we've developed a plugin to handle the universal docking ports so no one need settle for such a "poor man's" solution. The tweakable idea had occurred to me as well, though!

Oooh! That's amazing! Thank you very much toadicus and Cpt. Kipard!

[toadicus]

Quick update:

• I've got some quality-of-life improvements to the docking node decoupler staging thing.
  
• I've implemented ArcaneZedric's attach node fix.
  
• I've added some special handling that should fix the FAR problem with TweakableEngineFairings.
  

Haven't started on Tʜᴇ Cʟᴀᴡ yet, but hope to get to it this weekend.

Looking into the crew capacity tweak. I think there may be a way to make it work and my basic idea right now is this: the tweakable will only affect the value of CrewCapacity in the editor; in flight it will revert to the original value. This should have the effect of preventing the editor from over-filling your pod, while still allowing you to fill it as desired once the flight is active. I mean, hopefully. If everything goes as planned. For working the other way: enticing the editor to fill parts other than the primary pod, I'm not sure yet. At this point that's all locked up in the EditorLogic around launching and drawing the crew selection dialog. If I can find an event or lifecycle function that sneaks in to the right place, I might be able to make something work provided you have sufficient Kerbals on staff.

Looking into flags. I need to mess with some ideas, but I've got a couple and at least one should work. Worst case I can probably give flags three new event buttons for EVA Kerbals: reset to due north; rotate 15° clockwise; rotated 15° counter-clockwise. Best case I can hopefully get a slider on the flag itself that lets you pick the heading directly.

[Superfluous J]

All of these things sound wonderful. I'm loving this mod

Looking into the crew capacity tweak. I think there may be a way to make it work and my basic idea right now is this: the tweakable will only affect the value of CrewCapacity in the editor; in flight it will revert to the original value. This should have the effect of preventing the editor from over-filling your pod, while still allowing you to fill it as desired once the flight is active. I mean, hopefully. If everything goes as planned. For working the other way: enticing the editor to fill parts other than the primary pod, I'm not sure yet. At this point that's all locked up in the EditorLogic around launching and drawing the crew selection dialog. If I can find an event or lifecycle function that sneaks in to the right place, I might be able to make something work provided you have sufficient Kerbals on staff.

Sounds cool. Removing people from the main pod is 90% of my troubles for sure. Usually I want them full unless I'm sending up a rescue craft. I hate to eva my kerbal to send them falling to their death revert to the hangar just to make room for the guy I'm saving.

Looking into flags. I need to mess with some ideas, but I've got a couple and at least one should work. Worst case I can probably give flags three new event buttons for EVA Kerbals: reset to due north; rotate 15° clockwise; rotated 15° counter-clockwise. Best case I can hopefully get a slider on the flag itself that lets you pick the heading directly

Both of those options sound great. Slider would be cool but buttons work fine. Considering how often this will get used (Once per flag ) buttons wouldn't be a big deal at all. Bonus, you're always on the ground so you don't have to play "follow the button" games like you do with rotating crafts in orbit.

[Tallinu]

As Cpt. Kipard hinted, we've developed a plugin to handle the universal docking ports so no one need settle for such a "poor man's" solution. The tweakable idea had occurred to me as well, though!

At present no; there's no functional granularity available below the module level. I'll look into the possibility of adding a config file to disable tweakables that you don't want, but I'm not going to break the functionality out into an entirely separate module.

Well, the reason I was asking is that I wanted to be able to add a module to other parts that would let me disable crossfeed... Would using the tweakable module for docking ports to do that cause problems, or work fine (except for cluttering up the menu with useless controls)?

Also, I assume the updated universal docking ports work fine with this one? I'll have to give that a try.

(PS. I am curious, though, why you're opposed to having the crossfeed control as a separate module.)

[toadicus]

Well, the reason I was asking is that I wanted to be able to add a module to other parts that would let me disable crossfeed... Would using the tweakable module for docking ports to do that cause problems, or work fine (except for cluttering up the menu with useless controls)?

Also, I assume the updated universal docking ports work fine with this one? I'll have to give that a try.

(PS. I am curious, though, why you're opposed to having the crossfeed control as a separate module.)

The functionality in TweakableDockingNode is currently only applicable to docking nodes. I've tried to keep it from making a mess of things if you add a ModuleTweakableDockingNode to non-docking node parts, but it might, and it probably wouldn't do anything.

I misunderstood your request the first time around. I certainly could build a tweakable to toggle crossfeed for all parts everywhere, but I don't think I'd want to distribute it with the mod as an official component, because it'd kinda make a mess of things. But I'll try to make time to whip something up that you can apply to parts at your own discretion (i.e. via your own ModuleManager configs).

[Tallinu]

Thanks Toadicus, that would be really awesome.

[BudgetHedgehog]

Is there away to disable the decoupler in the docking ports? I get that it's useful for LES and such like, but I don't use them and it's making rearranging the staging harder when I have all these decouplers listed. Thanks

[toadicus]

Is there away to disable the decoupler in the docking ports? I get that it's useful for LES and such like, but I don't use them and it's making rearranging the staging harder when I have all these decouplers listed. Thanks

Yes; it's a tweakable like everything else here. It should default off, and you can turn it on and off by right-clicking on the port and toggling "Decoupler Staging".

[BudgetHedgehog]

Ahh, I see it now... Didn't know about it and for some crafts, it was enabled.. also didn't know you can only set it in the VAB. Is it possible to change it in flight?

[CSVoltage]

I just wanted to drop a "Thank-you" for my suggestion of disabling auto-fairings being added. It's nice to know that comments don't just disappear into the void.

[coldblade2000]

Hey, these is an incompatibility with this mod an RedAV8R FASA Realism pack. Multiple parts phase and have FX errors. This is spit out in the logs every second:

NullReferenceException: Object reference not set to an instance of an object

at TweakableRCS.ModuleTweakableRCS.LateUpdate () [0x00000] in <filename unknown>:0

This does not happen without TweakableEverything. Latest version does not fix the problem. More info here: http://forum.kerbalspaceprogram.com/threads/73319-0-23-WiP-RedAV8R-Realism-Packs-for-RSS-Last-Update-5-April-2014/page6

[toadicus]

Hey, these is an incompatibility with this mod an RedAV8R FASA Realism pack. Multiple parts phase and have FX errors. This is spit out in the logs every second:

NullReferenceException: Object reference not set to an instance of an object

at TweakableRCS.ModuleTweakableRCS.LateUpdate () [0x00000] in <filename unknown>:0

This does not happen without TweakableEverything. Latest version does not fix the problem. More info here: http://forum.kerbalspaceprogram.com/threads/73319-0-23-WiP-RedAV8R-Realism-Packs-for-RSS-Last-Update-5-April-2014/page6

My guess is that something in one of the realism kits removes a ModuleRCS from a part that had it previously, after TweakableRCS has already added its helper module.

The "right way" to fix this might be to look into the new ordering options in ModuleManager 2.0, but since adoption on that has been slow so far as I can tell and I really have no idea how all the realism stuff is tracked or applied, here's a DLL that should just make TweakableRCS fail more gracefully when it's on a part with no RCS modules. Let me know if that does the trick!

Also, if you're not using the TweakableRCS functionality, you can remove it entirely without removing the rest of TweakableEverything: just delete or relocate TweakableRCS.dll and TweakableRCS.cfg from the TweakableEverything folder.

On the crew capacity tweak:

Short version: I don't think it's going to work in this context. Long version follows:

CrewCapacity is tracked in each partPrefab (the set of "master" information read in from the GameData folder when the game is loaded used to create each Part instance during play), in each Part (the combination of prototype and prefab information that makes up a unique instance of a part as represented during play), and in the Internal model.

In flight, the latter two are used. If the part reports a small crew capacity, Kerbals will be refused admittance even if the internal model is filled. On the other hand, if the part reports a larger capacity, the internal's seat count will dictate the refusal. This is straightforward to deal with, if it's what I cared about. I can tweak the part's field directly, and can remove and add seats from the internal model's data structure.

Unfortunately, in the editor, automatic crew filling is governed by the prefab data. This means that in order to change the way the crew filler behaves, I have to change the prefab. This is undesirable: because the prefab is the "master" data for all future instances of the part, and because the editor does not entirely start parts up the way flight does, changing the prefab has very extensive interactions with future instances of parts. I've found suitable places to reset the prefab value, but it still produces behavior that IMO users will find confusing or unacceptable. Just because I can do something doesn't mean I should.

The more I think about it, the more I think that the right way to do this is to use a partless plugin that just gives a "Disable automatic crew assignment" toggle in the editor; on the Toolbar or near the crew assignment button, perhaps. From there the process should be simpler; if I don't care about assigning specific values, I ought to be able to deal with the problem from a different perspective.

[CaptainKipard]

This will probably fall outside the "tweakable" purview, but how about changing the behaviour of the "Launch" button so that it invokes the same function as pressing the launch pad?

[toadicus]

Thanks Toadicus, that would be really awesome.

Give this a try: http://toad.homelinux.net/KSP/TweakableEverything/TweakableCrossFeed.dll

I haven't tested it at all, but it's literally just the crossfeed code stripped out of TweakableDockingNode, so it should work as well as that does.

As I said, I'm not adding this to any parts myself, but if you want to use it you can write ModuleManager patches like this:

// Change <myPartName> to the "name" field of the part to which you're adding the module, e.g. for the Modular Girder Segment, <myPartName> should be replaced by trussPiece1x.
@PART[<myPartName>]
{
	MODULE
	{
		name = ModuleTweakableCrossFeed
		// If you want crossfeed to default to off, uncomment the line below.
		// fuelCrossFeed = False
	}
}

Edit: One bit of cautionary advice: fuel crossfeed in KSP is some dark arcanery. In general, this should prevent fuel from passing through a part when it's set to disabled. But fuel flow follows a lot of weird rules about attach nodes and orientation and who knows what else, so it will not cause fuel to flow across a part that would not normally conduct fuel in its stock behavior.

Edited April 14, 2014 by toadicus

[BudgetHedgehog]

So about my decoupling docking ports... yes, it defaults to disabled so they're not listed in the build stage list. But when I actually go to fly, they're enabled. Any ideas why? :/

[toadicus]

This will probably fall outside the "tweakable" purview, but how about changing the behaviour of the "Launch" button so that it invokes the same function as pressing the launch pad?

I think there's probably a way to do that, but you're right that it's out of scope for this particular mod. I might have a look at it soon, but this might also be something to take to someone with an existing editor-improvement mod, as they may already know more about it than I do.

So about my decoupling docking ports... yes, it defaults to disabled so they're not listed in the build stage list. But when I actually go to fly, they're enabled. Any ideas why? :/

Hrmm. Well, my git log tells me that I fixed some bugs to do with docking decouplers after the last release, but damned if I can remember what they were.

Here! Have an internal development .dll and let me know if this fixes the issue.

[BudgetHedgehog]

Here! Have an internal development .dll and let me know if this fixes the issue.

Most kind and yes, that appears to have fixed the issue. Me and my growing staging list thanks you!

[Tallinu]

One bit of cautionary advice: fuel crossfeed in KSP is some dark arcanery. In general, this should prevent fuel from passing through a part when it's set to disabled. But fuel flow follows a lot of weird rules about attach nodes and orientation and who knows what else, so it will not cause fuel to flow across a part that would not normally conduct fuel in its stock behavior.

I have a pretty decent idea of how it works - I just wanted to be able to toggle crossfeed between certain sections of a stack without having to insert docking ports in the middle of something that isn't intended to be detachable, and this should do the job just fine. Thanks again!

[MK3424]

Maybe another suggestion (if it's possible) i already suggested to disable suntracking on solarpanels.

I wonder: is there a way to rotate them manual?

Inside the VAB and ingame.

This would be handy: self placing solar panels in a fixed rotation setting.

[Benoit Hage]

Hello!

It seems the option of enable/disable staging of a decoupler is breaking the dV calculation of Mechjeb once it has been triggered. Un-trigger it and it stays broken. Does it come from TweakableEverything or from Mechjeb?

[Superfluous J]

Hello!

It seems the option of enable/disable staging of a decoupler is breaking the dV calculation of Mechjeb once it has been triggered. Un-trigger it and it stays broken. Does it come from TweakableEverything or from Mechjeb?

It does the same for Kerbal Engineer Redux. At least with KER, if you re-enable it the calculations come back. One thing I had to do was set the staging up reasonably, as the re-enabled decoupler was put in a weird spot in the sequence.

[Benoit Hage]

It does the same for Kerbal Engineer Redux. At least with KER, if you re-enable it the calculations come back. One thing I had to do was set the staging up reasonably, as the re-enabled decoupler was put in a weird spot in the sequence.

I'll try that as well. Maybe if I set the decoupler the way I want it before adding tanks and engines, the calculation will take into consideration the proper figures. I'll update this later today.

Thanks for the tip 5thHorseman!

EDIT: It works! yay!

Edited April 17, 2014 by Benoît

[toadicus]

Tried this with the MK3 cargo bays the other day, pretty neat!

Glad to hear you liked it!

Maybe another suggestion (if it's possible) i already suggested to disable suntracking on solarpanels.

I wonder: is there a way to rotate them manual?

Inside the VAB and ingame.

This would be handy: self placing solar panels in a fixed rotation setting.

That might be possible. I'll look into it, though if sirkut's issues with Infernal Robotics are any indication, it might be a huge mess to account for various attachment modes.

It seems the option of enable/disable staging of a decoupler is breaking the dV calculation of Mechjeb once it has been triggered. Un-trigger it and it stays broken. Does it come from TweakableEverything or from Mechjeb?

It does the same for Kerbal Engineer Redux. At least with KER, if you re-enable it the calculations come back. One thing I had to do was set the staging up reasonably, as the re-enabled decoupler was put in a weird spot in the sequence.

So the basic issue here is that both of those tools search for decouplers to determine if parts are shed at a particular stage. When I disable staging on a decoupler, I can only take it out of the list; I can't make those tools believe it not to be a decoupler, and they couldn't accomodate the tweak themselves without reflection or some dependence on my code. It's possible that I can work around the issue by "poisoning" the decoupler's stage (invaliding their checks later in the logic), but this may come with the side effect that it will always come back at one end of the staging list rather than trying to remember where it was.

Edited April 18, 2014 by toadicus