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

[BudgetHedgehog]

80 hours? Geez.. you take your time, mate

[toadicus]

TweakableEverything has been updated to version 1.8.1! This update re-introduces the TweakableLadders module and allows re-packed parachutes to be used as a part of the staging list.

CHANGELOG:

v.1.8.1 [2015-03-15]
* Old module!  TweakableLadders is back, because broken tweakables that play long animations in the editor make us sad.
* TweakableParachutes: Added logic to re-enable deployment via the staging list after chutes have been repacked.

[Drew Kerman]

is there any way to make the RCS thruster tweakable scale down to 0 from 5? Currently it just jumps from 5 to 0

[toadicus]

Are you talking about the EVA pack thruster throttle? If so, the answer is yes... but let me see if I can find a way to let you do it, without making everyone else also do it. I find tweakables with more than 20 or so stops on the line to be super annoying, which is why I coded it to make the increments divide into the total 20 times.

[futrtrubl]

is there any way to make the RCS thruster tweakable scale down to 0 from 5? Currently it just jumps from 5 to 0

I think he means how all thrusters/rcs can't be tweaked below 5% thrust. I find that questionable though, the vast majority of thrusters can't throttle lower than 50% IRL and in the game most (are supposed to) flame out below 10% thrust.

[Drew Kerman]

yea I'm talking about RCS thruster blocks, not EVA packs. And RCS thrusters should indeed be able to limit way down. futrtrubl you're referring to LF/O engines. RCS blocks aren't engines.

todicus as far as I've been able to tell, scaling thrust on RCS blocks can actually be done in single-step increments all the way down to 5, where it jumps to 0. Not sure what you mean about 20-something stops

[dc4bs]

Hi All,

Got an odd one here that I can't figure out.

Tweakable Everything 1.8a and 1.8.1 cause my VAB and launchpad craft loading to take a really long time.

For example, I have a ~600 part ship that loads into the VAB in about 15 seconds when tweakable everything is not installed but it takes that same ship 5+ minutes to load in the VAB or launchpad when it is installed.

Smaller ships of 50 parts or less seem to load with no noticeable delays. Only the larger craft seem to have the issue.

I was wondering if this was normal behavior for tweakable everything? And if not, does anyone knew if it might be conflicting with one of the mods below?

To find the mod that was causing my slowness issues I made a fresh test install and then I started adding mods to it a few at a time time. The list below were the ones installed when I finally found that the issue I'm having seems to be tweakable everything. The ones with * were installed together as the first group because my stress-testing craft requires all of them. Then I added FAR and tweakscale with tweakable everything and that's where I hit the slow loading issue.

Running V.90

B9 Aerospace R5 2.8 *

KSPX-v0.2.8.1 *

MechJeb2-2.4.2.0-402 *

RemoteTech-1.6.3 *

SXT_-_Stock_eXTension-20 *

TacLifeSupport_0.10.2.15 *

FAR 14.6

TweakScale_1_51_1

Given the above install, when I add tweakable everything, the initial game start up still loads to the main menu at the same speed but loading the craft into the VAB or the launchpad is super slow.

When I add/remove tweakable everything to my regular/full game install (around 50 mods or so) I get the same slow craft loading effect in the VAB and launchpad that goes away again when I remove it and restart the game.

NOTE: This issue does not appear to affect craft load times in-game. EG: When approaching my space station (around 400 parts) Pop-in seems to take about 10-15 seconds whether tweakable everything is installed or not.

Edited March 20, 2015 by dc4bs

[toadicus]

Gaiiden, I'll take a quick look, but I know what you're talking about and I'm pretty sure that's Squad's issue, not mine. When you drag particularly near to the bottom end of a floatrange tweakable, it clamps to zero for no apparent reason, even though the rest of the scale all works pretty smoothly. If you want to get finer precision in the general sense you could reduce the thrusterPower of your RCS blocks by half, which would give you more room to tweak at the bottom end of the range before the slider clamps down. If you only want it sometimes and it's fairly predictable, I could theoretically give you a "trim" range from -5..5% that would add to the actual throttle value.

