Lisias

[KSP >= 1.4.1] TweakScale - Under Lisias' Management - 2.4.3.10 - 2019-1030

Recommended Posts

Posted (edited)
On 2/28/2019 at 1:45 AM, AccidentalDisassembly said:

OK - I continue to believe something is messed up within TweakScale,

I don't believe. I know it. :) I'm not really fixing things for now, I'm patching them up to prevent the worst scenarios. :( 

There're no easy way out of this. I'm not masochist :D , I really didn't found a better solution other than that Big Refactoring from Krakens of mine.

 

On 2/28/2019 at 1:45 AM, AccidentalDisassembly said:

This is the picture I'll be referring to - this is what CERTAIN parts look like every time. Can't be scaled (except down by one step, but values in either slider do not change):

LfHG0a7.png

That's interesting.  I will investigate.

[Reproduced. See the POST EDIT below]

 

On 2/28/2019 at 1:45 AM, AccidentalDisassembly said:
  1. Just in case of MM screwiness (or something), delete all MM cache files, and also delete PartDatabse.cfg.

I think this is a good time to explain that Module Manager is not the problem. It only happens that it doesn't have, at least to the momento, any features that would allow it to be part of the Solution (at least, the Solution I managed to cook).

The problem are rogue patches. And the only sane fix is to detect and fix the patches. Clutches to cope with the rogue patches will just make things worst, as the clutches themselves can induce new colateral effects in a chain reaction - sometimes without perceptible symptoms until the crash and/or game corruption.

 

On 2/28/2019 at 1:45 AM, AccidentalDisassembly said:

All of that was wrong too. I have no idea what's going on, but it's borked even in a purely stock/TweakScale install, so something is messed up for sure. I tried.

Thanks for your efforts. We don't need to agree on every step to recognize the huge efforts you are doing for TweakScale. :) 

If a purely stock with TweakScale is borking, you are right on pinpointing TweakScale as the source of the bork. I should had done this again after the new discoveries of past few weeks to tell you the true.

What I know for sure is that TweakScale doesn't add itself to any part (and only recently I added code to withdraw itself from some nasty detectable scenarios), so the source of the glitch (to say the least) are the patches. This will be a dirty and gruesome task, but another one I need to accomplish is to test adding the patches gradually (it's a bit less painful using a binary tree search approach) in order to reduce the scope of the hunt.

But, on the other hand (and again), that BFR (Big Fine Refactoring :D ) would render this task unneeded, as Add'On support will be dismembered, drastically reducing the surface of attack for such bugs. So I'm kind of uncertain if I should waste yet more time on patching new roles on the dam instead of solving the thing properly.

 

On 2/28/2019 at 1:45 AM, AccidentalDisassembly said:

On another note, for purposes of safety and reducing duplication, I would suggest that EVERY patch in TweakScale be edited to use "%type =" and similar rather than "type = " when doing patches - just in case someone else has already defined a type for a part (etc.).

This is where I'm get some reserves with. This will not fix the rogue patches, this will hide them. The reasons for that follows:

  • A bad standard is better than no standard.
    • It's TweakScale the reference for scaling. Instead of blindly patching it to cope with random Add'Ons, it's that random Add'Ons that should, ideally, be patched to cope with TweakScale. By doing this, everybody will be on the same page. If TweakScale would cope with rogue patches by demand, so we would have no standard or expected defaults to cope with - and that would be a unholy mess of biblical dimensions.
    • It's already hard to cope with the current patches (as you are pinpointing above). Now try to imagine the huge colateral effects we would have by blindly changing the patches. See below for a technical explanation
  • This will not prevent rogue patches to exist. It will make them harder to detect.
    • Right now, it's feasible to monitor MM as it applies patches in order to catch who is duplicating things once you have named a part with double data. It's one of the features I'm planning for somewhat in future, by the way.
    • Without this, I would have to instrument Module Manager itself so he would raise an exception when such part is detected - but this would need to inject more knowledge on MM than it really needs to work, and a already complex piece of software would had it's already huge surface of attack for bugs even wider without not direct benefit for its core business
  • Dismembering the patch support will drastically reduce that surface of attack to manageable levels, as the majority of the users will not be exposed to more patches than they need. This appears to be the biggest lesson we can take from your reports.

