Lisias

[1.4.1+;1.5.1] TweakScale - Under New Management. 2018-1127

Recommended Posts

As from 2018-1016 and under @pellinor agreement, I'm the New Management for TweakScale. From now on, it's all officially my fault! :D 

In a Hurry:

Description:

TweakScale lets you change the size of a part. Not just that, but it will figure out how much fuel is in the resized part. And if it's an engine, it will become more powerful by scaling it bigger, or weaker by scaling it smaller.

(Pictures are work in progress! :) )

Credits:

Contributions From:

And future new features/bugs/mishaps from yours truly.

Support:

I need help in order to proper help you. :) So I ask that on asking for support:

  • A concise, textual description of the problem
    • Mentioning the KSP version and the TweakScale version involved
  • A screenshot of the problem
  • When applicable, the .craft file with a vessel that have the problem
  • When asked, the KSP.log and output_txt log from Unity.
    • See this article for instructions.

Using the Issue Tracker is highly encouraged, as GitHub provides services that make everything above easier. You can open an issue there, and call me here pinpoint there to be sure to get my attention.

Thank you.

Edited by Lisias
Support instructions
  • Like 11

Share this post


Link to post
Share on other sites

First Post! (ok, it's unfair) :P 

In the next few days, a proper TweakScale release will be issued. The current "unofficial" of mine, by being… unofficial… , it's full of crazy ideas that still need to be proven. Eventually some of them will be merged into the 'mainstream', but until there, I'll keep the official releases the more orthodoxically as possible.

Welcome aboard. Fasten your seat belts and sit tight. :) 

  • Like 1

Share this post


Link to post
Share on other sites

Congrats and good luck! Don't go too crazy...Tweakscale is awesome because "it just works". 

  • Like 2

Share this post


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

 From now on, it's all officially my fault! :D 

Oh you poor bugger! I wish you well.....

  • Like 2

Share this post


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

Oh you poor bugger! I wish you well.....

You also have the feeling that pellinor is way too happy? :D 

Share this post


Link to post
Share on other sites
Just now, Lisias said:

You also have the feeling that pellinor is way too happy? :D 

Oh maybe. Maybe not. Depends on how much maintenance Tweakscale needs. I'm guessing not a huge amount.

Share this post


Link to post
Share on other sites
1 minute ago, GDJ said:

Oh maybe. Maybe not. Depends on how much maintenance Tweakscale needs. I'm guessing not a huge amount.

There're new attributes on KSP 1.5 (on the gears, for example) that will need to be handled or stuff will be blown into orbit against your will.

I think (but I still need to correctly study the problem) that some issues on 1.4 are due the same. The first step, probably, is to read cautiously every KSP's Change Log from 1.3.1 to 1.5.

  • Like 1

Share this post


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

There're new attributes on KSP 1.5 (on the gears, for example) that will need to be handled or stuff will be blown into orbit against your will.

I think (but I still need to correctly study the problem) that some issues on 1.4 are due the same. The first step, probably, is to read cautiously every KSP's Change Log from 1.3.1 to 1.5.

The only think I can add to the fix pile (sorry about this) is the strength of the parts when they are "blown up" to around 180% of original size or more. The mass increases predictably, but I find that certain parts can get destroyed easily or they peel off the craft under their own mass (ie wings). It gets worse if there is fuel in the mix (even more mass).

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, JedTech said:

Congrats and good luck! Don't go too crazy...Tweakscale is awesome because "it just works". 

"What could possible go wrong?" :) 

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, Lisias said:

"What could possible go wrong?" :) 

When comes to coding ? Answer is simple - "everything" can go wrong. It is just a metter of timing, when it will go wrong at some point :unsure:

Share this post


Link to post
Share on other sites
15 hours ago, Lisias said:

First Post! (ok, it's unfair) :P 

In the next few days, a proper TweakScale release will be issued. The current "unofficial" of mine, by being… unofficial… , it's full of crazy ideas that still need to be proven. Eventually some of them will be merged into the 'mainstream', but until there, I'll keep the official releases the more orthodoxically as possible.

Welcome aboard. Fasten your seat belts and sit tight. :) 

Good to hear Tweakscale is in good hands. For a time I considered taking over myself as I had several ideas to improve it. but my hands are already more than full

But about ideas, I have several:

A: One thing that always annoyed in Tweakscale me is the tech unlocking. You can unlock a specific tweakscale size only by a single tech. Instead, I propose it will also be the combination of the part unlocking tech and the specific size unlocking. That way I can unlock fuel tank with a fuel tech but only allow a bigger tweakscale sizes after unlocking colossalRocketry.