dc4bs, I haven't built any megaships for a while, but several of my modules do linear searches of various parts of the ship -- usually just their own part, but sometimes the whole ship -- that might slow things down. If you can get me the craft file (or better yet, upload it to KerbalX so their software can do the hard part of finding the minimum set of mods required for me), I'll see if I can reproduce and nail down some optimizations or at least offer an explanation.

Also, does this happen just the first time you load a particular craft before re-saving it after installing TE, or does it happen every time? Because I add module to parts, the first time you load an existing ship save Squad has to go through all the parts and help the modules to all line up correctly. If you save the ship again after that's happened, it shouldn't need to happen again, but if you don't save the ship again it will have to re-run that adaptation every time you load it. A few other mods -- FAR is one -- also repeat similar processes as they add their helper modules. So, you should expect longer loads when loading saved craft the first time after installing mods that add a lot of modules (and TE does), especially for very large ships (because the process is always at least O(n) and sometimes worse).

[Neutrinovore]

I don't recall anyone else mentioning this, so I'll go ahead and throw it out there.

The 'Reverse Gimbal' Tweakable is really pretty cool, especially when I'm designing more unusual types of ships where I want to put some engines ahead of the CoM. BUT... (you knew there was a 'but' coming, I hope), but, I can't for the life of me conceive of a situation in which one would EVER want to reverse ROLL control inputs. Think about it. If the purpose of reversing the control inputs is to generate steering commands using engines ahead of the CoM, the roll inputs are still going to be the same. Let's say I want to yaw my ship LEFT. So I want the engines behind the Center of Mass to angle to the LEFT in order to force the tail to rotate to the right, thus yawing the ship to the left. I want the engines ahead of the CoM to angle their thrust to the RIGHT, in order to push the nose of the ship LEFT, the direction I want to go. So far so good. BUT, if I want to ROLL the ship to the LEFT, or shall we say 'Counter Clockwise', then I want ALL of the engines that are not directly in line with the axis of thrust to angle in the SAME direction, DOWN on the right side of the ship, UP on the left, to the right on the 'top' of the ship, etc. In this case, it doesn't matter where the engines are in relation to the Com. Got it?

Anyway, long-winded explanation, I know, but I wanted to be as thorough as possible in case anyone else reading (other than the developers, I mean) wasn't understanding what I was trying to say.

So, my point is, is there any way to have the 'Reverse Gimbal' tweakable act ONLY in certain axes, such as yaw and pitch, and leave roll control inputs unmodified? Since I know less than nothing about computer programming I'm genuinely asking if this is possible, and if so whether it would be relatively easy to implement.

That's all I had for today. Later, everyone!

[dc4bs]

dc4bs, I haven't built any megaships for a while, but several of my modules do linear searches of various parts of the ship -- usually just their own part, but sometimes the whole ship -- that might slow things down. If you can get me the craft file (or better yet, upload it to KerbalX so their software can do the hard part of finding the minimum set of mods required for me), I'll see if I can reproduce and nail down some optimizations or at least offer an explanation.

Also, does this happen just the first time you load a particular craft before re-saving it after installing TE, or does it happen every time? Because I add module to parts, the first time you load an existing ship save Squad has to go through all the parts and help the modules to all line up correctly. If you save the ship again after that's happened, it shouldn't need to happen again, but if you don't save the ship again it will have to re-run that adaptation every time you load it. A few other mods -- FAR is one -- also repeat similar processes as they add their helper modules. So, you should expect longer loads when loading saved craft the first time after installing mods that add a lot of modules (and TE does), especially for very large ships (because the process is always at least O(n) and sometimes worse).

Sounds like an issue we had with running reports on large databases. Adding in some indexes and partitioning the data dropped some of the report generation times by like 95% vs. the old full table-scans.

---

Anyway, the delays happen every time I load or reload any large craft in the VAB or on the launchpad. Does not affect craft save times. Once loaded, no further issues. Encountering other large craft "in the wild" does not trigger it for pop-ins either.

I think I can drop the mods used down to 2 or 3 pretty easily with a bit of ship editing. Then I'll see about posting it for you.