That technical reason I mentioned is due the way ConfigNode handles "arrays". When you add an array to a ConfigNode, you have a ordered (but not necessarily sequential) collection of data with the same name. You need to use a specific call to get all the values under that name, and if you use the call for singleton values you get the last value.  But I'm used to see code that uses the "array version" of the call and then getting the first value (I wonder if by similar reasons).

This last scenario would break beautifully if I edit an value that people are used to get duplicated and selecting the first one, and then people start to get the value from the later adders instead of the expected value added by the first one! And since by the ASCII ordering TweakScale tends to be the last guy on the chain, it also tends to be prevalent  on that scenario - i.e., any guy that have a disagreement with TweakScale on something and is used to get the first value will get suddenly "wrong values" came from nowhere.

So… It will accomplish very few, can potentially break expected behaviour (wrong behaviour, but a expected one nevertheless - remember when I said that a bad standard is better then no standard at all?) and the rogue patches will still be there. And the real problem are the rogue patches.

 

On 2/28/2019 at 1:45 AM, AccidentalDisassembly said:

Also - some patches have superfluous definitions, e.g. the engine plate's TS patch defines incrementSlide and scaleFactors, but does not need to because those are already defined by its scaletype (unless some custom increments are being used which I didn't catch).

Patches getting old without proper supervision. :(

The dismembering will help on this too.

 

On 2/28/2019 at 6:40 PM, Barzon Kerman said:

@Lisias how do I make Tweakscale configs? I want to make them for @DylanSemrau's WIP Provenance Aerospace?

You need to understand a bit about Module Manager patches first. A TweakScale config is nothing more than a patch.

Unless you are considering support TweakScale directly, and then TweakScale would be a hard dependency for your parts. If this is the case, I would suggest you to rethink this. Not everybody wants to use TweakScale - this could limit your audience. In my humble opinion, the best approach is to write MM patches for your Add'On and include them on the release, and tell MM to ignore such patches when TweakScale is not installed (see the :NEEDS clausule).

 

On 2/28/2019 at 10:03 PM, Tyko said:

what app are you opening them in? I use Notepad++ and they are fully formatted...

Or give a peek on the github directly, and make use of the auto-formatting features of the site.

https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/Examples.cfg

https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/documentation.txt

@Tyko - some text editors are using proportional fonts as default nowadays, messing up beautifully the visualization of the good, old and faithful text files. :( It's one of the reasons I, by default, use TABs and not spaces on my projects - my colleagues can set up the TAB width in pixels as they want, and (almost) everybody end up happy.

 

— — — POST EDIT — — — 

I reproduced the problem described above (with a screenshot). Things are a bit hairy, by the way. This is the grep for my KSP.log looking to EnginePlate4 (the internal name for the EP 50):

$ cat KSP.log | grep "EnginePlate4"

[LOG 00:31:43.977] Config(PART) SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4
[LOG 00:31:44.020] Config(@PART[EnginePlate4]) TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4]
[LOG 00:31:51.727] [ModuleManager] INFO: Applying update TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4] to SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/PART
[LOG 00:32:32.018] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4'
[LOG 00:32:32.048] PartLoader: Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4' has no database record. Creating.
[LOG 00:32:32.055] DragCubeSystem: Creating drag cubes for part 'EnginePlate4'
[WRN 00:33:17.429] [TweakScale] Removing TweakScale support for EnginePlate4.
[ERR 00:33:17.429] [TweakScale] Part EnginePlate4 didn't passed the sanity check due having a ModulePartVariants with Mass - see issue #13 https://github.com/net-lisias-ksp/TweakScale/issues/13.

This confirms my thesis de the MM is not on the guilty list for this problem. :) I used MM3 by the way, to prevent any worries due the new parallelized patching routines. 

On the MM cache I found this:

