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

[toadicus]

1.0.2 compatible?

Yep; I forestalled my upload and unpacked 1.0.2 just so I could compile against it to be sure.

[BudgetHedgehog]

Yep; I forestalled my upload and unpacked 1.0.2 just so I could compile against it to be sure.

Excellent stuff - get in mah Gamedata! Thanks for the update, I missed the tweakable Engine fairings!

Also, not sure if this is stock of StockBugFixModules (doubt it), but the radial decouplers have a tweakable Force Percent that can go down from 100 (presumably percent) to 0. What's all that about? I really need to investigate this when I'm a little bit less distracted..

[funk]

I've an issue with stageable docking port decouple. If triggered in flight, the stage with the docking port stays without resources and isn't maneuverable anylonger. When trying to go back to spacecenter it sets time back because: "[Log]: Active Vessel is under acceleration (G = 0.780494940469038). Cannot save."

log entry:

NullReferenceException: Object reference not set to an instance of an object
  at ModuleDockingNode.Decouple () [0x00000] in <filename unknown>:0 
  at TweakableEverything.ModuleTweakableDockingNode.OnActive () [0x00000] in <filename unknown>:0 
  at Part.ModulesOnActivate () [0x00000] in <filename unknown>:0 
  at Part.force_activate () [0x00000] in <filename unknown>:0 
  at Part+.MoveNext () [0x00000] in <filename unknown>:0 

log download: http://workupload.com/file/27c0oVu2

P.S. Is there a way to tell KER or MJ that the decoupling of a docking port triggers a new stage?

Edit: When toggling "decouple" manually it's fine, so it must be related to staging.

Edited May 2, 2015 by funk

[smjjames]

I'm having a problem with some things. For some mod parts which can be tweakable, when I right click on them, I get a huge amount of lag for no apparent reason. Examples are the fairings from Procedural Fairings and one of the segmented boosters from NovaPunch (using Tiberions beta version of the 1.0.1 compat).

Modlist:

DMagic Orbital Science

KER

MJ

USI mods FTT, Karbonite, MKS, Exploration pack

CRP

exception detector

Taurus HCV

SpaceY heavy-lifters

hyperedit

procedural fairings

stock bugfixes

KAC