B: Another big limitation of tweakscale is that is by default only always only one method of define is scaling growth which is a single exponent. Although this works reasonably well for scaling up, when scaling down it often resulted in ridiculous numbers. Therefore instead, I would like the ability to use float curves that allow we to define exactly how parameters should grow or shrink.

Edited by FreeThinker
  • Like 1

Share this post


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

A: One thing that always annoyed in Tweakscale me is the tech unlocking. You can unlock a specific tweakscale size only by a single tech. Instead, I propose it will also be the combination of the part unlocking tech and the specific size unlocking. That way I can unlock fuel tank with a fuel tech but only allow a bigger tweakscale sizes after unlocking colossalRocketry. 

This is possible today by putting the "TechRequired" field in the part-specific config, which overrides the one on the scaletype. Yes, doing this for hundreds of parts is probably not the most elegant solution. And there is currently no transparency in-game when things will unlock.

Share this post


Link to post
Share on other sites
12 minutes ago, pellinor said:

This is possible today by putting the "TechRequired" field in the part-specific config, which overrides the one on the scaletype. Yes, doing this for hundreds of parts is probably not the most elegant solution. And there is currently no transparency in-game when things will unlock.

I don't think I was clear enough. I mend that a part cannot be tweakscaled to a specific after both the Tweakscale TechRequired and part TechRequired are BOTH unlocked. Currently the Tweakscale  TechRequired overrides the part TechRequired

Share this post


Link to post
Share on other sites

Just to clarify some things:

There're TWO development branches on the repository: the orthodox and the heterodox. All bug fixes and "safe" development are done on the orthodox, and this branch is the only one that can be promoted to master now and then.

The heterodox branch is where we can play with nitroglycerine without killing the neighbours. We can discuss and even implement some ideas on there just to see what happens - the worst it can happens is to ditch the code. This branch will be never merged back to the orthodox one. If the event an idea proves valid and worths the potential migraine of becoming mainstream, the changes will be cherry-picked and eyeballed prior being committed into the production safe branch.

On the other hand, every change on the orthodox is merged to heterodox, so it keeps synchronized with the status quo. This broke something on heterodox? Too bad: fix it or ditch it. I didn't mentioned Dante's Inferno just because. :D 

So… Yeah.We can go wild on new ideas and even try an implementation on the heterodox branch without opening the gates of hell into us.

Note to myself: Implement a very scary warning to be issued every time you enter Space Center on the heterodox branch.

Edited by Lisias
tyops, as usulla.
  • Like 4

Share this post


Link to post
Share on other sites
2 hours ago, FreeThinker said:

I don't think I was clear enough. I mend that a part cannot be tweakscaled to a specific after both the Tweakscale TechRequired and part TechRequired are BOTH unlocked. Currently the Tweakscale  TechRequired overrides the part TechRequired