UrlConfig
{
	name = EnginePlate4
	type = PART
	parentUrl = SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4
	PART
	{
		name = EnginePlate4
		module = Part
		author = RoverDude
		rescaleFactor = 1
		node_stack_top = 0,0.4,0,0,1,0,4
		node_stack_bottom = 0,0,0,0,-1,0,4,0,0,1,0
		breakingForce = 2500
		breakingTorque = 2500
		fx_gasBurst_white = 0.0, 0.0650517, 0.0, 0.0, 1.0, 0.0, decouple
		sound_vent_large = decouple
		TechRequired = metaMaterials
		entryCost = 3000
		cost = 300
		category = Coupling
		subcategory = 0
		title = EP-50 Engine Plate

		[ CUT -- CUT -- CUT -- CUT -- ]

		MODULE
		{
			name = TweakScale
			type = stack
			defaultScale = 5.0
			scaleFactors = 0.1,  0.3,   0.625, 1.25,  1.875, 2.5,  3.75, 5.0, 7.5, 10, 20
			incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2
			TWEAKSCALEEXPONENTS
			{
				mass = 2
			}
			TWEAKSCALEEXPONENTS
			{
				name = TweakScale
				DryCost = 0.5
			}
		}
	}
}

Well. we have a problem: a duplicated TWEAKSCALEEXPOENTS thingy. This is fixed on the development branch, and was identified by @Tonka Crash here.

The hairy situation is that TweakScale 4.1.0 is detecting the EnginePlate4 as an unsupported part, and then it's withdrawing itself from the prefab. However, the thingy somehow survived to tell the history on the GUI. Twice, as we can see. The double slider appears to be due the double TWEAKSCALEEXPOENTS , but frankly, the while shebang should had been deleted from the prefab by now.

Need some time to figure my way out of this.

The good news is that a new maintenance release for TweakScale is on the works to have this solved. The bad news is that EnginePlate, as any Part using MODULEVARIANTPART with Mass on the variants, is not supported and the patch will be withdrawn on startup. I'm sorry for this, but this part is one of the probably causes for the KSP crashes due improperly mangled mass.

Edited by Lisias
tasting my own medicine :)

Share this post


Link to post
Share on other sites
Posted (edited)

Screenshots:

https://yadi.sk/i/Eq4nm3kxYDotxQ

https://yadi.sk/i/xptH_iSw5ktRhg

https://yadi.sk/i/jcOpJt-HoxPmow

My question is, why did this happen? 
Why the smaller engine makes bigger jet stream? 
Played on 4 different versions of the game with different versions of the mod, every time there is a graphic illogical nonsense. 
Is it possible to fix this graphical issue?
As for me, this is the main reason why I want to abandon your beautiful mod. But I use it.

Translated with the help of translator (rus -> en).

 

Edited by KOCMOHABT
my mistakes

Share this post


Link to post
Share on other sites

Hey guys, so I've had a couple of people ask me to make a mod that I'm working on TweakScale compatible. So I went ahead and wrote up a Module Manager patch, but I can't get it to work. I've asked a few other modders and they can't quite seem to be able to find what's going wrong. I know Tweakscale works because I added a module into the part cfg to test it out. If someone could help me out that'd be great!

Here's the code that I've written up

@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]
{
	%MODULE[TweakScale]
	{
		type = stack
		defaultScale = 3.75
	}
}

 

Share this post


Link to post
Share on other sites

I'm pretty sure that if you're adding a module you do not need the % in front of it

Share this post


Link to post
Share on other sites
8 minutes ago, linuxgurugamer said:

I'm pretty sure that if you're adding a module you do not need the % in front of it

Removed the % and it didn't change anything

Would it be helpful if i shared a github link?

Share this post


Link to post
Share on other sites
Posted (edited)
3 minutes ago, DylanSemrau said:

Removed the % and it didn't change anything

Would it be helpful if i shared a github link?

Being able to see everything is always helpful

Not sure if you know about these links:

https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook

https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax

 

Edited by linuxgurugamer

Share this post


Link to post
Share on other sites
Posted (edited)
8 hours ago, KOCMOHABT said:

My question is, why did this happen? 
Why the smaller engine makes bigger jet stream? 

Nice catch. I totally missed this feature, the effects are being scaled backwards! :P 