NRAP (stupid_chris's adjustable test weights)

AVC

Modular Rocket Systems

KJR

Firespitter

Hangar Extender

Taniwhas VispR

novapunch (Tiberions beta version for 1.0.1 compatibility)

Edited May 2, 2015 by smjjames

[toadicus]

funk, it seems like there's something else going on there. I tested a few cases just now and I can't duplicate your issue, so it's most likely a mod conflict or a version incompatibility in some other mod. You might try removing your mods one by one to see if you can eliminate the problem? Also, if there's a specific use case where this caused a problem for you, I could try to duplicate that.

smjjames, I grabbed NovaPunch, but couldn't really reproduce with simple craft and my testing mod set, but I'm going to hazard a guess that the issue is floating point issues on the FloatRange. When the control detects that something's changed, it does some work to assign the new value to the part and whatever needs to happen as a result of that goes ahead and happens. There are certain points in certain ranges that cause onEditorShipModified to be fired way too often when the ranges are open. The reasoning goes something like this:

1. The slider loads up and sets its position to X pixels long. The total slider is Y pixels long.
   
2. Since the slider is repositioned, fire an update event. (this eventually chains to an onEditorShipModified call, which can be very expensive depending on the mods installed and the size of the ship)
   
3. The control uses the slider's normalized position to interpolate along the available range, essentially Value=Min + (Max - Min) * X/Y
   
4. The control checks if Value lands on a stepIncrement (the feature that makes ranges "snap" to certain values along the range).
   
5. If Value does not land on a stepIncrement, it rounds the value to the nearest stepIncrement and repositions the slider, basically X=Y*(Value - Min)/(Max - Min) truncated to an integer (no fractional pixels).
   
6. If the slider is repositioned, start over at #1.

For certain values in certain ranges, especially when stepIncrement is small in relation to the overall tweakable range, that equation for Value will never return a value divisible by stepIncrement. When that happens, onEditorShipModified is called every Update for every float range visible that is subject to this condition. If you want to check if that's what's happening, compile this plugin and see if onEditorShipModified is called whole bunch in those trouble scenarios: http://hastebin.com/nudeniboli.cs

[smjjames]

Do I just stick that in a text document, make it a config and stick it into gamedata or how do I compile it as a plugin because I don't know how, or what you mean?

[funk]

I've tested without any mods except TE. The bug still exists. It seems to have some weird consequences how the craft is rebuild after decoupling.

Quicksave: http://workupload.com/file/A40Gfd8Y

...quickload shows "Station and Satellite" ship... it should be in orbit prepared for decoupling the satellite with the next stage... when you switch back to the station part after decoupling it's all fine, but there is already weird staging of the satellite after decoupling. Accelerate the satellite until the station part is on rails. Then switch back to the station on map view... Kerching!

Edit: When the bug appeared first, yesterday, I recognized, that the station part of the craft was doubled in tracking station, but if you choose the first one KSP showed emtpy space around Kerbin. The second one showed the same non-maneuverable bug.

Perhaps it is related to how I build the craft, so I uploaded it, too. Stockparts only.

Craftfile: http://workupload.com/file/FPIAf1Ld

Edited May 2, 2015 by funk

[toadicus]

Sorry smjjames; I was confusing you with a different james on these forums. Here's the plugin already compiled: http://ksp.hawkbats.com/onEditorShipModifiedSniffer.dll It doesn't print anything to the screen, but if you watch your output_log it'll print a message every second or so telling you how many onEditorShipModifiedSniffer calls were made in that second. If the number is in the hundreds when you have a tweakable window open, the odds are good the problem is related to the issue I described above.

funk, I'll take a look at those items, hopefully later today.

[smjjames]

No prob and thanks. I'll check it out a bit later.

[smjjames]

I tried it and the .dll failed to load. I tried the link which gave me a 404 not found, so I had to 'save link as':

Failed to load assembly C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\onEditorShipModifiedSniffer.dll:

System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.

at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0

at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0

at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0

at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0

at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0

at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0

at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0

[dc4bs]

Hi again...

I loaded the new 1.9.1 TE and that slow loading issue came back for my 600 part craft. The dev build you posted for me to work around this problem still seems to be working OK (warts and all) in 1.02. So unless I find any game breaking issue I guess I'll be sticking with that build for now as it looks like that big craft needs a rebuild from scratch due to the changes between .90 and 1.02.

All of the solar panels, sepratrons and vertical decouplers in the craft have disappeared (still poking around to figure out what else went awol)... Their icons still show in the staging stack but all of the boosters are now jammed together/touching where in .90 they were all spaced about a 1/2 meter apart by the decouplers. The weirdest part is that when I tried launching the craft staging DOES decouple the boosters with 0 ejection force but everything then explodes as the boosters scrape down the sides of the remaining craft (the invisible sepratrons don't fire...)

EDIT:

OK. tried loading the older "test" copy of the ship in question (the one I posted earlier). That one loads OK so it looks like it's not a 1.02 problem with the ship above. Looks like somehow the craft file was corrupted. Ugh.

Edited May 4, 2015 by dc4bs

[jazzkutya]

Hi Toadicus,

Since the new SAS modules and pilots in KSP do a not so optimal job at keeping a certain direction (causing jerky movement with overpowered control forces, iirc mechjeb did a better job), it would be nice to be able to tweak reaction wheel torque in-flight.

Here is a patch for this.

Also i think default stepmult for torque slider would be better being .1f for fine control (for example Mk1 command pod gets only 10 steps which is really 5 steps if we consider the original value range).

For anyone wanting to change granularity of the sliders, you can already do this:

Open GameData/TweakableEverything/PluginData/TweakableReactionWheels/config.xml

You will see this somewhere: <double name="stepMult">1</double>

Change the 1 to something else, smaller values for finer granularity. I'd recommend 0.1.

Too bad this was not documented, i spent an hour trying to hack this value in the source

[toadicus]

I tried it and the .dll failed to load. I tried the link which gave me a 404 not found, so I had to 'save link as':

I've re-uploaded a version with slightly different compile options that loads up just fine for me. But here's an example of its output when I open up a tweakable menu on one of the NovaPunch segmented boosters:

onEditorShipModified fired 0 times since last report (0.00 calls per second).
onEditorShipModified fired 48 times since last report (47.67 calls per second).
onEditorShipModified fired 184 times since last report (180.92 calls per second).
onEditorShipModified fired 216 times since last report (211.76 calls per second).
onEditorShipModified fired 224 times since last report (215.59 calls per second).
onEditorShipModified fired 224 times since last report (216.01 calls per second).
onEditorShipModified fired 192 times since last report (185.87 calls per second).
onEditorShipModified fired 216 times since last report (214.07 calls per second).
onEditorShipModified fired 216 times since last report (212.60 calls per second).
onEditorShipModified fired 216 times since last report (216.00 calls per second).
onEditorShipModified fired 192 times since last report (187.50 calls per second).
onEditorShipModified fired 232 times since last report (223.51 calls per second).
onEditorShipModified fired 224 times since last report (223.55 calls per second).
onEditorShipModified fired 48 times since last report (47.76 calls per second).
onEditorShipModified fired 0 times since last report (0.00 calls per second).

And here it is on an FL-T400:

onEditorShipModified fired 0 times since last report (0.00 calls per second).
onEditorShipModified fired 1 times since last report (1.00 calls per second).
onEditorShipModified fired 4 times since last report (4.00 calls per second).
onEditorShipModified fired 0 times since last report (0.00 calls per second).

This is very typical of the symptoms I described previously. Unfortunately, there's nothing I can really do about it, especially for Squad's tweakables (fuel tanks, etc). Theoretically for my tweakables I could adjust the granularity so this happened less frequently in default cases.

Hi again...

I loaded the new 1.9.1 TE and that slow loading issue came back for my 600 part craft. The dev build you posted for me to work around this problem still seems to be working OK (warts and all) in 1.02. So unless I find any game breaking issue I guess I'll be sticking with that build for now as it looks like that big craft needs a rebuild from scratch due to the changes between .90 and 1.02.

I'll take another look at the logic. It's difficult because I need to do something when the parts start up the first time, and the more parts you have that are set with staging opposite their default (engines/decouplers with staging off, docking ports/etc with staging on) the more work I can't avoid doing. I'll try to take another thorough look at it and see if I can reinvent the process entirely. Maybe using onEditorShipModified so it can suffer from problems like smjjames'.

All of the solar panels, sepratrons and vertical decouplers in the craft have disappeared (still poking around to figure out what else went awol)... Their icons still show in the staging stack but all of the boosters are now jammed together/touching where in .90 they were all spaced about a 1/2 meter apart by the decouplers. The weirdest part is that when I tried launching the craft staging DOES decouple the boosters with 0 ejection force but everything then explodes as the boosters scrape down the sides of the remaining craft (the invisible sepratrons don't fire...)

Guessing that's a more-or-less expected side effect of the 0.90->1.0 update, and nothing to do with this mod. Bummer, though.

Hi Toadicus,

Since the new SAS modules and pilots in KSP do a not so optimal job at keeping a certain direction (causing jerky movement with overpowered control forces, iirc mechjeb did a better job), it would be nice to be able to tweak reaction wheel torque in-flight.

Here is a patch for this.

Also i think default stepmult for torque slider would be better being .1f for fine control (for example Mk1 command pod gets only 10 steps which is really 5 steps if we consider the original value range).

That's a fine idea; maybe it be better to do a single "torque limiter" slider that reduces all three to make it easier to adjust while hurtling through the thermosphere?

Too bad this was not documented, i spent an hour trying to hack this value in the source

It's not documented because I'm thoroughly unhappy with how I'm handling that and want to change it. When I get something I'm happy with I'll make it a bit clearer.

[jazzkutya]

That's a fine idea; maybe it be better to do a single "torque limiter" slider that reduces all three to make it easier to adjust while hurtling through the thermosphere?

Well i would prefer a single torque gain slider instead, 0-100 (percentage), with a stepincrement of 1 or 2 or maybe 5 (and hoping this will not choke on UI_FloatRange). I can do this and provide a new patch, but not right now.

Edit: change of plans, i just did it. Patch here.

Edited May 3, 2015 by jazzkutya

[dc4bs]

I'll take another look at the logic. It's difficult because I need to do something when the parts start up the first time, and the more parts you have that are set with staging opposite their default (engines/decouplers with staging off, docking ports/etc with staging on) the more work I can't avoid doing. I'll try to take another thorough look at it and see if I can reinvent the process entirely. Maybe using onEditorShipModified so it can suffer from problems like smjjames'.

Hmm...

The ship has 10 docking ports (2 small, 2 regular and 6 large - all 6 large used as decouplers with 2 of those disabling cross feed), many decouplers and loads of engines & SRBs that are not tweaked.

[Superfluous J]

vardicd, I'll look into tweaking the new fairings soon.

Sweet do you plan to allow tweaking the number of pieces around? Right now it's hard coded for each base diameter. I'd love to be able to specify how many I want for each.

[toadicus]

Well i would prefer a single torque gain slider instead, 0-100 (percentage), with a stepincrement of 1 or 2 or maybe 5 (and hoping this will not choke on UI_FloatRange). I can do this and provide a new patch, but not right now.

Edit: change of plans, i just did it. Patch here.

Here's your commit, sir: https://github.com/toadicus/TweakableEverything/commit/4a1571a8dc6dd1abd70b6e59452b04fb8576cf0d

Made a couple minor tweaks; I don't like 100-step tweakables (they're too tricky to get on the number you want), so I changed the stepIncrement to 2. Also, only dividing by 100 once during the update pass.

This shouldn't cause any issues with the floatrange going nuts, because all of the available steps are integers, which are expressible without error in floats, and because the range is pretty small (0..100). The problem usually comes from infinite binary fractions like 0.3 (et al) and really large ranges with small steps (e.g. the NovaPunch engines with fuel values in the tens of thousands and a stepIncrement in the single digits or so).

Hmm...

The ship has 10 docking ports (2 small, 2 regular and 6 large - all 6 large used as decouplers with 2 of those disabling cross feed), many decouplers and loads of engines & SRBs that are not tweaked.

So, here's the basic logic. When a ModuleTweakableStaging module is started up, it tries to detect if it needs to do any work (e.g. does it need to add an icon to a part that doesn't have one, or remove one for a part that does), and whether or not that icon needs to be added or removed from the staging list. If work does need to be done, among the things that may happen as a result is a calculation of what stage the part will be removed in. To do this, it walks up the part tree starting from itself until it finds a decoupler that's being removed, or gets to the top. For parts that are rather deep in their tree on a very big ship, this might go a long ways before it hits the top.

Now, to get the kind of slowdown we're looking at, I'm almost certainly detecting something incorrectly at the beginning and doing searches for parts that don't need them (e.g.: "many decouplers"). If you've patched TweakableStaging to apply to engines, I might even be doing searches for all of them. The dev build I gave you in 0.90 was an attempt to fix that detection, but it broke another part of it which is why things that shouldn't have been defaulting to "on" were doing so. When I fixed that for the 1.9 release, I apparently un-fixed my first fix.

Anyway, I'm going to revisit the way I do the search and separate a few bits of logic that are currently coupled needlessly. Hopefully I'll have another test build for you soon.

Sweet do you plan to allow tweaking the number of pieces around? Right now it's hard coded for each base diameter. I'd love to be able to specify how many I want for each.

I haven't even looked at it yet, but if it's as easy as setting fairing.PiecesAround = XYZ (or even if it's a bit harder), then I absolutely will.

[jazzkutya]

Made a couple minor tweaks; I don't like 100-step tweakables (they're too tricky to get on the number you want), so I changed the stepIncrement to 2.

Yeah stepIncrement of 2 is also perfect, thanks.

I'm glad you liked my idea and happy to contribute to your nice mod .

[dc4bs]

So, here's the basic logic. When a ModuleTweakableStaging module is started up, it tries to detect if it needs to do any work (e.g. does it need to add an icon to a part that doesn't have one, or remove one for a part that does), and whether or not that icon needs to be added or removed from the staging list. If work does need to be done, among the things that may happen as a result is a calculation of what stage the part will be removed in. To do this, it walks up the part tree starting from itself until it finds a decoupler that's being removed, or gets to the top. For parts that are rather deep in their tree on a very big ship, this might go a long ways before it hits the top.