Basically it's a beast designed to put 9 fully fueled orange tanks wrapped around an orbital tug into LKO. Uses an additional 20 orange tanks (and just a few smaller ones) and 48 of the large NASA style SRBs in 8 stages... And she does the job real nice! (only stage 8-5 used in launch - 4 is just spare maneuvering fuel to get to the station - 3-0 are for after mating it with the station to be pushed interplanetary.)

--------------------

EDIT: OK got the test version posted.

Edited March 21, 2015 by dc4bs

[Drew Kerman]

Gaiiden, I'll take a quick look, but I know what you're talking about and I'm pretty sure that's Squad's issue, not mine.

Yea I figured. Just wanted to make sure. Don't bother with it

[toadicus]

I don't recall anyone else mentioning this, so I'll go ahead and throw it out there.

The 'Reverse Gimbal' Tweakable is really pretty cool, especially when I'm designing more unusual types of ships where I want to put some engines ahead of the CoM. BUT... (you knew there was a 'but' coming, I hope), but, I can't for the life of me conceive of a situation in which one would EVER want to reverse ROLL control inputs. Think about it. If the purpose of reversing the control inputs is to generate steering commands using engines ahead of the CoM, the roll inputs are still going to be the same. Let's say I want to yaw my ship LEFT. So I want the engines behind the Center of Mass to angle to the LEFT in order to force the tail to rotate to the right, thus yawing the ship to the left. I want the engines ahead of the CoM to angle their thrust to the RIGHT, in order to push the nose of the ship LEFT, the direction I want to go. So far so good. BUT, if I want to ROLL the ship to the LEFT, or shall we say 'Counter Clockwise', then I want ALL of the engines that are not directly in line with the axis of thrust to angle in the SAME direction, DOWN on the right side of the ship, UP on the left, to the right on the 'top' of the ship, etc. In this case, it doesn't matter where the engines are in relation to the Com. Got it?

Anyway, long-winded explanation, I know, but I wanted to be as thorough as possible in case anyone else reading (other than the developers, I mean) wasn't understanding what I was trying to say.

So, my point is, is there any way to have the 'Reverse Gimbal' tweakable act ONLY in certain axes, such as yaw and pitch, and leave roll control inputs unmodified? Since I know less than nothing about computer programming I'm genuinely asking if this is possible, and if so whether it would be relatively easy to implement.

That's all I had for today. Later, everyone!

The short answer is "no". The long answer is that I can't intercept the control inputs individually without replacing the whole ModuleGimbal module, which applies the same gimbalRange scalar value to all three axes. TweakableGimbals works by negating that value. Since I can't invert it "just sometimes" and I can't change the roll input "just for gimbals", I'd need to write a new gimbal module to replace Squad's that used different values for each axis. I know that's been done a couple times before, but I'm not sure what the most recent adaptation. At this point, it's out of scope here. Sorry!

Sounds like an issue we had with running reports on large databases. Adding in some indexes and partitioning the data dropped some of the report generation times by like 95% vs. the old full table-scans.

---

Anyway, the delays happen every time I load or reload any large craft in the VAB or on the launchpad. Does not affect craft save times. Once loaded, no further issues. Encountering other large craft "in the wild" does not trigger it for pop-ins either.

I think I can drop the mods used down to 2 or 3 pretty easily with a bit of ship editing. Then I'll see about posting it for you.

Basically it's a beast designed to put 9 fully fueled orange tanks wrapped around an orbital tug into LKO. Uses an additional 20 orange tanks (and just a few smaller ones) and 48 of the large NASA style SRBs in 8 stages... And she does the job real nice! (only stage 8-5 used in launch - 4 is just spare maneuvering fuel to get to the station - 3-0 are for after mating it with the station to be pushed interplanetary.)

--------------------

EDIT: OK got the test version posted.

I think I've found the problem, and have solved it for most cases. The issue was to do with TweakableStaging, which was running a full search through the ship for every decoupler in the ship on the first LateUpdate call. That's actually only necessary if you're toggling the staging in the first frame (e.g. if you've set a decoupler to "Disable Staging"), so I added a tiny bit of logic that should make sure we only run in the first frame if we need to. I need to test it before I release to make sure I didn't break anything else... hopefully I'll have a chance to do that tomorrow.

Yea I figured. Just wanted to make sure. Don't bother with it

Roger that.

[dc4bs]