It's consistent, I tested with NERV as you, but also with Reliant and with Terrier. The glitch is less visible on some engines, but it's clearly there!

I can't give you a deadline to have this fixed, as I have some more pressuring issues to solve (as to support stock parts at all). But I will tackle this down as soon as I get rid of that pressuring thingies.

https://github.com/net-lisias-ksp/TweakScale/issues/27

 

Edited by Lisias
uh… some really bad grammars. X-(

Share this post


Link to post
Share on other sites

This is what I think you need:

@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]
{
	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 3.75
	}
}

 

Share this post


Link to post
Share on other sites
16 minutes ago, DylanSemrau said:

Hey guys, so I've had a couple of people ask me to make a mod that I'm working on TweakScale compatible. So I went ahead and wrote up a Module Manager patch, but I can't get it to work. I've asked a few other modders and they can't quite seem to be able to find what's going wrong. I know Tweakscale works because I added a module into the part cfg to test it out. If someone could help me out that'd be great!

Here's the code that I've written up


@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]
{
	%MODULE[TweakScale]
	{
		type = stack
		defaultScale = 3.75
	}
}

 

Are you using a MODULEVARIANTPART with mass? Please publish your KSP.log so I can give a peek!

Share this post


Link to post
Share on other sites

Testing @linuxgurugamer's patch.

It didn't work.

This is my edited copy of the tweakscale compatibility cfg:


@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]
{
	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 3.75
	}
}

@PART[engine] // First Stage Engine Cluster
{
	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 3.75
	}
}

 

Share this post


Link to post
Share on other sites
Posted (edited)
14 minutes ago, Barzon Kerman said:

Testing @linuxgurugamer's patch.