Now, to get the kind of slowdown we're looking at, I'm almost certainly detecting something incorrectly at the beginning and doing searches for parts that don't need them (e.g.: "many decouplers"). If you've patched TweakableStaging to apply to engines, I might even be doing searches for all of them. The dev build I gave you in 0.90 was an attempt to fix that detection, but it broke another part of it which is why things that shouldn't have been defaulting to "on" were doing so. When I fixed that for the 1.9 release, I apparently un-fixed my first fix.

Anyway, I'm going to revisit the way I do the search and separate a few bits of logic that are currently coupled needlessly. Hopefully I'll have another test build for you soon.

I will keep an eye out for it.

Though having loaded up the current partial form of voxel FAR and due to less burn time on the NASA SRBs it looks like this ship may not be workable in it's current size/shape... Or maybe I'll have to launch it with no fuel in the core tanks and refuel them once in orbit before docking with the colony/station it's meant to push out to some distant planet.

[toadicus]

New dev build that should probably fix the long delay without breaking things is available here: [zip] [tar.gz] [tar.xz]

I've still got some optimizations that I want to do, but I need to find new and better ways of detecting state in Squad's code. In the meantime, let me know how that one does.

UPDATE: Optimizations pretty much done; waiting on a bit of testing before I release.

Edited May 5, 2015 by toadicus

