Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicated TweakScale support on some parts #20

Closed
Lisias opened this issue Feb 15, 2019 · 7 comments

Comments

Projects
None yet
1 participant
@Lisias
Copy link

commented Feb 15, 2019

[(and yeah… it appears to be my fault)] - (no, it was not! :D )

On command parts such as the HECS probe core or the 1.25m or 2.5m remote guidance units, which all have "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" in their patches, the apparent size of the part in the editor (as well as apparent size of its nodes, and also the direction of attachment the stack nodes allow) are all messed up. In addition, they have two tweakscale sliders (see image - shows scale problem and slider, but not nodes):

In any case, removing the "#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }" also seems to fix the issue.

(AccidentalDisassembly)

Image

TASK: Revise the patches before the Big Refactoring from Krakens (tm), this appears to be two different patches trying to add different scalings (my guess: one for science, other for part size).

@Lisias Lisias self-assigned this Feb 15, 2019

@Lisias

This comment has been minimized.

Copy link
Author

commented Feb 15, 2019

This can be triggered by the following situations:

  • TweakScale adding support for things "by pieces", i.e., first one patch add support por scaling Science, while other had previously added support for sizing.
  • Same thing, done by someone else after (or before!) TweakScale ones.
  • Third parties blindly adding support for his own parts, and "leaking" for other ones.
  • Just for my peace of mind, check if by some reason MM could not be doing this. (almost impossible, such a glitch would had be detected already - but who knows? Kraken poo happens!)

In a way or another, TweakScale itself is not checking for the its presence before patching up, so I'm part of the problem myself (even if by luck I'm innocent this time). In a way or another, I need to revise the patches at the very least.

@Lisias Lisias added Not My Fault and removed My fault. labels Feb 15, 2019

@Lisias

This comment has been minimized.

Copy link
Author

commented Feb 15, 2019

I have to backtrack on the "my fault" setting.

There's not a single way I could force a patch to be applied twice - on every single attempt, even by mangling ModuleManager's cache manually, a single instance of the TweakScale module data is the final result at runtime.

No guesses for while. Still working on reproducing the problem, so I can test the fix!!!

@Lisias

This comment has been minimized.

Copy link
Author

commented Feb 16, 2019

To making things clearer.

This is what I was thinking I would find on the MM caches (but I didn't:

MODULE
{
	name = TweakScale
	type = stack_square
	defaultScale = 2.5
	TWEAKSCALEEXPONENTS
	{
		mass = 2.5
	}
}
MODULE
{
	name = TweakScale
	type = stack_square
	defaultScale = 2.5
	TWEAKSCALEEXPONENTS
	{
		mass = 2.5
	}
}

However, this is what I found instead:

MODULE
{
	name = TweakScale
	type = stack_square
	type = stack_square
	defaultScale = 2.5
	defaultScale = 2.5
	TWEAKSCALEEXPONENTS
	{
		mass = 2.5
		mass = 2.5
	}
}

I don't think it's a patch problem anymore. Aparently this can only be done programmatically, by code.

@Lisias

This comment has been minimized.

Copy link
Author

commented Feb 16, 2019

HA! GOTCHA! :)

This is an excerpt from the Module Manager's cache once I managed to force the problem.

MODULE
{
	name = TweakScale
	type = stack_square
	defaultScale = 2.5
	type = stack_square
	defaultScale = 2.5
	TWEAKSCALEEXPONENTS
	{
		mass = 2.5
	}
}
MODULE
{
	name = TweakScale
	TWEAKSCALEEXPONENTS
	{
		mass = 2.5
	}
	}
}

However, the duplicated U.I. is not happening. :-(

screen shot 2019-02-15 at 23 40 29

But the craft file is tainted as "expected":

MODULE
{
	name = TweakScale
	isEnabled = True
	currentScale = 3.75
	defaultScale = 2.5
	defaultTransformScale = (1, 1, 1)
	DryCost = 10372.3643
	stagingEnabled = True
	EVENTS
	{
	}
	ACTIONS
	{
	}
	UPGRADESAPPLIED
	{
	}
}
MODULE
{
	name = TweakScale
	isEnabled = True
	currentScale = 2.5
	defaultScale = 2.5
	defaultTransformScale = (0, 0, 0)
	DryCost = 10372.3643
	stagingEnabled = True
	EVENTS
	{
	}
	ACTIONS
	{
	}
	UPGRADESAPPLIED
	{
	}
}

Once I fixed the MM's cache (by hand), by loading the craft file the first instance of the TweakScale data is ignored, with the second instance being used instead - what "corrupts" the craft as these parts falls to default values at loading.

@Lisias

This comment has been minimized.

Copy link
Author

commented Feb 16, 2019

Oh, joy. :D

The code that detects a 0 sized list of ScaleFactors was preventing the code that detects the Duplicates to work. By "luck" :D on 1.6.1 a duplicated TweakScale module section has this info zeroed.

Well… At least now it works. :)

@Lisias

This comment has been minimized.

Copy link
Author

commented Feb 16, 2019

The Workaround works. Perfectly.

Once the newest TweakScale is installed, every mangled craft file will be "mangled again" in a good way. All but the first instance will be persisted with the module name mangled (and a warning added) in order to prevent it from overwrite the live instance's data once the triggering misbehaviour (adding more than one instance of TweakScale on a part) is solved.

@Lisias

This comment has been minimized.

Copy link
Author

commented Feb 16, 2019

Fixed on commit: b99d82f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.