I think I've found the problem, and have solved it for most cases. The issue was to do with TweakableStaging, which was running a full search through the ship for every decoupler in the ship on the first LateUpdate call. That's actually only necessary if you're toggling the staging in the first frame (e.g. if you've set a decoupler to "Disable Staging"), so I added a tiny bit of logic that should make sure we only run in the first frame if we need to. I need to test it before I release to make sure I didn't break anything else... hopefully I'll have a chance to do that tomorrow.

That's great! I really need tweakble everything running for this craft as I am using a Sr. docking port as a stage decoupler because I need crossfeed enabled through it. If I didn't need that crossfeed I could use a regular decoupler. I suppose I could also use octagonal struts and fuel lines to work around a regular decoupler as well but that is a less elegant solution.

[toadicus]

OK, so I didn't get a chance to test it this weekend. In the interest of trying to release something sooner rather than later, here's a test version including the fix:

[zip] [tar.gz] [tar.xz]

Let me know how it goes! Failing that, I'll try to test and release properly next weekend.

[dc4bs]

OK, so I didn't get a chance to test it this weekend. In the interest of trying to release something sooner rather than later, here's a test version including the fix:

[zip] [tar.gz] [tar.xz]

Let me know how it goes! Failing that, I'll try to test and release properly next weekend.

Cool!

The craft is back to loading with no delays in the VAB and on the launchpad with the dev version you posted above installed in my game.

Thanks!

EDIT 1:

OK, just did a bunch of testing and found the following.

1: Not sure if this is an issue with your mod or "Crew Manifest". When using CM to change/remove kerbals from the ship while on the pad, it goes back to taking several minutes to refresh/reload the craft once CM is done. Just wondering if there is a craft reload function call or something that is still using the old scanning method.

NOTE: Removing all kerbals in the VAB crew assignment menu before loading on the launchpad avoids this reload/delay.

2: When loaded in the VAB, ALL docking ports on the craft now always show up in the staging stack (unassigned ports all go to stage 0). If I enable staging and then disable staging on each port it will remove it from the stack (temporarily).

NOTE: Docking ports intentionally used for staging stay in the staging stack in their assigned locations as expected when loading a saved craft that uses them (they do NOT migrate to stage 0).

3: Even if the ports are removed from the stage stack as in note 2 (and even if the craft is then saved again), they will all be returned to sage 0 on the staging stack when the craft is loaded on the launchpad.

NOTE: Docking ports intentionally used for staging stay in the staging stack in their assigned locations as expected (they do NOT migrate to stage 0).

4: No ports ever get removed from the staging stack unless they are removed by being staged off the craft at some point so they are no longer present. The dead separator symbols for every port just sit there in the staging stack with no way to remove them.

EDIT 2:

5: Docking with another craft made all the extra ports in the staging stack disappear...

Anyway, hopefully these notes will help with further debugging.

EDIT 3:

And here's the completed station/colony ready to head out... 5.3k delta-V (6k if only the smaller, more efficient nuke rockets are used but at much less than the .34 TWR it has with the 5 larger ones in the rear ).

Edited April 1, 2015 by dc4bs

[toadicus]

Pretty! Thanks for the info; that will be helpful in debugging. I figured I was going to break something like that with this change... that's why it's a test release.

[Wyrmshadow]

I've run into a mission breaking bug that I believe is associated with this mod. My docking ports some times don't want to disengage.

I've run into this problem before so I've been very careful to tweak the re-engage distance to zero and to max out the decoupling force on all my docking ports BEFORE launch. Yet sometimes things slip past me. At the moment I've got a lander connected to a space station above Moho refueling before a trip to Duna. Docking went fine but now they are stuck and won't undock, even after I've pressed the correct button, it no longer shows up. In times past, if it looks like I've undocked (the crew pictures change) but I'm still physically connected, I use HYPEREDIT to change my orbit and the other docked ship is no longer attached. Or some times when it appears I have physically left the other ship and speed up timescale, when I return to normal time the Kraken attacks and things go all crazy and reattached.

Okay long story short, is there any way I can undock the damn thing. I did a quicksave before and then again after I docked, but now I'm stuck.

[BudgetHedgehog]

Do you have KJR installed? If so, update it.