[dc4bs]

New dev build that should probably fix the long delay without breaking things is available here: [zip] [tar.gz] [tar.xz]

I've still got some optimizations that I want to do, but I need to find new and better ways of detecting state in Squad's code. In the meantime, let me know how that one does.

UPDATE: Optimizations pretty much done; waiting on a bit of testing before I release.

OK. The new dev build loads fast.

Although I get no staging stack on the right in VAB after loading a craft. But that appears as soon as I add or remove an engine or some other part that affects it.... (easy to work around. )

[toadicus]

Posted a new dev build including my optimizations and a bit of tweaking. I've got a staging list after I load a ship; do you? Any other weirdness?

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

[dc4bs]

Posted a new dev build including my optimizations and a bit of tweaking. I've got a staging list after I load a ship; do you? Any other weirdness?

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

That looks pretty good.

I've only fiddled with it a few minutes so far but I didn't see any of the issues from before.

EDIT: Found an oddity. If you toggle decoupler engine shrouds off they don't redraw when you toggle them back on. Had to save and reload the craft in order to see them again.

Edited May 7, 2015 by dc4bs

[BudgetHedgehog]

Ooh, I just remembered - Squad fixed the engine gimbal bug where they don't move correctly if they're ahead of the CoM. With that in mind, is the 'reverse gimbal' option needed any more? I can't think of a situation that would require it...

[toadicus]

EDIT: Found an oddity. If you toggle decoupler engine shrouds off they don't redraw when you toggle them back on. Had to save and reload the craft in order to see them again.

That's unrelated to this particular issue, but I'll give it a look. Are you using any other mods that mess with shrouds, e.g. procedural fairings?

Ooh, I just remembered - Squad fixed the engine gimbal bug where they don't move correctly if they're ahead of the CoM. With that in mind, is the 'reverse gimbal' option needed any more? I can't think of a situation that would require it...

I saw that as well, and wondered similarly. I can't think of a good use for it, either, but I'm loathe to remove functionality without talking it out here first. I guess you could use it to do poor-man's translation or something?

So, to all concerned parties: does the "Reverse Gimbal" toggle continue to serve any use for you? If not, I will remove it.

We can always revert the commit later.