MM is not applying your patches. :(

acmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance"

Provenance Aerospace
[LOG 19:27:54.280] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal
[LOG 19:27:54.401] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture
[LOG 19:27:54.494] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal
[LOG 19:27:54.571] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture
[LOG 19:28:29.814] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model
[LOG 19:28:33.852] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model
[LOG 19:28:56.347] Config(@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]
[LOG 19:28:56.347] Config(@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale]
[LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster
[LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank
Added   : Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale.cfg
Added   : Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster.cfg
Added   : Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank.cfg
  ProvenanceAerospace
[LOG 19:29:05.221] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass
[LOG 19:29:05.221] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass
[LOG 19:29:05.221] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass
[LOG 19:29:05.222] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART
[LOG 19:29:05.223] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART
[LOG 19:29:05.675] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster'
[LOG 19:29:05.839] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' has no database record. Creating.
[LOG 19:29:05.972] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank'
[LOG 19:29:05.988] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' has no database record. Creating.

Look how it applies the PartInfo patch, but remains silent about TweakScale.

(I'm testing the HEAD from the repository you pinpointed).

— — — — — POST EDIT — — — — — 

Are you sure you named the part correctly on the patch? I'm not finding a part with that name on the GameData… 

macmini:Provenance Aerospace lisias$ find . -name "*.cfg" -exec grep "First_Stage_Fuel_Tank" {} \;

@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]

The command above should had returned at least a second occurrence of the "First_Stage_Fuel_Tank" string from the basket of cfg files that it's GameData!

 

— — — — POST POST EDIT — — — — 

HERE. :) You forgot to put "_" on the partname. :)

PART
{
        name = First Stage Fuel Tank

 

Edited by Lisias
post edit

Share this post


Link to post
Share on other sites
2 minutes ago, Lisias said:

MM is not applying your patches. :(


acmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance"

Provenance Aerospace
[LOG 19:27:54.280] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal
[LOG 19:27:54.401] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture
[LOG 19:27:54.494] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal
[LOG 19:27:54.571] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture
[LOG 19:28:29.814] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model
[LOG 19:28:33.852] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model
[LOG 19:28:56.347] Config(@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]
[LOG 19:28:56.347] Config(@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale]
[LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster
[LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank
Added   : Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale.cfg
Added   : Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster.cfg
Added   : Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank.cfg
  ProvenanceAerospace
[LOG 19:29:05.221] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass
[LOG 19:29:05.221] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass
[LOG 19:29:05.221] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass
[LOG 19:29:05.222] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART
[LOG 19:29:05.223] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART
[LOG 19:29:05.675] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster'
[LOG 19:29:05.839] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' has no database record. Creating.
[LOG 19:29:05.972] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank'
[LOG 19:29:05.988] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' has no database record. Creating.

Look how it applies the PartInfo patch, but remains silent about TweakScale.

(I'm testing the HEAD from the repository you pinpointed).

So does this give any indication to what the issue might be?

Share this post


Link to post
Share on other sites
2 minutes ago, DylanSemrau said:

So does this give any indication to what the issue might be?

We posted at the same time! :) Check the name of the part on the CFG file, you forgot the "_" there.

Share this post


Link to post
Share on other sites
4 minutes ago, Lisias said:

We posted at the same time! :) Check the name of the part on the CFG file, you forgot the "_" there.

Well now the part doesn't even show up in ksp anymore :/ 

It's the same name as the folder the cfg is in so I'm not sure why there's an issue there

Share this post


Link to post
Share on other sites
Posted (edited)

Does this look any better:


@PART[First Stage Fuel Tank]:NEEDS[TweakScale]
{
	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 3.75
	}
}

@PART[engine] // First Stage Engine Cluster
{
	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 3.75
	}
}

I've been adding the changes talked about here.

Edited by Barzon Kerman

Share this post


Link to post
Share on other sites
27 minutes ago, DylanSemrau said:

Well now the part doesn't even show up in ksp anymore :/ 

It's the same name as the folder the cfg is in so I'm not sure why there's an issue there

Humm… Unexpected. Well, there must be a reason for the stock parts names not using "_'. So I edited your CFG files and got rid of "_" and " ", ie, named the parts as FirstStageEngineCluster and FirstStageFuelTank  on all configs/patches.

That made some difference:

macmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance"

Provenance Aerospace
[LOG 20:27:27.931] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal
[LOG 20:27:28.070] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture
[LOG 20:27:28.229] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal
[LOG 20:27:28.321] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture
[LOG 20:28:03.507] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model
[LOG 20:28:07.625] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model
[LOG 20:28:29.208] Config(@PART[FirstStageFuelTank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale]
[LOG 20:28:29.208] Config(@PART[FirstStageEngineCluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageEngineCluster]:NEEDS[TweakScale]
[LOG 20:28:29.208] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster
[LOG 20:28:29.208] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank
  ProvenanceAerospace
[LOG 20:28:29.940] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART
[LOG 20:28:29.940] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageEngineCluster]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART
[LOG 20:28:37.626] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass
[LOG 20:28:37.626] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass
[LOG 20:28:37.626] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass
[LOG 20:28:37.627] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART
[LOG 20:28:37.627] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART
[LOG 20:28:38.069] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster'
[LOG 20:28:38.216] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster' has no database record. Creating.
[LOG 20:28:38.323] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank'
[LOG 20:28:38.335] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' has no database record. Creating.


But… TweakScale is not being applied yet. =/ Well, I have some ideas, I will be back to this post soon.

Share this post


Link to post
Share on other sites
Posted (edited)
On 2/18/2019 at 2:36 PM, Tonka Crash said:

I thought about including this above, but skipped it as it's really a different discussion. I ran into a patch ordering problem with Simple Fuel Switch a couple weeks ago and learned all about patch order directives. TweakScale would have to use :FOR[TweakScale] on every one of it's patches to allow the :BEFORE or :AFTER directives to function as intended.

Tonka, I found some docs on MM about exactly this, and the problem is… Damn, @DylanSemrau's patches should be working by now:

Quote

The stuff within the needs section is based on either:

  • A plugin .dll with the same assembly name.
  • A subdirectory name under GameData. (Names with spaces can be used, just remove the spaces: GameData/My Mod/ => :NEEDS[MyMod]
  • A FOR[Blah] defined would allow NEEDS[Blah]

Source: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax

TweakScale fails the first criteria, as the DLL is named "Scale.dll". But it should had been caught by the second criteria, as the there is a directory called "TweakScale" on the GameData.

On the bright side, I will apply the FOR clausule on TweakScale this weekend, and then release (another) minor revision with the latests fixes until the moment.

I think we finally are nailing why things are getting hairy with TweakScale lately. I wanna to dig in some code, however, before telling anything more about the issue.

— — — POST EDIT — — — 

Boy, this is going to be a hell of a weekend! :D 

Near 1900 patches to apply that !#$#@$@#%@$% FOR. :P 

macmini:patches lisias$ find   -name "*.cfg" -exec grep -H "@PART" {} \; | wc -l
1892

If I understood correctly, TweakScale is being caught by the "LegacyPassSpecifier" , that always returns "true" on the check. In order to be correctly ordered on the :AFTER , :BEFORE and (I'm not sure yet) :NEEDS , I need to apply that :FOR stunt on everything that "it's mine". 

Edited by Lisias
post edit

Share this post


Link to post
Share on other sites
Posted (edited)

With lots of little changes, I actually got Tweakscale working on the tank.

Nevermind. now its not working at all.

Edited by Barzon Kerman

Share this post


Link to post
Share on other sites
1 hour ago, Lisias said:

Nice catch. I totally missed this feature, the effects are being scaled backwards! :P 

It's consistent, I tested with NERV as you, but also with Reliant and with Terrier. The glitch is less visible on some engines, but it's clearly there!

I can't give you a deadline to have this fixed, as I have some more pressuring issues to solve (as to support stock parts at all). But I will tackle this down as soon as I get rid of that pressuring thingies.

https://github.com/net-lisias-ksp/TweakScale/issues/27

 

Screenshot: https://yadi.sk/i/u5T6Utj5WPcohg

I think that this is wrong too. The width of the trace of such particles, though changing, but the length remains unchanged.

     1) It is illogical.

     2)It looks terrible.

Share this post


Link to post
Share on other sites
Posted (edited)
32 minutes ago, Barzon Kerman said:

With lots of little changes, I actually got Tweakscale working on the tank.

Nevermind. now its not working at all.

Interesting. Now, using names without "_" neither " " I managed to make MM apply the TweakScale patch:

macmini:1.6.1 lisias$ cat KSP.log | grep -i "FirstStageFuelTank"
[LOG 21:03:06.688] Config(@PART[FirstStageFuelTank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale]
[LOG 21:03:06.688] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank
[LOG 21:03:07.529] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART
[LOG 21:03:16.354] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank'
[WRN 21:03:16.358] [ShipConstruct for FirstStageFuelTank]: part cost (6400.0) is less than the cost of its resources (21103.2)
[LOG 21:03:16.369] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' has no database record. Creating.
[LOG 21:03:16.370] DragCubeSystem: Creating drag cubes for part 'FirstStageFuelTank'

However, the scaling slider is not being shown on the part's menu yet. So, yeah, we have TWO cascading errors! :0.0:

(sigh).

I just checked the MM cache, and the TweakScale MODULE section is there as expected.

Now I'm trying to nail down this second problem. It's like TweakScale withdrawing support for parts (i.e., deleting the MODULE section for TweakScale from the prefab by code), but this part is not eligible for the withdrawn I had coded (and I do not do things without logging, and there's no log on the KSP.log for this part, while there're some for some others).

I will compile a special DLL of TweakScale to further investigate this issue, @DylanSemrau . The first step is to, indeed, get rid of "_" and " " on the part names. This fixed a problem, as now the logs are showing TweakScale patches being applied to your parts. What we are facing now is another issue.

Edited by Lisias
some comments added

Share this post


Link to post
Share on other sites
Posted (edited)
13 hours ago, DylanSemrau said:

@LisiasOh boy this is interesting. Thanks for helping out man, I appreciate it :) 

Well.. That's what I have to the moment:

  • By removing "_" and " " from the part name (both on the config, and from the patch), I managed to make MM to apply the TweakScale patches. Evidence on the spoiler below.
  • But the damn thing still doesn't works as expected. TweakScale is on the prefab at loading, but no slider are being shown and once you save a .craft with these parts, no TweakScale section is present on them. So, it's like the patches were not applied (but they were, the MM cache below confirms that).

Until the moment, I have three theories:

  1. something on TweakScale is withdrawing silently the support for these two parts. Unlikely, but not impossible - there's some code there that I didn't proper reviewed yet.
  2. something else is doing that post dorsum .
  3. something somewhere else is preventing that specific module to be loaded from the prefab once the part is instantiated on the editor.

I will pursue the 1st thesis by Sunday - tomorrow (Saturday) my block will be have the power cut for power lines maintenance and I don't have the slightest clue about how much time I will be offline.

The 2nd and 3rd thesis will be a hairy and dirty job of guessing and trying in the hope to hit something. :( I think there're one "easy" test that you can do in the mean time. Since getting rid of spaces (and '_') solved the previous issue, perhaps it can solve this one too. How about getting rid of all spaces on the file and directory names? I tried to do that myself, but some filenames are hardcoded somewhere and things just don't work by brute-forcing my way on it.

I will call it a day now. I'm up since early morning, time to get some sleep. :) 

Spoiler

UrlConfig
{
	name = FirstStageEngineCluster
	type = PART
	parentUrl = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster
	PART
	{
		name = FirstStageEngineCluster
		module = Part
		author = Dylan Semrau
		rescaleFactor = 1.0
		node_stack_top = 0.0, 2.01521, 0.0, 0.0, 1.0, 0.0, 2
		node_stack_bottom = 0.0, -2.97, 0.0, 0.0, -1.0, 0.0, 2
		node_attach = 0.0, 1.08738, 0.0, 0.0, 1.0, 0.0, 2
		attachRules = 1,1,1,1,0
		fx_exhaustFlame_blue = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running
		fx_exhaustLight_blue = 0.0, -2.2, 0.0, 0.0, 0.0, 1.0, running
		fx_smokeTrail_light = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running
		fx_exhaustSparks_flameout = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, flameout
		sound_vent_medium = engage
		sound_rocket_hard = running
		sound_vent_soft = disengage
		sound_explosion_low = flameout
		TechRequired = heavierRocketry
		entryCost = 9200
		cost = 2300
		category = Engine
		subcategory = 0
		title = BE-4 Engine Cluster
		manufacturer = Blue Origin
		description = None
		mass = 8.5
		dragModelType = default
		maximum_drag = 0.2
		minimum_drag = 0.3
		angularDrag = 2
		crashTolerance = 7
		breakingForce = 150
		breakingTorque = 150
		maxTemp = 2000
		fuelCrossFeed = True
		bulkheadProfiles = size1, srf
		tags = new glenn first stage be-4 provenance aerospace
		MODEL
		{
			model = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model
		}
		MODULE
		{
			name = ModuleEngines
			thrustVectorTransformName = thrustTransform
			exhaustDamage = True
			ignitionThreshold = 0.1
			minThrust = 0
			maxThrust = 4500
			heatProduction = 175
			fxOffset = 0, 0, 0.1
			EngineType = LiquidFuel
			exhaustDamageDistanceOffset = 0.35
			PROPELLANT
			{
				name = LiquidFuel
				ratio = 0.9
				DrawGauge = True
			}
			PROPELLANT
			{
				name = Oxidizer
				ratio = 1.1
			}
			atmosphereCurve
			{
				key = 0 330
				key = 1 265
				key = 9 0.001
			}
		}
		MODULE
		{
			name = ModuleGimbal
			gimbalTransformName = thrustTransform
			gimbalRange = 5
		}
		MODULE
		{
			name = ModuleSurfaceFX
			thrustProviderModuleIndex = 0
			fxMax = 0.8
			maxDistance = 50
			falloff = 2
			thrustTransformName = thrustTransform
		}
		MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
		MODULE
		{
			name = ModulePartInfo
		}
	}
}

 

 

Edited by Lisias
really need some sleep! =P

Share this post


Link to post
Share on other sites
3 minutes ago, Lisias said:

Well.. That's what I have to the moment:

  • By removing "_" and " " from the part name (both on the config, and from the patch), I managed to make MM to apply the TweakScale patches. Evidence on the spoiler below.
  • But the damn thing still doesn't works as expected. TweakScale is on the prefab at loading, but no slider are being shown and once you save a .craft with these parts, no TweakScale section is present on them. So, it's like the patches were not applied (but they were, the MM cache below confirms that).

Until the moment, I have two theories:

  1. something on TweakScale is withdrawing silently the support for these two parts. Unlikely, but not impossible - there's some code there that I didn't proper reviewed yet.
  2. something somewhere else is preventing that specific module to be loaded from the prefab once the part is instantiated on the editor.

I will pursue the 1st thesis by sunday - tomorrow, saturday, my block will be have the power cut for power lines maintenance and I don't have the slightest clue about how much time I will be offline.

The 2nd thesis will be a hairy and dirty job of guessing and trying in the hope to hit something. :( I think there're one "easy" test that you can do in the mean time. Since getting rid of spaces (and '_') solved the previous issue, perhaps it can solve this one too. How about getting rid of all spaces on the file and directory names? I tried to do that myself, but some filenames are hardcoded somewhere and things just don't work by brute-forcing my way on it.

I will call it a day now. I'm up since early morning, time to get some sleep. :) 

  Reveal hidden contents


UrlConfig
{
	name = FirstStageEngineCluster
	type = PART
	parentUrl = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster
	PART
	{
		name = FirstStageEngineCluster
		module = Part
		author = Dylan Semrau
		rescaleFactor = 1.0
		node_stack_top = 0.0, 2.01521, 0.0, 0.0, 1.0, 0.0, 2
		node_stack_bottom = 0.0, -2.97, 0.0, 0.0, -1.0, 0.0, 2
		node_attach = 0.0, 1.08738, 0.0, 0.0, 1.0, 0.0, 2
		attachRules = 1,1,1,1,0
		fx_exhaustFlame_blue = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running
		fx_exhaustLight_blue = 0.0, -2.2, 0.0, 0.0, 0.0, 1.0, running
		fx_smokeTrail_light = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, running
		fx_exhaustSparks_flameout = 0.0, -2.2, 0.0, 0.0, 1.0, 0.0, flameout
		sound_vent_medium = engage
		sound_rocket_hard = running
		sound_vent_soft = disengage
		sound_explosion_low = flameout
		TechRequired = heavierRocketry
		entryCost = 9200
		cost = 2300
		category = Engine
		subcategory = 0
		title = BE-4 Engine Cluster
		manufacturer = Blue Origin
		description = None
		mass = 8.5
		dragModelType = default
		maximum_drag = 0.2
		minimum_drag = 0.3
		angularDrag = 2
		crashTolerance = 7
		breakingForce = 150
		breakingTorque = 150
		maxTemp = 2000
		fuelCrossFeed = True
		bulkheadProfiles = size1, srf
		tags = new glenn first stage be-4 provenance aerospace
		MODEL
		{
			model = Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model
		}
		MODULE
		{
			name = ModuleEngines
			thrustVectorTransformName = thrustTransform
			exhaustDamage = True
			ignitionThreshold = 0.1
			minThrust = 0
			maxThrust = 4500
			heatProduction = 175
			fxOffset = 0, 0, 0.1
			EngineType = LiquidFuel
			exhaustDamageDistanceOffset = 0.35
			PROPELLANT
			{
				name = LiquidFuel
				ratio = 0.9
				DrawGauge = True
			}
			PROPELLANT
			{
				name = Oxidizer
				ratio = 1.1
			}
			atmosphereCurve
			{
				key = 0 330
				key = 1 265
				key = 9 0.001
			}
		}
		MODULE
		{
			name = ModuleGimbal
			gimbalTransformName = thrustTransform
			gimbalRange = 5
		}
		MODULE
		{
			name = ModuleSurfaceFX
			thrustProviderModuleIndex = 0
			fxMax = 0.8
			maxDistance = 50
			falloff = 2
			thrustTransformName = thrustTransform
		}
		MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
		MODULE
		{
			name = ModulePartInfo
		}
	}
}

 

 

Okay cool, thanks again! Hopefully one of your theories are correct and the issue can be resolved :) 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.