[Wyrmshadow]

Do you have KJR installed? If so, update it.

Was that for me? Yes and it's updated. Ship won't undock, and other docking ports won't dock to begin with.

[toadicus]

Wyrmshadow, docking and undocking is one of the most esoteric bits in the game and lots of mods do things that wind up affecting it. However, I'm unsure how this one could at all, unless it's to do specifically with reducing your re-engage distance to 0 (so even if the ship does undock, it tries to dock again literally immediately thereafter). So, I'd try setting that to a sane number (at least half a meter) and trying again... if it's still going on, I'm happy to take a look, but I'll need a log (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) in order to do so.

[pellinor]

@toadicus:

You use -1 to mark fields as not initialized (for example rollTorque in tweakableReactionWheels). TweakScale currently messes up your internal states by trying to scale this -1. Since all negative values are invalid states, it would be more robust to ask for "localField<0" instead of "localfield==-1".

For making TweakScale and TweakableEverything work together, is there a kspField that I can scale to affect the tweaking range?

[smjjames]

There is something wierd going on with one of the tweakable everything modules as it's breaking a craft when I try to load it in VAB and kind of breaks KSP's everything (and then some) when I try to load that specific craft. I should note that when I removed all of tweakable everything, the craft loaded fine.

I'm putting in the modules one by one to find out what it is.

Edit: I found one of them, which is tweakableSAS, but when I tried putting the rest of them in, it broke again, so I'm still looking.

tweakable reaction wheels

tweakable fuel pumps (I have KAS and KIS, so there could be a conflict coming from there, or maybe TAC fuel balancer, no idea)

Edited April 20, 2015 by smjjames

[toadicus]

@toadicus:

You use -1 to mark fields as not initialized (for example rollTorque in tweakableReactionWheels). TweakScale currently messes up your internal states by trying to scale this -1. Since all negative values are invalid states, it would be more robust to ask for "localField<0" instead of "localfield==-1".

For making TweakScale and TweakableEverything work together, is there a kspField that I can scale to affect the tweaking range?

pellinor, I'll take a look; a solution like yours will probably work to fix the initialization gate.

A few of the modules let you set tweakable ranges in a config.XML file in PluginData, but that probably doesn't help with TweakScale much. Can you be more specific about what you need?

There is something wierd going on with one of the tweakable everything modules as it's breaking a craft when I try to load it in VAB and kind of breaks KSP's everything (and then some) when I try to load that specific craft. I should note that when I removed all of tweakable everything, the craft loaded fine.

I'm putting in the modules one by one to find out what it is.

Edit: I found one of them, which is tweakableSAS, but when I tried putting the rest of them in, it broke again, so I'm still looking.

tweakable reaction wheels

tweakable fuel pumps (I have KAS and KIS, so there could be a conflict coming from there, or maybe TAC fuel balancer, no idea)

smjjames, can you get me a log file? Also, do you use VOID and/or CKAN?

[smjjames]

pellinor, I'll take a look; a solution like yours will probably work to fix the initialization gate.

A few of the modules let you set tweakable ranges in a config.XML file in PluginData, but that probably doesn't help with TweakScale much. Can you be more specific about what you need?

smjjames, can you get me a log file? Also, do you use VOID and/or CKAN?

Sure, soon, and no I don't use VOID or CKAN. I used the download off the OP.

Using the tweakableSAS (behavior is the same for all three of those bugged ones):

Output log: http://sta.sh/0226crg9zc0n

This is what happens when I try to load a particular craft in the VAB, it glitches out and creates a bugged vehichle with the name "vehichle name", the lone piece is a command pod way up. This shows the KIS error that gets generated and shows the craft that I had intended to load.

This is what happens when I attempt to load the craft on the launchpad. Also insert roaring noise and possibly explosions while KSP has a meltdown.

Btw, the craft that I was trying to load is this behemoth. I'm actually building it in orbit using EPL, it's just on the launchpad for a test of something.

Edited April 20, 2015 by smjjames

[smjjames]

Okay, after I put in actiongroups extended mod (and put the tweakable everything folder back in after taking it out, and after updating vens stock revamp), something else is screwing up that craft. Now I need to look all over again.