Jump to content

[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921

Lisias

By Lisias
in KSP1 Mod Releases

 Share

Recommended Posts

Lisias

Lisias

Posted
Posted (edited)

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 (well, not everything... :) )

In a Hurry:

  • Help Wanted!
  • Current Release:  2.4.8.6 for KSP >= 1.3 (2024-0921)
  • TweakScale Companion Program
    • Third Party support is being implemented into Companions, and all legacy patches are going End Of Life on TweakScale 2.4.4.
      • Most of them are unusable anyway
    • Check the TweakScale Companion Program's Thread for more information. New Companions are being released on a regular basis.
  • Relevant Notes
    • Kraken Food (unholy interactions between Add'Ons) is detected on startup, and a proper (and scary) Warning is shown when appropriated. Pay attention to that message, and reach me here for help!
      • Overrules and HotFixes can be issued to workaround the problems if needed. See this post.
      • A PhD thesis about the current problems can be found on this post.
      • An article about how new patches will be handled is here.
    • For users of Infernal Robotics:
Spoiler

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 eternal 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. :) Open the spoiler for instructions about how to get support:

Spoiler

Please provide:

  • 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.
    • The Player.log changed location:
      • On MacOS
        • For KSP < 1.8, they are on ~/Library/Logs/Unity
        • On KSP >=1.8, you will find the Player.log on ~/Library/Logs/Squad/KSP/
      • On Windows
        • On KSP >=1.8, you will find the Player.log on C:\Users\<USERNAME>\AppData\LocalLow\Squad\KSP\
      • On Linux
        • On KSP >=1.8, you will find the Player.log on ~/.config/unity3d/Squad/KSP/
    • Publish the files on DropBox, Google Drive or similar, and post the link so we can inspect it.
      • DO NOT paste the log on Forum, this causes a lot of problems and it's useless, as Forum also truncate the file
        • It's ok to paste small excerpts to pinpoint something, but we still need the full KSP.log and Player.log in order to help you/
      • Do not use pastebin, gist or similars. They have a pretty small cap on the file size, and will truncate the log rendering yet more useless
    • Imgur is a good choice for publishing screenshots when needed.

Be sure to quit KSP before copyong the KSP.log, otherwise we risk losing information due the internal file buffers (technical thingy, it's a way to make writing files faster by consolidating lots of small writes into a big one).

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 pinpointing there to be sure to get my attention.

Thank you.

Scale Safe! :sticktongue:

Edited by Lisias
2.4.8.6 is on the wild. All your Distributions Channels are belong to us.
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted

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. :) 

Link to comment
Share on other sites
GDJ

GDJ

Posted
Posted
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.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
GDJ

GDJ

Posted
Posted
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).

Link to comment
Share on other sites
FreeThinker

FreeThinker

Posted
Posted (edited)
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
Link to comment
Share on other sites
pellinor

pellinor

Posted
Posted
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.

Link to comment
Share on other sites
FreeThinker

FreeThinker

Posted
Posted
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

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)

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.
Link to comment
Share on other sites
pellinor

pellinor

Posted
Posted
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?

Link to comment
Share on other sites
FreeThinker

FreeThinker

Posted
Posted
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.

Link to comment
Share on other sites
pellinor

pellinor

Posted
Posted
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.

Link to comment
Share on other sites
FreeThinker

FreeThinker

Posted
Posted (edited)
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
Link to comment
Share on other sites
Trollsama

Trollsama

Posted
Posted

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. 
 

Link to comment
Share on other sites
FreeThinker

FreeThinker

Posted
Posted (edited)
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
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
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
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
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...

Link to comment
Share on other sites
pellinor

pellinor

Posted
Posted (edited)

 

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
Link to comment
Share on other sites
pellinor

pellinor

Posted
Posted
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.

Link to comment
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.

×
 Share
Go to topic listing
×
×
  • Create New...