Ok then I was not clear enough. Most TweakScale config values can appear in two places: the scaletype or the part module. The code will first look in the config of the part module, any values found there will win over those in the scaletype (I'm talking about this part of the code). So if you put something like "techRequired = tech1,tech2,tech3" in the TweakScale module of a specific part, the requirements should only apply to the scaleFactors of that specific part. So my statement is that the current interface allows to specify a separate tech for any scale of any part, which is the finest granularity possible.

Or maybe the missing piece is that techRequired is not a single value but a list, mapping a tech to every scaleFactor?

Share this post


Link to post
Share on other sites
9 minutes ago, pellinor said:

. So if you put something like "techRequired = tech1,tech2,tech3" in the TweakScale module of a specific part, the requirements should only apply to the scaleFactors of that specific part. So my statement is that the current interface allows to specify a separate tech for any scale of any part, which is the finest granularity possible.

Yes I know, but its not a lack of granularity , but a lack ability to combine. Let me illustrate with a little example

PART
{
	name = AdvancedFuelTank
	module = Part

	TechRequired = specializedFuelStorage


	MODULE
	{
		name = TweakScale
		type = stack
		defaultScale = 2.5
		scaleFactors =  0.625 1.25, 2.5
		techRequired = heavyRocketry,heavierRocketry, veryHeavyRocketry
	}

}

 

Now currently the AdvancedFuelTank will get unlocked  with heavyRocketry, what I want is that you require BOTH at least specializedFuelStorage and heavyRocketry to use this fuel tank.

Share this post


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

Now currently the AdvancedFuelTank will get unlocked  with heavyRocketry, what I want is that you require BOTH at least specializedFuelStorage and heavyRocketry to use this fuel tank. 

Now I understand. So if no scale is allowed the current behavior is probably to allow the defaultScale. This looks like a workaround because once the partModule comes to life it is too late to hide the part. Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful.

  • Like 1

Share this post


Link to post
Share on other sites
10 minutes ago, pellinor said:

Now I understand. So if no scale is allowed the current behavior is probably to allow the defaultScale. This looks like a workaround because once the partModule comes to life it is too late to hide the part. Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful.

Yes, that would be even better. It would allow use to balance tweakscale much better. Tweakscale is often shunned because it gives access to higher sizes too fast, well with the discussed improvement we can balanc it better by using the higher technodes like veryHeavyRocketry, giganticRocketry and colossalRocketry, which is now not used

Edited by FreeThinker
  • Like 1

Share this post


Link to post
Share on other sites

So Random question, The mod is posted on CKAN as well.  Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. 
I ask because I tend to check for updates out of CKAN and not the forums themselves. (i found out about new management out of fluke TBH lol) unless the mod in question isnt listed on CKAN in the first place. 
 

Share this post


Link to post
Share on other sites
5 hours ago, Trollsama said:

So Random question, The mod is posted on CKAN as well.  Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. 
I ask because I tend to check for updates out of CKAN and not the forums themselves. (i found out about new management out of fluke TBH lol) unless the mod in question isnt listed on CKAN in the first place. 
 

Well that sound be to hard. Its just a matter of changing the download reference to the new spacedock location where the new releases are hosted

Edited by FreeThinker

Share this post


Link to post
Share on other sites
8 hours ago, Trollsama said:

 Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. 

I'm not an enthusiastic user of CKAN, mainly because the Mono defaults are a mess on Linux and Mac, and I'm a heavy user of these OS'es. I was also bitten heavily when a bunch of mods were automatically updated, but one of them caused undesired behaviour and it took me an awful amount of time to figure out what happened. Doing things by hand revealed to be a better solution for me, with me relying on KSP-AVC to keep me informed about updates.

That said, I will not drop CKAN support on Releases, but pre-releases (the present state) and experimental will not be CKAN'd (neither published on SpaceDock and Curseforge) for obvious reasons. 

Edited by Lisias

Share this post


Link to post
Share on other sites
13 hours ago, pellinor said:

Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful.

Meddling with Module Manager and Hide Empty Tech Nodes, I understand how they handle customized Tech Trees. On the fly, in the case of HETN.

The same technique appears to be applicable on parts list - obviously, this info is to be confirmed.

However...  There're risks on such endeavor. I found that it's currently common practice to "hijack" the TechTree unconditionally, what ends up in a race condition where the TechTree currently in use is determined by the not necessarily deterministic order in which such "hijacks" happen. I'm foreseeing the same happening here. 

I think we will need an Arbitrator for customs Parts List. I think we already need one for TechTrees...

Share this post


Link to post
Share on other sites

 

6 hours ago, Lisias said:
12 hours ago, mattinoz said:

Is there a more advanced version of Tweakscale that allows scaling independently in one direction?

Almost a purely aesthetic thing that parts that transition between to sizes often feels to short blend nicely with the next part.

Curiously, I thought on something like that recently. But I consider this to be "tricky" to implement as it would break an (programming) interface that are in use for years. OK, there're techniques to make things coexist, but we need to balance cost and benefits of such a feature.

The "easier" changes on the programming interface would render the user interface less intuitive, and vice versa.

(quoting this from the old TweakScale thread)

The scaling part is quite simple and has been done before (for example the DIY Kits in GC). Some other questions are

* Many parts in TweakScale assume the scaling has one degree of freedom, for example the config interface (scaleFactors, exponents, techRequired), the API for other mods. Is it clear how they should behave once a part can be scaled with two or three degrees of freedom? What additional config possibilities does this need?

* Will the resulting config interface still be usable for the average modder?

* How many parts benefit from non-isotropic scaling? This is the main point why I haven't done this yet. Most models just look bad when stretched.

Edit: for simple cases like visually stretching an adapter, it could also be a separate part module that lacks all the interaction with other part modules.

Edited by pellinor

Share this post


Link to post
Share on other sites
5 hours ago, Lisias said:

That said, I will not drop CKAN support on Releases, but pre-releases (the present state) and experimental will not be CKAN'd (neither published on SpaceDock and Curseforge) for obvious reasons. 

My experience is that CKAN hasn't caused trouble for TweakScale yet. It targets inexperienced users and should only see the stable releases.

I found it quite useful for the initial installation, but also prefer to update things manually and selectively.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now